Re: [Talk-ca] Building Import

2019-03-16 Thread Danny McDonald
After further consideration, I have decided to unsubscribe to this mailing
list, at least for the near future.  I will not be participating in further
discussion, but I don't plan to import any more buildings until you all
reach a consensus.

I have two reasons for this decision:
- I don't enjoy discussion, I don't think I make my points very well, and I
don't think I add to the tone of the discussion.  I'm on OSM to map, not to
discuss and argue about mapping.  @Rps333 (an Ottawa mapper) has it right
with his tagline "Map, Not Words".
- I have been deeply offended by the behaviour of Nate, who has refused to
apologize for a personal insult he made in a private email.  I don't feel
comfortable engaging in a discussion with him in it.

DannyMcD

P.S. Please do not send any emails to this account
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Saints in street names in Ontario

2019-03-15 Thread Danny McDonald
I agree with Jarek, St. should generally not be expanded for English
Canadian street names.  The proper spelling is St. (or St) even if the
pronunciation is Saint.  name:pronunciation (
https://wiki.openstreetmap.org/wiki/Key:name:pronunciation) is a tag that
can capture the pronunciation, if desired.

In Quebec, I believe it is different, and St often is expanded.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Building Import

2019-03-15 Thread Danny McDonald
OK, so this discussion has gone a bit off the rails.  In terms of the DWG,
this has all happened so fast - the referral to the DWG was less than 2
hours after the initial message, and was not in response to any actual
edits I made after receiving Pierre's stop message.

I suggest that we all stop emailing this list for the rest of the day,
given the high level of tension on both sides.  I will not be importing
anything for the next week (at the very least), and I don't think anyone
else will either.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] Building Import

2019-03-15 Thread Danny McDonald
By the way, I strongly object to the way Nate immediately went to the DWG,
instead of attempting to engage in discussion.

I think many people on this list fundamentally misunderstand the way OSM
operates.  Most OSM contributions are made by individuals who see a
gap/mistake in the data and fix it.  It is not a "community process" where
contributions are made by a group of "local mappers" (although this
sometimes happens).

The great strength of OSM (relative to Google Maps), is that you can make
edits immediately without going through a peer review process.  Some people
on this list seem to want to impose a peer review process on OSM (at least
for imports, for now), because they think they know better, and should be
given power because of it.

DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] Building Import

2019-03-15 Thread Danny McDonald
As previously noted, I will continue importing, unless I hear a specific
valid concern.  I will wait a week before re-starting, to allow time for
concerns to be raised.  To address some existing concerns:
- Making buildings orthogonal isn't an improvement, it is degrading correct
footprints for no good reason.
- I don't think mapping a large block of connected buildings as a single
building is incorrect.  It might be better to split large blocks of
buildings, but this is best done separately from the initial import.

As for local mappers, PierZen is a Quebec mapper, and Nate seems to map
almost exclusively around Cincinnati - I don't think either qualify as a
local mapper for Toronto or BC.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Microsoft has released its building outlines for Canada

2019-03-02 Thread Danny McDonald
Just looking at the data for some random areas, it looks like the quality
is comparable to hand-drawn buildings (but not as good as most municipal
data).  There are some weirdly rotated and sized buildings, as well as some
missing buildings, there may be other problems in areas I haven't examined.
A few comments:
- The StatsCan data is of better quality, it should be used instead of the
Microsoft data when possible.
- Existing hand-drawn/imported buildings should not be replaced by the
Microsoft data (except for CanVec buildings, maybe).
- In any import, the bigger provinces should be split into smaller areas
(counties or regions)
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-04 Thread Danny McDonald
In JOSM, open the preferences dialog (F12), go to the data validator tab,
and click the "show informational level" checkbox (it is third from the
top).  Any validation done will then check for "Building with an almost
square angle", which will appear under the Other tab.  "Building with an
almost square angle" used to cause a Warning, but it was downgraded to
Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
Danny

On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

