Re: [Talk-ca] mapping Ottawa light rail stations.

[John Whelan]

It looks like the entrances railway=subway_entrance  have been mapped 
but the optional name tag hasn't been added in all cases.  Without the 
name OSMAND struggles to find them.  Parliament subway entrance for 
example is searchable.


If someone is passing (Danny?) could they add the names to the subway 
entrances please.  I'm unable to figure out what they should be.  Lyon 
is missing the names, Parliament has everything labelled parliament. 
Dunno about the others.


Thanks John

Jeff McKenna wrote on 2020-11-25 07:45:
You can ask the OsmAnd community directly in their forum, which is 
quite vibrant: https://groups.google.com/g/osmand/


-jeff





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

Re: [Talk-ca] mapping Ottawa light rail stations.

[John Whelan]

I'm more interested in being able to say to OSMAND get me from a 
specific exit whatever to a street address and I couldn't figure out how 
to do that.


Cheerio John

James wrote on 2020-11-24 19:30:
I don't think osmand handles elevators, there's a issue open on github 
to support indoor mapping, but it's been flagged as a "nice to have"


On Tue., Nov. 24, 2020, 7:22 p.m. John Whelan, <mailto:jwhelan0...@gmail.com>> wrote:


Today I wanted to use OSMAND+ to work out the by foot from Lyon
station to 60 Cambridge street.  There are two entrances / exits
to the station and I wanted to leave by a particular exit.  The
most westerly one.

The route suggested by OSMAND+ was at first glance bizarre but
looking more closely seems to follow the underground foot ways
from the platform level which is fine except I was interested in
using the elevators.  So how do I tell OSMAND+ I wish to go from a
particular street level exit?

The second question is should the exits be marked on the map in
someway that OSMAND can find?

Thanks John
-- 
Sent from Postbox <https://www.postbox-inc.com>

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



--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] mapping Ottawa light rail stations.

[John Whelan]

Today I wanted to use OSMAND+ to work out the by foot from Lyon station 
to 60 Cambridge street.  There are two entrances / exits to the station 
and I wanted to leave by a particular exit.  The most westerly one.


The route suggested by OSMAND+ was at first glance bizarre but looking 
more closely seems to follow the underground foot ways from the platform 
level which is fine except I was interested in using the elevators.  So 
how do I tell OSMAND+ I wish to go from a particular street level exit?


The second question is should the exits be marked on the map in someway 
that OSMAND can find?


Thanks John
--
Sent from Postbox 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] How is protect_class used in Canada?

[john whelan]

>I am guessing that some or all of the categories on that list under class
7 can simply be deleted.

Have you attempted to contact the original mappers?

We have a few mappers in Canada who have been mapping for more than ten
years.

John

On Sun, Nov 15, 2020, 23:28 Brian M. Sperlongano 
wrote:

> Hello neighbors to the north,
>
> I have been working to clean up and improve documentation on tagging of
> protected areas.  I've found that in many cases the documentation on the
> wiki does not match how tagging is actually done in real life, so I am
> working to make the wiki more accurate and make the information more useful
> to mappers.
>
> The wiki [1] lists seven different categories that are tagged
> protect_class=7 in Canada.  I was able to find wikipedia links for a few of
> them, but the other items in the list looked like generic terms that were
> just tossed in there by the original author ~10 years ago.
>
> So..  what does protect_class=7 tagging mean in Canada?  Does this have
> real meaning or is it a long-ago forgotten convention?  Since this value
> does not render on the default map, it is always paired with something like
> leisure=nature_reserve to force the drawing of an outline.  An overpass
> inspection [2] shows that this value is almost entirely in Quebec.
>
> I am guessing that some or all of the categories on that list under class
> 7 can simply be deleted.  I'd like to understand how this tagging is
> actually used in order to make the documentation useful and/or understand
> what the Canadian consensus for how these values *should* be used.
>
> [1] https://wiki.openstreetmap.org/wiki/Key:protect_class
> [2] https://overpass-turbo.eu/s/10bS
>
> -Brian (Rhode Island, USA)
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] York Region Building Import

[john whelan]

Thanks John

On Tue, Oct 6, 2020, 09:47 Daniel @jfd553  wrote:

> There is a list of available datasets and the proportion of
> existing/imported buildings for each municipality [1].
>
>
>
> Daniel
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings
>
>
>
>
>
> *From:* John Whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Tuesday, October 06, 2020 09:25
> *To:* Daniel @jfd553
> *Cc:* Andrew Deng; Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] York Region Building Import
>
>
>
> Apologies for omitting your name.  I hang my head in shame.
>
> So the final result on the building import was the process and licenses
> are fine but local mappers need to agree with the import being done and if
> they do they can just go ahead but should follow the agreed process?
>
> How many areas does the data exist for that haven't been imported yet?
> Perhaps there might be some interest in importing a few other areas.
>
> Thanks John
>
> Daniel @jfd553 wrote on 2020-10-06 00:00:
>
> Hi all.
>
> The York Region is a component of ODB data import, which has been widely
> discussed and we all agreed that whole import process was acceptable. There
> is then no reason to go back to the import mailing list to do the
> discussion again. Look here [1] for the appropriate import procedure.
>
>
>
> Speaking of buildings... In order to stay active during Covid-19
> lockdowns, I have been working on a Covid-19 personal mapping project since
> mid-April. My objective was to map the buildings in Sherbrooke (ODB only
> providing 5% of the buildings).
>
> After mapping around 30,000 buildings (according to an Overpass Turbo
> query), 80% of my initial goal is achieved. I keep moving forward with
> mapping and updating buildings and related features.
>
>
>
> Best regards
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings
>
>
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com ]
>
> *Sent:* Monday, October 05, 2020 22:55
> *To:* Andrew Deng
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] York Region Building Import
>
>
>
> There are two sources of buildings to import one is Bing the other is the
> stat Canada licensed one.  Both have the correct license for OSM.
>
>
>
> If you are going after the stat can one then there was an import plan
> drawn up for Canada and that is in the wiki.
>
>
>
> I suggest if you use the stat can import plan basically just copy it
> together with the license information or perhaps you can do a sort of
> amendment of it to cover York.  The reason I suggest that is there is an
> import mailing group that gets involved and they tend to ask all sorts of
> questions.  Getting by them has been described as the hardest part of the
> import process.
>
>
>
> The original import was done in Ottawa and we got all the licensing
> permissions sorted out and because Ottawa is fairly small the local group
> formed a consensus that that is what they were happy with and that was the
> basis of that import.
>
>
>
> When we set it up to import across Canada the problem with the stat can
> data was the quality varied from municipality to municipality and there was
> some concerns about if the data should be preprocessed in some way.  Also
> in some areas such as Toronto local mappers wanted to feel more in control.
>
>
>
> I can't recall who came up with the preprocessing but I'm sure James will
> remember.  Pierre I'm almost certain expressed his opinion.  It might be
> worth looking at what they came up with and why.  I do recall that some
> mappers thought the Ottawa building import should have been preprocessed
> but the local mappers were happy with the raw data.
>
>
>
> Cheerio John
>
>
>
> On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca <
> talk-ca@openstreetmap.org> wrote:
>
> Hello,
>
>
>
> I primarily map in York Region, Ontario, and I have noticed that the
> Toronto Building Import has been completed 3 months ago. Therefore, I am
> proposing to open a task on the Task Manager for York Region buildings,
> since having the buildings imported here would be nice. I'm not sure of the
> process on how to do that, which is why I'm emailing this group.
>
>
>
>
>
> --
>
>
>
> Andrew (andrepoiy on OSM)
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> --
>
> Sent from Postbox <https://www.postbox-inc.com>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] York Region Building Import

[John Whelan]

Apologies for omitting your name.  I hang my head in shame.

So the final result on the building import was the process and licenses 
are fine but local mappers need to agree with the import being done and 
if they do they can just go ahead but should follow the agreed process?


How many areas does the data exist for that haven't been imported yet? 
Perhaps there might be some interest in importing a few other areas.


Thanks John

Daniel @jfd553 wrote on 2020-10-06 00:00:


Hi all.

The York Region is a component of ODB data import, which has been 
widely discussed and we all agreed that whole import process was 
acceptable. There is then no reason to go back to the import mailing 
list to do the discussion again. Look here [1] for the appropriate 
import procedure.


Speaking of buildings... In order to stay active during Covid-19 
lockdowns, I have been working on a Covid-19 personal mapping project 
since mid-April. My objective was to map the buildings in Sherbrooke 
(ODB only providing 5% of the buildings).


After mapping around 30,000 buildings (according to an Overpass Turbo 
query), 80% of my initial goal is achieved. I keep moving forward with 
mapping and updating buildings and related features.


Best regards

[1] 
https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings


*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Monday, October 05, 2020 22:55
*To:* Andrew Deng
*Cc:* Talk-CA OpenStreetMap
*Subject:* Re: [Talk-ca] York Region Building Import

There are two sources of buildings to import one is Bing the other is 
the stat Canada licensed one.  Both have the correct license for OSM.


If you are going after the stat can one then there was an import plan 
drawn up for Canada and that is in the wiki.


I suggest if you use the stat can import plan basically just copy it 
together with the license information or perhaps you can do a sort of 
amendment of it to cover York.  The reason I suggest that is there is 
an import mailing group that gets involved and they tend to ask all 
sorts of questions.  Getting by them has been described as the hardest 
part of the import process.


The original import was done in Ottawa and we got all the licensing 
permissions sorted out and because Ottawa is fairly small the local 
group formed a consensus that that is what they were happy with and 
that was the basis of that import.


When we set it up to import across Canada the problem with the stat 
can data was the quality varied from municipality to municipality and 
there was some concerns about if the data should be preprocessed in 
some way.  Also in some areas such as Toronto local mappers wanted to 
feel more in control.


I can't recall who came up with the preprocessing but I'm sure James 
will remember.  Pierre I'm almost certain expressed his opinion.  It 
might be worth looking at what they came up with and why.  I do recall 
that some mappers thought the Ottawa building import should have been 
preprocessed but the local mappers were happy with the raw data.


Cheerio John

On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca 
mailto:talk-ca@openstreetmap.org>> wrote:


Hello,

I primarily map in York Region, Ontario, and I have noticed that
the Toronto Building Import has been completed 3 months ago.
Therefore, I am proposing to open a task on the Task Manager for
York Region buildings, since having the buildings imported here
would be nice. I'm not sure of the process on how to do that,
which is why I'm emailing this group.

--

Andrew (andrepoiy on OSM)

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



--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] York Region Building Import

[john whelan]

There are two sources of buildings to import one is Bing the other is the
stat Canada licensed one.  Both have the correct license for OSM.

If you are going after the stat can one then there was an import plan drawn
up for Canada and that is in the wiki.

I suggest if you use the stat can import plan basically just copy it
together with the license information or perhaps you can do a sort of
amendment of it to cover York.  The reason I suggest that is there is an
import mailing group that gets involved and they tend to ask all sorts of
questions.  Getting by them has been described as the hardest part of the
import process.

The original import was done in Ottawa and we got all the licensing
permissions sorted out and because Ottawa is fairly small the local group
formed a consensus that that is what they were happy with and that was the
basis of that import.

When we set it up to import across Canada the problem with the stat can
data was the quality varied from municipality to municipality and there was
some concerns about if the data should be preprocessed in some way.  Also
in some areas such as Toronto local mappers wanted to feel more in control.

I can't recall who came up with the preprocessing but I'm sure James will
remember.  Pierre I'm almost certain expressed his opinion.  It might be
worth looking at what they came up with and why.  I do recall that some
mappers thought the Ottawa building import should have been preprocessed
but the local mappers were happy with the raw data.

Cheerio John

On Sun, Oct 4, 2020, 12:32 PM Andrew Deng via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> Hello,
>
> I primarily map in York Region, Ontario, and I have noticed that the
> Toronto Building Import has been completed 3 months ago. Therefore, I am
> proposing to open a task on the Task Manager for York Region buildings,
> since having the buildings imported here would be nice. I'm not sure of the
> process on how to do that, which is why I'm emailing this group.
>
>
> --
>
>
>
> Andrew (andrepoiy on OSM)
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Proposal to tag Yonge Street in Toronto and York Region as Primary

[john whelan]

What Jarek says makes sense to me.  I suspect many of the map users don't
live where the use the map.

Having said that could we come up with something that could be applied
across Canada or is that too much to ask for?

Thanks John

On Thu, Jul 16, 2020, 22:39 Jarek Piórkowski  wrote:

> On Thu, 16 Jul 2020 at 11:30, Andrew Deng via Talk-ca
>  wrote:
> > Hello, I believe Yonge Street in Toronto and York Region (Regional Road
> 1) should be tagged as highway=primary rather than highway=secondary as it
> is tagged now.
> > Here are some reasons I believe why:
> > 1) Yonge Street is considered the "Main Street" of Toronto, Thornhill,
> Richmond Hill, and Aurora. It is also a major road in Newmarket.
> > 2) It is a major thoroughfare throughout the route. In Toronto, the
> Yonge subway follows it and in York Region, Viva bus lanes are being built.
> It also connects to Bradford in the north.> 3) It was a former Ontario
> King's Highway - Highway 11. Some other former King's Highways in the
> Toronto/York area are tagged as highway=primary, such as Highway 27,
> Highway 7, and Highway 48.
>
> Hi Andrew, hi mailing list,
>
> I've been thinking about this for a while. Thanks for bringing this up!
>
> I'd like to contribute to a wider discussion about tagging primary in
> Ontario, particularly in urban and suburban areas. I think we should
> use it more - here's why.
>
> I've been unhappy for a while with the tagging guidelines for Ontario
> roads. The primary/secondary/tertiary OSM scheme originated in the UK,
> where basically all "A-roads" are primary (or trunk) and all "B-roads"
> are secondary. This is a UK-wide scheme and a crucial point is that
> there are still A-roads in busy urban areas. For example what is by
> GTA standards a narrow street in inner city like
> https://osm.org/way/327282307 (one-way, 1 or at most 2 lanes) is
> primary because it's an A road. [1] Many other regions in Europe also
> use primary for urban thoroughfares with frequent cross streets.
>
> For a long time, the Canadian tagging guidelines were a very close
> copy of the UK scheme - check out Danny's wiki edit in May 2019 [2]
> that removed very UK-like references to "C roads" (a UK
> classification) and "a suburb" ("An example would be the main roads
> within the suburb to get to the local primary school", "A
> highway=residential road which is used for accessing or moving between
> private residential properties (homes).  Otherwise called a
> 'suburb'."), and removed a statement that primary, secondary, and
> tertiary roads are "all maintained by the provincial governments, with
> provincial jurisdiction."
>
> https://wiki.openstreetmap.org/wiki/Highway:International_equivalence
> still specifies that in Canada, a highway=primary is a "Provincial
> primary highway that does not meet freeway standards". That might work
> in BC, where there are provincial highways in downtown Vancouver, but
> it doesn't work in Ontario. BC Highway 99 through downtown Vancouver
> is tagged as trunk, and it is no wider than Yonge through York Region
> tagged as secondary.
>
> Historically, in Ontario, the maintenance and jurisdiction of a road
> has more to do with whether a lower-level government could be
> strong-armed into accepting ownership in the 1990s than with its
> actual role in the road network. Ontario government downloaded the
> roads it could onto the regions and cities, but of course the volume
> of traffic or significance of the road doesn't change just because we
> enter a somewhat-built-up area (or it increases). There's some good
> examples along Highway 7 entering east Kitchener and east Guelph.
> Highways 8 and 24 entering south Cambridge are more examples - it's
> just a cut at point of jurisdiction change, it's got nothing to do
> with the actual road or its use.
>
> As a result, we don't really show the main roads in Ontario cities. We
> mostly jump from a freeway straight to secondary, and most exceptions
> are recent changes.
>
> To an extent a grid system, which most Ontario cities use, does of
> course consist of a number of fairly equal arterials, but natural
> obstacles often get in the way, and so in Toronto/GTA some arterials
> are more equal than others. Is every grid street really the same rank?
> When everything is secondary, what really is secondary?
>
> To give some examples, in Toronto Lake Shore Blvd is clearly a busier
> road and can carry more inter-local traffic than Church or Yonge
> downtown, yet currently they're all secondary. Adelaide and Richmond
> are the designated through corridors - consider especially their
> direct connection to the DVP. Given the choice, you should be driving
> on Adelaide/Richmond, not on Queen - they are designed for this. Yet
> again, Queen, Adelaide, and Richmond are currently all secondary.
>
> Until last year, York Region's Highway 7 was being indicated the same
> secondary as Dundas Street next to Dundas Square (because after all,
> Hwy 7 was downloaded). They are 

Re: [Talk-ca] WikiProject Canada Post - franchise assessment

[john whelan]

I think you can use it to see where to look.

If there is only one building and you can see a Canada Post logo
floating around I think it is fair game.

Canada Post is part of federal government so there is some sort of
commitment to Open Data floating around under the Federal government's open
data initiative.

Cheerio John

On Tue, Jun 16, 2020, 09:10 Justin Tracey  wrote:

> Is it legal to import that data from the Canada Post site?
>
>  - Justin
>
> On Tue, Jun 16, 2020 at 8:04 AM David Nelson via Talk-ca <
> talk-ca@openstreetmap.org> wrote:
>
>> I have just finished assessing which post offices in Canada among those
>> we have not yet added to OSM are franchises, and which of those franchise
>> outlets' parent businesses already appear in our database.  Those such
>> locations are now marked in pale red on the project's spreadsheets.  The
>> node for each such post office location just has to be positioned right
>> next to its respective parent business.  You can determine what each parent
>> business is by looking on Canada Post’s own website, or by doing a simple
>> web search for the postal code of each such outlet.  With this, we are in a
>> position to immediately add nearly 700 more Canada Post outlets across the
>> country to OSM.  This would bring the progress of this project to a
>> completion measure of just under 48 percent.
>>
>>
>>
>> - David E. Nelson
>>
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Missing maps in Canada from weeklyosm

[John Whelan]

Which sort of ties into the building import side of things as there was 
mention at the start of the project that for many remote communities the 
building data would be valuable.


https://www.missingmaps.org/blog/2020/03/31/a-year-of-blogs/

To me I think missing maps implies mapathons and possible data quality 
issues.


Would it be worth while doing the remote communities with Microsoft 
building data or some such?


Thoughts?

Thanks

Cheerio John






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

Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

[john whelan]

One of the nice things about the disabled community is we get a fair amount
of data either from them or by people supporting them.  As Clifford
mentioned this sort of thing is useful to them and as I grow older this
sort of information is unfortunately getting more useful to myself.

Universities can be useful as well although the students do tend to refine
the detail on highways etc close the them.  In Ottawa a foot bridge I
orginally mapped near the University of Ottawa  has been updated about
thirty times now.  On a personal note the building import in Ottawa came
from a file that was identified by a University lecturer so Universities
can be useful.

When I look at the map I wonder about the level of detail we have
sometimes.  Do we really need to know that the surface is asphalt rather
than paved?

Personally I'd rather see the data included.

Cheerio John

On Fri, Apr 3, 2020, 4:26 PM Martin Chalifoux via Talk-ca, <
talk-ca@openstreetmap.org> wrote:

> Nate, when reading this and other comments I try to figure who puts those
> sidewalks in and to the benefit of what users. From what I can see it is
> being done by university groups essentially, not the community. The
> beneficiaries are organizations that funds those groups with strings
> attached, essentially buying a service. The OSM mass of end-users is not it
> appears the beneficiary but rather a very small group of people. I thus ask
> very honestly are the universities hijacking OSM to execute their research
> projects just because it is there, free and easily usable ? Are OSM users
> ever a concern ? With regards to this specific sidewalk mapping effort I
> really have a hard time figuring how a mainstream OSM user, through the
> site or a mobile app, benefits in any way from this added layer or
> complexity. I tend to think to the contrary is makes the map overly
> complex, add information nobody will ever care about, render the experience
> cumbersome, that with no tangible gain. If that was the case I don’t think
> that would be right.
>
> I don’t mean this to be inflammatory but just an honest questioning.
>
> On Apr 3, 2020, at 15:14, Nate Wessel  wrote:
>
> I used to be opposed to sidewalk mapping, and I still think it is often
> done poorly. I've changed my mind in the last year or two though. When I
> first moved into my current neighborhood and started mapping the area, I
> hated at all the poorly drawn sidewalks. They weren't well aligned, they
> didn't do anything to indicate crossings, and they were far from complete.
> For a while I was temped to delete the lot of them, but instead worked to
> gradually fix them up, noted marked or signalized crossings, added in
> traffic islands, pedestrian barriers etc.
>
> Once you have a high-quality, relatively complete mapping of sidewalks, I
> really think they add a lot of value. You can see where sidewalks end,
> where crossings are absent, how long crossings are, whether there is
> separation from other traffic by e.g. fence or bollards.
>
> It's not just about routing. Sidewalks (and crossings) are infrastructure
> in their own right and deserve to be mapped as such, at least in many dense
> urban areas, and especially where they vary significantly from street to
> street. I'm not saying it should be done everywhere, but it definitely does
> have value in some places.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-04-03 2:49 p.m., Frederik Ramm wrote:
>
> Hi,
>
> On 4/3/20 19:45, Martin Chalifoux via Talk-ca wrote:
>
> This morning I checked some large cities namely New-York, Paris, Amsterdam, 
> London, Berlin. Since OSM is best developed in Europe these capitals make 
> sense. I just checked Tokyo, Shangai, Seoul, Sydney to sample Asia. None of 
> them have this sidewalk mapping as separate ways.
>
> There are pockets here and there in Europe as well. Mostly what happens
> is this:
>
> 1. Someone wants to make a cool pedestrian/wheelchair/schoolkid routing
> project
>
> 2. The person or team has limited programming capability or budget, and
> hence must attack the problem with a standard routing engine
>
> 3. Standard routing engines do not have the capability to infer a
> sidewalk network from appropriately tagged streets (i.e. even if the
> street has a tag that indicates there's sidewalks left and right, the
> routing engine will not generate individual edges and hence cannot do
> something like "follow left side of X road here, then cross there, then
> follow right side" or so
>
> 4. Hence, tons of sidewalks (and often also pseudo-ways across plazas)
> are entered into OSM, to "make the routing work".
>
> (5. often people will then find that the routing engine generates
> instructions like "follow unnamed footway for 1 mile" which leads them
> to copy the road's name onto the sidewalk geometry... to "make the
> routing work").
>
> (6. In some countries a pedestrian is allowed to cross a street
> 

Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

[John Whelan]

Since it is dependent on municipal bylaws then I think it should be 
explicitly tagged.


Cheerio John

Pierre-Léo Bourbonnais wrote on 2020-04-03 2:05 PM:
The reason why we were asked to add them is for pedestrian security 
assessment and urban planning. When all sidewalks and crossing are 
mapped, we can measure crossing distances and estimate the probability 
of accidents, which can save lives when the cities add curb extensions 
(avancées de trottoirs). We use openstreetmap data to convince 
government officials that it is statistically better to take them into 
account when planning new neighbourhoods or enhance existing ones. 
Also, it allows us to get better precision and calculate penalties 
when routiong at traffic signals which must be crossed twice by 
pedestrian at some intersections. OpenStreetMap objective is to map 
what is there with the best precision available. When aerial 
photography was not precise enough for sidewalks, it was not feasible 
to add them, but now we get precise aerial photos that permit better 
representativity of the physical world. I can tell you that the amount 
of precision and completeness in openstreetmap data will increase 
rapidly in the coming years. And the COVID-19 pandemy will increase 
the need for precise and complete mapping of urban environments, so we 
must deal with it accordingly.
Mapping sidewalks as separate ways is now in the official wiki and has 
been accepted by the community by vote, so we must now find the best 
way to accomodate everyone. For now, I am just trying to know if we 
must add bicycle=no to them.


About the routing directions, we must add the street names to 
sidewalks (as we do in my team), otherwise like Martin said, routing 
engines will tell people to turn left, turn right instead of turn left 
on A street, then turn right on B street, etc.






On Apr 3, 2020, at 13:51, Harald Kliems > wrote:




On Fri, Apr 3, 2020 at 10:17 AM Martin Chalifoux via Talk-ca 
mailto:talk-ca@openstreetmap.org>> wrote:


What cities allow cycling on sidewalks anyway, seriously ? This
sounds so inadequate. That it is tolerated is one thing, but
outright legal or encouraged ? Makes no sense to me.

In the US that's pretty common. For example here in Madison 
(Wisconsin), sidewalk riding is generally allowed by ordinance, 
except where buildings directly abut the sidewalk (I manually tag 
those as bicycle=no).

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




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


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

Re: [Talk-ca] Tagging sidewalks as separate ways and issues with bicycle routing

[John Whelan]

I'd recommend bicycle=no and I live in Ottawa.  In Ottawa footpaths that 
connect in general are bicycle=yes as they come under municipal 
regulation but a sidewalk on a highway comes under provincial 
legislation which bans bicycles on sidewalks.  Sparks street is fun I 
think you are not permitted to ride your bicycle but I'm unsure if this 
is provincial, municipal or it might even be NCC which is federal of course.


In the UK they are banned by law but in certain cities the Chief 
Constable has stated the law will not be enforced within the police 
force boundaries as a letter of interpretation.  It might be nice for 
Ottawa to do the same sometime but there again we have City of Ottawa 
police, OPP, RCMP and of course the PPS.


Cheerio John

James wrote on 2020-04-03 10:25 AM:
I don't think it's more tagging for the renderer as much as it's being 
more specific(more data) to specify a abstract view: without knowledge 
of Canadian/Provincial/Municipal laws about biking on sidewalks.


I think Montreal and Gatineau are more enforced as Ottawa it is 
illegal to bike on the sidewalk, but people are still doing it, but 
that's beside the point.


On Fri., Apr. 3, 2020, 10:18 a.m. Pierre-Léo Bourbonnais via Talk-ca, 
mailto:talk-ca@openstreetmap.org>> wrote:


Hi!

I would like to start a discussion on how we should deal with
sidewalks tagged separately, like it is is done in downtown Ottawa
and like we are starting to do in the Montreal region.

The issue is that by default highway=footway with or without
footway=sidewalk should have an implicit bicycle=no by default
according to this page:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions

However, some osm users told me I should tag them with bicycle=no
everywhere because routing engines use sidewalks for bicycle
routing which is illegal in most part of Canada.

What are your thoughts on this ? Should we adapt to routing
engines or should routing engines fix the issue themselves?

Thanks!


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



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


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

Re: [Talk-ca] Canada Post offices

[john whelan]

It might be worthwhile highlighting those that do not have a postcode or
are tagged name=Canada Post.

Useful locally as I hadn't checked the ones I know of had been mapped nor
that their details were correct.  I did note one address was wrong, the
post office had moved from one side of the street to the other a year or so
ago.

Thanks John

On Sat, 28 Mar 2020 at 16:04, David E. Nelson via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> I have started a project with the objective of adding as many post offices
> as can be found in Canada to OpenStreetMap.
>
> Canada Post's own database yields just over 6000 post offices within the
> country, and I have used the Overpass API to determine that just over 2000
> of those, or only about one in every three such outlets, have already been
> added to OSM's database.
>
> I would like to enlist the help of mappers across Canada to add as many
> more of the missing post offices as they can find.  To that end, I have
> produced these spreadsheets detailing which post offices have already been
> added to OSM and which have not.
>
> Atlantic (A, B, C, E): <
> https://docs.google.com/spreadsheets/d/13O2oY4te6EvOPSqpaCOtWbUZ2UkO-ahq9CeODruvcDA/
> >
>
> Quebec (G, H, J):
> <
> https://docs.google.com/spreadsheets/d/1IOrbwQsEgSM8PvzWzBDHNPvM0d3HsiW_XLXYnK7utm8/
> >
>
> Ontario (K, L, M, N, P):
> <
> https://docs.google.com/spreadsheets/d/1k_mOmiL15L6ObCeJJ8DntVBXb21JSZwOsJTbfb1FOI0/
> >
>
> Western and Northern (R, S, T, V, X, Y):
> <
> https://docs.google.com/spreadsheets/d/1lcOL5ISS9aML6oaUOcgyngw4bio_gRmbxzLn-4GCjXQ/
> >
>
> Each spreadsheet has a "master list" of post offices, and each of those
> entries has been colour-coded according to their disposition:
>
> Green = Already added to OSM; node/way ID given, with dash before ID
> indicating a way, no dash indicating a node
> Red = Not yet added to OSM
> Yellow = Location listed on waymarking.com (although I am not sure
> waymarking.com data is licence-compatible with OSM) <
> https://www.waymarking.com/cat/details.aspx?f=1=610386da-84d0-4983-bdf1-7eb34a03e64b
> >
> Blue = Added to OSM, but since moved to a new location or simply needs to
> have its address re-verified
> Lilac = Postal code needs to be corrected—the correct postal code is in
> the spreadsheet; postal codes for Canada Post facilities *always* end with
> a zero
> Violet = A letter has been sent to that post office asking for its precise
> geographical location
>
> Each spreadsheet also has a second sheet titled "extraneous data",
> detailing which post offices found in the OSM data have been determined to
> have closed; which OSM post office data is redundant and needs to be
> merged, i.e., if a single post office location has both a way and a
> disconnected node describing it, in which case the tags from the node
> should be moved to the way; and which locations have been erroneously
> tagged as post offices.  Only locations branded as Canada Post where
> postage stamps can be purchased should have the "amenity=post_office" tag,
> while outlets branded as "FedEx", "UPS", or any other private courier
> should instead be tagged as "office=logistics".
>
> I would also like to see a harmonized tagging schema for Canada Post
> outlets, consisting as follows:
>
> addr:housenumber (Use ground survey or local knowledge wherever and
> whenever possible)
> addr:postcode (Use from spreadsheets)
> addr:street (Use ground survey or local knowledge wherever and whenever
> possible)
> amenity=post_office
> brand=Canada Post
> brand:wikipedia=en:Canada Post
> brand:wikidata=Q1032001
> name (Use from spreadsheets)
> operator (Either "Canada Post", for an outlet run directly by Canada Post,
> or for an independently-run franchise, the name of the business that the
> postal outlet can be found in)
> phone (Optional)
>
> I would prefer that no two or more post office locations share a postal
> code.  If this is not the case, only the outlet listed in the above
> spreadsheets should get tagged with "addr:postcode", while the others not
> use the "addr:postcode" tag at all.  As well, no two post office locations
> within the same province or territory should be permitted to have identical
> name values, and I have made sure of that in the spreadsheets.
>
> - David E. Nelson
> https://www.openstreetmap.org/user/DENelson83
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] James work on Task Manager

[John Whelan]

From memory you're based in Cobourg and Port Hope in Ontario.   
Squamish is in BC so may not be local to you.


The Ottawa cycle club did some mapping in OSM 
https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide you may find 
this useful.


Task manager is better suited to imports and to mapping from satellite 
data.


If you're on the ground then Street Complete, or Vespucci on android are 
useful, also OSMand for adding POIs.  iD on a windows laptop or tablet.  
There are editors for Apple Ios avaulbale but I'm not familiar with them.


JOSM is about the most powerful editor but it doesn't run on a 
smartphone as far as I am aware.


If you just want to add to Mapillary then their web site will show you 
what has been photographed so far and it isn't very much in Cobourg or 
Port Hope.


I'm not sure what the advantage of having a task set up on task manager 
would be.


Have fun

Cheerio John

jonab...@gmail.com wrote on 2020-02-24 8:24 AM:


When James has finished tweaking the Task Manager, I would like to 
test it out with our local bike club along with Mapillary streetview. 
http://tasks.openstreetmap.in/project/84


Jonathan



Hi all,

I was able to split Squamish into Quadtree tiles with a maximum of 200 
buildings each. James is now looking into whether/how this could be 
implemented in the task manager. If no one else is volunteering to be 
the local import manager this week, I will do the work and contact 
Squamish's local mappers. Since most ODB buildings were imported about 
a year ago, I don't expect an opposition from local mappers with 
reviewing that import.




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


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

Re: [Talk-ca] James work on Task Manager

[john whelan]

Are you simply asking for a task to be set up or something else?

James currently is looking at the data to import then resizing the squares
to better fit the task.

I don't think there are any plans to import buildings in your local area.
I seem to recall mapping a thousand or so  manually in JOSM so the locals
you organised could add detail.  I seem to recall we got one address added
by the locals.

Cheerio John

On Mon, Feb 24, 2020, 8:26 AM ,  wrote:

> When James has finished tweaking the Task Manager, I would like to test it
> out with our local bike club along with Mapillary streetview.
> http://tasks.openstreetmap.in/project/84
>
>
>
> Jonathan
>
>
>
> 
>
> Hi all,
>
> I was able to split Squamish into Quadtree tiles with a maximum of 200
> buildings each. James is now looking into whether/how this could be
> implemented in the task manager. If no one else is volunteering to be the
> local import manager this week, I will do the work and contact Squamish's
> local mappers. Since most ODB buildings were imported about a year ago, I
> don't expect an opposition from local mappers with reviewing that import.
>
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

We should start somewhere so yes it would be fun.

Thanks John

On Sat, Jan 25, 2020, 3:15 PM Daniel @jfd553,  wrote:

> Bonjour groupe,
>
> The pre-processing procedure has been tested for the Squamish (BC) area.
> Squamish has a small number of buildings (6K) with a good Esri World
> imagery which need to be aligned with ODB data. A large number of ODB
> buildings show an inaccurate delineation (shaky drawing with too many
> nodes). Orthogonalization worked great but the result is not perfect
> because of the quality of the data. About 10% of the nodes were removed
> from the dataset. It contains all the problems we may encounter during this
> import. Consequently, I suggest that the import procedure be discussed and
> documented in detail using this case.
>
> I could identify myself as the local import manager, but I would much
> prefer someone from the area to volunteer. When the local contributors have
> been contacted, and as long as there are no objections, we could start an
> import project in the OSMCanada task manager. Pre-processed data are
> available. We only have to make it available to the task manager. We also
> have to provide the task manager with the working areas (tasks) adjusted to
> 200 buildings per task. I am currently working to define these working
> areas, but if someone else can build it in the meantime it would be great.
>
> Once the import project has been configured in the task manager,
> interested contributors will have to identify themselves in talk-ca in
> order to add them as authorized contributors (James, am I right?)
>
> Would it be fun to try this?
>
> Daniel
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Sounds very reasonable to me.

Thanks John

On Sat, 18 Jan 2020 at 20:02, Nate Wessel  wrote:

> In short, yes. But we should give them a clear option and a clear path
> toward doing it either way - written procedures, provide preprocessing
> scripts/help, etc.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-01-18 7:37 p.m., john whelan wrote:
>
> > But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> My interpretation is you're happy to leave this call to the local
> coordinator?  If they have no buildings it's fairly simple if there are
> buildings already mapped it becomes more complex.
>
> Thanks John
>
> On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:
>
>> Hi all,
>>
>> Daniel, thanks for continuing to prod the conversation along :-)
>>
>> I guess the point of disagreement here is that I generally don't agree
>> that the ODB buildings are of higher quality than what's already in OSM.
>> The ODB data I've seen is quite messy, and IMO only marginally better than
>> having no data in an area, especially if not properly checked and conflated
>> with surrounding OSM data. People seem to generally disagree with that
>> perspective though, so I'll assume that other areas are better represented
>> by their respective ODB data sources. Central Toronto may just not have
>> been well mapped by the City's GIS dept; it certainly isn't the easiest
>> thing to get right.
>>
>> My real worry here is that someone will be carelessly going through an
>> import replacing geometries and will destroy the work of an editor like
>> myself who carefully contributed their time to make a neat and accurate
>> map. I know for certain I've contributed better data in Toronto than what's
>> available from government sources for the same area.
>>
>> We must recall that governments produce building footprints in the same
>> way that we do - usually by tracing imagery, and there is little reason to
>> suppose that their data is better or more accurate just because it comes
>> from a seemingly authoritative source. It comes from interns - likely
>> interns with outdated software and low-resolution surveys.
>>
>> All that being said, I think my real reluctance to go with the flow here
>> stems from the haste and carelessness of the original importers in the GTA.
>> We're working toward a process that should be very different from theirs
>> though and I probably need to just trust that our process will be calmer,
>> slower, and more thoughtful. If it is, I can get on board.
>>
>> But also - sorry this is such a long email - we certainly should not be
>> manually doing re-conflation where buildings are very dense (e.g. downtown
>> Toronto) or where they have already been imported extensively (much of the
>> rest of the GTA). The import plan I'm working on for Toronto will take care
>> of most of this automatically by importing only in the sparse gaps between
>> existing OSM buildings. For other parts of Canada, this may not be much of
>> an issue at all - I wouldn't know.
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>>
>> Bonjour groupe,
>>
>> Here is a sequential summary of the last exchanges. I inserted some
>> comments […] within these exchanges description and summarize what I
>> understand from it at the end.
>>
>> *Nate* asked not to confuse the process of importing new data with that
>> of updating/modifying existing OSM data in order to keep things simple for
>> this import.
>>
>> *Daniel* (I) responded that importing new data and updating/modifying
>> existing ones at the same time (when necessary) is not unusual in OSM [*and
>> would be more efficient*].
>>
>> *John* replied that importing new data and updating/modify existing data
>> when required worked quite nicely when importing Ottawa.
>>
>> *Nate *explained he believes that the buildings will not be compared
>> manually since there are hundreds of 

Re: [Talk-ca] Importing buildings in Canada

[john whelan via Talk-ca]

> But also - sorry this is such a long email - we certainly should not be
manually doing re-conflation where buildings are very dense (e.g. downtown
Toronto) or where they have already been imported extensively (much of the
rest of the GTA). The import plan I'm working on for Toronto will take care
of most of this automatically by importing only in the sparse gaps between
existing OSM buildings. For other parts of Canada, this may not be much of
an issue at all - I wouldn't know.

My interpretation is you're happy to leave this call to the local
coordinator?  If they have no buildings it's fairly simple if there are
buildings already mapped it becomes more complex.

Thanks John

On Sat, 18 Jan 2020 at 19:12, Nate Wessel  wrote:

> Hi all,
>
> Daniel, thanks for continuing to prod the conversation along :-)
>
> I guess the point of disagreement here is that I generally don't agree
> that the ODB buildings are of higher quality than what's already in OSM.
> The ODB data I've seen is quite messy, and IMO only marginally better than
> having no data in an area, especially if not properly checked and conflated
> with surrounding OSM data. People seem to generally disagree with that
> perspective though, so I'll assume that other areas are better represented
> by their respective ODB data sources. Central Toronto may just not have
> been well mapped by the City's GIS dept; it certainly isn't the easiest
> thing to get right.
>
> My real worry here is that someone will be carelessly going through an
> import replacing geometries and will destroy the work of an editor like
> myself who carefully contributed their time to make a neat and accurate
> map. I know for certain I've contributed better data in Toronto than what's
> available from government sources for the same area.
>
> We must recall that governments produce building footprints in the same
> way that we do - usually by tracing imagery, and there is little reason to
> suppose that their data is better or more accurate just because it comes
> from a seemingly authoritative source. It comes from interns - likely
> interns with outdated software and low-resolution surveys.
>
> All that being said, I think my real reluctance to go with the flow here
> stems from the haste and carelessness of the original importers in the GTA.
> We're working toward a process that should be very different from theirs
> though and I probably need to just trust that our process will be calmer,
> slower, and more thoughtful. If it is, I can get on board.
>
> But also - sorry this is such a long email - we certainly should not be
> manually doing re-conflation where buildings are very dense (e.g. downtown
> Toronto) or where they have already been imported extensively (much of the
> rest of the GTA). The import plan I'm working on for Toronto will take care
> of most of this automatically by importing only in the sparse gaps between
> existing OSM buildings. For other parts of Canada, this may not be much of
> an issue at all - I wouldn't know.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-18 5:24 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe,
>
> Here is a sequential summary of the last exchanges. I inserted some
> comments […] within these exchanges description and summarize what I
> understand from it at the end.
>
> *Nate* asked not to confuse the process of importing new data with that
> of updating/modifying existing OSM data in order to keep things simple for
> this import.
>
> *Daniel* (I) responded that importing new data and updating/modifying
> existing ones at the same time (when necessary) is not unusual in OSM [*and
> would be more efficient*].
>
> *John* replied that importing new data and updating/modify existing data
> when required worked quite nicely when importing Ottawa.
>
> *Nate *explained he believes that the buildings will not be compared
> manually since there are hundreds of thousands of them in OSM for Toronto
> alone. In other words, he thinks there will be automated edits, and these
> edits are not governed by the same policies as imports. [*This is an
> important consideration. What has happened in Ottawa and Toronto so far?
> Have automatic processes been used?*]
>
> *Tim* replied that in most cases it might be appropriate to replace OSM
> data, as he believes [*as I do for most of the cases*] that the ODB
> footprints will be more accurate than existing buildings. However he
> considers it is a case-by-case decision [*then no automation process
> should be used*].
>
> *John* couldn’t resist digressing toward the “Microsoft buildings import”
> but had to bring back the discussion on ODB import after reactions from
> *Tim* and *Pierre* (LOL).
>
>
>
> I think that, somehow, we could all agree on how the import should be done:
>
> -  Align images on ODB, unless evidence ODB data are ill located.
>
> -  Align existing OSM content with the image, *only* 

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Pierre looking at the Microsoft imports south of the border and their
process is undoubtedly sensible.

I suggest waiting until we have got some movement on the current import
rather than try to tackle to many things at once.

Cheerio John

On Fri, Jan 17, 2020, 1:47 PM Pierre Béland,  wrote:

> John,
>
> Exprime tu simplement une opinion, ou as-tu vérifié les procédures
> d'import incluant correction des données et validé la qualité des données
> importées aux États-Unis ? Considères-tu la qualité des données dans la
> base OSM aux États-Unis comparable à ce qui s'est fait au Canada l'an
> dernier ?
>
> La qualité des données Microsoft peut sans doute varier selon divers
> facteurs dont la qualité et précision des données aériennes utilisées.
>
> De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le
> gestionnaire de tâches US, il est possible d'y repérer les tâches créées
> pour cartographier des bâtiments.
>
> https://tasks.openstreetmap.us/contribute?difficulty=ALL=ARCHIVED=BUILDINGS
>
> Dans ces zones, j'ai constaté en général une bonne qualité des données.
> Je ne connais pas les procédures utilisées, ni regardé le connu des
> fichiers de données Microsoft pour ces zones, mais la tâche ci-dessous
> montre un processus de validation où il était demandé d'orthogonaliser les
> bâtiments.
> https://tasks.openstreetmap.us/project/164#bottom
>
> Pierre
>
>
> Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> > As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM.
>
> Well yes that is one opinion but we do have a range of opinions in
> OpenStreetMap and from the number of buildings that have already been
> imported into OpenStreetMap from Microsoft, there seems to be a large
> number in the US for example, it would appear there are those who disagree
> with you which is not surprising given the number of mappers.
>
> To me the buildings are of more interest once they get enriched with more
> tags and the place that happens is in OpenStreetMap.  Streetcomplete I
> think is either the most popular editor these days or very close to it.
> You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
> display the outlines by using the Microsoft data but that does not show
> tags such as building type, building levels, etc etc. and streetcomplete is
> a tool that can be used to introduce OpenStreetMap to many people.
>
> I think perhaps we should concentrate our efforts on the current import
> for the moment but I suspect that some Microsoft buildings will start to be
> imported in Canada even if they don't have an official import plan.
>
> Cheerio John
>
>
> On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:
>
> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  <mailto:o...@elrick.de>> wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

> As stated before, I don't consider the Microsoft dataset being close to
the minimum quality requirements I would expect from any automated
building entry into OSM.

Well yes that is one opinion but we do have a range of opinions in
OpenStreetMap and from the number of buildings that have already been
imported into OpenStreetMap from Microsoft, there seems to be a large
number in the US for example, it would appear there are those who disagree
with you which is not surprising given the number of mappers.

To me the buildings are of more interest once they get enriched with more
tags and the place that happens is in OpenStreetMap.  Streetcomplete I
think is either the most popular editor these days or very close to it.
You can't add tags if the buildings are not in OpenStreetMap.  Yes you can
display the outlines by using the Microsoft data but that does not show
tags such as building type, building levels, etc etc. and streetcomplete is
a tool that can be used to introduce OpenStreetMap to many people.

I think perhaps we should concentrate our efforts on the current import for
the moment but I suspect that some Microsoft buildings will start to be
imported in Canada even if they don't have an official import plan.

Cheerio John


On Fri, 17 Jan 2020 at 12:12, Tim Elrick  wrote:

> Hi John,
>
> As stated before, I don't consider the Microsoft dataset being close to
> the minimum quality requirements I would expect from any automated
> building entry into OSM. If you just want to display buildings, you can
> download the MS dataset and use it right away - no need to import into
> OSM. I think, the MS dataset has value as proof of concept and to count
> the number of buildings in a given area (e.g. to estimate market size
> for roofers, estimate number of persons living there for desaster
> relief, etc.). I also think, when Microsoft feeds its algorithm with
> higher resolution data than they did (I don't recall, but I think they
> only used the regular Bing data) they will probably end up with building
> footprints that will meet our/my quality requirements for import into
> OSM one day.
>
> For me, the value of OSM is having accurate information in terms of tags
> and geometry. Otherwise, we could join Wikimapia; they don't care too
> much about geometry accuracy but emphasize on content/tags of objects.
> Pretty interesting project, but different from OSM.
>
> Cheers,
> Tim
>
> On 2020-01-17 10:40, john whelan wrote:
>   >first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset)
>
> I can't resist.  Does this infer that for parts of the country without
> Stat Can data we are happy to import Microsoft dataset buildings as is?
> Or would we wish to wait until we have some more imports done before
> looking at preprocessing them in some way first.
>
> Thanks John
>
>
>
> On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  <mailto:o...@elrick.de>> wrote:
>
>  I would assume in most cases the imported building footprint will be
>  more precise than existing data. For me, this would be a reason to
>  replace already existing objects. However, I think this is a case by
>  case decision. However, I think it is important to keep tags and
>  history
>  of buildings already existent in OSM. This is how I would
>  read/interpret
>  the import guideline stated by Nate: "If you are importing data where
>  there is already some data in OSM, then *you need to combine this
> data*
>  in an appropriate way or suppress the import of features with overlap
>  with existing data." (emphasis added by me)
>
>  However, that just means, the import, hence, is nothing easy and could
>  not be achieve quickly, I would assume. One way of making sure that
>  this
>  is dealt with diligently, would be setting the tasking manager to
>  'experienced mappers only'. We would have to ask James, who is in
>  charge
>  of the Canada Tasking Manager, how to edit/set up the 'experienced
>  mapper role' in the TM. It might be possible to feed in a list of
>  mappers manually or to set a threshold of objects/changesets that they
>  must have entered in OSM. However, maybe only mappers who feel
>  experienced enough to handle the import would contribute to the TM
>  project anyway and we let everyone judge on their own and don't
>  restrict
>  access.
>
>  If we were to separate the new and overlapping buildings, I am also
>  leaning towards Daniel's assessment. I would be afraid to cause more
>  issues than by doing it all at once (with a reasonable tile size, of
>  course).
>
>  In the end, the main point of importing this specifi

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

>first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without Stat
Can data we are happy to import Microsoft dataset buildings as is?  Or
would we wish to wait until we have some more imports done before looking
at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick,  wrote:

> I would assume in most cases the imported building footprint will be
> more precise than existing data. For me, this would be a reason to
> replace already existing objects. However, I think this is a case by
> case decision. However, I think it is important to keep tags and history
> of buildings already existent in OSM. This is how I would read/interpret
> the import guideline stated by Nate: "If you are importing data where
> there is already some data in OSM, then *you need to combine this data*
> in an appropriate way or suppress the import of features with overlap
> with existing data." (emphasis added by me)
>
> However, that just means, the import, hence, is nothing easy and could
> not be achieve quickly, I would assume. One way of making sure that this
> is dealt with diligently, would be setting the tasking manager to
> 'experienced mappers only'. We would have to ask James, who is in charge
> of the Canada Tasking Manager, how to edit/set up the 'experienced
> mapper role' in the TM. It might be possible to feed in a list of
> mappers manually or to set a threshold of objects/changesets that they
> must have entered in OSM. However, maybe only mappers who feel
> experienced enough to handle the import would contribute to the TM
> project anyway and we let everyone judge on their own and don't restrict
> access.
>
> If we were to separate the new and overlapping buildings, I am also
> leaning towards Daniel's assessment. I would be afraid to cause more
> issues than by doing it all at once (with a reasonable tile size, of
> course).
>
> In the end, the main point of importing this specific dataset fulfils
> two purposes, in my opinion: first, to add missing buildings (if it were
> just for this purpose we could also use the much bigger Microsoft
> dataset), second, to get the best geospatial representation possible in
> our OSM database. That means, we defer from using the Microsoft dataset
> and use the much higher quality data from the ODB. This also means that
> we should replace already existing buildings (yet keeping tags and
> history) wherever the ODB footprint is more precise than the existing one.
>
> Just my two cents here,
> Tim
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building tags in Canada

[john whelan]

That sort of works but doesn't include roof:levels.

The easy tag would be building=detached but then you get building=house
which can be used for a semi detached house.

Locally we have some split levels so a single floor at ground level then a
garage often slightly sunk with another room or two on top.
building:levels=?

I'm tempted by the idea of using Streetcomplete's set of suggested tags.

Postcode is fine if you know it but it isn't always obvious from looking at
the building on the outside.

I think what is in the wiki is a sort of dream.  An accurate building date
for example is often difficult to determine. but probably it needs a sort
of low hanging fruit section of what should be easy to tag.

Thanks John

On Thu, 16 Jan 2020 at 17:49, stevea  wrote:

> On Jan 16, 2020, at 2:37 PM, John Whelan  wrote:
> > Is there somewhere that offers guidelines on how to add additional tags?
> and which tags are more interesting and which should be avoided?   For
> example country=Canada is probably superfluous.
>
> As it hasn't been touched in five months, I'm not sure how applicable the
> wiki
>
>
> https://wiki.osm.org/wiki/Canada/Building_Canada_2020#The_data_that_could_be_mapped
>
> is, relevant to how "this" is being done today.  This effort's wikis and
> approaches have changed — and grown!— since that document was drafted.
>
> But, that section does indicate that OSM's "key building=* currently has
> over 60 documented values" and the "man_made=* key now has over 50
> documented values."  I do recall when I selected eight or ten of the values
> noted there that I was largely making educated guesses.  But now, as is
> true of wiki, especially during a project that is still sort of "wet cement
> being mixed" (nothing wrong with that, it has to happen, it happens well
> now) please feel free to modify these values as you see fit.  It was meant
> to be a starting point, may you continue with it as well as possible.  (Or
> not).
>
> SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Building tags in Canada

[John Whelan]

Part of the building import was the idea that once an outline was in 
place it could be tagged with more detail by someone with local 
knowledge. Sometimes some of this this information might be available 
from Mapillary.


For example building=house rather than building=yes

In Coburg there are a number of buildings labelled roof:levels=1

My understanding is this means a room in the attic which is fine but if 
you'd noted the attic room would it not make sense to map the number of 
levels as well?


Is there somewhere that offers guidelines on how to add additional tags? 
and which tags are more interesting and which should be avoided?   For 
example country=Canada is probably superfluous.


Thanks John

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

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[john whelan]

My understanding is that is when we imported Ottawa we followed the normal
process as detailed by Daniel and that seemed to work quite nicely.

Cheerio John

On Thu, Jan 16, 2020, 2:57 PM Daniel @jfd553,  wrote:

> Hello Nate,
>
> I understand that you don’t like to see an import process that both bring
> in new objects and overwrite existing ones. You also suggest removing
> "overlapped" building from ODB prior to import it. Such pre-processing,
> that would ensure there will be no buildings "overwrite" during the import,
> is not realistic (i.e. you will need to overwrite some buildings anyway).
> Here are two reasons why it would be difficult...
>
> 1-  OSM is a dynamic project and, unless you can "clean" the data on
> the fly, you will end up with overlaps since some contributors will have
> added buildings in the meantime.
>
> 2-  One cannot assume that an OSM building, and its ODB counterpart,
> will be found at the same location (look at DX and DY columns in ODB
> inventory tables). These are averages, which means there are larger offsets
> between both datasets (i.e. you won’t get a match between buildings, or get
> a match with the wrong ones).
>
> The only realistic option is then to manually delete the ODB buildings if
> they overlap OSM ones. Here is what the import guideline suggests [1]…
>
> "If you are importing data where there is already some data in OSM, then
> you need to combine this data in an appropriate way or suppress the import
> of features with overlap with existing data."
>
> Therefore, importing data and using a conflation process is not unusual.
> Again, I understand that in case of an overlap, you go for the last option
> (suppress the import building). I am rather inclined toward using
> conflation when necessary, which means...
>
> -  Importing an ODB building when there is no corresponding one
> in OSM;
>
> -  Conflating both ODB and OSM buildings when it significantly
> improves existing OSM content;
>
> -  Not importing an ODB building when the corresponding one in
> OSM is adequate.
>
> What do the others on the list think?
>
> Daniel
>
> [1]
> https://wiki.openstreetmap.org/wiki/Import/Guidelines#Don.27t_put_data_on_top_of_data
>
>
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Thursday, January 16, 2020 10:38
> *To:* Daniel @jfd553; talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> Responding to point C below,
> I would strongly suggest that we not confuse the process of importing new
> data with that of updating/modifying existing data in the OSM database. One
> of the things I really disliked about the initial building import was that
> it overwrote existing data at the same time that new data was brought in.
> These are really two separate import processes and require very different
> considerations.
>
> We can certainly consider using this dataset to improve/update existing
> building geometries, but I think that is a separate process from the import
> we are discussing here. To keep things simple for this import, I would
> suggest removing any building from the import dataset that intersects with
> an existing building in the OSM database. That is, let's not worry about
> conflation for now, and come back and do that work later if we still feel
> there is a strong need for it.
>
> I see the main point of this effort as getting more complete coverage - it
> we want to use the dataset to do quality assurance on existing data, that
> is a whole other discussion.
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-15 12:55 p.m., Daniel @jfd553 wrote:
>
> Thanks for the quick replies!
>
> Now, about...
>
> *a) Data hosting:*
>
> Thank you James, I really appreciate your offer (and that of others). So
> yes, I think hosting pre-processed data in the task manager, for approved
> regions, is an attractive offer. When we agree on a municipality for
> pre-processing, I will contact you to make the data available.
>
> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
> manager. I understand that ODB data are currently converted on the fly when
> requested?
>
> *b) Task manager work units for import:*
>
> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
> was thinking at the same importation rate, but for an hour of work. It
> seems best to target 20-minute tasks.
>
> *c) Task manager work units for checking already imported data*
>
> According to Nate, it is definitely not faster than actively importing. We
> should then keep the above setup (b).
>
> However, what if I add a new tag to pre-processed data indicating if a
> building was altered or not by the orthogonalization (and simplification)
> process? For instance, *building:altered=no*, would identify buildings
> that were not changed by the process and that could be left unchanged in
> OSM (i.e. 

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

I'll cross my fingers and hope it all comes together.

Thanks John

Tim Elrick wrote on 2020-01-15 5:18 PM:

Hi all,

I understand your concerns, John. However, many mappers might not 
follow talk-ca. So, I guess, Daniel's suggestion to contact them, 
might work better than waiting for them to incidentally check talk-ca.


* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of 
changesets, ie. presumably experienced mappers. The disadvantage is 
that these changesets do not have to be from the area we are 
interested in (however, with activity center in the last 6 months we 
at least make sure they were working in our area); another 
disadvantage is that you cannot collect the names of the mappers 
easily (or am I missing something here?). The advantage of the 
overpass query is that you get that list of names easily and you can 
see how many objects they have added in your area in the past months. 
The disadvantage, of course, is that we don't know how experienced the 
mappers are (but maybe this doesn't matter).


Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:

for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be 
send out to local mappers that include the everything that Daniel 
suggested in his last message below.


Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.


IMHO, we just need to make sure that we have done everything 
reasonable to inform the concerned contributors, in order to discuss 
the import in case they do not agree with it. That is why I proposed 
the following, in a previous email, concerning local mappers buy-in…


1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.

3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there 
is no or only a few answers. The identification of local contributors 
using Neis’ tool, or the query Tim Elrick just proposed, are what I 
consider reasonable attempts for contacting the local mappers.


Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour 
tasks


*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
    // I collected users active in the last 6 months, but you can
    // change that
    node(newer:"{{date:6 months}}")(area.searchArea);
    way(newer:"{{date:6 months}}")(area.searchArea);
    relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. First, zoom to the area of interest (i.e. your
bounding box), then paste the following code on the left and export:

// overpass query
[out:csv(::user)];
(
    node(newer:"{{date:6 months}}")({{bbox}});
    way(newer:"{{date:6 months}}")({{bbox}});
    relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I 

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[john whelan]

One concern I have at present is the lack of comments from what I would
call more average mappers in smaller population areas.

The conversation seems to be limited to two or three players.

I'm not sure if this is because we lost momentum earlier or people now feel
they have to have made more than a hundred edits to get involved.

We know the major cities have something worked out or are working on it.

My concern is more those locations with a smaller population and fewer
mappers who may not follow this list.

Cheerio John

On Wed, Jan 15, 2020, 1:05 PM James,  wrote:

> Just to let you know there is a maximum of geometry the tasking manager
> can handle, I'm not exactly sure what it is, but I have encountered it
> before. So try not to go too ham with the geometric shapes
>
> On Wed., Jan. 15, 2020, 12:56 p.m. Daniel @jfd553, 
> wrote:
>
>> Thanks for the quick replies!
>>
>> Now, about...
>>
>> *a) Data hosting:*
>>
>> Thank you James, I really appreciate your offer (and that of others). So
>> yes, I think hosting pre-processed data in the task manager, for approved
>> regions, is an attractive offer. When we agree on a municipality for
>> pre-processing, I will contact you to make the data available.
>>
>> BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
>> manager. I understand that ODB data are currently converted on the fly when
>> requested?
>>
>> *b) Task manager work units for import:*
>>
>> I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
>> was thinking at the same importation rate, but for an hour of work. It
>> seems best to target 20-minute tasks.
>>
>> *c) Task manager work units for checking already imported data*
>>
>> According to Nate, it is definitely not faster than actively importing.
>> We should then keep the above setup (b).
>>
>> However, what if I add a new tag to pre-processed data indicating if a
>> building was altered or not by the orthogonalization (and simplification)
>> process? For instance, *building:altered=no*, would identify buildings
>> that were not changed by the process and that could be left unchanged in
>> OSM (i.e. not imported); *building:altered=yes* for those who were
>> changed by the process and that should be imported again. The same
>> pre-processed datasets could then be made available for all cases. Thoughts?
>>
>> *d) Finding local mappers:*
>>
>> I agree with Nate’s suggestion to try contacting the top 10 mappers in an
>> area. Using the "main activity center" would work for most of the
>> contributors but selecting other overlays (.e.g. an activity center over
>> last 6 months) could also work great. As long as we identify who might be
>> interested in knowing there is an import coming.
>>
>> Comments are welcome, particularly about the proposal on c)
>>
>> Daniel
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] FW: Re: Importing buildings in Canada

[john whelan]

I think we should have a list of ways to find local mappers.

Ideally we start with Pascal Neis’ tool  but then allow ourselves to reduce
the bar to consider others perhaps with 9 changesets or less after two
weeks after approaching the ideal mapper /mappers first.

Do we have a target municipality at the moment of reasonable data  that
doesn't need cleaning up so we can start there?

If need be I can host on jaws.org but I'm more than happy for James to do
so.

Cheerio John

On Wed, 15 Jan 2020 at 08:35, Daniel @jfd553  wrote:

> Bonjour Groupe,
>
> Concerning the proposal (ODB import), there are questions that remain
> before moving forward; here are some of them…
>
> a)  Who on this list host the ODB data? If pre-processing is
> required, how should we proceed to have the results made available
> (assuming I ran the pre-process)?
>
> b)  Nate mentioned that the working units (shapes) proposed by the
> task manager are customizable according to data density. So, how many
> buildings can be imported properly (i.e. following the procedure) in an
> hour or so? Would it be a good size to proceed?
>
> c)   There are areas where the data has already been imported. What
> would be the size of an import check task? I expect that a much larger
> number of buildings can be checked in an hour or so, but by how much (10x)?
>
> d)  Who should be contacted when trying to get the local mappers
> buy-in? IMHO I would contact only those found by Pascal Neis’ tool [1],
> which would have contributed more than 10 changesets and for which the main
> activity centre is within a the concerned municipality (tick/untick the
> display option boxes [1]).
>
> Proposals or comments you which to share?
>
> Daniel
>
> [1] Overview of OpenStreetMap Contributors aka Who’s around me?
> http://resultmaps.neis-one.org/oooc?
>
> *From:* Daniel @jfd553 [mailto:jfd...@hotmail.com]
> *Sent:* Saturday, January 11, 2020 15:41
> *To:* talk-ca@openstreetmap.org
> *Subject:* [Talk-ca] FW: Re: Importing buildings in Canada
>
>
>
> By the way, have a look at
>
> https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
> https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings
>
> Cheers
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Which is what I imagined was the case but the audience in talk-ca is large
and with two languages around it is easy for misunderstandings to occur.

Cheerio John

On Sun, Jan 5, 2020, 12:33 PM Nate Wessel,  wrote:

> John,
> Those links were just to indicate what can be done with task setup. I
> don't think we're close to setting up actual import tasks yet, though we do
> seem to be on the road toward getting things sorted out :-)
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-01-05 12:20 p.m., john whelan wrote:
>
> I'm getting lost as to who is organising what and who is taking
> responsibility for defining and setting up the tasks and where they are
> being set up.
>
> Are your two examples of what can be done?  Or are they to be used by
> mappers to add buildings?
>
> My understanding was Daniel would identify those areas that looked the
> most interesting then these would be set up after the process to see if any
> local mappers were available and what their input would be.
>
> Thanks John
>
> On Sun, Jan 5, 2020, 11:41 AM Nate Wessel,  wrote:
>
>> The task size, and even shape is totally customizable. I've set up a
>> couple that are entirely based on the density of the data:
>> http://tasks.osmcanada.ca/project/168
>> https://tasks.openstreetmap.us/project/107
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>> On 2020-01-04 12:40 p.m., Daniel @jfd553 wrote:
>>
>> Bonjour groupe
>>
>>
>>
>> Looks like we're going in the same direction so far :-)
>>
>> I agree with Nate regarding the implementation of the task manager. In my
>> experience, a size of a few blocks would be better in urban areas, but
>> boring in rural areas. Is it something that can be adjusted?
>>
>>
>>
>> Daniel
>>
>>
>>
>> *From:* Nate Wessel [mailto:bike...@gmail.com ]
>> *Sent:* Saturday, January 04, 2020 10:09
>> *To:* talk-ca@openstreetmap.org
>> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>>
>>
>>
>> Hi Daniel,
>>
>> Thank you for all the work you've put into this. I'd like to offer a
>> couple suggestions and/or clarifications for your proposed import process,
>> overview though it is.
>>
>> First, I think it is very important that a tasking manager is set up on a
>> city/by city basis only, and that only AFTER consensus is achieved that the
>> import should proceed in that area. I would really like to avoid seeing the
>> massive nationwide tasking that was set up the first time around. We should
>> be making it hard for people to go rogue in regions where consensus for an
>> import doesn't (yet) exist.
>>
>> Related to this, though important enough to be a second point in it's own
>> right, the tasking squares need to be small enough that a single user can
>> manage them and inspect every single building in a task. The first round of
>> import used task squares that were massive, and which couldn't be divided
>> any further past a certain point. Even in rural areas, it is likely
>> inappropriate to import areas larger than 1km^2. In central Toronto it
>> would be (and was) idiotic. An import that doesn't take local scale into
>> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
>> big to import in my opinion and is not a good enough benchmark for import
>> batch sizing.
>>
>> That is, each import needs to be local, and not just in a superficial
>> sense.
>>
>> I'll also add that the issue of conflation doesn't seem to have been
>> worked out yet except to note that it is an issue. What will we do with the
>> millions of buildings which will substantially overlap/duplicate existing
>> buildings or imports? This needs to be worked out in detail before anything
>> starts up again.
>>
>> And what needs to be done about already existing low quality imports?
>> It's good to acknowledge their existence, but what will be done about them?
>> We've set up a task to clean up some of the mess in Toronto (
>> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
>> iceberg.
>>
>> Again, I thank everyone for their time and effort on this - we can get
>> this done if we go slow and do it right :-)
>>
>> Best,
>>
>> Nate Wessel, PhD
>> Planner, Cartographer, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>>
>> On 2020-01-03 3:40 p.m., 

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

I'm getting lost as to who is organising what and who is taking
responsibility for defining and setting up the tasks and where they are
being set up.

Are your two examples of what can be done?  Or are they to be used by
mappers to add buildings?

My understanding was Daniel would identify those areas that looked the most
interesting then these would be set up after the process to see if any
local mappers were available and what their input would be.

Thanks John

On Sun, Jan 5, 2020, 11:41 AM Nate Wessel,  wrote:

> The task size, and even shape is totally customizable. I've set up a
> couple that are entirely based on the density of the data:
> http://tasks.osmcanada.ca/project/168
> https://tasks.openstreetmap.us/project/107
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-04 12:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe
>
>
>
> Looks like we're going in the same direction so far :-)
>
> I agree with Nate regarding the implementation of the task manager. In my
> experience, a size of a few blocks would be better in urban areas, but
> boring in rural areas. Is it something that can be adjusted?
>
>
>
> Daniel
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com ]
> *Sent:* Saturday, January 04, 2020 10:09
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
>
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the 

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Daniel addressed this if you reread his email and proposal.  Basically we
look for local mappers first.  If we don't find any we increase the
distance for local.

At the moment we are discussing the stats can sourced data.

My feeling is let's get this import moving once more and to do that let's
aim at those areas with good data, a local mapper or two and we can tackle
the more complex ones later.

Those areas with no local mappers are also areas where we probably need to
use Microsoft or another source of data.  Each separate source will need a
separate overall import plan together with "subplans" which is what I'll
call Daniel's idea of tackling the stat can data an area at a time.

Cheerio John

On Sat, Jan 4, 2020, 4:07 PM Matthew Darwin,  wrote:

> Hello all,
>
> Happy to see progress here.
>
> My ongoing question is how to define that a "local" group has determined
> that an import can proceed.   And more specifically what is "local"? There
> are rural and remote parts of Canada which have in the order of zero active
> mappers or sense of a local community.  How do we consensus around imports
> there? Can we get agreement by (part-of) province/territory where there is
> not some other group that puts their hand up?  (maybe use admin level 5
> boundaries, with holes for big cities)
>
> I just want to make sure we don't stop at doing imports only for big
> cities. Buildings are important for the whole country.
> On 2020-01-04 10:09 a.m., Nate Wessel wrote:
>
> Hi Daniel,
>
> Thank you for all the work you've put into this. I'd like to offer a
> couple suggestions and/or clarifications for your proposed import process,
> overview though it is.
>
> First, I think it is very important that a tasking manager is set up on a
> city/by city basis only, and that only AFTER consensus is achieved that the
> import should proceed in that area. I would really like to avoid seeing the
> massive nationwide tasking that was set up the first time around. We should
> be making it hard for people to go rogue in regions where consensus for an
> import doesn't (yet) exist.
>
> Related to this, though important enough to be a second point in it's own
> right, the tasking squares need to be small enough that a single user can
> manage them and inspect every single building in a task. The first round of
> import used task squares that were massive, and which couldn't be divided
> any further past a certain point. Even in rural areas, it is likely
> inappropriate to import areas larger than 1km^2. In central Toronto it
> would be (and was) idiotic. An import that doesn't take local scale into
> account shouldn't proceed. "Too big to load into JOSM" is about 100x too
> big to import in my opinion and is not a good enough benchmark for import
> batch sizing.
>
> That is, each import needs to be local, and not just in a superficial
> sense.
>
> I'll also add that the issue of conflation doesn't seem to have been
> worked out yet except to note that it is an issue. What will we do with the
> millions of buildings which will substantially overlap/duplicate existing
> buildings or imports? This needs to be worked out in detail before anything
> starts up again.
>
> And what needs to be done about already existing low quality imports? It's
> good to acknowledge their existence, but what will be done about them?
> We've set up a task to clean up some of the mess in Toronto (
> http://tasks.osmcanada.ca/project/168 ) but this is only the tip of the
> iceberg.
>
> Again, I thank everyone for their time and effort on this - we can get
> this done if we go slow and do it right :-)
>
> Best,
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com 
> On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. 

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Sounds sane to me.

Thanks John

On Fri, 3 Jan 2020 at 16:05, Daniel @jfd553  wrote:

> Hi John,
>
> To comply with the import directive, I would like the discussion to
> continue on the current ODB import only. Could we talk about other sources
> of potential imports at another time? -)
>
>
>
> Thanks
>
> Daniel
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* Friday, January 03, 2020 15:57
> *To:* Daniel @jfd553
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Sounds sane to me.
>
>
>
> Are we thinking of setting up a second import to handle Microsoft building
> outlines on a similar basis? Or extending this one?  I only ask since if we
> are doing it municipality by municipality it might be an idea to identify
> those municipalities that do not have suitable open data through stats
> canada.  I can see us with a list of municipalities and a data source and I
> think it probably should be in one place.
>
>
>
> Cheerio John
>
>
>
> On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:
>
> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

Sounds sane to me.

Are we thinking of setting up a second import to handle Microsoft building
outlines on a similar basis? Or extending this one?  I only ask since if we
are doing it municipality by municipality it might be an idea to identify
those municipalities that do not have suitable open data through stats
canada.  I can see us with a list of municipalities and a data source and I
think it probably should be in one place.

Cheerio John

On Fri, 3 Jan 2020 at 15:42, Daniel @jfd553  wrote:

> Bonjour groupe, mes excuses pour ce très long courriel !-)
>
> I have reviewed everything that has been written on the ODB import (aka
> Canada Building Import) in Talk-ca and the wiki. I proposed changes to some
> wiki pages (via talk tabs) to ease the discussions about this import and
> the following. Now, in order to restart the import, here are some thoughts
> and a proposal on how to proceed to complete the task.
>
>
>
> *1. Issues with the ODB Data Import*
>
> Many concerns were raised about the import. One major concern was to
> obtain local communities’ buy-in in the Canadian context. Another concern
> was to improve the quality of the data prior the import. The following
> paragraphs intend to clear most of these concerns.
>
> *1.1. Which data import project?*
>
> According to the import guidelines (steps 3 & 4), a data import explicitly
> refers to a single data source (ODB in our case). Discussions about the
> availability and quality of Microsoft or ESRI data, while interesting, are
> not relevant as they should be dealt with as other import projects.
>
> *1.2. What has been imported so far?*
>
> According to what I found [1], the ODB import is completed for 21
> municipalities. These imports seem to have kept OSM content’s history, at
> least for the samples checked, but many problems were found. In some case,
> the imports brought swimming pools in OSM because they were included in the
> dataset (e.g. Moncton). In other cases, importing buildings with accurate
> locations (XY) over content mapped from less accurate imagery resulted in
> buildings that now overlap the street network (e.g. Squamish). It means
> that all these 21 imports need to be carefully re-examined and corrected as
> required.
>
> For 12 other municipalities, the import is partial, either suspended as
> requested, or because previous imports had already provided most of the
> buildings (often from the same municipal provider). That said the import
> will definitely improve OSM accuracy and completeness if done properly.
>
> *2. How should ODB Data be imported?*
>
> I will copy the following paragraphs in the “Canada Building Import” wiki
> page [3] for a detailed discussion…
>
> Since the data (ODB, OSM and imagery) differ from one municipality to
> another, there can be no imports at the national or provincial level. We
> have to work on a municipal basis and make sure to identify all the
> problems and the corrective measures to apply when dealing with issues like
> those I identified [1].
>
> *2.1 Importing Locally*
>
> According to the import guidelines (step 2), we must not import the data
> without local buy-in. However, and contrarily to some European country,
> there is usually no such thing as a local OSM community in each
> municipality. However, we may find a few local mappers from time to time.
> Working on a municipal basis should allow identifying these local mappers
> before doing the import. I often use this tool [2] to identify and contact
> local mappers. Once identified, I suggest that…
>
> - We contact them to explain our intents by referring to appropriate wiki
> pages.
>
> - We wait a week or two to let them respond nothing, that they have
> concerns, or wish to help.
>
> - Without negative answers we could proceed to the import.
>
> I first suggest that when a contributor wishes to import ODB for a given
> municipality, he first identifies himself as responsible for the import (we
> need to create an entry for each municipality somewhere in the wiki). He
> can then contact local mappers, as explain above, and go ahead with the
> import once everything settled. For those who already made the import, I
> suggest that they review their work since many issues were detected with
> some of these imports.
>
> Since there are only a few local OSM communities in Canada, and because
> Canada is large, I suggest not limiting the import of a given municipality
> to the people of the concerned province or region.
>
> *2.2 Pre-processing*
>
> Once local mappers have agreed, some pre-processing can be done if
> required.
>
> A few months ago, I developed a tool that could be used to process the
> data [4]. Concerns were raised because the application was developed using
> proprietary software. So I documented the whole process and algorithms in
> order to see courageous coders converting it in open source software. In
> the meantime, and as long as I have access to an FME licence, I could
> process the data, when 

Re: [Talk-ca] Importing buildings in Canada

[john whelan]

There are some areas of reasonable quality where buildings are missing.
These I think can be imported on the technical side without too much
difficulty and those were the ones I cherry picked as low hanging fruit
that should not be contentious.

Having said that I have seen the view expressed it is better to have poor
quality data created by local mappers in OSM than high quality data by
expert mappers so it may well be contentious .

In Ottawa buildings were not imported to overwrite existing buildings.
Basically the missing ones were imported by experienced mappers.  That is
just process and I think we have the process fairly well documented and
defined.

There are three sources of building data with the right license in Canada.
Bing is one and that almost certainly covers Newfoundland so Newfoundland
is involved to some extent.

For data that is deemed in need of cleanup or squaring again we can come up
with a process to do that and we have experienced mappers who can follow
the agreed process.

I suggest we hold back for a few days before getting into a heavy
discussion.

Cheerio John



On Tue, 24 Dec 2019 at 18:30, Adam Martin  wrote:

> Hi all,
>
> Looking at the wiki page, a large volume of the buildings are of low
> quality requiring processing.  The trade off here is between not having
> buildings and having buildings that are out of place and of poor quality.
> I can see people being reluctant to have it imported in an area, especially
> where buildings have been drawn by hand.  If this is to be imported, I
> think many would be more amenable to the idea if the data already present
> was given precedence.
>
> As a Newfoundlander, the lack of any such data for this province could be
> a blessing or a curse, depending on how you see the mass importation of
> buildings.
>
> Happy holidays!
>
> Adam
>
> On Tue., Dec. 24, 2019, 7:36 p.m. Daniel @jfd553, 
> wrote:
>
>> Have a look at the wiki page I referred to. Further discussions will be
>> more easy and focused
>>
>> Sent from Galaxy S7
>>
>> --
>> *From:* John Whelan 
>> *Sent:* Tuesday, December 24, 2019 2:50:29 PM
>> *To:* James 
>> *Cc:* Daniel @jfd553 ; Talk-CA OpenStreetMap <
>> talk-ca@openstreetmap.org>
>> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>>
>> I think the first problem to be addressed is the presence or absence of a
>> local community.
>>
>> In the north we have few mappers but lots of interested agencies and
>> people in seeing the buildings imported.
>>
>> Montreal I think is under control.  Toronto is in the process of sorting
>> itself out but I'm unclear how much territory the Toronto local group
>> covers.
>>
>> Vancouver should be big enough to support a local group.  As should
>> Calgary and Edmonton.
>>
>> Ottawa is complete as is Gatineau.
>>
>> It's the smaller cities and regions that would be my concern.  Often it
>> will be by chance that two or more mappers meet occasionally.
>>
>> So step one can we list the local groups?
>>
>> I also have a problem with what happens if two people agree but haven't
>> done any mapping are they a local group?
>>
>> Step two to me would be a consensus on how to tackle those areas without
>> a local group and I think Daniel's suggestion would be a way forward in
>> this area.
>>
>> Cheerio John
>>
>>
>>
>> James wrote on 2019-12-24 1:28 PM:
>>
>> wasn't there talk about this before and someone blocked it because of
>> non-square buildings and the resulting discussion was that each community
>> was going to decide if they want to import or not?
>>
>> On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, 
>> wrote:
>>
>> Hi Group!
>>
>> I am currently working on a proposal which, I hope, will bring consensus
>> among the community and relaunch the import of ODB footprints (StatCan).
>> The proposal should be ready in a few weeks, or sooner.
>>
>>
>>
>> In the meantime, I suggest to all those who are interested to take note
>> of the observations I made regarding these data. This information can be
>> found in the OSM wiki (1). According to OSM import guideline requirements,
>> it describes the data to import. At the same time, I updated the
>> Canada-federal section of the Data Potential wiki page (2).
>>
>>
>>
>> I will be offline in the next few days, so if you have any
>> questions/comments, please be patient :-)
>>
>>
>>
>> Daniel
>>
>>
>>
>> 1 - https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

So an approach would be to pick off those areas with good data available 
first with few existing buildings mapped?


Such as Victoria or Courtenay in BC

Burlington, Caledon, Barrie in Ontario

Then move forward based on that experience?

I'd feel more comfortable with a mapper from the province at least 
coordinating the mapping even if there wasn't a local group.


How would we tackle places such as Perth? Smith Falls and Brockville 
which are available in Bing if not other sources?  These are in Ontario 
and fairly local to Ottawa by the way.


Thanks John

Daniel @jfd553 wrote on 2019-12-24 6:04 PM:
Have a look at the wiki page I referred to. Further discussions will 
be more easy and focused


Sent from Galaxy S7


*From:* John Whelan 
*Sent:* Tuesday, December 24, 2019 2:50:29 PM
*To:* James 
*Cc:* Daniel @jfd553 ; Talk-CA OpenStreetMap 


*Subject:* Re: [Talk-ca] Importing buildings in Canada
I think the first problem to be addressed is the presence or absence 
of a local community.


In the north we have few mappers but lots of interested agencies and 
people in seeing the buildings imported.


Montreal I think is under control.  Toronto is in the process of 
sorting itself out but I'm unclear how much territory the Toronto 
local group covers.


Vancouver should be big enough to support a local group.  As should 
Calgary and Edmonton.


Ottawa is complete as is Gatineau.

It's the smaller cities and regions that would be my concern.  Often 
it will be by chance that two or more mappers meet occasionally.


So step one can we list the local groups?

I also have a problem with what happens if two people agree but 
haven't done any mapping are they a local group?


Step two to me would be a consensus on how to tackle those areas 
without a local group and I think Daniel's suggestion would be a way 
forward in this area.


Cheerio John



James wrote on 2019-12-24 1:28 PM:
wasn't there talk about this before and someone blocked it because of 
non-square buildings and the resulting discussion was that each 
community was going to decide if they want to import or not?


On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, <mailto:jfd...@hotmail.com>> wrote:


Hi Group!

I am currently working on a proposal which, I hope, will bring
consensus among the community and relaunch the import of ODB
footprints (StatCan). The proposal should be ready in a few
weeks, or sooner.

In the meantime, I suggest to all those who are interested to
take note of the observations I made regarding these data. This
information can be found in the OSM wiki (1). According to OSM
import guideline requirements, it describes the data to import.
At the same time, I updated the Canada-federal section of the
Data Potential wiki page (2).

I will be offline in the next few days, so if you have any
questions/comments, please be patient :-)

Daniel

1 -
https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

2 -

https://wiki.openstreetmap.org/wiki/Potential_Datasources#Federal_.28Open_Government.29

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



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


--
Sent from Postbox <https://www.postbox-inc.com>


--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

I think the first problem to be addressed is the presence or absence of 
a local community.


In the north we have few mappers but lots of interested agencies and 
people in seeing the buildings imported.


Montreal I think is under control.  Toronto is in the process of sorting 
itself out but I'm unclear how much territory the Toronto local group 
covers.


Vancouver should be big enough to support a local group.  As should 
Calgary and Edmonton.


Ottawa is complete as is Gatineau.

It's the smaller cities and regions that would be my concern.  Often it 
will be by chance that two or more mappers meet occasionally.


So step one can we list the local groups?

I also have a problem with what happens if two people agree but haven't 
done any mapping are they a local group?


Step two to me would be a consensus on how to tackle those areas without 
a local group and I think Daniel's suggestion would be a way forward in 
this area.


Cheerio John



James wrote on 2019-12-24 1:28 PM:
wasn't there talk about this before and someone blocked it because of 
non-square buildings and the resulting discussion was that each 
community was going to decide if they want to import or not?


On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, > wrote:


Hi Group!

I am currently working on a proposal which, I hope, will bring
consensus among the community and relaunch the import of ODB
footprints (StatCan). The proposal should be ready in a few weeks,
or sooner.

In the meantime, I suggest to all those who are interested to take
note of the observations I made regarding these data. This
information can be found in the OSM wiki (1). According to OSM
import guideline requirements, it describes the data to import. At
the same time, I updated the Canada-federal section of the Data
Potential wiki page (2).

I will be offline in the next few days, so if you have any
questions/comments, please be patient :-)

Daniel

1 - https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings

2 -

https://wiki.openstreetmap.org/wiki/Potential_Datasources#Federal_.28Open_Government.29

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



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


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

Re: [Talk-ca] Postcodes in Canada

[john whelan]

Canadian Postal Codes in urban areas are blocks of roughly 50 buildings
which makes them extremely interesting to use for GIS studies.  Average
income etc.

Both in the UK and Canada many people would rather type in a 6 character
code than a street address with city when looking for directions to a
location.  In the UK postcodes where restricted to a street which meant
when computer storage was expensive we used something called a prem code
which was the building number followed by the postcode and generated the
full address when required.  Canadian postcodes can spam different streets
especially in areas served by supermail boxes.

If I use  the example of my own address.  The house was built in the City
of Cumberland, but my postal address was Navan.  Then Canada Post changed
the postal address to Orleans which is interesting as Orleans does not
exist as a municipality.  Apparentyl there are one or two other places in
Canada that Canada Post doesn't use the municipality name in the postal
address.  Currently it is in the City of Ottawa so some mail gets addressed
Orleans and some Ottawa.  I had an elderly aunt who always addressed my
Christmas card to Navan and included the postcode until she died and each
year the post office would attach a sticker saying the postal address was
wrong.  The post code remains the same over all the changes.

So yes a postcode can change but from time to time they are more stable
than the official postal address.

As long as one address contains the postcode then Nominatim will find it
which means it can be used for directions.  You might be 30 buildings away
but you are in the right general area so I think adding them as part of a
street address is of value.

Cheerio John



On Thu, 3 Oct 2019 at 11:24, Justin Tracey  wrote:

> In the US, ZIP Codes (the US postal code equivalent) are frequently
> emphasized to not correspond to geographic locations, but sets of
> addresses. Of course they frequently cluster according to geography (and
> the prefixes are indeed assigned to states and regions within the
> state), and are often used as stand-ins, but you can't make assumptions
> about continuity or proximity for the addresses they correspond with.
> Even though I can't find it explicitly worded that way (i.e., "post
> codes are address sets, not locations"), it seems to be the same
> situation here. Given that, the most "correct" thing to do would be
> tagging postal codes in addresses, and not as distinct entities.
>
> The Canada Post website has a tool to lookup the postal code for a
> particular address, so if it were released, wouldn't the data they use
> to supply that information be good enough for this? It doesn't quite
> solve people trying to navigate "to" a particular postal code, but it
> seems like that's an ambiguous request anyway.
>
>  - Justin
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Postcodes in Canada

[John Whelan]

I had long discussions with Canada Post about postcodes years ago.  I 
was working with Treasury Board standards group at the time looking at 
addressing standards and I'm very aware of the limitations.


Rural post codes are very definitely an issue and not all postcodes used 
by Stats Canada and other government departments for example are 
physical locations.


Open Data would be nice but realistically it isn't going to happen in 
the short term.


Having said that what is doable is spotting postcodes that do exist but 
are not in OpenStreetMap then tagging a building with an address that 
includes a postcode in that postcode.


For example  if K4A 1M7 exists in the map then it would be reasonable to 
assume that K4A 1M6 - 1M1 should also exist so could be looked for.


Cobourg is an example where there are far fewer postcodes than one might 
like to see.


Cheerio John



Kevin Farrugia wrote on 2019-10-02 8:53 PM:
I don't want to rain on the postal code party, and maybe I'm a little 
jaded from using the data, but I use the Postal Code Conversion File 
(PCCF) from Statistics Canada (who get it from Canada Post) at work.  
In general I would say that the postal code points are in mediocre shape.


Some things I've noticed about the data and postal codes in general:
* There is usually one postal code point per postal code, although 
there are cases where there can be several points for a postal code.  
For example, with some postal codes, if you were to make them 
polygons, would generate multiple polygons that are intersected by 
other postal codes.
* Postal codes, especially rural ones, pop in and out of existence and 
so are a little harder to track and are less permanent than addresses.
* Postal codes will sometimes jump from one side of a road (even 
municipality) between years as they try to improve accuracy.
I would check out the Limitations section if you'd like to see more: 
https://www.canadapost.ca/cpc/assets/cpc/uploads/files/marketing/2017-postal-code-conversion-file-reference-guide-en.pdf


Forward Sortation Areas do exist as open data through Statistics 
Canada - StatsCan generates these FSA polygons based on respondents of 
the Census.  There are two limitations to this dataset on which I 
would advise against importing it into OSM:
1) Since businesses do not respond to the Census, they generally do 
not have FSAs for large industrial areas.  These areas are covered by 
the nearest FSA that they know about/can define, but this can also 
cause some movements of boundaries from Census to Census.
2) Because postal codes are created for the purpose of mail sortation 
and delivery, the FSA boundaries StatsCan is able to create are not exact.
Here's the reference document if you're interested: 
https://www150.statcan.gc.ca/n1/pub/92-179-g/92-179-g2016001-eng.htm


If at some point they did release it as open data, it might be decent 
enough for the purposes of general geocoding in OSM, I just don't want 
people to think it's as well maintained and reliable as some other 
types of government data.


-Kevin (Kevo)


On Wed, 2 Oct 2019 at 20:39, James <mailto:james2...@gmail.com>> wrote:


funny you should mention geocoder.ca <http://geocoder.ca>

The owner of that website was sued by Canada Post because he was
crowd sourcing postal codes. Just recently (2 ish years ago?) they
dropped the lawsuit because they knew they didnt have a case(He
came to the Ottawa meetups a couple of times)

On Wed., Oct. 2, 2019, 8:08 p.m. Jarek Piórkowski,
mailto:ja...@piorkowski.ca>> wrote:

Yeah, Canada Post currently considers postal codes their
commercial
data. Crowd-sourcing all or a substantial amount of full codes
seems
infeasible. Crowd-sourcing the forward sortation areas (the
first A1A)
seems difficult since verifiability is going to be a problem
especially around the edges of the areas.

The website OpenStreetMap.org returns results for some postal
codes
from a third-party database https://geocoder.ca/?terms=1 which
is not
ODbL-compatible either.

Partial mapping is causing some problems with tools like Nominatim
that attach the nearest tagged postcode to search results, often
resulting in improper postal codes for reverse address lookups,
however that is arguably a tooling problem and not an OSM
problem per
se.

This isn't going to be pretty until Canada Post is persuaded
to free
the data. Call your MP, everybody.

--Jarek

On Wed, 2 Oct 2019 at 17:38, john whelan
mailto:jwhelan0...@gmail.com>> wrote:
>
> " The number one request on open.canada.ca
<http://open.canada.ca> is to open the postal code database. 
Feel free to add your vote.
https://open.canada.ca/en/suggested-datasets;
>
  

Re: [Talk-ca] Postcodes in Canada

[John Whelan]

I seem to recall the case was dropped as well. Having sad that I think 
the best way forward is


" The number one request on open.canada.ca <http://open.canada.ca> is to 
open the postal code database.  Feel free to add your vote. 
https://open.canada.ca/en/suggested-datasets;


and also add in a building that has a missing postcode.

For example I'm not sure a commitment from the "Stop Climate Change 
Party " to make them Open Data should mean we all vote for this party.  
I think current MPs are too busy with the election at the moment.


Cheerio John


James wrote on 2019-10-02 8:38 PM:

funny you should mention geocoder.ca <http://geocoder.ca>

The owner of that website was sued by Canada Post because he was crowd 
sourcing postal codes. Just recently (2 ish years ago?) they dropped 
the lawsuit because they knew they didnt have a case(He came to the 
Ottawa meetups a couple of times)


On Wed., Oct. 2, 2019, 8:08 p.m. Jarek Piórkowski, 
mailto:ja...@piorkowski.ca>> wrote:


Yeah, Canada Post currently considers postal codes their commercial
data. Crowd-sourcing all or a substantial amount of full codes seems
infeasible. Crowd-sourcing the forward sortation areas (the first A1A)
seems difficult since verifiability is going to be a problem
especially around the edges of the areas.

The website OpenStreetMap.org returns results for some postal codes
from a third-party database https://geocoder.ca/?terms=1 which is not
ODbL-compatible either.

Partial mapping is causing some problems with tools like Nominatim
that attach the nearest tagged postcode to search results, often
resulting in improper postal codes for reverse address lookups,
however that is arguably a tooling problem and not an OSM problem per
se.

This isn't going to be pretty until Canada Post is persuaded to free
the data. Call your MP, everybody.

--Jarek

On Wed, 2 Oct 2019 at 17:38, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>
> " The number one request on open.canada.ca
<http://open.canada.ca> is to open the postal code database.  Feel
free to add your vote. https://open.canada.ca/en/suggested-datasets;
>
    > Cheerio John
>
> On Wed, 2 Oct 2019 at 13:32, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>>
>> On the import mailing list there is a proposal to import
postcodes in the UK one of the reasons given was that many like to
input a postcode to get directions on smartphones using things
like OSMand.
>>
>> I don't think an Open Data source with the correct licensing is
available in Canada but OSMand appears to be able to use the
postcode if it is entered in the map as part of the address.  Is
there any Open Data that might be useful?
>>
>> I don't know if it is possible but could something be used to
extract postcodes in the current map and from there perhaps we
could come up with a list of missing postcodes that need one
address with it in mapped?
>>
>> As a minimum if you could add a few in you know from local
knowledge that might help fill in some gaps.
>>
>> Thoughts
>>
>> Thanks John
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca

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



--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Postcodes in Canada

[john whelan]

" The number one request on open.canada.ca is to open the postal code
database.  Feel free to add your vote.
https://open.canada.ca/en/suggested-datasets;

Cheerio John

On Wed, 2 Oct 2019 at 13:32, john whelan  wrote:

> On the import mailing list there is a proposal to import postcodes in the
> UK one of the reasons given was that many like to input a postcode to get
> directions on smartphones using things like OSMand.
>
> I don't think an Open Data source with the correct licensing is available
> in Canada but OSMand appears to be able to use the postcode if it is
> entered in the map as part of the address.  Is there any Open Data that
> might be useful?
>
> I don't know if it is possible but could something be used to extract
> postcodes in the current map and from there perhaps we could come up with a
> list of missing postcodes that need one address with it in mapped?
>
> As a minimum if you could add a few in you know from local knowledge that
> might help fill in some gaps.
>
> Thoughts
>
> Thanks John
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Postcodes in Canada

[john whelan]

On the import mailing list there is a proposal to import postcodes in the
UK one of the reasons given was that many like to input a postcode to get
directions on smartphones using things like OSMand.

I don't think an Open Data source with the correct licensing is available
in Canada but OSMand appears to be able to use the postcode if it is
entered in the map as part of the address.  Is there any Open Data that
might be useful?

I don't know if it is possible but could something be used to extract
postcodes in the current map and from there perhaps we could come up with a
list of missing postcodes that need one address with it in mapped?

As a minimum if you could add a few in you know from local knowledge that
might help fill in some gaps.

Thoughts

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

Re: [Talk-ca] Importing building and routing info regionally/locally (Jonathan)

[john whelan]

I was under the impression that most buildings in both Port Hope and
Cobourg had been manually mapped.

Now the outlines have been done it really needs boots on the ground to add
detail.  There are addresses from Canvec which give an address range so
Stats might have something better but I'm not sure.

What exactly are you looking for?  I'm sure if you and Kelsey were to sit
down over a mug of coffee as the local mappers to the area you may decide
that a buildings import would be useful but I'm not sure how many more
buildings remain to be mapped in the area.

Cheerio John

On Wed, 2 Oct 2019 at 06:10, Jonathan Brown  wrote:

> Ditto Kevin’s post. Erik, I live in Cobourg and have an interest in
> working with local mappers to map Northumberland County. At the moment we
> only have one novice (myself) and Kelsey Saunders, a GIS grad.
>
>
>
> Jonathan
>
>
>
>
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Adding buildings.

[john whelan]

 OpenStreetMap is highly decentralised which is both one of its strengths
and also one of its weaknesses.

There are a number of sources of building data, the first is an experienced
mapper adding in buildings with something like JOSM and the buildings_tool
plugin working from Microsoft imagery.  Esri, and Maxar and Mapbox
satellite imagery are also available.  That one is the least contentious
and is acceptable to everyone.

Second is iD which is the default mapping tool on the OSM web page.  You
can map buildings accurately with this one but in inexperienced hands you
get some very poor results.  Pierre noted in disaster mapping with new
mappers the results were really very bad.  There is something called a
mapathon where inexperienced mappers are invited to map.  Yes it gets a lot
of data into the map but the clean up effort required afterwards is fairly
horrendous.  Stats Canada pilot project was going to be based on this until
they were persuaded to go Open Data and use the City of Ottawa's Open Data
and the import process.

In Ottawa today practically every building has been mapped and has the
correct address.  There are one or two new buildings that haven't yet been
added to the map.  It took a fair amount of effort and organisation and
included help from Mapbox.  One problem was the license for the data.
Toronto has Open Data but the license has not been confirmed to align with
OpenStreetMap.

Although there are guidelines the authoritative body in OpenStreetMap is
consensus of the local mappers.  So Ottawa local mappers decided the import
could go ahead, were very involved in it and were happy with the data
quality. We'd seen iD mapping of buildings before and the City of Ottawa
data was fairly good.

After the pilot there was no serious money available at Stats so the second
part was going to be "community led".  They managed to talk to various
municipalities to allow them to release the municipality data under the
Stat Can license.  Following a discussion in talk-ca I put forward the
formal import plan.  The data quality was different for each municipality
and was questioned.

Normally you look at the client requirements to see what is required.  This
is something that OpenStreetMap very rarely does.  Mappers basically map.
Each has their own individual standard of what is acceptable.  For your
purposes if the angle of the corners isn't quite 90 degrees it really
doesn't matter.  What you're interested in is something within two meters
of the right place.  However consensus requires agreement from everyone.

However the problem for you is the local mappers in Toronto and I assume
York would like a higher standard even if it means fewer buildings get
mapped.

Today we have two other sources of building data that could be imported.
One is the Microsoft building data and the other is NR Can LiDAR data but
neither are much use without the local mappers support.

Some courier companies have hired mappers to add data to the map.
Bangladesh is one area where this is done.  Some are very good, some are
not so good.  I don't recommend this route, one danger would be they'd just
import the Microsoft buildings and charge you for mapping then someone
would challenge the data and have it removed.

If you have a specific problem area email me directly and I have been known
to add in buildings with JOSM.

Once we get the building outlines added then adding the address is fairly
simple with a smartphone and something like StreetComplete.  Also Stats
Canada has address information that can be imported.

Does that help clarify and define the problem?

Thanks

Cheerio John

On Mon, 30 Sep 2019 at 22:03, Eric Geiler  wrote:

> Team Canada, (unsure who this should be address to)
>
>
>
> We are a local/regional courier and trucking company in southern Ontario
> with a decent sized fleet.  We are using Mapbox for our mapping / nav
> engine, therefore subject to using OSM data.  We have noticed a number of
> “issues/lack of data” for southern Ontario.  This ranges from lack of lane
> info, to lack of buildings, missing streets, missing exit/on-ramps to for
> Hwy 400 (which we added, and had Mapbox expedite the changesets) as it
> affected navigation for our drivers.
>
>
>
> We are currently using a few devices to provide street level imagery via
> Mapillary, with a push coming shortly to map 1000km per day of street
> imagery.  We are currently mapping about 250km per day in York Region.  Our
> internal goal is to provide /gathered street level imagery for 75% York
> Region by end of January 2020.
>
>
>
> We are not in a position to provide map edits etc, as due to staff
> resources and lack of experience, our staff are not suited to become ‘map
> editors’ as our core business is transportation.  We are just trying to
> assist the editors with accurate ground level info.
>
>
>
> I would be interested in further understanding how we can become involved
> on a regional level to improve OSM in southern Ontario.
>
>
>
>
>

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

I'm glad to see Toronto getting involved once more.

The original idea for using Open Data to import buildings followed on 
from a group of Toronto mappers who imported address information for a 
new sub division that was not available in CANVEC from Stats Canada 
after very carefully checking that the licenses etc aligned.


There was discussion in Talk-ca at the time before the import was done.

Cheerio John

Nate Wessel wrote on 2019-09-30 12:14 AM:


Hi Steve,

Thanks for posting the event! I just RSVPed.

I think a separate import event would probably be helpful - somewhere 
with wifi and outlets for laptops, probably not a bar. Perhaps we can 
book a meeting room at a public library or something?


I can poll some of the more active local editors to find a time that 
works well for people. Once we have a time and place it would be good 
to post something to the meetup group as well as here, Slack, etc.


If you or anyone else on the list feels like taking charge of this I'm 
happy to defer - otherwise I may try to organize something in the next 
month or so as I have time and energy.


Thanks,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2019-09-28 6:37 p.m., Steve Singer wrote:

On Sat, 28 Sep 2019, Nate Wessel wrote:



I for one would be happy to support a local effort to import high 
quality buildings in Toronto and/or the GTA. I
think if we can actually meet up face to face our discussions may 
remain a bit more civil and productive. Hopefully

consensus will be a bit easier to achieve with smaller groups too!

I see that the OSM Toronto meetup doesn't have any upcoming 
events... Would others in the GTA be interested in
planning a meet up to talk about a local import plan? Is anyone on 
the list in charge of organizing these?


I am one of the organizers of the OSM Toronto meetup.

I've now posted the regular monthly mappy hour meetup for the Toronto 
OSM group. I had been meaning to do this anyway.


I'm also happy to post a special event dedicated to discussing an 
import in the GTA if people are interested.







Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com

On 2019-09-28 1:03 p.m., Jarek Piórkowski wrote:

Hi all,

To be a bit more positive:

If we want to get buildings on the map, but we can't get Canada-wide
data improved by Statcan to a standard acceptable to all mappers in
Canada, IMO the best bet will be to split this into much smaller
batches and support local mappers who would be interested in getting
the data in.

In my browsing of neis-one.org statistics for Canadian mappers and the
Notes active in Canada, I've seen active mappers and small communities
in at least Halifax, Calgary, Edmonton, Vancouver, and Victoria
metros, and I might have missed some more. Many of them I have never
seen on the mailing list (which is a whole another issue), but
contacting them directly (via osm.org messages?), asking if they are
aware of other local mappers, if they would be interested in having
building data, if it is of acceptable standard to them, and if they
would be willing to help validate-and-upload the data (with help of
the central tooling) might get some success.

I hope that will go better than the previous attempt which could be
read - uncharitably - as a bunch of mailing list insiders throwing
federal data over the fence with little consultation.

It'll be a lot of work communicating and organizing. But getting
buildings is a lot of work, and if data producers can't do better,
whoever wants the buildings will have to do the work. Maybe with more
local support even the imports list will be more bearable.

Thanks,
--Jarek

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






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


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

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

My suggestion would be to amend and clean up the original import plan to 
split out the country into regions and have a regional coordinator for 
each region based on local input.  I'd also add in the two other data 
sources as alternative data sources.


The reason for this approach is an amended import plan might be more 
acceptable to the import mailing list than new plans and in our smaller 
regions there may not be the resources to put together a full import 
plan for a thousand buildings.


Cheerio John

Nate Wessel wrote on 2019-09-28 1:37 PM:


I for one would be happy to support a local effort to import high 
quality buildings in Toronto and/or the GTA. I think if we can 
actually meet up face to face our discussions may remain a bit more 
civil and productive. Hopefully consensus will be a bit easier to 
achieve with smaller groups too!


I see that the OSM Toronto meetup 
 doesn't have any 
upcoming events... Would others in the GTA be interested in planning a 
meet up to talk about a local import plan? Is anyone on the list in 
charge of organizing these?


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2019-09-28 1:03 p.m., Jarek Piórkowski wrote:

Hi all,

To be a bit more positive:

If we want to get buildings on the map, but we can't get Canada-wide
data improved by Statcan to a standard acceptable to all mappers in
Canada, IMO the best bet will be to split this into much smaller
batches and support local mappers who would be interested in getting
the data in.

In my browsing of neis-one.org statistics for Canadian mappers and the
Notes active in Canada, I've seen active mappers and small communities
in at least Halifax, Calgary, Edmonton, Vancouver, and Victoria
metros, and I might have missed some more. Many of them I have never
seen on the mailing list (which is a whole another issue), but
contacting them directly (via osm.org messages?), asking if they are
aware of other local mappers, if they would be interested in having
building data, if it is of acceptable standard to them, and if they
would be willing to help validate-and-upload the data (with help of
the central tooling) might get some success.

I hope that will go better than the previous attempt which could be
read - uncharitably - as a bunch of mailing list insiders throwing
federal data over the fence with little consultation.

It'll be a lot of work communicating and organizing. But getting
buildings is a lot of work, and if data producers can't do better,
whoever wants the buildings will have to do the work. Maybe with more
local support even the imports list will be more bearable.

Thanks,
--Jarek

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



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


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

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

And I totally agree.  Because the Stat Can data has come from many 
sources the data quality is variable to put it politely.  The Microsoft 
data has been shown in the US to also be of variable quality.  I'm not 
so sure about the NR Can LiDAR data hopefully it is at least consistent.


If we look at the history of the project then we can get an idea of how 
we came to be where we are.


First I wanted to import all the bus stops in Ottawa because only by 
importing could you ensure you had all the stops with their reference 
numbers but the City of Ottawa Open Data license did not align with 
OSM.  I was also talking to Treasury Board and explained to them that 
their Open Data license version 1 didn't align with OSM so we couldn't 
use their data.  Five years later TB released their Open Data license 
version 2 which they felt did align.


Stat Can has two types of project, pilot ones and ones that earn money. 
The original pilot was based on Ottawa and Gatineau and was for two 
years.  Their original plan was mapathons using iD.  I was impressed 
when a stat can employee managed to accurately map a building using iD 
during a presentation.  I hadn't thought it was possible after some of 
the efforts I'd seen in HOT mapping.   Fine except that it requires a 
lot of mappers and I think Fredrick has commented this sort of mapping 
with new mappers needs a lot of clean up effort sometimes more than 
required for an experienced mapper to map it right in the first place. 
Montreal has identified there just aren't enough experienced mappers 
available.


I worked at Stats Canada for a number of years.  The corporate culture 
is very different to OSM.  It makes its money by selling data.  Want to 
open a new coffee bar? Stats Canada will combine its data to sell you 
the ideal spot based on residents' income etc..  I had a meeting with 
Stats Canada, City of Ottawa planning department, an Open Data 
specialist from Carlton University, someone from Metrolink who had added 
data to openstreetmap to help people find the nearest bus stop and a 
couple of HOT board members.   We convinced Stats Canada to change the 
direction of the pilot to use Open Data rather than go the mapathon 
route partly for data quality reasons and partly because I didn't think 
we could find the mappers to map the buildings completely.  The Stat Can 
involvement meant the City of Ottawa was persuaded to change its Open 
Data license to the same as the TB one.  That took time and had to go to 
council for approval.  There was a lot of discussion with the local 
community and it was they who organised and did the import.   The local 
group worked nicely together and had a range of skill sets in the 
group.  I actually played more of a connecting role than anything else.


The import was challenged on the data license amongst other things but 
eventually the OSM legal working group was very kind and ruled the 
license was acceptable.  Stats is very interested in added detail to 
buildings.  I was very interested that we could now import the bus stops.


I think you picked up on the fact that the buildings mapped in a 
mapathon were less than ideal.  I was involved in one in Ottawa and just 
taught the new mappers to use JOSM and the building_tool.  That produced 
more buildings per mapper hour and they were fairly accurate.  I must 
confess not every attached garage was mapped in detail.


I seem to recall Mapbox being involved in the Maperthons in some way.

The Stats Can involvement meant we saw some interest from schools.  What 
I was interested in was added detail so mapped a couple of thousand 
buildings in Ontario using JONM and the building_tool so details could 
be added easily.  We got two addresses added.  Apparently in Ontario the 
provincial government has purchased ESRI for school children to learn 
about GIS.


At the end of the pilot the money had run out.  Stats covered some of 
the costs involved in the HOT summit that was held in Ottawa and during 
that summit phase two was launched but without any real funding.


What Stats could do though was release data from the municipalities 
under the government Open Data license and that is what they did.  As 
Jarek has pointed out following the import process is stressful so I 
volunteered to do the paperwork and submit the plan.  There was some 
discussion on talk ca and the idea surfaced to go with one plan rather 
than divide the country up.  So that's what I did.


Today we have three sources of data that could be imported, and I 
suspect the two that are not municipal data are more consistent.  We 
still have the original plan of mapathons with iD floating around.


My person view is the imported data quality is better than the mapathon 
approach but to go forward from here I think it needs to be re-planned 
and a new import plan(s) drawn up.


I don't think Stats have any real funding available at the moment.  They 
may find an odd hour in a quiet time but its coming up to 

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

Both your input and Nate's are useful in that at least they confirm my thoughts 
that there is little chance of moving forward on a Canada wide basis.

Hopefully the Toronto mappers can sort something out for Toronto and the rest 
will follow in time.

As a Toronto mapper, I'm happy to load data into JOSM and press Q on
it if that's approved, but for sake of mental health I will not be
posting to the imports mailing list.

and I totally agree with that comment.

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

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

The Stat Can data comes directly from the municipalities so each 
municipality will have a different quality of data.  The Microsoft and 
NR Can data maybe more consistent.


Both your input and Nate's are useful in that at least they confirm my 
thoughts that there is little chance of moving forward on a Canada wide 
basis.


Hopefully the Toronto mappers can sort something out for Toronto and the 
rest will follow in time.  I seem to recall Montreal thought it would 
sort something out internally was it as soon as they reached three 
mappers per square kilometer?


Thanks John



Jarek Piórkowski wrote on 2019-09-27 7:47 PM:

On Fri, 27 Sep 2019 at 11:45, john whelan  wrote:

I do know that a number of departments and agencies would like to use buildings 
and although they can use the open data sources using OSM would be more 
convenient.

Then you can encourage these agencies to urge Statcan to improve the
quality of their data.

If we expect some volunteers to come up with a building squaring
algorithm and implementation, surely an agency whose whole job is
collecting and massaging data can do better.


I'm not sure what if anything is happening at the moment.

Nothing.


My gut feeling is with three sources of data we'll see new mappers importing in 
buildings without going through an import process.  Are we content to let that 
happen?

It seems basically impossible to prevent this, and given the number of
active editors in Canada who care about this, would be difficult to
even detect this. That would make the question of whether we're
content about it moot.

That's the effect of strict import guidelines here - those who would
like to keep to them usually give up, and those who don't care (or
don't know) go ahead anyway. (See, for example, trees in London, Ont.)
That works in Germany which has 3 nitpicking OSM editors per square
kilometer to notice, less so in Canada.


Have whoever it was who was going to come up with a preprocessing plan done so?

There's been work towards this but my understanding is that it's far
from complete and stalled.


Can we get a consensus about what to do next?

I don't believe so. Sorry - you asked.

Thanks,
--Jarek


--
Sent from Postbox <https://www.postbox-inc.com>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[John Whelan]

I'll try to sum up my understanding.

Currently your view is the existing import plan for Canada building 
imports does not meet the import guidelines and cannot be amended to 
meet them.  I was hoping that something might have happened in the last 
six months on the preprocessing of data side which would have meant we 
could have got a consensus to move forward but no movement on this has 
apparently happened.


Second no consensus exists for importing all the buildings or how it 
should be done.  My personal view is originally I didn't think this was 
achievable for all Canada.  There were simply too many players and 
getting complete unanimous consensus was always going to be a problem 
but it was found the most difficult part of the Ottawa buildings import 
was the import mailing list and the OSM guidelines for imports so based 
on input from outside the original Ottawa group the decision was made to 
go for a Canada wide import plan to minimise the requirements for 
multiple people to submit import plans.  The technical side of the 
import by comparison was fairly simple and much more interesting.  So it 
was worth trying a country wide import plan.


The Ottawa import was thrashed out over coffee and the local mappers are 
happy with the data quality even though some non-local mappers were not.


I still have reservations about the ability of some of the smaller 
groups of mappers to get an import plan through all the loops.


So I think we are at the point where ideally we expect local groups to 
come up a decision on data quality and submit individual import plans. 
All three sources, Stat Can, Microsoft and NR Can LiDAR data meet the 
licensing OpenStreetMap licensing requirements but your plan will have 
to specify which license is being used for the import and how it meets 
the OSM guidelines.


I note some imports in Africa are done by mappers who live outside 
Africa so I'm unclear if you need to live in the area to import or not 
or how far away you can be and still be counted as a local mapper.


Since in Nate's opinion the Canada wide import plan does not meet the 
guidelines please do not use it as a template.


Have fun

Cheerio John






Nate Wessel wrote on 2019-09-27 12:03 PM:


John,
You are once again purposely mischaracterizing my position on this and 
I do not appreciate it one bit. Your import did not follow the import 
guidelines and was not approved by the broader community. It was not 
sent out to the mailing list, it was barely documented, it was not 
posted on the import page on the wiki... I could go on. I was not the 
only person who had a problem with it - I was just the first to say 
something. The buildings imported in Toronto were very low quality IMO 
and the changes were happening very, very quickly and without notice.


But we do not need to rehash old fights.

I would like to see buildings (re)imported in Toronto (the rest of 
Canada is not really my business), but I would like to see it done 
right. I can elaborate what I mean by that, but so can the archives of 
this mailing list. If people are interested in engaging in a serious 
discussion about moving forward with a building import for Toronto, I 
am happy to engage constructively with that.


Respectfully,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com <http://www.natewessel.com>

On 2019-09-27 11:44 a.m., john whelan wrote:
From memory we have imported Ottawa's buildings under the correct 
license (Stat Can so the federal government's open data license) and 
the quality was deemed acceptable by the local mappers.


Then we opened up a second import plan to import buildings and a fair 
number were imported.  This included an task manager set up with 
tiles to assist the mapping.


The data sources were different as each municipality created their 
own source.


My understanding is some mappers thought the data should be 
preprocessed and two or three were going to come up with a plan to 
preprocess the data.


About that time an American mapper, Nate, who was living in Toronto 
took exception to 1,000,000 buildings being imported in Western 
Canada and requested the DWG to remove them without waiting for 
discussion on talk-ca to address his concerns.


We do have three sources of correctly licensed data, the Stat Can 
data sets, the Microsoft data sets, and the NR Canada LiDAR data.


I do know that a number of departments and agencies would like to use 
buildings and although they can use the open data sources using OSM 
would be more convenient.


I'm not sure what if anything is happening at the moment.

Are we expecting local groups to draw up their own import plan as 
Ottawa did since we seem to be unable to get a consensus across Canada?


My gut feeling is with three sources of data we'll see new mappers 
importing in buildings without going through an import process.  Are 
we content to let that happen?


Have whoever it was who was going to come up with a preproc

[Talk-ca] Importing buildings in Canada

[john whelan]

>From memory we have imported Ottawa's buildings under the correct license
(Stat Can so the federal government's open data license) and the quality
was deemed acceptable by the local mappers.

Then we opened up a second import plan to import buildings and a fair
number were imported.  This included an task manager set up with tiles to
assist the mapping.

The data sources were different as each municipality created their own
source.

My understanding is some mappers thought the data should be preprocessed
and two or three were going to come up with a plan to preprocess the data.

About that time an American mapper, Nate, who was living in Toronto took
exception to 1,000,000 buildings being imported in Western Canada and
requested the DWG to remove them without waiting for discussion on talk-ca
to address his concerns.

We do have three sources of correctly licensed data, the Stat Can data
sets, the Microsoft data sets, and the NR Canada LiDAR data.

I do know that a number of departments and agencies would like to use
buildings and although they can use the open data sources using OSM would
be more convenient.

I'm not sure what if anything is happening at the moment.

Are we expecting local groups to draw up their own import plan as Ottawa
did since we seem to be unable to get a consensus across Canada?

My gut feeling is with three sources of data we'll see new mappers
importing in buildings without going through an import process.  Are we
content to let that happen?

Have whoever it was who was going to come up with a preprocessing plan done
so?  Has it been accepted by the rest of us?

I note that Pierre has noted there is now a validation process in JOSM for
correcting buildings that are not quite 90 degrees on the corners.  Would
an acceptable approach be to import then return to check the angles on the
corners and correct them?

Does Nate still have unaddressed concerns about buildings being imported in
Western Canada?

Can we get a consensus about what to do next?

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

Re: [Talk-ca] Présentation à SotM2019 sur l'analyse des bâtiments

[John Whelan]

Where are we up to with imported buildings in Canada?

I understood someone was looking at some routines to run on the data 
before import for Microsoft, Stats Canad and the Natural Resources 
Canada LiDAR data sources.


Has that been done for Canada as a whole or are we at the point where 
local mappers are deciding to import their local area?


I note there seems to be a fair number of buildings in many cities but 
apart from Ottawa I don't think any are complete.


Thanks John

Pierre Béland via Talk-ca wrote on 2019-09-24 6:47 PM:

Bonjour,

Je suis de retour du SOTM-2019 à Heidelberg où j'ai pu me rendre grâce 
à un Scholarship de la Fondation OSM.  Des présentations et rencontres 
fort intéressantes. Les videos des présentations sont déja disponibles 
à partir du lien https://media.ccc.de/b/conferences/sotm2019


Vous pouvez voir le video de ma présentation «OSM Quality Mapping : 
Metrics to monitor Buildings outbounds»
à l'adresse 
https://media.ccc.de/v/sotm2019-1046-osm-quality-mapping-metrics-to-monitor-buildings-outbounds
Les diapos sont disponibles sur le Blog OpendatalRDC. Je prévois aussi 
y publier au cours des prochaines semainesles analyses détaillées des 
projets analysés. 
https://github.com/opendatalabrdc/Blog/blob/master/SOTM_2019-OSM-Quality-Mapping--Metrics-to-monitor-Buildings-outbounds_Pierre_Beland.odp


Je vais aussi réviser le contenu du répertoire OQ_Analysis sur Github 
avec la nouvelle version des fonctions PostGIS contenant les nouvelles 
variables d'analyse que j'ai ajouté au projet.


Lors de la présentation, j'y ai fait une brève comparaison d'imports 
de données comparant Toronto et Dallas (import Microsoft). L'image 
Microsoft auquelle je fait référencepour l'Afrique dans ma 
présentations est accessible sur l'article de Blog Microsoft releases 
18M building footprints in Uganda and Tanzania to enable AI Assisted 
Mapping 
 


https://blogs.bing.com/BingBlogs/media/MapsBlog/2019/09/Extractions_MusomaTanzania.jpg

Sur cette image, Les données vectorielles de bâtiments observées sont 
en général rectangulaires. Par contre on observe certaines 
inexactitudes dans les géométries dérivées par les technique 
d'intelligence artificielle (angles inexacts ou plusieurs bâtiments 
regroupés).  J'en ai discuté avec les développeurs de Microsoft et 
nous avons convenu que ceci semble s'expliquer dans ce cas spécifique 
pour la Tanzanie par une moins grande qualité des images satellites.


J'ai brièvement examiné ces données pour le centre-ville de 
Saint-Jean-sur-Richelieuet constaté que les blocs de bâtiments y sont 
représentés dans les données Microsoft comme un seul bâtiment. Les 
techniques d'IA rencontrent donc le même problème que nous avons comme 
contributeurs avec difficulté de déterminer chaque bâtiment individuel 
à partir d'images non suffisamment précises.



Pierre


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

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

[john whelan]

Looks good to me and if Matthew has cast his eye over it and not spotted
anything major then I think we can safely say Ottawa is happy with it.

Cheerio John

On Mon, Sep 9, 2019, 9:57 PM Pierre Béland via Talk-ca, <
talk-ca@openstreetmap.org> wrote:

> Cela semble bien préciser, mais les collègues d'Ontario pourront mieux
> répondre.
>
> Pierre
>
> Envoyé à partir de Yahoo Courriel sur Android
> 
>
> Le lun., sept. 9 2019 à 3:11 PM, Jarek Piórkowski
>  a écrit :
> Hi Pierre,
>
> (I responded via email at first, but realized one more thing, so
> adding on and sending to talk-ca:)
>
> The proposed wiki addition does start with "In Ontario". However
> thanks bringing this up, as I realized I forgot to account for parts
> of Ontario where streets will be named in French - this change should
> not apply to those.
>
> I am changing the suggested wording to:
>
> In parts of **Ontario** that primarily name streets in English,
> street and road names containing initial "St." or "St" should only be
> expanded to "Saint" when "Saint" is common usage for that street. To
> be clear, this overrides the general rule
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> for "St." which does not stand for "street". As with other names in
> OSM, factors you might want to consider when determining common usage
> include spellings posted on street signs ("on the ground" rule),
> spellings used in local media, GeoBase street name data, and spellings
> used by official municipal sources including open data datasets. See
> discussion on talk-ca [0].
>
> Would this wording be fine for Ottawa and other bilingual areas, or am
> I missing a pitfall?
>
> Thanks,
> --Jarek
>
> On Mon, 9 Sep 2019 at 08:51, Pierre Béland  wrote:
> >
> > Marek
> >
> > Ces instructions ne s'appliquent pas à toutes les provinces. Il faudrait
> donc indiquer sur la page wiki à quelles provinces elles s'appliquent
> >
> > Pierre
> >
> > Envoyé à partir de Yahoo Courriel sur Android
> >
> > Le lun., sept. 9 2019 à 2:51 AM, Jarek Piórkowski
> >  a écrit :
> > Hello,
> >
> > I'm following up on the thread about saints and lack thereof in street
> > names from a couple of months ago (see archives [1] [2]).
> >
> > I would like to suggest the following wording added to Canadian
> > tagging guidelines at
> >
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Street_names
> > :
> >
> >In Ontario, street and road names containing initial "St." or "St"
> > should only be expanded to "Saint" when "Saint" is common usage for
> > that street. To be clear, this overrides the general rule
> >
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> > for "St." which does not stand for "street". As with other names in
> > OSM, factors you might want to consider when determining common usage
> > include spellings posted on street signs ("on the ground" rule),
> > spellings used in local media, GeoBase street name data, and spellings
> > used by official municipal sources including open data datasets. See
> > discussion on talk-ca [0].
> >
> > where [0] would be a link to this message/thread archive. (Comments on
> > the wording and suggestions appreciated!)
> >
> > Is anyone opposed to this change?
> >
> > I have attempted to advertise/announce this proposed change. This was:
> > - posted in this mailing list in March/April of this year (some quoted
> > below, see list archives for more discussion)
> > - I posted a note https://www.openstreetmap.org/note/1741334 in
> > Toronto with a link to this thread (supportive responses from Kevo and
> > DannyMcD)
> > - on April 10, sent a message [2] with a link to the note to editors
> > who were showing up as top editors on
> > http://osmstats.neis-one.org/?item=countries=Canada
> > (they aren't necessarily representative of the community, but it's
> > really the closest we can reasonably do given our current tooling) [3]
> > (no private message responses)
> > - posted on OSM Canada Slack on 17 August
> > https://osm-ca.slack.com/archives/CASP8UQNT/p1566053199044200
> > (supportive responses from Matthew Darwin and Eric Geiler)
> > - on August 27, sent a few more private messages to editors in top 50
> > on the stats page who had done Ontario edits [4] (no private message
> > responses)
> >
> > If you know of anyone else who might have a further opinion on this,
> > please forward as possible.
> >
> > Thanks,
> > --Jarek
> >
> >
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list

Re: [Talk-ca] Removing "WikiProject" prefix

[john whelan]

Sounds wonderful, but that is a purely personal comment.

Cheerio John

On Sat, Jul 20, 2019, 2:13 PM dcapillae,  wrote:

> Hi,
>
> I am Daniel, from Spain. I would like to change the name of the wiki
> pages related to the Canada mapping project to remove the "Wikiproject"
> prefix following the pages name conventions [1].
>
> The name of the pages related to the Canada mapping project would be
> "Canada" (name of place) instead of "Wikiproject Canada", as recommended
> by the wiki conventions. It is a change that I have already made in
> United States [2], Spain [3], and all Spanish speaking countries in the
> OSM Wiki [4], consulting with their communities beforehand. Hard work
> but good results.
>
> I could make the necessary changes, no problem, and also add the
> "Country" template [5] to the Canada project page, although this change
> is optional.
>
> Some questions from your OSMCanada Slack group:
>
> 1.-  What affect does it have on the wiki to be frank?
>
> Really, not much. Instead of "WikiProject Canada" the pages change to
> "Canada" (place name) to make direct reference to the country object of
> the mapping project, following the wiki conventions. The rest will
> remain the same (no changes).
>
> 2.- Will there be a redirect to Canada page?
>
> Of course. You can search for "Canada" directly in the wiki. And if
> someone shares a link to "WikiProject Canada", it will link directly to
> the Canada mapping project ("Canada" page in the wiki).
>
> 3.- Is it going to break old links to it?
>
> No, not at all. The redirects will be automatic.
>
>
> I have posted a message on the wiki about this subject [6]. Please,
> comment there if you want to send me your opinions.
>
>
> Thank you for your attention. Greetings from Spain!
>
> Regards,
>
> Daniel
>
>
> [1]
>
> https://wiki.openstreetmap.org/wiki/Wiki_organisation#Pages_naming_convention
>
> [2] https://wiki.openstreetmap.org/wiki/United_States
>
> [3] https://wiki.openstreetmap.org/wiki/Spain
>
> [4]
> https://wiki.openstreetmap.org/wiki/Category:Spanish_speaking_countries
>
> [5] https://wiki.openstreetmap.org/wiki/Template:Country
>
> [6]
>
> https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Canada#Removing_.22WikiProject.22_prefix
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] English and French translation required for some road names

[John Whelan]

In Ottawa highway names for the most part have both English and French.  
name:fr rue Sparks, name:en Sparks street.  If only name is present it 
is the English version.


Just to add confusion to your life.  There has also been a discussion 
about street names in Canada and I think the municipality is the 
authority so adding an English version in Quebec might cause problems. 
Could CNIB assist?


Cheerio John

Steven Abrams wrote on 2019-07-05 7:40 AM:
Hi all, I am working with Microsoft Research and we have an app called 
Microsoft Soundscape (on iPhone only currently) for the Visually 
Impaired and Blind communities. The app provides a 3D map experience 
and calls out to the user several points of interest and road names, 
all based on OSM data.
In Canada we have noticed that in the French speaking cities and areas 
of Quebec, that roads may be named "1e Avenue" or "1er Avenue".
I am assuming that this should be called out as "Première Avenue" in 
French and "First Avenue" in English. Is this correct?

But I have noticed that there is no translation for both languages.
Is it possible for some local OSM mappers to consider providing these 
translations so that apps can callout the names of roads accurately? 
i.e. a user using the French Language & Voice settings would hear 
"Première" and users using the English Language & Voice settings would 
hear "First"?
I have included a link to such a road where I have added the English 
translation.

https://www.openstreetmap.org/way/20443208
What are the thoughts here?
Thanks
Steven


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


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

Re: [Talk-ca] NRC building footprints - from lidar

[John Whelan]

Is it just Manitoba or all of Canada?

In which case do we want to revise the building import project.

Thanks John

keith hartley wrote on 4/27/2019 9:56 AM:

Hi all,
Canadian Geomatics posted this data set a few months back from Natural 
Resource Canada.

It's Building footprints from Lidar or high res imagery.
https://canadiangis.com/automatically-extracted-buildings-canadian-open-data.php?fbclid=IwAR22SaWwz7--LarDksVfcQuZ9RDgkVc421n9saJ_Lv8r6xq1qPSrouEF0Ww

https://open.canada.ca/data/en/dataset/7a5cda52-c7df-427f-9ced-26f19a8a64d6

From what I can tell when placing the data over imagery it's very bang 
on. Highly accurate, good shapes (unlike the bing files) and well 
placed. As far as I can tell no one else has uploaded these to OSM. 
The areas in manitoba are mainly where there's little to no other 
building info.
I can write an upload plan on Manitoba wiki as the data is complaint 
license wise. Anything else I should be looking for? The local mappers 
here are pretty excited about it.


Keith





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


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

Re: [Talk-ca] Open Data for Airdrie AB

[john whelan]

I'd check to see if it is included in the Stats Canada data first.  If not
then the buildings will be available in the Microsoft data which is
correctly licensed.

The open data licenses are a mine field.

Stats is looking a releasing more municipal Open Data under the Federal
Government license.

Cheerio John

On Tue, 23 Apr 2019 at 11:58, Joshua Kenney  wrote:

> If I can obtain explicit permission from the city, would I still need to
> wait for the LWG approval?
>
> --Joshua
>
> On 2019-04-22 16:03, Jarek Piórkowski wrote:
> > Hi Joshua,
> >
> > Welcome to OSM, and thank you for your contributions!
> >
> > To answer your first question: the non-building data sets (parks,
> > address points, bus stops, etc) are not currently importable without
> > further effort: we would have to get that exact licence (with text
> > including "City of Airdrie") approved by the OSM Licensing Working
> > Group. I don't know if the LWG would object to the attribution
> > requirements, possibly not, but the approval itself might take quite a
> > while anyway, as lawyer things don't move fast.
> >
> > --Jarek
> >
> > On Mon, 22 Apr 2019 at 15:42, Joshua Kenney 
> wrote:
> >> Hello everybody!
> >> Relatively new mapper here.  I've been working on mapping my home town,
> and a couple of other places I've been, for the past 3 or 4 months.
> >>
> >> I have found that my city of Airdrie, AB has a number of datasets
> available under an Open Data Licence:
> >>
> >> http://data-airdrie.opendata.arcgis.com/pages/our-open-licence
> >> The licence terms look straight forward enough, are there any
> additional steps I need to take to confirm compatibility with OSM?
> >>
> >> One of the datasets includes building footprints.  Would importing that
> get in the way of the import of the national data? Where can I access the
> national data to compare the quality?
> >>
> >> --Joshua
> >>
> >>
> >>
> >> ___
> >> Talk-ca mailing list
> >> Talk-ca@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Open Data for Airdrie AB

[john whelan]

I believe Toronto has been waiting a couple of years for approval from the
LWG to give you some idea of time frames.

Cheerio John

On Mon, 22 Apr 2019 at 18:05, Jarek Piórkowski  wrote:

> Hi Joshua,
>
> Welcome to OSM, and thank you for your contributions!
>
> To answer your first question: the non-building data sets (parks,
> address points, bus stops, etc) are not currently importable without
> further effort: we would have to get that exact licence (with text
> including "City of Airdrie") approved by the OSM Licensing Working
> Group. I don't know if the LWG would object to the attribution
> requirements, possibly not, but the approval itself might take quite a
> while anyway, as lawyer things don't move fast.
>
> --Jarek
>
> On Mon, 22 Apr 2019 at 15:42, Joshua Kenney  wrote:
> >
> > Hello everybody!
> > Relatively new mapper here.  I've been working on mapping my home town,
> and a couple of other places I've been, for the past 3 or 4 months.
> >
> > I have found that my city of Airdrie, AB has a number of datasets
> available under an Open Data Licence:
> >
> > http://data-airdrie.opendata.arcgis.com/pages/our-open-licence
> > The licence terms look straight forward enough, are there any additional
> steps I need to take to confirm compatibility with OSM?
> >
> > One of the datasets includes building footprints.  Would importing that
> get in the way of the import of the national data? Where can I access the
> national data to compare the quality?
> >
> > --Joshua
> >
> >
> >
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Open Data for Airdrie AB

[john whelan]

For building footprints there are two sources of open data that are
correctly licensed.  One is Microsoft's building footprints and the other
is the Stat Can released data.  The Stats Canada data is basically the
municipal data released under the federal government's licence.

I suggest you first check with James and ask him if your city's data is in
the Stat Can data set.

The next step having sorted out a source of open data that has an approved
licence is to work out a process to include the data.

There is a single import of the Stat Can buildings in progress.  However a
Toronto mapper took exception to a million buildings being added mainly in
the West of Canada and asked the DWG to remove them.

A group of three mappers are looking at ways to "cleanse" the data using
open source software.  Once they have arrived at an agreed acceptable
solution then I assume the Canada wide building import will continue in
some way.

So you can hang on or you can submit your own import plan.  To do this the
local mappers have to be in agreement.  In Ottawa this meant we met over
coffee.

Then you need to formally write up an import plan in the wiki.  Submit it
to the import mailing list and answer any queries they may have.  In this
case Nate will probably say it is already covered in the current Canada
wide import plan so why introduce yet another plan.  It also has to be
listed somewhere or other as an import.

It also has to be discussed in this mailing group.

The City of Ottawa was kind enough to adopt the municipal version of the
federal government's open data licence.  It took about five years from
start to finish to get them to be nice and adopt it.  It has been formally
approved by the legal working group.  If you can get your city to adopt the
same licence great.  In Ottawa it meant we could bring in bus stops etc.

Any other licence should either be approved by the Legal Working Group or
you can put your own interpretation on it.  If challenged at a later date
your imported data could be removed so I don't recommend this route.

In short if you have a couple of local mappers in agreement that they would
like to import the data, and if it is available via Stat Can and they find
the data quality acceptable then ask to be permitted to import it on this
mailing list.  James maybe able to assist.  Only if this route is not
available should you think about doing something else.

Cheerio John

On Mon, Apr 22, 2019, 3:42 PM Joshua Kenney,  wrote:

> Hello everybody!
> Relatively new mapper here.  I've been working on mapping my home town,
> and a couple of other places I've been, for the past 3 or 4 months.
>
> I have found that my city of Airdrie, AB has a number of datasets
> available under an Open Data Licence:
>
> http://data-airdrie.opendata.arcgis.com/pages/our-open-licence
> The licence terms look straight forward enough, are there any additional
> steps I need to take to confirm compatibility with OSM?
>
> One of the datasets includes building footprints.  Would importing that
> get in the way of the import of the national data? Where can I access the
> national data to compare the quality?
>
> --Joshua
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[john whelan]

The trade off is if it can be used elsewhere then there is a benefit for
using open source software however if it's only going to be used once here
and we have someone who knows the proprietary software very well the data
that ends up in OSM doesn't really care how it was produced.

This is more a religious argument.

Lots of people run OSM applications on Windows and Android both if which
are proprietary ran than on an open source version of Unix.

Cheerio John

On Thu, Mar 28, 2019, 10:04 AM Roman Auriti,  wrote:

> Why is it that FME seems to be a tool that's OK to use for OSM when
> someone replied that they could use PostGIS and was shut down by someone
> else replying  'I'm not installing postgesql for you to accept
> simplification'? Does anyone else find it a little ironic that the
> community would move forward with proprietary software over open software?
>
> On Thu, Mar 28, 2019 at 7:46 AM Begin Daniel  wrote:
>
>> Buildings where there is no available municipal data
>>
>> Sent from Galaxy S7
>>
>> --
>> *From:* John Whelan 
>> *Sent:* Thursday, March 28, 2019 9:32:32 AM
>> *To:* Begin Daniel
>> *Cc:* Talk-ca; keith hartley
>> *Subject:* Re: [Talk-ca] Building Import
>>
>> Are you talking about the older CANVEC data or the data that Stats has
>> released which is really municipal data?
>>
>> Thanks John
>>
>> Begin Daniel wrote on 2019-03-28 8:31 AM:
>>
>> Someone has compared Bing and Canvec data in rural areas?
>>
>> Sent from Galaxy S7
>>
>> --
>> *From:* OSM Volunteer stevea 
>> 
>> *Sent:* Wednesday, March 27, 2019 11:52:02 PM
>> *To:* Talk-ca
>> *Cc:* keith hartley
>> *Subject:* Re: [Talk-ca] Building Import
>>
>> Ah, good dialog ensues.  Municipality by municipality, in conjunction
>> with BOTH the StatsCan and Bing data, the right things are getting noticed,
>> the right things are getting human-realized at what the next steps are to
>> do.  It gets better.
>>
>> Yay.  Stitch it together.  One municipality at a time.  One province at a
>> time.  Pretty soon, after a few revisions of data and back-and-forths
>> between municipalities and province-wide data checking, you've got
>> something.  There, you go.
>>
>> SteveA
>>
>> > On Mar 27, 2019, at 8:23 PM, keith hartley 
>>  wrote:
>> >
>> > The patchwork of municipalities is at least useful, before we didn't
>> have a framework for adding this data, but at least we do now thanks to the
>> umbrella license @ Stats Canada. We're a big country with very few, but
>> very skilled OSM mappers (IE gecho111 mapped all of regina's building
>> footprints! ).
>> >
>> > I like the concept of the Bing data, but they may have to do another
>> few tries, or maybe retain their Neural network. - Is there anywhere where
>> the Bing data looks nice? I found burbs in Winnipeg not bad, but there's
>> some really weird elements when the source data is too simple (buildings in
>> the middle of fields) or too complex (urban cores)
>> >
>> > On Wed, Mar 27, 2019 at 6:29 AM John Whelan 
>>  wrote:
>> > The Stats Canada data comes from the municipalities.  Unfortunately
>> there are over 3,000 in Canada so yes ideally each would be treated
>> separately in reality each municipality doesn't have a group of skilled OSM
>> mappers who are capable of setting up an import plan and doing the work
>> although there is nothing to stop them doing so.
>> >
>> > Cheerio John
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>> ___
>> Talk-ca mailing 
>> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>> --
>> Sent from Postbox
>> <https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[John Whelan]

Are you talking about the older CANVEC data or the data that Stats has 
released which is really municipal data?


Thanks John

Begin Daniel wrote on 2019-03-28 8:31 AM:

Someone has compared Bing and Canvec data in rural areas?

Sent from Galaxy S7


*From:* OSM Volunteer stevea 
*Sent:* Wednesday, March 27, 2019 11:52:02 PM
*To:* Talk-ca
*Cc:* keith hartley
*Subject:* Re: [Talk-ca] Building Import
Ah, good dialog ensues.  Municipality by municipality, in conjunction 
with BOTH the StatsCan and Bing data, the right things are getting 
noticed, the right things are getting human-realized at what the next 
steps are to do.  It gets better.


Yay.  Stitch it together.  One municipality at a time.  One province 
at a time.  Pretty soon, after a few revisions of data and 
back-and-forths between municipalities and province-wide data 
checking, you've got something.  There, you go.


SteveA

> On Mar 27, 2019, at 8:23 PM, keith hartley  wrote:
> 
> The patchwork of municipalities is at least useful, before we didn't have a framework for adding this data, but at least we do now 
thanks to the umbrella license @ Stats Canada. We're a big country 
with very few, but very skilled OSM mappers (IE gecho111 mapped all of 
regina's building footprints! ).
> 
> I like the concept of the Bing data, but they may have to do another few tries, or maybe retain their Neural network. - Is there 
anywhere where the Bing data looks nice? I found burbs in Winnipeg not 
bad, but there's some really weird elements when the source data is 
too simple (buildings in the middle of fields) or too complex (urban 
cores)
> 
> On Wed, Mar 27, 2019 at 6:29 AM John Whelan  wrote:
> The Stats Canada data comes from the municipalities.  Unfortunately there are over 3,000 in Canada so yes ideally each would be treated 
separately in reality each municipality doesn't have a group of 
skilled OSM mappers who are capable of setting up an import plan and 
doing the work although there is nothing to stop them doing so.
> 
> Cheerio John



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


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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[John Whelan]

We have a history of using CANVEC data and importing that.  Daniel was 
very closely connected to the data.  In Ontario the ESRI tools are used 
in schools but they can be used with openstreetmap as the base map.   
From a practical point of view developing a set of tools or process in 
the open data world would allow others outside Canada to use them 
however Daniel knows his tools very well.


Cheerio John

Tim Elrick wrote on 2019-03-26 9:33 PM:
I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data 
quality (as it orthogonalized the buildings). Even difficult buildings 
were treated well [1].


As OSM is mainly built on open source tools, the OSMF tries to work 
with open source tools only and the process should be reproducible (if 
not for this import, then for the next one somewhere else in the OSM 
cosmos), I suggest, we try to resemble Daniel's pre-processing in open 
source software, e.g. PostGreSQL/PostGIS. I already found the code for 
collinearity; the orthogonalization seems to be a bit trickier, but it 
should be possible to built the process in PostGIS as well, if it was 
possible to built it in FME. What do you think?


Tim

[1] https://imgur.com/a/aCKMVb7

On 2019-03-26 13:45, Jarek Piórkowski wrote:
On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
There is actually no standard “code” available since I use FME 
(www.safe.com). It is a proprietary ETL application and all 
operations are done using “transformers” 
(https://www.safe.com/transformers/). I can provide you with the 
workbench I developed (a bunch of linked transformers) but you need a 
license to run it. This is why I tried to describe the operations I 
run on the data in the wiki.


As you did, people may send me coordinates (bounding box) of an area 
they know well. I’ll process the area and send the results back in 
OSM format. Please, be reasonable on the amount of data to process ;-)


Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

 From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

--Jarek

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



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


--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

[john whelan]

At least it is an indication of interest.

Thanks John

On Tue, Mar 26, 2019, 4:57 PM Darren Wiebe,  wrote:

> I'm from rural Alberta close to Lloydminster.  The building import is
> something that interests me and would be useful in my area but I haven't
> been very actively mapping over the last year or two.  Hopefully there are
> Alberta mappers on here who are much more active than I have been.
>
> Darren Wiebe
>
> On Tue, Mar 26, 2019 at 2:04 PM John Whelan  wrote:
>
>> I think my concerns are to do with the "black box" approach.  Knowing
>> your background I trust your work but others might not.
>>
>> On a technical side I get the impression that cites with buildings that
>> are close to each other are problematical.  I assume that small locations
>> with a population of say under 125,000 this is an insignificant problem?
>>
>> The other issue is I'd like to either see buy in from Nate or at least
>> some Toronto mappers to get an indication that something will happen at the
>> end of the day as it is a fair chunk of Daniel's time to work out how do
>> the preprocessing.
>>
>> I think some BC mappers expressed some doubts as well so perhaps they
>> would like to think about if they are happy or would prefer BC to be
>> outside of the import project and express their views.
>>
>> Out of interest if it does move ahead are we including the Microsoft data
>> for areas where we do not have data from Stats Canada?  If so we will need
>> to amend the project plan.
>>
>> My personal view is realistically I think having building information
>> even if its a meter or two out is better than not having the building
>> outlines.
>>
>> What would be nice is if we could have some indication from places such
>> as Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario
>> excluding Toronto and the other provinces and territories whether they are
>> happy with importing the buildings either from Stats or Microsoft.
>>
>> I seem to recall Keith is in Manitoba, so any views other than it wasn't
>> present in the first release from Stats?
>>
>> Note to Alessandro this is just background stuff.
>>
>> Thanks
>>
>> Cheerio John
>>
>> Begin Daniel wrote on 2019-03-26 3:29 PM:
>>
>> Jarek,
>> The area you proposed in quite interesting and will force me to look further 
>> at buildings with sharing edges, a concern Pierre also had. I'll be back 
>> soon with your area processed.
>> Daniel
>>
>> -Original Message-
>> From: Begin Daniel [mailto:jfd...@hotmail.com ]
>> Sent: Tuesday, March 26, 2019 14:34
>> To: Jarek Piórkowski; talk-ca@openstreetmap.org
>> Subject: Re: [Talk-ca] Building Import
>>
>> Jarek,
>> Since it is a one-time process, I expect to be able to process the files if 
>> the community feels comfortable with it. In the meantime, people are welcome 
>> to send me the bounding box of an area they would like to examine.
>>
>> Daniel
>>
>> -Original Message-
>> From: Jarek Piórkowski [mailto:ja...@piorkowski.ca ]
>> Sent: Tuesday, March 26, 2019 13:46
>> To: Begin Daniel; talk-ca@openstreetmap.org
>> Subject: Re: [Talk-ca] Building Import
>>
>> On Tue, 26 Mar 2019 at 13:10, Begin Daniel  
>>  wrote:
>>
>> There is actually no standard “code” available since I use FME 
>> (www.safe.com). It is a proprietary ETL application and all operations are 
>> done using “transformers” (https://www.safe.com/transformers/). I can 
>> provide you with the workbench I developed (a bunch of linked transformers) 
>> but you need a license to run it. This is why I tried to describe the 
>> operations I run on the data in the wiki.
>>
>> As you did, people may send me coordinates (bounding box) of an area they 
>> know well. I’ll process the area and send the results back in OSM format. 
>> Please, be reasonable on the amount of data to process ;-)
>>
>> Thanks Daniel. Let me know how it looks then!
>>
>> Coming from an open-source background, the process is unusual to me,
>> and I have questions about scalability - will you be able to process
>> and provide updated data files for all of Canada then? - but if others
>> are comfortable with it then I won't object.
>>
>> Some general thoughts regarding tooling as raised upthread:
>>
>> I was initially excited to see building footprints data as they help
>> two quite distinct purposes:
>>
>> 1. they provide a mostly-automatic source of geometries for the
>> millions of 

Re: [Talk-ca] Building Import

[John Whelan]

I think my concerns are to do with the "black box" approach.  Knowing 
your background I trust your work but others might not.


On a technical side I get the impression that cites with buildings that 
are close to each other are problematical.  I assume that small 
locations with a population of say under 125,000 this is an 
insignificant problem?


The other issue is I'd like to either see buy in from Nate or at least 
some Toronto mappers to get an indication that something will happen at 
the end of the day as it is a fair chunk of Daniel's time to work out 
how do the preprocessing.


I think some BC mappers expressed some doubts as well so perhaps they 
would like to think about if they are happy or would prefer BC to be 
outside of the import project and express their views.


Out of interest if it does move ahead are we including the Microsoft 
data for areas where we do not have data from Stats Canada?  If so we 
will need to amend the project plan.


My personal view is realistically I think having building information 
even if its a meter or two out is better than not having the building 
outlines.


What would be nice is if we could have some indication from places such 
as Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario 
excluding Toronto and the other provinces and territories whether they 
are happy with importing the buildings either from Stats or Microsoft.


I seem to recall Keith is in Manitoba, so any views other than it wasn't 
present in the first release from Stats?


Note to Alessandro this is just background stuff.

Thanks

Cheerio John

Begin Daniel wrote on 2019-03-26 3:29 PM:

Jarek,
The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.
Daniel

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Tuesday, March 26, 2019 14:34
To: Jarek Piórkowski; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Jarek,
Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca]
Sent: Tuesday, March 26, 2019 13:46
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:

There is actually no standard “code” available since I use FME (www.safe.com). 
It is a proprietary ETL application and all operations are done using 
“transformers” (https://www.safe.com/transformers/). I can provide you with the 
workbench I developed (a bunch of linked transformers) but you need a license 
to run it. This is why I tried to describe the operations I run on the data in 
the wiki.

As you did, people may send me coordinates (bounding box) of an area they know 
well. I’ll process the area and send the results back in OSM format. Please, be 
reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

 From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much 

Re: [Talk-ca] FW: Building Import

[John Whelan]

I like the idea of building a consensus on a building import.

More seriously if we can get any sort of consensus I'll be more than happy.

Cheerio John

Begin Daniel wrote on 2019-03-21 2:40 PM:


Oups, I still miss the “reply all” button

*From:*jfd...@hotmail.com
*Sent:* Thursday, March 21, 2019 14:36
*To:* 'Nate Wessel'
*Subject:* RE: [Talk-ca] Building Import

Hi all,

Concerning the pre-processing, let’s try/check first the 
“orthogonalization” component then, if there is a consensus on the 
validity of the result, we can build on it J


Daniel

*From:*Nate Wessel [mailto:bike...@gmail.com]
*Sent:* Thursday, March 21, 2019 14:30
*To:* John Whelan
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Building Import

I've specifically and repeatedly requested that the tasking manager be 
taken down while this project is reworked... though that doesn't 
pertain directly to the email I just sent.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com <http://natewessel.com>

On 3/21/19 2:02 PM, John Whelan wrote:

Nate are you requesting something specific on the Canadian task
manager for Toronto at this time or would you prefer to look
through Daniel's work first?

Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:

Daniel,

This is exciting news! After much talk on this list, it seems we
may have some actual progress toward fixing the various data
quality issues. Would you mind sharing some of your code, or a
description of your workflow here or on GitHub or the like so we
can take a look?

One thing you didn't mention which I think will be really
critical, especially in central Toronto: We need to remove
buildings from the import dataset that may already be mapped in
OSM. That is, buildings that overlap with existing buildings. For
this import to make any sense in Central Toronto, we need
conflation to move slowly, and in smaller, more manageable steps.
Buildings that are already mapped should be checked manually at a
later time in batches that a skilled human can manage in less than
an hour. The tasking manager as it's currently set up would have
all of downtown conflated by hand in one task by a single mapper -
a recipe for disaster I'm sure, given how detailed the map is in
that area.

Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com <http://natewessel.com>

On 3/19/19 12:58 PM, Begin Daniel wrote:

Hi all,

As mentioned a few weeks ago, I have almost completed the
development of a clean-up tool for the data to be imported.

So far, it removes nonessential vertices, orthogonalizes
building corners when reasonable and ensures walls’ alignment
within given tolerances. Building footprints that can’t be
processed completely are flagged accordingly, so they could be
examined thoroughly at import time.

Eventually, It should be easy to remove overlapping buildings
(potentially generated from a 3d mapping), but I doubt that
splitting terrace into individual buildings can be done
automatically.

The tool uses some parameters that need to be adjusted. I
would like that those who are interested in this aspect of the
import send me benchmark data that could be problematic. I
will process them to adjust parameters and/or the tool, and I
will send back the results to the sender for a thorough
examination.

I should soon document the process in the “Canada Building
Import” wiki page (in a pre-processing section).

Thought? Comments?

Daniel

___

Talk-ca mailing list

Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>

https://lists.openstreetmap.org/listinfo/talk-ca

___

Talk-ca mailing list

Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>

https://lists.openstreetmap.org/listinfo/talk-ca

-- 


Sent from Postbox

<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>



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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[John Whelan]

Nate are you requesting something specific on the Canadian task manager 
for Toronto at this time or would you prefer to look through Daniel's 
work first?


Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:


Daniel,

This is exciting news! After much talk on this list, it seems we may 
have some actual progress toward fixing the various data quality 
issues. Would you mind sharing some of your code, or a description of 
your workflow here or on GitHub or the like so we can take a look?


One thing you didn't mention which I think will be really critical, 
especially in central Toronto: We need to remove buildings from the 
import dataset that may already be mapped in OSM. That is, buildings 
that overlap with existing buildings. For this import to make any 
sense in Central Toronto, we need conflation to move slowly, and in 
smaller, more manageable steps. Buildings that are already mapped 
should be checked manually at a later time in batches that a skilled 
human can manage in less than an hour. The tasking manager as it's 
currently set up would have all of downtown conflated by hand in one 
task by a single mapper - a recipe for disaster I'm sure, given how 
detailed the map is in that area.


Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 3/19/19 12:58 PM, Begin Daniel wrote:


Hi all,

As mentioned a few weeks ago, I have almost completed the development 
of a clean-up tool for the data to be imported.


So far, it removes nonessential vertices, orthogonalizes building 
corners when reasonable and ensures walls’ alignment within given 
tolerances. Building footprints that can’t be processed completely 
are flagged accordingly, so they could be examined thoroughly at 
import time.


Eventually, It should be easy to remove overlapping buildings 
(potentially generated from a 3d mapping), but I doubt that splitting 
terrace into individual buildings can be done automatically.


The tool uses some parameters that need to be adjusted. I would like 
that those who are interested in this aspect of the import send me 
benchmark data that could be problematic. I will process them to 
adjust parameters and/or the tool, and I will send back the results 
to the sender for a thorough examination.


I should soon document the process in the “Canada Building Import” 
wiki page (in a pre-processing section).


Thought? Comments?

Daniel


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

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


--
Sent from Postbox 

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

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

[john whelan]

Go back to Ottawa and from the discussion we had there in Ontario it is the
municipality that is the authority.

>From memory years ago when OSM was mapped by cyclists taking photos of
street names what was on the sign post was deemed correct.

Unfortunately locally one street had three different signs that all
differed slightly.

Cheerio John

On Tue, Mar 19, 2019, 4:19 PM Tristan Anderson, 
wrote:

> When in doubt, ask.
>
> I posed this question to three Ontario municipalities.  Red Lake has told
> me either are acceptable, as has Amherstburg.  However, this is the
> response I got after emailing 3...@toronto.ca
>
> Dear Tristan:
>
> Street names displayed on signs and outlined in official documents should
> match the authorized spelling of the road name. For street names beginning
> with Saint, the abbreviated spelling is correct.
>
> Best regards,
>
> John House
> Supervisor, Land & Property Surveys
> Engineering Support Services
> Engineering & Construction Services
> City of Toronto
>
> Names in Openstreetmap may only be abbreviated if the expanded version is
> incorrect.  Where either are acceptable, the Saint must be used.  In
> general, an abbreviation in an official document does not imply that the
> expanded version is incorrect; it may just be used for convenience.  I'm
> still not 100% convinced that we should be using St even in Toronto (note
> that John admits to it being an "abbreviated spelling") but I just wanted
> to throw his response out there.
>
> Tristan
>
>
>
> From: Nate Wessel 
> Sent: March 15, 2019 1:42 PM
> To: Jarek Piórkowski
> Cc: talk-ca
> Subject: Re: [Talk-ca] Saints in street names in Ontario
>
>
> Interesting!
>
>
> I didn't mean to imply that etymology should be decisive, but that linking
> the name to the history of some beatified person would help explain the
> origin of the 'St'... In this case, seemingly supporting the abbreviation,
> but also referencing an actual 'saint' or two at the same time.
>
>
> I like Danny's suggestion of the pronunciation tag. That seems like the
> most elegant solution if anyone knows IPA. I've always wanted to learn it
> actually but haven't yet had a good enough reason.
>
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
>
> On 3/15/19 1:18 PM, Jarek Piórkowski wrote:
>
> On Fri, 15 Mar 2019 at 13:02, Nate Wessel  wrote:
>
> Don't forget about the various alternative naming tags like alt_name=*,
> short_name=*, loc_name=*, and also name:etymology=* to make things
> absolutely clear.
>
> Having either spelling in one of these alternatives as appropriate would
> likely satisfy any dissenters and make both the full and abbreviated name
> searchable.
>
> Certainly, but my message is to suggest that "St. Clair Avenue West"
> _is_ the full name. We could set up an "expanded name" tag I suppose?
>
> Etymology wise, Wikipedia, citing (as far as I can tell) local
> historians, suggests that St. Clair Avenue is named after Augustine
> St. Clare, a character in Uncle Tom's Cabin, and the book spells the
> last name "St. Clare", never expanded to "Saint".
>
> In any case, suggesting etymology as being decisive for names seems to
> me problematic in many ways, especially in Canada where we've
> adopted/mangled many names and phrases from other languages.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[John Whelan]

Bonne chance

John

Begin Daniel wrote on 2019-03-19 2:14 PM:


I expect Pierre, Tim and others to send me any data they believe would 
be problematic. If I send them my own test dataset, it may not cover 
the cases they are interested in. J


Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Tuesday, March 19, 2019 13:32
*To:* Begin Daniel
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Building Import

It would make logical sense to preprocess all the data but then you 
end up with two sources.  The Open Data original and the preprocessed 
data source.


From a logical point of view it would make sense to use the Microsoft 
data to fill in the gaps.  So add it into the preprocessed data.


Then you get to reality.  To make it work across Canada you need to 
get agreement and that I think will be the most difficult part.


Step one I think is ask Pierre nicely to review a sample and see if it 
meets his "quality" expectations.


Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we 
can get some sort of acceptance across the country possibly blacking 
out certain areas.


If we can we'll need to go back to the import mailing list and say we 
wish to combine two sources and amend the plan accordingly.


Otherwise it is up to whoever sorts out an import plan / import for a 
particular area to consider its use.


Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel <mailto:jfd...@hotmail.com>> wrote:


Hi all,

As mentioned a few weeks ago, I have almost completed the
development of a clean-up tool for the data to be imported.

So far, it removes nonessential vertices, orthogonalizes building
corners when reasonable and ensures walls’ alignment within given
tolerances. Building footprints that can’t be processed completely
are flagged accordingly, so they could be examined thoroughly at
import time.

Eventually, It should be easy to remove overlapping buildings
(potentially generated from a 3d mapping), but I doubt that
splitting terrace into individual buildings can be done
automatically.

The tool uses some parameters that need to be adjusted. I would
like that those who are interested in this aspect of the import
send me benchmark data that could be problematic. I will process
them to adjust parameters and/or the tool, and I will send back
the results to the sender for a thorough examination.

I should soon document the process in the “Canada Building Import”
wiki page (in a pre-processing section).

Thought? Comments?

Daniel

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



--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[john whelan]

It would make logical sense to preprocess all the data but then you end up
with two sources.  The Open Data original and the preprocessed data source.

>From a logical point of view it would make sense to use the Microsoft data
to fill in the gaps.  So add it into the preprocessed data.

Then you get to reality.  To make it work across Canada you need to get
agreement and that I think will be the most difficult part.

Step one I think is ask Pierre nicely to review a sample and see if it
meets his "quality" expectations.

Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we can
get some sort of acceptance across the country possibly blacking out
certain areas.

If we can we'll need to go back to the import mailing list and say we wish
to combine two sources and amend the plan accordingly.

Otherwise it is up to whoever sorts out an import plan / import for a
particular area to consider its use.

Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel  wrote:

> Hi all,
>
> As mentioned a few weeks ago, I have almost completed the development of a
> clean-up tool for the data to be imported.
>
> So far, it removes nonessential vertices, orthogonalizes building corners
> when reasonable and ensures walls’ alignment within given tolerances.
> Building footprints that can’t be processed completely are flagged
> accordingly, so they could be examined thoroughly at import time.
>
> Eventually, It should be easy to remove overlapping buildings (potentially
> generated from a 3d mapping), but I doubt that splitting terrace into
> individual buildings can be done automatically.
>
> The tool uses some parameters that need to be adjusted. I would like that
> those who are interested in this aspect of the import send me benchmark
> data that could be problematic. I will process them to adjust parameters
> and/or the tool, and I will send back the results to the sender for a
> thorough examination.
>
> I should soon document the process in the “Canada Building Import” wiki
> page (in a pre-processing section).
>
>
>
> Thought? Comments?
>
>
>
> Daniel
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Defining a local mapper group

[john whelan]

This needs a bit of context.  It relates to importing building outlines of
which there are two Open Data sources available for Canada both have
acceptable licenses.

Traditionally mappers have concentrated on one aspect of mapping.  I happen
to like bus stops for example and bus shelters also footpaths that lead to
them.

What we have discovered is different people have different ideas of what is
acceptable.  Ottawa mappers for example are happy with the building
outlines available for Ottawa.  At least one mapper outside Ottawa feels
the Ottawa building outlines are not acceptable because they do all have
right angles at the corners.

We have a mapper in Toronto who I understand feels that building outlines
should be simplified to omit things like bay windows.  Bay windows appear
to be acceptable in Montreal.

So what the local mappers find acceptable is acceptable.

Then we get to people like Jonathon whose only interest is not mapping
building outlines but in using tools such as street complete to add tags to
building outlines.  Students using street complete rather than drawing in
the building outline in iD then adding tags create fewer errors on the
map.  They are interested in having those building outlines on the map that
can be enriched.  Are their desires taken into account or do they have to
map something first?

Now we get to the tricky bit.  I'm local to Ottawa but I very rarely do
meetups.  So should my vote count?

If Africa there are lots of HOT remote mappers but ideally any decisions
are made by the "local" mappers.

So who counts as a local mapper?  Just those who attend a physical
meeting.  What about a conference call?  HOT allows its mumble servers to
be used for OSM business by the way.  Mumble is an Open Source VIOP.   I've
seen conference calls used to discuss things certainly, Slack is another
method of communication that I know nothing about other than it is
commercial. The major cities are fine but some of the smaller locations
have very few mappers.  One of the Ontario towns I've been mapping remotely
in has essentially one mapper who is very much in favour of importing
buildings.  Their thoughts are not really relevant since practically all
the building outlines in that location have been mapped with JOSM and the
buildings_tool plugin.  If I look at Ontario there is one mapper whose name
pops up all over the place but are they a "local" mapper for locations a
thousand kilometers apart?

So since it is the local mappers who make decisions, who are they?

Cheerio John

On Tue, 19 Mar 2019 at 11:34, Martijn van Exel  wrote:

> If you’re interested in forming local mapper groups based on actual
> contributions to OSM you are free to use the Meet Your Mapper tool I built
> a little while ago.
>
> You can draw a bounding box and retrieve a list of mappers who contributed
> there. It generates some basic stats such as number of nodes / ways /
> relations and tries to classify mappers in a few categories.
>
> Some more information here:
> https://www.openstreetmap.org/user/mvexel/diary/44833 and the tool lives
> at https://mym.rtijn.org/
>
> Martijn
>
> On Mar 19, 2019, at 11:29 AM, Jonathan Brown  wrote:
>
> Ideally, a local mapper/group would be one that contributed data to an
> open digital map that can be verified and used to solve a problem (e.g.,
> food security, fresh water, climate change, etc.). The local mapping group
> should be able to contribute data via satellite imagery, open data, and/or
> a physical location. The challenge is how to cultivate and maintain local
> mapper groups based on volunteer work.
>
> Jonathan Brown
>
> *From: *John Whelan 
> *Sent: *Friday, March 15, 2019 10:01 AM
> *To: *Jonathan Brown 
> *Cc: *talk-ca@openstreetmap.org
> *Subject: *Re: [Talk-ca] Local groups as part of import plan
>
> The problem is defining and contacting a local group.  Once defined then
> they can make the decision.
>
> I've seen as few as two people make a local group decision on an import
> before now although normally it is done over coffee.
>
> Also we get into who is a local mapper.
>
> Many people have an interest in seeing the data imported but I'm under the
> impression only those with a OpenStreetMap userid who have contributed
> count.
>
> Would anyone care to define a local mapper or group?
>
> Thanks John
>
> Jonathan Brown wrote on 2019-03-15 9:46 AM:
>
> Could we get Stats Can to support a few local groups who want to use a
> common framework for a collaborative research project that addresses a
> sustainable development goal outcome (e.g., the OSM fresh security challenge
>  https://wiki.openstreetmap.org/wiki/Food_security and
> https://www.usda.gov/topics/food-and-nutrition/food-security) ?
>
> Jonathan
>
>
>
>
> _

Re: [Talk-ca] Building Import

[john whelan]

I think at this point in time we need to try to get some sort of agreement
on how to proceed.  My first thought would be to ban the youngsters so
anyone under 65 shouldn't be involved.  That way it would slow the process
down unfortunately it isn't really practical.

I think we need time to digest and review what has been done so far.  I
think it would be sensible for a different mapper to go over the imported
areas using the task manager and verify the buildings against Bing or other
imagery to ensure we haven't introduced an imaginary town etc.

I do think we need to break the import up into more manageable chunks.
Whether these need to be at municipal level or not needs thought.  The case
for is that would allow the data from different sources to be carefully
checked over. The case against is there are a lot of municipalities and in
places like Manitoba there are very few mappers on the ground.

Basically from a population point of view Canada is a collection of around
half a dozen cities and these have a local OSM community.  Montreal,
Ottawa, Vancouver, Toronto for example.  Once you take these out then you
have much smaller numbers.  I'm not certain about Calgary and Edmonton
whether they have a local community or not.

Quebec with its own mailing list is self contained and I think will sort
itself out in time.  Montreal is working together to sort something out.

Terraced houses in Ottawa we just have the outline with a tag of terrace.
This was the way they were mapped even before the City of Ottawa import.
Units may have an individual address node.

At the moment I favour breaking the country up into provinces and for each
province depending on the number of buildings I might split it up again.
So Ontario would be something like Ontario rural and Toronto but I'm not
quite sure of where Toronto begins and ends.

Thoughts and bear in mind that Microsoft has released buildings for Canada
as well.  I haven't noticed an import plan but it would be fairly easy for
someone to bring in some buildings so to retain some sort of control a plan
might well be useful.

Thanks John



On Fri, 15 Mar 2019 at 15:34, Tim Elrick  wrote:

> I think, Montreal's OSMappers would appreciate to discuss the import of
> the buildings there first on the local list. By the way, John, I have never
> said I would be taking the lead for the entirety of Québec (at least, at
> the moment). However, I feel that the import should be discussed on the
> liste OSM de Québec first.
>
> Danny, I disagree with you on the import of building blocks. I find it
> much more tedious to discern them later, then splitting them into single
> buildings first before importing, because, I think, you need to know your
> neighbourhood very well to find unsplit buildings in the OSM database.
> Doing this for a whole town or even city (like Montreal) would take much
> longer than pre-processing.
>
> As for the rest, I have some understanding for the impatience of OSMappers
> about the moratorium on the import - as quite some time has passed and the
> discussion hasn't really moved on nor has the development of the
> countrywide import plan [1] - last change there was beginning of February.
>
> Having looked at the Microsoft data and compared quality to the Open
> Building Database in two places (Montréal, QC and Williams Lake, BC), I
> would suggest to refrain from using it as a source for importing, unless
> you verify them for small areas (but then you can almost draw them by
> hand). In dense areas like downtown Montréal the building footprints are in
> many cases plainly wrong (see my contribution to this list on 2019-03-02,
> 19h57 EST), in more scattered areas and suburban landscapes buildings are
> randomly aligned and quite some buildings are missing (my unverified
> estimate is about 5-10%).
>
> As for the Open Building database, it is important to discern the data by
> the sources as each municipality that contributed data might have used
> different methods and has different mapping standards. Now add the
> disagreement on this list about orthogonalization and building details. I
> think, this suggests breaking up the import plan in smaller batches; for
> the start it can be cloned from the original one, but the pre-processing
> and import process might differ due to how data sources might need to be
> treated as well as how local OSM communities would like to go forward.
>
> What do you reckon?
>
> Tim
>
> [1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
>
> On 2019-03-15 14:01, John Whelan wrote:
> Which I think comes back to defining the local mappers.
>
> There has been discussion on Montreal as well and not all Ontario thinks
> the same way.  Ottawa local mappers for example have different opinions to
> Pierre and Nate on what is acceptable and I'm under the impression t

Re: [Talk-ca] Building Import

[John Whelan]

Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers.  How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

[John Whelan]

I think there are two issues here the first is I accept having a large 
number of anything by one mapper has the potential for a systematic error.


If the import is verified by a second mapper independently I assume this 
would be acceptable?


The second is more to do with discussion within the community and is I 
feel more complex.


Cheerio John

Frederik Ramm wrote on 2019-03-15 12:06 PM:

Hi,

On 15.03.19 16:23, Danny McDonald wrote:

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.

True!


It is not a "community process"
where contributions are made by a group of "local mappers" (although
this sometimes happens).

True!

As long as we're talking normal, everyday, "manual" mapping. Like, 100
edits a day, or maybe 1000 edits on a good day.

For things that go beyond a little mapping by the individual, we tend to
have processes, e.g. for imports, for automated edits, for organised edits.

The general idea behind the discuss-these-things-first rules is not that
one mapper is better than another, but quite the opposite: One mapper
alone can actually make stupid mistakes or suffer from bad judgement,
something that the larger community can help against.

Bye
Frederik



--
Sent from Postbox 

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

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

[john whelan]

I'm of the opinion that what the city says goes.

We used that in Ottawa with things such as rue Slater rather than Rue
Slater which I understand is more normal in Quebec.

Cheerio John

On Fri, Mar 15, 2019, 1:19 PM Jarek Piórkowski,  wrote:

> On Fri, 15 Mar 2019 at 13:02, Nate Wessel  wrote:
> > Don't forget about the various alternative naming tags like alt_name=*,
> short_name=*, loc_name=*, and also name:etymology=* to make things
> absolutely clear.
> >
> > Having either spelling in one of these alternatives as appropriate would
> likely satisfy any dissenters and make both the full and abbreviated name
> searchable.
>
> Certainly, but my message is to suggest that "St. Clair Avenue West"
> _is_ the full name. We could set up an "expanded name" tag I suppose?
>
> Etymology wise, Wikipedia, citing (as far as I can tell) local
> historians, suggests that St. Clair Avenue is named after Augustine
> St. Clare, a character in Uncle Tom's Cabin, and the book spells the
> last name "St. Clare", never expanded to "Saint".
>
> In any case, suggesting etymology as being decisive for names seems to
> me problematic in many ways, especially in Canada where we've
> adopted/mangled many names and phrases from other languages.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building import in BC and Quebec

[John Whelan]

At the end of the day one would hope we are a community.  We are a large 
group with divergent opinions and to be honest there is a great deal of 
interest in non-mappers in this sort of data.


For example building data is being used in Tanzania to work out the 
optimal areas for group solar panels.  It can be used for many other 
things which may not be immediately apparent to a traditional paper 
based mapper.


With both the Stats Can released data and the Microsoft released data 
floating around some data is going to creep in anyway.


At the moment we have Tim taking responsibility for Montreal.

There seems to be a number of divergent views in Toronto so I think they 
should sit down and see if they can come to some sort of agreement.


We have Pierre and Nate who would appear to have different standards of 
what is acceptable to other mappers.  We have at least half a dozen 
mappers who support the import, shown by their imports. I can probably 
find a few more mappers who support the import if it comes to a simple vote.


I would suggest we try to best manage the process.  If that means the 
imported data is verified by another mapper I think that can be arranged.


Cheerio John

Yaro Shkvorets wrote on 2019-03-15 11:22 AM:
As an experienced local Ontario and Quebec mapper I don't see any 
major problems with Stats Can building quality. It's detailed and 
recent, it's the best dataset we could ever possibly get and it's far 
superior to Microsoft quality. Having many buildings with "almost 
square angles" in this dataset is not an issue as vast majority of 
such deviations cannot be seen with a naked eye. Unfortunately any 
orthogonalization algorithms will do more harm than good in such 
cases. Mapping for the Validator, just like mapping for the Renderer 
is a wrong way to map.
Issues were raised, issues were addressed in the import plan. If there 
are any problems with some mappers violating any specific import plan 
rules such issues need to be pointed out so they can adjust their 
workflow.

My 2 cents.

On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel > wrote:


I just reported this to the data working group, in case you
haven't already. Hopefully they will step in!

Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 3/15/19 10:30 AM, Pierre Béland wrote:

Réponse immédiate avec refus de discussion de la part de
DannyMcD_imports. Celui-ci indique qu'il prévoit continuer l'import.
voir https://www.openstreetmap.org/changeset/67686901

There was a discussion, issues were raised, the problems (to the
extent that they existed at all) have been addressed. I plan to
continue importing, unless a *specific* valid issue is raised.
Please do not contact me again unless you have such an issue.


La prochaine étape est je pense de contacter le Data Working Group.


Pierre



___
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


--
Sent from Postbox 

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

Re: [Talk-ca] Local groups as part of import plan

[John Whelan]

The problem is defining and contacting a local group.  Once defined then 
they can make the decision.


I've seen as few as two people make a local group decision on an import 
before now although normally it is done over coffee.


Also we get into who is a local mapper.

Many people have an interest in seeing the data imported but I'm under 
the impression only those with a OpenStreetMap userid who have 
contributed count.


Would anyone care to define a local mapper or group?

Thanks John

Jonathan Brown wrote on 2019-03-15 9:46 AM:


Could we get Stats Can to support a few local groups who want to use a 
common framework for a collaborative research project that addresses a 
sustainable development goal outcome (e.g., the OSM fresh security 
challenge https://wiki.openstreetmap.org/wiki/Food_security and 
https://www.usda.gov/topics/food-and-nutrition/food-security) ?


Jonathan



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


--
Sent from Postbox 

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

Re: [Talk-ca] Building import in BC and Quebec

[John Whelan]

If the local mappers in Alberta or BC feel the data quality is not good 
enough then I think it is up to them to take action but I think it 
really is up to the local mapping community and defining them is 
difficult sometimes.  Also remember agreements within the local 
community are not always electronic in nature.


This is not as simple and clear cut as one might like.

Cheerio John

Jarek Piórkowski wrote on 2019-03-15 8:28 AM:

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:

I would suggest, again, that the tasking manager for this import be locked or 
taken down if that is not possible. One good way to stop people from importing 
when we don't have consensus is to not make it so easy for them. Indeed, I 
would find it plausible if these people said they didn't even know the import 
was paused - their evidence: that the tasking manager is still active!

Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

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

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

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

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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building import in BC and Quebec

[john whelan]

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import,
the Stats Can stuff and the Microsoft stuff.  I haven't seen any import
plan for the Microsoft stuff but unfortunately it's probably fairly easy to
import on the Stats Can side my feeling is we need to work out who the
locals are to get buy in since Canada wide there is no consensus on what is
acceptable.  After a request from a local group then I think that
particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

> Are people aware that there are buildings being imported by
> https://www.openstreetmap.org/user/huronavemapper (most recent 12
> hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
> (most recent 5 days ago)?
>
> I notice the wiki still says the import is on hold.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Northumberland county

[John Whelan]

Ontario

Thanks John

wambac...@posteo.de wrote on 2019-03-06 5:14 AM:


which relation? there are at least two in canada. Brunswick and Ontario.

walter

Am 06.03.19 um 02:05 schrieb john whelan:
I can search in nomation for a supermarket in Ontario or Cobourg or 
even greater Manchester UK but it doesn't work for Northumberland 
county.


Could a relation specialist take a look at Northumberland county for 
me please.


Admin level 6

Thanks John

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

--
My projects:

Admin Boundaries of the World <https://wambachers-osm.website/boundaries>
Missing Boundaries 
<https://wambachers-osm.website/index.php/projekte/internationale-administrative-grenzen/missing-boundaries>

Emergency Map <https://wambachers-osm.website/emergency>
Postal Code Map (Germany only) <https://wambachers-osm.website/plz>
Fools (QA for zipcodes in Germany) <https://wambachers-osm.website/fools>
Postcode Boundaries of Germany 
<https://wambachers-osm.website/pcoundaries>



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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Northumberland county

[john whelan]

I can search in nomation for a supermarket in Ontario or Cobourg or even
greater Manchester UK but it doesn't work for Northumberland county.

Could a relation specialist take a look at Northumberland county for me
please.

Admin level 6

Thanks John
___
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

[john whelan]

Please read Tim's comments below I suspect he meant to cc talk-ca.

My thoughts run along the same lines as Tim's basically local groups have
to look at what is available then decide for themselves how they wish to
proceed.

We have some experience in the import process available but I think it
needs to be driven by local mappers since they are the authority.

Cheerio John

On Sat, Mar 2, 2019, 7:45 PM Tim Elrick,  wrote:

> Hi everyone,
>
> Thanks John for pointing out the new dataset!
>
> Steve, John just indicated that there is this new dataset available now. I
> am confident, that after our discussion on importing building footprints in
> Canada, the OSMappers who want to go forward with it, will provide the
> information on the import plan/wiki.
>
> You can download the Microsoft file at the site indicated by John. The
> license information can be found there as well (as mentioned by James it is
> ODbL. It is much more extensive than the Open Building Database release by
> StatCan (> 12 million buildings vs. 4.4 million buildings).
>
> So, I got interested and I had a look at the data for Montreal:
> https://imgur.com/a/PwuZ3Q5
> I chose an area where OSM data existed. As you can see OSM hand-drawn
> buildings from Bing imagery are nicely drawn and separated.
> When you compare the OSM data to the Open Building Database (OBD) data
> from StatCan (brown in my images) which draws on the données ouvertes de
> Ville de Montréal (extracted from photogrammetric imagery) you can see that
> the OBD data is somehow more precise than the OSM/Bing data, but the huge
> draw back is that the OBD data only captures the building outlines of
> attached/terraced buildings, i.e. of building blocks without separating
> single buildings (as already mentioned by me in a separated e-mail to the
> list - this is why we will have to do some pre-processing of the data).
> When you then compare this data set to the Microsoft data set (pink in my
> images), you see that their deep neural network approach fails in areas
> with terraced houses big time. Same goes for the the city centre of
> Montreal (not shown in my images).
>
> So, the Microsoft data set might work for areas with single homes and that
> would be helpful to fill in the blanks in remote areas, but for areas where
> we have data from the ODB, importing from the ODB might be better. However,
> caution has to be taken with ODB as well, as every municipality that
> contributed data might have contributed a different data source, where the
> quality should be check each time.
>
> Just my two cents here.
>
> Tim
>
>
> On 2019-03-02 17:40, john whelan wrote:
> Why are you planning to import it?
>
> Cheerio John
>
> On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, <
> stevea...@softworkers.com> wrote:
>
>> A responsible complement to this would be a link to license information,
>> a wiki page about these data, and perhaps an Import Plan should those data
>> actually be asserted to be worthy of being responsibly imported into OSM.
>>
>> SteveA
>> California
>>
>> > On Mar 2, 2019, at 2:17 PM, john whelan  wrote:
>> >
>> > https://github.com/Microsoft/CanadianBuildingFootprints
>> >
>> > So now there are two Open Data sources for building outlines in Canada.
>> >
>> > Cheerio John
>> > ___
>> > Talk-ca mailing list
>> > Talk-ca@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
___
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

[John Whelan]

>More discussion often yields consensus.

Feel free to lead the discussion and gain consensus.

My feeling is it will not be possible to reach one across Canada.

Good Luck

Cheerio John


___
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

[John Whelan]

I would concur in general but any import needs the agreement of local 
mappers and I think we have to define who they are first.


Cheerio John

Danny McDonald wrote on 2019-03-02 7:23 PM:
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


--
Sent from Postbox 

___
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

[John Whelan]

Two years ago a group of Toronto mappers submitted the City of Toronto 
Open Data license to the LWG to see if it was acceptable.  I assume they 
meant to import things such as building outlines.  I also assumed as I 
think others did that this meant Toronto mappers were happy to import 
the City of Toronto's data especially as it was discussed on talk-ca first.


More recently Nate who currently lives in Toronto feels that this should 
be discussed once more in Toronto to work out what is desired etc.


Tim I think is organising Montreal open data import.

I note that Nate and Tim have different ideas about what should be 
imported.  One is happy with bay windows and I think the other feels 
they should be removed.


We also have Pierre who is unhappy because the imported building 
outlines available have too many corners that are not right angles.


The local Ottawa mappers are content with their Open Data import and 
find the data quality acceptable even though Pierre has expressed 
reservations about it.


Someone in Manitoba? mentioned there were no building outlines released 
for Manitoba?  I apologise if I have the province name wrong.


So we have a mixture of expectations which is only to be expected in a 
large group.


Microsoft's Open Data provides another source of Open Data which might 
meet Pierre's data quality expectations.  They may meet Nate's.  All 
provinces and Territories now have Open Data building outlines available.


Northwest Territories, Nunavut, and Yukon have populations of around 
35,000 people.  Realistically I don't think they have a group of local 
OSM mappers.


The next four provinces in size range between 142,000 to 1,275,000.

The larger provinces contain Toronto, Montreal, Vancouver, Calgary and 
Edmonton.


Essentially the problem now we no longer have a Canada wide consensus on 
what is acceptable appears to be how do you identify local mappers 
across Canada and how far away can a "local" mapper be to be considered 
local since it is the local mappers who make the decision about what is 
acceptable and I think it is they who have to drive the import process.


I'm sure if a local group would like to contact me we can find resources 
to assist them if required.


Cheerio John

OSM Volunteer stevea wrote on 2019-03-02 5:52 PM:

No, I am not planning to import these.  However, your notification that the data are 
available seems to be encouraging the data to BE imported into OSM.  Of course, there is 
a "more correct" way to do that.

Perhaps I might encourage you to sharpen up your intention for notifying talk-ca of the availability of the 
data.  Are they an additional source to ENTER into OSM?  (Thus importing them).  Or, perhaps you mean them to 
be a set of "comparison data" which might be used to verify or compare against the 
"other" data.  Although, then, should there be a discrepancy, the question becomes "which are 
(more) correct?"  I didn't see any of these issues addressed by your notification, which feel likes it 
begs these questions.  Thank you in advance for any follow-up that better clarifies.

Late notice just before I clicked Send:  thanks to James for letting us know 
here that the data are ODbL and therefore OSM-compatible.  (One down, perhaps a 
bit more to go).

SteveA


On Mar 2, 2019, at 2:40 PM, john whelan  wrote:

Why are you planning to import it?

Cheerio John

On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea,  
wrote:
A responsible complement to this would be a link to license information, a wiki 
page about these data, and perhaps an Import Plan should those data actually be 
asserted to be worthy of being responsibly imported into OSM.

SteveA
California


On Mar 2, 2019, at 2:17 PM, john whelan  wrote:

https://github.com/Microsoft/CanadianBuildingFootprints

So now there are two Open Data sources for building outlines in Canada.

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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
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

[john whelan]

Why are you planning to import it?

Cheerio John

On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> A responsible complement to this would be a link to license information, a
> wiki page about these data, and perhaps an Import Plan should those data
> actually be asserted to be worthy of being responsibly imported into OSM.
>
> SteveA
> California
>
> > On Mar 2, 2019, at 2:17 PM, john whelan  wrote:
> >
> > https://github.com/Microsoft/CanadianBuildingFootprints
> >
> > So now there are two Open Data sources for building outlines in Canada.
> >
> > Cheerio John
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[john whelan]

https://github.com/Microsoft/CanadianBuildingFootprints

So now there are two Open Data sources for building outlines in Canada.

Cheerio John
___
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

[John Whelan]

If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus 
stops you can get hold of as well.


Just be aware that we had a fairly large number of questions asked about 
the license etc when we did Ottawa and one of the people questioning 
referred the license to the LWG.  Even the basis of CANVEC licensing 
came into question at the time.


Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as 
well but that was about two years ago and I note that the LWG web site 
has no mention of it so it is probably still in the queue.


Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    terrible: no parallel to street buildings, no right angles,
    sometimes even not the right size of building parts. Fact is that
    secondary data buildings footprints can be from many different data
    sources - from AutoCAD, handdrawn by a municipal GIS experts to
    photogrammetric and satellite machine learning sources; all those
    sources have their peculiarities, which I think, you cannot satisfy
    in one import plan fits all - especially, as the Open Building
    Database in Canada is stitched together from those very different
    sources.

    In Montreal, e.g., the source for the Open Building Database is the
    données ouvert

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

[john whelan]

When you look at importing Montreal you might like to look at the following
first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper record
fine but if they are no longer part of the community then there maybe a
problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick  wrote:

> Hi all,
>
> After following the building import discussion for a while now, I wanted
> to chime in as well.
>
> After moving to Montréal from Germany recently, I got more engaged with
> the local mappers here in MTL (beforehand, I was more analysing OSM data
> scientifically).
>
> I took part in the initial meeting of the Building Canada 2020 initiative,
> in which great interest in the project was expressed by many institutions,
> organizations and businesses. However, apart from Statistics Canada,
> municipalities and OSMappers no one seemed to be willing to invest into the
> effort to support the initiative with manpower or funding (to my
> knowledge). Therefore, I found it quite impressive what StatCan has
> achieved with the Open Building Database and do not share the view of some
> on this list that the initiative got off on the wrong foot; but that all
> water under the bridge now.
>
> So, yes, there seems to be some interest to use the data from the Open
> Building Database in OSM easily. However, I am also hesitant, that one
> massive import can be the answer.
>
> I'm generally hesitant with imports as such, maybe because I was
> acculturated in OSM in Germany where OSMappers value original entries much
> more than secondary data. Further, I'm skeptical, that secondary data is
> necessary better than original data (even from mapathons). I initiated two
> mapathons with university students in the context of Building Canada 2020.
> Both mapathons resulted in mostly nice buildings, I would say - and, when
> there is the odd not-so-nice building, there is still the validation step
> as we always used the tasking manager [1]. By the way, both mapathons used
> the ID editor; and, of course, you can square buildings in ID as well; so,
> I don't really understand the ID editor bashing that appears on this list
> here now and then. That said, of course, I prefer JOSM over ID as it is the
> more versatile tool, but to introduce interested persons to editing in OSM,
> ID is really nice.
>
> I'm even more skeptical about imports after Yaro pointed us to the Texas
> import [2]. I wonder why there was no outcry there (or maybe there was and
> I did not hear about it) - the imported data is terrible: no parallel to
> street buildings, no right angles, sometimes even not the right size of
> building parts. Fact is that secondary data buildings footprints can be
> from many different data sources - from AutoCAD, handdrawn by a municipal
> GIS experts to photogrammetric and satellite machine learning sources; all
> those sources have their peculiarities, which I think, you cannot satisfy
> in one import plan fits all - especially, as the Open Building Database in
> Canada is stitched together from those very different sources.
>
> In Montreal, e.g., the source for the Open Building Database is the
> données ouvertes des batiments. This is photogrammetric imagery probably
> turned into AutoCAD files, which then were exported to a shapefile and
> geojson. The building outlines are impressively precise, however, the open
> data files contain building blocks not single buildings [3], however, offer
> building dividers in a separate shapefile (I assume due to the export from
> AutoCAD, see second image in [3]). Unfortunately, the Open Building
> Database only included those building blocks in their data set, making it
> not very easy to import into OSM (as they do not include the building
> dividers). Hence, a bit of non-trivial pre-processing of the original
> données ouvertes des batiments would be necessary to import them into OSM
> (as the building divider file does also include roof extensions and roof
> shapes). The local OSM group is discussing this pre-processing for a while
> now at their local meetings (we started discussing this even before the
> Building Canada 2020 initiative started). As the City of Montreal has
> granted OSM the explicit use of their open data file, the way forward, we
> think, is to pre-process the original files. Further, there is extensive
> overlap of existing buildings with the open data file. Therefore, the
> imports in Montreal would have to happen in very small batches to not
> destroy the work of other OSMappers.
>
> I am also pretty skeptical about the simplification of the secondary data
> before importing that was suggested on the list 

Re: [Talk-ca] OSM Local Mappers and Editing Tool

[john whelan]

So you are adding data to OSM in Cobourg and Port Hope but not in
Peterborough?

There is an add-on to the ESRI products that will allow them to edit
OpenStreetMap.

Thanks

Cheerio John

On Sun, Feb 10, 2019, 1:02 PM Jonathan Brown  JW wrote:
>
> The way forward probably I suggest an opt out method.  Those locations that
>
> have a local group who would prefer more control we block out.  At the
>
> moment this would include Toronto and Montreal.  That way smaller
>
> municipalities can take advantage of the infrastructure that has been set
>
> up but larger locations with local groups can make their own decisions.
>
>
>
> John: We are running a training session for OSM mapping in Northumberland
> County (see description
> https://docs.google.com/document/d/1dKutxWnsspfYUhzR73laZ_UV8srVq-4KxM3z4ZT3qC0/edit?usp=sharing).
> We are looking or team participants and volunteers to assist with our first
> OSM local mapping event in Cobourg, Ontario. The GoGeomatics Peterborough
> event on the same day will be using ESRI Community Mapping tool for missing
> maps in Durham Region.
>
>
>
> We are also looking for help in setting up an OSM Task Manager Project for
> Northumberland County. We would then be happy to test out different editing
> tools that day and for future mapping events in our region with students,
> teachers and the broader public as we proceed, to use Tim’s term, “bit by
> bit.” We have Kelsey Saunders and Jennifer Rolph, local GIS professionals,
> helping with the training on March 12. We will have 12 laptops with mice
> set up for the general public and teams to be trained on how to add
> features and building attributes in OSM for Cobourg and Port Hope. Because
> the students are looking for coop placements in local government, we are
> also providing training on ArcGIS Online. The idea is to encourage
> crowdsourcing with OSM because it is open source and teaches students the
> value of ground truthing.
>
>
>
> Jonathan Brown
>
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
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

[john whelan]

Mapping buildings in iD can be done accurately, however going back in time
to the Nepal earthquake generally speaking they were really poor quality.
Pierre first took an interest in data quality around this time.  Well he
was interested before but grew more vocal.  As part of 2020 a number of
mapathons were organised as part of Geoweek using students and iD.  The
results were not pretty and were commented on in talk-ca.  These mapathons
for the most part did not have an experienced OSM mapper to guide them.  I
did one but cheated I took a couple of laptops with JOSM on and we only
used the buildings_tool.  For new mappers they did quite a nice job.  I
have done a fair amount of validation on HOT projects typically I saw 5 -7
buildings per mapper per mapathon done using iD.

Canada is fairly large so many locations do not have a group of OSM
mappers.  Peterborough Ontario, pop 80,000 for example, there is a related
mapathon happening there March 2nd with some students.  However I don't
think there are any local OSM mappers and I can't get there by train or bus
by the time it starts in the morning.

It's these smaller locations that are the problem.  Sorting out the
license, going through the OSM import process and setting up a tile server
takes resources and its these locations are the ones that simply don't have
the experienced mappers available to do the tasks.  The other problem is
students.  France I think thinks all its students should be familiar with
OpenStreetMap so there is interest in the education world.  What we have
found is if the building outlines are present then it is much easier for
students etc to add detail and that is basically what has happened in
Ottawa.

There is a range of points of view about what is acceptable.  The larger
the group, the wider the range and the more difficult it is to get
consensus.  In Ottawa the local mappers are more than happy with the data
quality on the import.

The City of Toronto Open Data licence was submitted for approval by the
local Toronto group must be two years ago now.  So at that time there was a
definite interest by local mappers in using Toronto's open data.

I think I agree with you about running mechanical edits on the data before
importing.  I think Pierre found that using JOSM neither squaring nor the
plugin worked perfectly in all cases.

The way forward probably I suggest an opt out method.  Those locations that
have a local group who would prefer more control we block out.  At the
moment this would include Toronto and Montreal.  That way smaller
municipalities can take advantage of the infrastructure that has been set
up but larger locations with local groups can make their own decisions.

I seem to recall the project plan actually does allow for this.  The
intention certainly was that local groups would sort out the import locally.

Cheerio John







On Sun, 10 Feb 2019 at 00:04, Tim Elrick  wrote:

> Hi all,
>
> After following the building import discussion for a while now, I wanted
> to chime in as well.
>
> After moving to Montréal from Germany recently, I got more engaged with
> the local mappers here in MTL (beforehand, I was more analysing OSM data
> scientifically).
>
> I took part in the initial meeting of the Building Canada 2020 initiative,
> in which great interest in the project was expressed by many institutions,
> organizations and businesses. However, apart from Statistics Canada,
> municipalities and OSMappers no one seemed to be willing to invest into the
> effort to support the initiative with manpower or funding (to my
> knowledge). Therefore, I found it quite impressive what StatCan has
> achieved with the Open Building Database and do not share the view of some
> on this list that the initiative got off on the wrong foot; but that all
> water under the bridge now.
>
> So, yes, there seems to be some interest to use the data from the Open
> Building Database in OSM easily. However, I am also hesitant, that one
> massive import can be the answer.
>
> I'm generally hesitant with imports as such, maybe because I was
> acculturated in OSM in Germany where OSMappers value original entries much
> more than secondary data. Further, I'm skeptical, that secondary data is
> necessary better than original data (even from mapathons). I initiated two
> mapathons with university students in the context of Building Canada 2020.
> Both mapathons resulted in mostly nice buildings, I would say - and, when
> there is the odd not-so-nice building, there is still the validation step
> as we always used the tasking manager [1]. By the way, both mapathons used
> the ID editor; and, of course, you can square buildings in ID as well; so,
> I don't really understand the ID editor bashing that appears on this list
> here now and then. That said, of course, I prefer JOSM over ID as it is the
> more versatile tool, but to introduce interested persons to editing in OSM,
> ID is really nice.
>
> I'm even more skeptical about imports after Yaro 

Re: [Talk-ca] Building Import update

[john whelan]

So are we happy with Yaro's suggestions?  Or perhaps I should rephrase that
can we live with them?

On the task manager square size I take it these have been split and split
again?

Thanks John

On Mon, 4 Feb 2019 at 18:08, Yaro Shkvorets  wrote:

> Briefly, here are my thoughts.
> 1) *Simplification*, i.e. removing nodes in the middle of a straight
> line. We should be able to apply this fix to the original data. Looks like
> James has done it a couple of weeks ago, so we can try take this data and
> go with it if there are no objections.
> 2) *Almost square angles*. Simple squaring in JOSM (Q) is a non-starter
> as it ruins geometries. Looks like we found a way to do it using JOSM
> Validator (this thread:
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009099.html).
> I think it should work. I don't like preprocessing data for this step since
> there would be no way to go back if the algorithm makes a mistake. Besides,
> I don't think we were able to find a working script to do it to begin with.
> 3) Preserving *building history*. I agree we should absolutely try to
> preserve the history whenever possible. "Replace geometry" (Ctrl-Shift-G)
> is the way to go here. For the record, here's what I meant when I was
> writing about possibility of deleting clusters of low quality generic
> buildings (there exist far worse than that):
> https://i.imgur.com/CNfDjvw.png If we want to preserve history for these
> buildings as well - fine by me.
> 4) *Import data quality vs existing OSM quality*. If there is any
> difference it should be addressed on a case-by-case basis by a person doing
> the import. Checking building history, imagery, etc. From my experience in
> Toronto East, import data is almost always more recent and has better
> details. IMO in the end we should try to replace geometries in most cases.
> 5) Secondary bulidings that are not in the dataset (*sheds, garages*). We
> should leave those to local mappers. Import should only be about importing
> data from the dataset.
> 6) *Square sizes*. I agree, in the high density Toronto core current
> squares are indeed too big. However, creating new smaller project at this
> point would make things quite complicated along the edges since we would
> have to deal with already imported data. I would prefer to finish Ontario
> project the way it is right now. If a square turns out to be too massive,
> the person doing the import will need to tackle that square in several
> changesets.
>
>
> On Sun, Feb 3, 2019 at 7:06 PM john whelan  wrote:
>
>> I'm not hearing we have a clear consensus on modifying the shape of
>> buildings with scripts and the Q button.
>>
>> My own personal view is it could introduce errors and unless it is very
>> obviously wrong when it should get picked up by the importing mapper it
>> should be left as is.
>>
>> Cheerio John
>>
>> On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:
>>
>>> I'm hearing we keep the single import project as such.
>>>
>>> I'm hearing that we should preprocess the data first splitting out
>>> outlines that meet Pierre's right angle checks.  This data can just be
>>> imported using the current processes.
>>>
>>> I'm hearing we should then run the correcting scripts and extract the
>>> corrected buildings.  This becomes the second stage.  This data should be
>>> imported separately to the first since it needs to be more closely
>>> inspected in case the script has caused some deformation.
>>>
>>> At the moment I'm not sure if the two scripts above exist.
>>>
>>> I'm hearing what is left becomes the third stage which needs to be
>>> sorted out manually before being made available for import.  Again I see
>>> this as a separate task since the outlines will have been modified from the
>>> original.
>>>
>>> Note to James is the above practical?  Do we have the resources to do
>>> it?  Please do not do anything until we have an agreement to proceed.
>>>
>>> I'm hearing the existing imported building outlines will be subject to
>>> an overpass to pick out those building outlines that are not square.
>>>
>>> Then the "a miracle occurs" box on the project plan gets these into a
>>> JOSM todo list and mappers manually sort them out.  I'm not certain how
>>> this will happen.  I suspect if the overpass query is small enough and
>>> the buildings are loaded up from an off line source this might work.
>>>
>>> To come back to Toronto my feeling is this is best left to the local
>>> mappers in Toronto to decide how to proceed.  Ther

Re: [Talk-ca] Building Import update

[john whelan]

I'm not hearing we have a clear consensus on modifying the shape of
buildings with scripts and the Q button.

My own personal view is it could introduce errors and unless it is very
obviously wrong when it should get picked up by the importing mapper it
should be left as is.

Cheerio John

On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:

> I'm hearing we keep the single import project as such.
>
> I'm hearing that we should preprocess the data first splitting out
> outlines that meet Pierre's right angle checks.  This data can just be
> imported using the current processes.
>
> I'm hearing we should then run the correcting scripts and extract the
> corrected buildings.  This becomes the second stage.  This data should be
> imported separately to the first since it needs to be more closely
> inspected in case the script has caused some deformation.
>
> At the moment I'm not sure if the two scripts above exist.
>
> I'm hearing what is left becomes the third stage which needs to be sorted
> out manually before being made available for import.  Again I see this as a
> separate task since the outlines will have been modified from the original.
>
> Note to James is the above practical?  Do we have the resources to do it?
> Please do not do anything until we have an agreement to proceed.
>
> I'm hearing the existing imported building outlines will be subject to an
> overpass to pick out those building outlines that are not square.
>
> Then the "a miracle occurs" box on the project plan gets these into a JOSM
> todo list and mappers manually sort them out.  I'm not certain how this
> will happen.  I suspect if the overpass query is small enough and the
> buildings are loaded up from an off line source this might work.
>
> To come back to Toronto my feeling is this is best left to the local
> mappers in Toronto to decide how to proceed.  There is/was room for a local
> coordinator in the project plan.  Nate's expectations are different to mine
> and I think it makes sense for the local mappers to decide what they would
> like to do together with Nate and a Toronto mapper set themselves up to
> coordinate in Toronto.  The speed at which the buildings were added has
> been raised as a concern.  I'm unable to think of a way to address this
> other than a "please take it slowly" added to the instructions.
>
> Again this option is available to any other areas who would like to use
> this method.
>
> I feel for Quebec the best thing to do is hold back until we have an
> agreement for the rest of the country since there are Quebec mappers who
> are not following this thread on talk-ca and to be honest we do seem to be
> evolving on a hourly basis so waiting until the dust settles might well be
> sensible.
>
> Am I missing something apart from my sanity?
>
> Thanks John
>
> On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:
>
>> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
>> qu'ensuite il sera beaucoup plus simple d'importer les données déja
>> corrigées. Sinon une variable pour distinguer les deux et risque de
>> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
>> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
>> données corrigées.
>>
>> L'importation des données orthogonales devrait être grandement facilitée.
>> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
>> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
>> s'agirait davantage de valider avec l'imagerie et de faire la conflation
>> avec les données existantes.
>>
>> Pour l'importation des données irrégulières, il faudrait oui valider /
>> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
>> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
>> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
>> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
>> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
>> greffon ToDo est très utilie pour réviser successivement des données et
>> s'assurer de toutes les réviser.
>>
>> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment
>> ci-dessous avec beaucoup d'angles se rapprochant de 90 degrés mais avec une
>> variance plus grande que +-5 degrés. Pour détecter davantage de bâiments
>> quasi-orthogonaux, il serait possible de tenir compte de cette situation
>> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
>> tester cette option et voir si cela permettrait de détecter un grand nombre
>> de cas.
>> angles entr

Re: [Talk-ca] Building Import update

[john whelan]

I'm hearing we keep the single import project as such.

I'm hearing that we should preprocess the data first splitting out outlines
that meet Pierre's right angle checks.  This data can just be imported
using the current processes.

I'm hearing we should then run the correcting scripts and extract the
corrected buildings.  This becomes the second stage.  This data should be
imported separately to the first since it needs to be more closely
inspected in case the script has caused some deformation.

At the moment I'm not sure if the two scripts above exist.

I'm hearing what is left becomes the third stage which needs to be sorted
out manually before being made available for import.  Again I see this as a
separate task since the outlines will have been modified from the original.

Note to James is the above practical?  Do we have the resources to do it?
Please do not do anything until we have an agreement to proceed.

I'm hearing the existing imported building outlines will be subject to an
overpass to pick out those building outlines that are not square.

Then the "a miracle occurs" box on the project plan gets these into a JOSM
todo list and mappers manually sort them out.  I'm not certain how this
will happen.  I suspect if the overpass query is small enough and the
buildings are loaded up from an off line source this might work.

To come back to Toronto my feeling is this is best left to the local
mappers in Toronto to decide how to proceed.  There is/was room for a local
coordinator in the project plan.  Nate's expectations are different to mine
and I think it makes sense for the local mappers to decide what they would
like to do together with Nate and a Toronto mapper set themselves up to
coordinate in Toronto.  The speed at which the buildings were added has
been raised as a concern.  I'm unable to think of a way to address this
other than a "please take it slowly" added to the instructions.

Again this option is available to any other areas who would like to use
this method.

I feel for Quebec the best thing to do is hold back until we have an
agreement for the rest of the country since there are Quebec mappers who
are not following this thread on talk-ca and to be honest we do seem to be
evolving on a hourly basis so waiting until the dust settles might well be
sensible.

Am I missing something apart from my sanity?

Thanks John

On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:

> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
> qu'ensuite il sera beaucoup plus simple d'importer les données déja
> corrigées. Sinon une variable pour distinguer les deux et risque de
> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
> données corrigées.
>
> L'importation des données orthogonales devrait être grandement facilitée.
> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
> s'agirait davantage de valider avec l'imagerie et de faire la conflation
> avec les données existantes.
>
> Pour l'importation des données irrégulières, il faudrait oui valider /
> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
> greffon ToDo est très utilie pour réviser successivement des données et
> s'assurer de toutes les réviser.
>
> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous
> avec beaucoup d'angles se rapprochant de 90 degrés mais avec une variance
> plus grande que +-5 degrés. Pour détecter davantage de bâiments
> quasi-orthogonaux, il serait possible de tenir compte de cette situation
> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
> tester cette option et voir si cela permettrait de détecter un grand nombre
> de cas.
> angles entre 82.6 et 94.5 degrés
>
> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
> https://www.openstreetmap.org/way/479048070
>
> Pierre
>
>
> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I accept the nicest way is to check the data beforehand.  Scripting it is
> fairly simple.  Are you suggesting a two stage process of take the data and
> run the script first then task manager the data to be imported to manually
> correct the data?  My eyesight isn't good enough to pick out none right
> angled corners so is there some way someone can come up with 

Re: [Talk-ca] Building Import update

[john whelan]

I accept the nicest way is to check the data beforehand.  Scripting it is
fairly simple.  Are you suggesting a two stage process of take the data and
run the script first then task manager the data to be imported to manually
correct the data?  My eyesight isn't good enough to pick out none right
angled corners so is there some way someone can come up with to feed them
into a JOSM todo list?

However we have a fairly large number of building outlines that have
already been imported.  The issue here is different as extra tags have been
added.  Can the questionable ones be identified in such a way that a JOSM
todo list can be used to correct them rather than throw out all the work
that has been done adding tags?

I think you are assuming a more top down management arrangement than exists
with volunteer Canadian mappers.

Thanks John

On Sun, 3 Feb 2019 at 15:33, Pierre Béland  wrote:

> John
>
> Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier
> la donnée avant l'importation. Des critères comme ceux que j'ai présenté
> pourraient être utilisés dans un script pour simplifier les polygones qui
> sont quasi orthogonaux.
>
> Pour simplifier la procédue d'import, deux fichiers distincts pourraient
> être produits :
>
> 1. Formes géométriques quasi-orthogonales corrigées - import plus rapide -
> mais a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
>
> 2. Formes géométriques irrégulières - Import avec révision / correction
> plus serrée.
>
> Il reste à ceux qui mènent le projet de faire ces développements
> logiciels. Et pourquoi pas, de proposer des outils que les communautés
> locales pourront ensuite utiliser. Par contre éviter qu'un petit groupe
> importe rapidement les données et ignore le rôle des communautés locales.
>
> Et l'argument, si tu t'opposes, tu est responsable pour ta communauté,
> nous ont fait le reste du pays, à mon avis cela ne tient pas la route.
>
> Pierre
>
>
> Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> So you're proposing that a script is run to correct minor deviations in
> the remaining data which sounds a reasonable approach to me and would
> improve data quality.
>
> So run the data through the script.  Then import and run overpass to pick
> out those that need manual adjustment?
>
> If we do this though then I think we need to stay with the single import
> plan rather than have individual import plans popping up that didn't use
> the scripts.
>
> I have no control over the number of mappers importing or the rate at
> which they import and I'm not sure how you would mange this other than
> having a person identified in the wiki as leading a particular area and
> there is provision or rather was I'm not sure what the latest version says.
>
> Even with smaller import plans there would be nothing to stop one mapper
> bringing in building outlines very quickly.
>
> Cheerio John
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

So you're proposing that a script is run to correct minor deviations in the
remaining data which sounds a reasonable approach to me and would improve
data quality.

So run the data through the script.  Then import and run overpass to pick
out those that need manual adjustment?

If we do this though then I think we need to stay with the single import
plan rather than have individual import plans popping up that didn't use
the scripts.

I have no control over the number of mappers importing or the rate at which
they import and I'm not sure how you would mange this other than having a
person identified in the wiki as leading a particular area and there is
provision or rather was I'm not sure what the latest version says.

Even with smaller import plans there would be nothing to stop one mapper
bringing in building outlines very quickly.

Cheerio John

On Sun, 3 Feb 2019 at 14:09, Pierre Béland  wrote:

> Le «acid test» de John, avec une architecture aussi irrégulière, a abimé
> les «Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur
> Orléans à l'extérieur de la zone étudiée ! Une analyse plus approfondie de
> la zone du centre-ville nous montre qu'il y a peu de telles architectures.
> Cette réponse ne tient pas la route et n'explique pas le ratio élevé de
> polygones avec formes irrégulières dans la base OSM.
>
> Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à
> corriger pour orthognaliser. voir
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html
>
> Ce que je comprends bien aux réactions de John depuis le début, c'est
> laissons les données telles qu'elles.  Plusieurs évitent de se pronconcer.
> Cela ne me convainct pas de l'urgence pour un petit groupe de se hâter à
> importer les données sans tenir compte de problèmes de qualité importants.
>
> J'ai révisé mon script qualité pour cerner davantage les formes
> régulières. Il tenait compte jusqu'ici des angles à 90 degrés et des autres
> formes régulières (hexagones, octogones, etc). Je l'ai révisé au cours des
> derniers jours acceptant une tolérance jusqu'à 5 degrés. Les angles à 45
> degrés  (ie. 45, 135, 225, 315) sont maintenant pris en compte.
>
> Ces modifications ont eu peu d'impact sur le nombre de bâtiments
> identifiés avec formes irrégulières. Cela confirme qu'il a a des polygones
> avec formes qui s'éloignent sensiblement de formes régulières.
>
> Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments
> peuvent être orthogonalisés automatiquement à l’aide de scripts. Ou encore
> il serait possible de réviser tous les bâtiments avec tolérance de 1 à 5
> degrés (ceux à moins de 1 degrés resteraient tels quels. Malgré tout, Il
> reste toujours 25% des bâtiments qui doivent être analysés manuellement et
> voir si des corrections sont nécessaires.
>
>
> Pierre
>
>
> Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I can't think of a way to pull in all the suspect buildings but if you
> have a look here:
>
>
> https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696
>
> 556, 558, 560 are all examples that I think would fail your test.  However
> they are the shape of the buildings.
>
> As far as I am aware we haven't had any outraged users complaining about
> the building shapes in Ottawa and that I think is the acid test.  The
> Ottawa building import has been useful certainly in gaining new mappers and
> adding tags to the outlines.
>
> Your test originally was to pick out very badly mapped buildings that had
> been done in iD and I would agree with you that some were very bad.
> Sometimes 3 or 4 times the size of the building and some very odd shapes
> indeed.  From memory most were done on HOT tasks with the iD editor.
>
> These I think we should definitely aim to avoid but where the
> representation of the building is reasonably accurate then I think they are
> acceptable.  We are using reasonably experienced mappers who would balk at
> importing some of the stuff we saw in Nepal etc and rightly so.  They'd
> almost certainly be very vocal about the quality of the data.
>
> There is a case to be made that most residential buildings would be
> acceptable if they were mapped with the JOSM buildings_tool plugin and all
> the small blobs take up database size.  There is also a case that you get a
> better sense of the building with the small blobs, bay windows etc.  I
> don't have strong feelings either way but I strongly suspect there are
> examples of both already in OSM in Canada.
>
> I note that both Google and Bing have most buildings these days and it has
> almost become a map user expectation.  Certainly there are apps that guide
> blind people

Re: [Talk-ca] Building Import update

[john whelan]

The Ottawa building outline import was done by the local Ottawa mappers to
a standard they were happy with.

Cheerio John

On Sun, 3 Feb 2019 at 14:42, Pierre Béland  wrote:

> De tes exemples sortis du chapeau ne font pas avancer la discussion.
>
> J'attends la démonstration de John que les données d'import pour Ottawa
> représentent bien le contour des bâtiments et sont des données de qualité.
>
> Pierre
>
>
> Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> From OSMweekly 445 and I'm not sure if it is relevant or not.
>
> Cheerio John
>
> Imports
>
>- Frederik Ramm suggested
>
> <https://lists.openstreetmap.org/pipermail/imports/2019-January/005902.html>
>reverting a four-year-old building import in Ulster County, New York State,
>because only simple squares had been imported instead of the correct
>building outlines. Two years ago the import was featured
>
> <http://worstofosm.tumblr.com/post/148016716836/in-ulster-county-ny-people-live-in-small-square>
>by *Worst of OSM*.
>
>
> On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:
>
> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> 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 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
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

[john whelan]

So I suggest that you name yourself as the coordinator on the wiki page for
Toronto that allows the local mappers in Toronto to import at the rate and
to the standard you suggest.

For the rest of the country the data is licensed to be acceptable to
OpenStreetMap thus anyone can set up their own import plan and import it
even if this import is abandoned.  I'd like to see this voiced as the
general desire though on talk-ca before it happens as it was a talk-ca
decision to proceed.

My reading of the posts on talk-ca is that there is a desire to bring in
the buildings by many.  There is also a desire by many to use them for many
purposes.

Cheerio John

On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John,
>
> You seem to be mostly addressing topics which have been brought up
> elsewhere. My email was meant to address specific data quality issues in
> Toronto, so I'm not sure how to respond to all of this.
>
> To your broader question though, my position is that we *do* have the
> volunteers and skills necessary to make this a good import. Supposing that
> we didn't though, then I would have to say that the import should wait
> until we have the right people working on it. A bad import is worse than no
> import.
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 2/3/19 1:14 PM, john whelan wrote:
>
> My expectation was that the import would be based on the city's records of
> foundations for the buildings.
>
> I would not expect to see sheds etc.and I'd be quite happy to only get
> most of the buildings. The rest can be added by local mappers at a later
> date.
>
> My expectation is they will be consistent and not some mapped from Bing,
> others from ESRI etc.
>
> There are estimated to be in excess of 11,000,000 buildings in Canada.  I
> don't think we have enough skilled mappers to map them all from imagery.
>
> My expectation is the import would give us a reasonable number of fairly
> accurate building outlines at relatively low cost in mapper time.  Missing
> building imports from city open data are now fairly common in many parts of
> the world.
>
> My expectation is that the building outlines would have additional tags
> added and that this would draw in less skilled mappers.  At the same time
> corrections could be made to the outlines if deemed necessary.
>
> It would avoid too many badly mapped buildings.
>
> Before the import started it was raised in talk-ca and there was some
> discussion.  I understand you were not a member at that time or took part
> in that discussion but that doesn't change the fact that the issue was
> discussed.
>
> The idea of a single import plan came from talk-ca and that is why there
> is a single import plan covering the entire country and there was
> discussion on talk-ca on the point.
>
> The original plan on the wiki mentioned having some coordination in an
> area.  I don't think this happened but it was an attempt to give a louder
> local voice as it was recognised it would be better if local mappers took
> the lead.
>
> Different mappers have different ideas of what is acceptable.  I think
> your standards are fairly high thus more demanding in resources and do we
> have enough resources?  I don't think we do to import to the standard at
> which you are asking.
>
> Could you clarify what you are saying?
>
> I assume that for other parts of the country if they wish to continue and
> find the building outlines acceptable they may do so?
>
> Thanks John
>
> Thanks John
>
>
>
> On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:
>
>> Hi all,
>>
>> I had a chance this morning to work on cleaning up some of the
>> already-imported data in Toronto. I wanted to be a little methodical about
>> this, so I picked a single typical block near where I live. All the
>> building data on this block came from the import and I did everything in
>> one changeset: https://www.openstreetmap.org/changeset/66881357
>>
>> What I found was that:
>>
>> 1) Every single building needed squaring
>>
>> 2) Most buildings needed at least some simplification.
>>
>> 3) 42 buildings were missing.
>>
>> I knew going in that the first two would be an issue, but what really
>> surprised me was just how many sheds had not been imported. There are only
>> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
>> quite large, and none of which had been mapped.
>>
>> I haven't seen the quality of the outbuildings in the source data, and
>> maybe I would change my mind if I did, but I think if we're going to do
>> this import pro

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

[john whelan]

My expectation was that the import would be based on the city's records of
foundations for the buildings.

I would not expect to see sheds etc.and I'd be quite happy to only get most
of the buildings. The rest can be added by local mappers at a later date.

My expectation is they will be consistent and not some mapped from Bing,
others from ESRI etc.

There are estimated to be in excess of 11,000,000 buildings in Canada.  I
don't think we have enough skilled mappers to map them all from imagery.

My expectation is the import would give us a reasonable number of fairly
accurate building outlines at relatively low cost in mapper time.  Missing
building imports from city open data are now fairly common in many parts of
the world.

My expectation is that the building outlines would have additional tags
added and that this would draw in less skilled mappers.  At the same time
corrections could be made to the outlines if deemed necessary.

It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some
discussion.  I understand you were not a member at that time or took part
in that discussion but that doesn't change the fact that the issue was
discussed.

The idea of a single import plan came from talk-ca and that is why there is
a single import plan covering the entire country and there was discussion
on talk-ca on the point.

The original plan on the wiki mentioned having some coordination in an
area.  I don't think this happened but it was an attempt to give a louder
local voice as it was recognised it would be better if local mappers took
the lead.

Different mappers have different ideas of what is acceptable.  I think your
standards are fairly high thus more demanding in resources and do we have
enough resources?  I don't think we do to import to the standard at which
you are asking.

Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue and
find the building outlines acceptable they may do so?

Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

>From OSMweekly 445 and I'm not sure if it is relevant or not.

Cheerio John

Imports

   - Frederik Ramm suggested
   
   reverting a four-year-old building import in Ulster County, New York State,
   because only simple squares had been imported instead of the correct
   building outlines. Two years ago the import was featured
   

   by *Worst of OSM*.


On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> 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 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

So how would you tackle it?

Adding buildings with JOSM and the buildings_tool is possible, I think
Julia tried to whip up some interest with the 2020 project.  Unfortunately
mapathons using iD and new mappers for some reason don't work too well for
buildings. They do work fine for adding tags though.

I seem to recall March 2nd is some sort of student GIS day and we can
expect something to happen in GEO/GIS week whenever it is.  I'd prefer
adding tags to existing outlines rather than having to clean up buildings
added with iD.

If we go back in time to the Ottawa import and the licensing issues I seem
to recall a Toronto mapper submitting the Toronto Open Data License to the
legal working group which implies at least one Toronto OSM mapper was after
the Toronto Open Data.

My feeling at the moment is there is a suggestion that "cleaning" the data
up then some sort of team approach in a particular area would be acceptable
but how you put it together I'm not sure.

Suggestions please

Thanks

Cheerio John

On Fri, 1 Feb 2019 at 15:52, Begin Daniel  wrote:

> +1
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Friday, February 01, 2019 08:54
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Building Import update
>
>
>
> John,
>
> IMO, this is a red herring and I think you must recognize that to at least
> some degree. Just like no one suggested we do 3700 import plans, no on has
> suggested that we not add buildings to OSM. The question is how, and if
> that "how" in part is an import, then what data, at what speed, by who, etc?
>
> We're not debating between "import" and "nothing" here. There were tens of
> thousands of carefully hand-mapped buildings in Toronto before you and a
> couple others rode in and quietly changed everything in the course of a
> week.
>
> I'd like to point out to you the interesting case of Kenton County
> Kentucky:
> https://www.openstreetmap.org/relation/361564
>
> Go ahead and zoom in and take a good look at that data. Poke around the
> rest of Northern Kentucky too while you're at it. Notice how good not only
> the building data is, but landuses, named places, etc. The only substantial
> import this area has ever seen is the TIGER road import of about a decade
> ago. By the time we started our Hamilton County building import (just north
> of the river), there were more than 150,000 buildings added by hand in the
> region already.
>
> I'm not saying this is the way Toronto/Canada needs to develop, but don't
> imply that it's impossible - it isn't.
>
> Cheers,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 2/1/19 7:35 AM, john whelan wrote:
>
>
> https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069
>
>
>
> https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z
>
>
>
> https://www.bing.com/maps?FORM=Z9LH3
>
>
>
> Port Hope Ontario is relatively obscure yet both Bing and google have
> buildings and neither company would spend the money dropping them in unless
> they saw a demand.
>
>
>
> A small sample but I'm sure that others are quite capable of looking
> locally for themselves.
>
>
>
>
>
> I'm a shades of grey person so to me there is no absolute need to have
> buildings in OpenStreetMap and I think different end users have different
> expectations.  I seem to recall osmand has a street only map which takes up
> less room on the device.  It's perfectly adequate for some users.
>
>
>
> I can make a case for both having them and not having any.  On the not
> having any way up there would be the buildings added by inexperienced
> mappers using iD often in HOT projects.  There are duplicates, strange
> shapes that bare no relation to any imagery, and city blocks marked as a
> single building.  On the having them side would be where can I get a coffee
> and wifi?
>
>
>
> There are many users of the map who would like to see buildings or more
> importantly have building information available in an electronic form.
>
>
>
> For Ottawa I think I can safely say the local mappers are happy with the
> imported buildings.  In OpenStreetMap there will always be a range of
> points of view.
>
>
>
> As you say it is for the local mappers to decide what they would like to
> do.  In this case is it difficult to define the local mappers.
>
>
>
> Cheerio John
>
>
>
>
>
>
>
>
>
> ___
>
> Talk-ca mailing list
>
> Talk-ca@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069

https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z

https://www.bing.com/maps?FORM=Z9LH3

Port Hope Ontario is relatively obscure yet both Bing and google have
buildings and neither company would spend the money dropping them in unless
they saw a demand.

A small sample but I'm sure that others are quite capable of looking
locally for themselves.


I'm a shades of grey person so to me there is no absolute need to have
buildings in OpenStreetMap and I think different end users have different
expectations.  I seem to recall osmand has a street only map which takes up
less room on the device.  It's perfectly adequate for some users.

I can make a case for both having them and not having any.  On the not
having any way up there would be the buildings added by inexperienced
mappers using iD often in HOT projects.  There are duplicates, strange
shapes that bare no relation to any imagery, and city blocks marked as a
single building.  On the having them side would be where can I get a coffee
and wifi?

There are many users of the map who would like to see buildings or more
importantly have building information available in an electronic form.

For Ottawa I think I can safely say the local mappers are happy with the
imported buildings.  In OpenStreetMap there will always be a range of
points of view.

As you say it is for the local mappers to decide what they would like to
do.  In this case is it difficult to define the local mappers.

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