> Danny,
> Do you mind sharing how to fix almost square angles in JOSM? I remember
> seeing such warning a year or two ago but for some reason I don't see it
> anymore and can't find it in the Validator settings.
> Did they remove it from the latest version of JOSM or you need to add this
> rule manually?
> If there is an easy way to do it then we should do it I guess.
>
> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:
>
>> I largely agree with Yaro, but will say
>> 1) It is possible to square almost square angles with JOSM - it has an
>> informational warning in validation, and automatically squares the angle by
>> slightly moving the offending node.  This fix doesn't ruin the geometry of
>> the building, as pressing Q so often does.  Unfortunately, it also leads to
>> other angles in the building not being square.
>> 3) I'm fine with importing smaller buildings as well (they don't seem to
>> be in the source data in Toronto, they are for some of the other data
>> sets).  I believe they were excluded because of their relatively low
>> importance/permanence.
>>
>> I would also like to know how the Toronto building footprints were
>> produced.  Does anyone know?
>> DannyMcD
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> Best Regards,
>   Yaro Shkvorets
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Some feedback on import quality in Toronto

2019-02-03 Thread Danny McDonald
I largely agree with Yaro, but will say
1) It is possible to square almost square angles with JOSM - it has an
informational warning in validation, and automatically squares the angle by
slightly moving the offending node.  This fix doesn't ruin the geometry of
the building, as pressing Q so often does.  Unfortunately, it also leads to
other angles in the building not being square.
3) I'm fine with importing smaller buildings as well (they don't seem to be
in the source data in Toronto, they are for some of the other data sets).
I believe they were excluded because of their relatively low
importance/permanence.

I would also like to know how the Toronto building footprints were
produced.  Does anyone know?
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Building Import update

2019-02-02 Thread Danny McDonald
On squaring buildings, no one has yet been explained why buildings should
be square.  My understanding is that non-square buildings are a warning
sign for mapathons with hand-traced buildings - the lack of squaring is
often noticeable for hand-traced buildings, and indicative of generally
poor building footprints. That doesn't apply here, since the buildings
involved are not hand-traced (at least in Toronto).  In fact, the imported
footprints are generally extremely accurate, much better than would (or
could) be done by hand.

It seems like the automated verification tool (of checking whether
buildings are square or not) is being misapplied in this case.

DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] OSM Canada building import

2019-01-26 Thread Danny McDonald
As I said before, I'd like to hear about specific problems that need to be
fixed,  For instance, the issues Nate raised before about large retail
buildings and buildings in buildings were helpful to know about, and I
believe I have fixed those issues in the areas I imported.  I have also
done "human" verification, and corrected a few imported buildings with
wonky footprints, as well as fixing churches and garages that were
improperly not tagged as buildings.

I don't think broad philosophical discussions are helpful to this
discussion - there has been all too much of that on this list (which is why
I have tried to not comment, until now)

P..S. James, could you upload the simplified data to data.osmcanada.ca ,
and point the tasking manager there?  That makes it easier to examine
snippets, and will need to be done anyway if we're using the simplified
data going forward.

DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Talk-ca Digest, Vol 131, Issue 48

2019-01-26 Thread Danny McDonald
1. In terms of validation, it would be helpful to have a clear idea of what
sorts of problems need to be fixed.  I have re-validated almost all of the
areas I imported (and all of them in Central Toronto), and fixed all of the
building related errors/warnings I found (with a few exceptions) there
weren't many errors, and many pre-dated the import.  The only JOSM warning
I didn't fix is "Crossing building/residential area".  Yaro's and John's
areas don't seem to have many errors either, although there a few isolated
"Crossing building/highway" warnings (and some "building duplicated nodes"
errors).  I have also split big retail buildings in dense areas.
2. I'm fine with simplification, I think we should just do it.  In terms of
orthogonalization, I don't understand why non-orthogonal buildings are a
problem.  If they are, JOSM allows them to be auto-fixed.
3. I agree that the task manager squares are too big in central Toronto.  A
separate task can be created for central Toronto only, with smaller
squares.  I think the square size is fine outside of Toronto, as long as
the squares are split appropriately.
4. In terms of conflation, I agree that deleting and re-adding buildings is
not desirable, but I don't agree that that means it should never be done,
no matter the time cost.  The ideal solution here is some sort of
script/plugin that auto-merges new and recently added buildings -
basically, an iterated "replace geometry".
DannyMcD

>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Talk-ca Digest, Vol 131, Issue 46

2019-01-26 Thread Danny McDonald
Personally, I'm eager to re-start importing, but I'd like to hear what Nate
has to offer.  Nate, are you OK with the wiki import process as written?
If not, are there specific things you want changed?  The current process is
the one Yaro followed, although John and I basically did the same thing (I
didn't always replace existing building footprints unless the geometry was
really bad).  It doesn't seem that the building data has been simplified,
although this should be an easy fix.

DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] Place Tagging

2019-01-24 Thread Danny McDonald
A place does not need to incorporated to be a place=town, city, village.
That is not how it works anywhere in OSM - there are many unincorporated
places with these tags, worldwide.  The tagging in Ottawa is a good guide,
with e.g. Richmond a village, but e.g. Centretown and Stittsville
place=suburbs, based on distinctness.
DannyMcD

On Thu, Jan 24, 2019, 1:53 PM OSM Volunteer stevea <
stevea...@softworkers.com wrote:

> On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> > My understanding of place tagging is that place=city, place=town, and
> place=village are for distinct urban settlements, whether or not they are
> separate municipalities.
>
> Correct, in that these tags can be placed upon a node, way or relation (if
> a boundary relation, a node with role admin_centre is correct).  Sometimes
> a way (often a closed polygon) is not precisely known, or is, but license
> restrictions prevent those data from entering OSM.  In that case, a simple
> node tagged place=* with appropriate value is used, as documented at
> https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful
> regarding "incorporated" areas; see below.
>
> > Place=suburb is for large parts of urban settlements (such as North York
> in Toronto, or Kanata in Ottawa).
>
> While I am not a political scientist, I did participate in the development
> of consensus in the United_States in
> https://wiki.osm.org/wiki/United_States_admin_level , a complex task
> indeed (and I'll say we only have it "largely correct," certainly not
> "exactly correct").  While Canada has similarities, it certainly is unique
> in admin_level, appropriately documented at
> https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept
> found in many countries, Canada included, is that of "incorporation" —
> whether an urban settlement is a "body corporate."  Cities always are,
> suburbs and towns, depending on differing context for each of these, may or
> may not be.
>
> > Whether to classify a place as a place=city/town/village or place=suburb
> depends on the facts on the ground (I.e. whether a place is part of a
> larger urban settlement), and not primarily on municipal/administrative
> boundaries.
>
> I can't speak for all of Canada, but I can speak to what OSM documents in
> our place=* wiki:  that urban and rural populated places are distinguished
> by two separate tables there, so it is useful to understand how OSM
> characterizes these as slightly different (with specific tags in each
> table).  This is regardless of how any particular country might use the
> same names.  For example, place=suburb has a very specific semantic as it
> is used in OSM, contrasted with how "real world" "suburb" might mean an
> incorporated (smaller) city near a (larger) city, OR it might mean a
> district/area/small region INSIDE of an incorporated city (how OSM means
> it).  We must be careful to tag in OSM with how OSM means things, mapping
> our "real world" semantics onto OSM semantics.
>
> > Municipal boundaries might be somewhat relevant in determining if a
> place is distinct (e.g. Vaughan is a city, not a suburb), but they are a
> relatively minor factor.
>
> I don't know what this means exactly.  Municipal boundaries ARE EXACTLY
> relevant in determining if a place is distinct:  they literally distinguish
> it.  In "real world speak" Vaughn might be called a suburb, but unless it
> meets OSM's place=suburb definition, it shouldn't be tagged that way in
> OSM.  This isn't minor, it is "either correct or incorrect."
>
> > The main way that municipal names are mapped is through admin boundary
> relations, not place nodes (although many municipalities have the same name
> as their largest urban settlement, of course).
>
> Yes, this is true, although for many smaller human settlements (and some
> larger ones), place nodes simply "will have to" suffice.
>
> > The way to distinguish between a place=city, place=town, and
> place=village is population size, with nearby places shading things a bit
> (so a smaller population size qualifies for a place=town in Northern
> Ontario).  Very roughly, a city has population >50k, a town has population
> 5k-50k, and a village is <5k.
>
> OSM's place wiki notes that a village is more like "200 to town size" so
> that 5k edge is fuzzy.  The USA admin_level wiki documents some "rules of
> thumb" here, but, yes, these can be rough, and are sometimes "stretched"
> (or "shaded" as you say) a bit so that wide-zoom views of very rural areas
> (e.g. northern Ontario) show settlements a bit more clearly.
>
> > There seems to 

[Talk-ca] Ongoing Place Reclassification needs to be stopped, possibly reverted

2019-01-24 Thread Danny McDonald
Repeating this, since it seemed to get bumped by all the building import
talk.  Now with a catchier subject line.
DannyMcD

My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

Any thoughts?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] Place Tagging

2019-01-24 Thread Danny McDonald
My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
  Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

Any thoughts?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca