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

[James]

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, 
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 
> ___
> 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] can I submit road data?

[James]

https://wiki.openstreetmap.org/wiki/Import/Guidelines

Usually involves creating a wiki page like

https://wiki.openstreetmap.org/wiki/Ottawa/Import/Plan

outlining that licensing isnt an issue and what tags would be
used(addr:housenumber and addr:street for address points) as well as
contigency for conflating against existing data

On Tue., Jul. 7, 2020, 5:11 p.m. Jason Carlson, 
wrote:

> Okay, I'll scrap the idea of importing roads - mostly because they are
> already there - just off skew but a dozen or more meters in many places. I
> wrote software to fix most of our issues in our area - maybe there is an
> API to do the same with OSM and I can volunteer some skills there.
>
> As a side note, what about point data. I have a bunch of rural addresses
> that I could upload as point data and it would be a lot easier to do the
> initial import at least if I can get a hold of those guidelines so I can
> set it up right the first time :) You know where I can find those?
>
>
> *Jason Carlson*
>
> IT/GIS Administrator
>
> *403.772.3793*
>
> *Starland County*
> *Morrin, AB  *
> *(403) 772-3793*
> *www.starlandcounty.com *
>
> *Our organization accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the information
> provided, unless that information is subsequently confirmed in writing. The
> content of this message is confidential. If you have received it by
> mistake, please inform us by an email reply and then delete the message. It
> is forbidden to copy, forward, or in any way reveal the contents of this
> message to anyone. *
>
>
> On Tue, Jul 7, 2020 at 2:16 PM stevea  wrote:
>
>> > Imports are quite the pain to try and do - there's a whole process in
>> place now to do them. It stems from the experience in the States of an
>> import more than a decade ago of the TIGER data (from the Census Bureau)
>> that is still being fixed after pretty large amounts of time working
>> through it.
>>
>> Major components of the USA's TIGER import included both road (highway=*)
>> and rail (railway=*).  This took place in 2007-8 with early-to-mid-2000s
>> data and resulted in OSM data which were (and still are in places) quite
>> problematic.  There have been many strategies and even renderers which aim
>> to address helping fix the massive amount of TIGER data that were imported,
>> yet it will likely take another decade (three?) to complete these
>> improvements — that's a lot of work.  This sort of "ongoing work to improve
>> an import" is common with earlier / older imports (especially when OSM had
>> little to no "official" guidelines to doing imports well).  Our Import
>> Guidelines go a long way towards remedying common problems associated with
>> imports from "lessons learned" in earlier ones, but imports are still both
>> controversial and often problematic.  However, there are excellent examples
>> of well done imports, usually with very carefully written Import
>> Guidelines, a good deal of community buy-in and consensus and often the
>> guidance of OSM volunteers who have experience with imports and can steer
>> the process in better directions if they begin to go awry.  I don't need to
>> say it, but Kevin is correct:  let TIGER be a lesson to OSM about imports,
>> especially those done at very wide (national) scales in large geographic
>> areas like Canada or USA.  They are challenging to do well, but shouldn't
>> be completely prohibited, but rather done quite carefully and slowly.
>>
>> SteveA
>> California
>
> ___
> 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] NRCan lakes

[James]

I don't think canvec is updating these things on a regular basis, OSM after
corrections are usually more accurate than canvec anyways and doubt would
update data from Canvec to fix outdated data

On Tue., Jul. 7, 2020, 11:27 a.m. Hannes Röst,  wrote:

> Dear Adam and Daniel
>
> Thanks a lot, so this answers the question that these are import artefacts
> and not intended. One question still remains, namely whether we should
> clean them up and how (joining ways makes sense from the OSM data model but
> may make a future update based on CANVEC files much harder while adding all
> ways into a relation would preserve the import but the resulting shape will
> look funny). My instinct is still to fix the ways unless there is a strong
> reason against this. One reason I ran into this was trying to match OSM to
> Wikidata items and of course having 3 ways all called the same name makes
> this difficult. Let me know what you think
>
> Another issue I found was with nodes such as these: 1279897592, 1279898654
> and 1279896951 which also seem to come from an import (see [1] for overpass
> query). I am not sure whether these are duplicate imports or whether they
> are supposed to indicate the extent of a feature (most east and most
> western point) of the channel. The wiki indicates to either map this as
> "natural=strait" and use either a single node, a line or a multipolygon [2]
> but not as multiple nodes with the same name. Honestly, in this case its a
> bit hard to see where the supposed "channel" should be, but connecting the
> nodes to a line would seem sensible here to me, any thoughts?
>
> Best
>
> Hannes
>
> [1]
> http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B
> [2] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map
>
>
> Gesendet: Dienstag, 07. Juli 2020 um 09:56 Uhr
> Von: "Adam Martin" 
> An: "Hannes Röst" 
> Cc: "Talk-CA OpenStreetMap" 
> Betreff: Re: [Talk-ca] NRCan lakes
>
> As mentioned by Daniel, this is due to the nature of the CANVEC data
> import.  CANVEC shapefile data is based on tiles and these will chop
> practically anything into pieces - lakes are just ones of the more
> noticeable.  I have corrected some of these myself as I've come across
> them.  Just be careful in cases where the lake pieces are part of different
> relations in the area - you will need to adjust those to make sure nothing
> breaks.
>
> Adam
>
> On Tue, Jul 7, 2020 at 2:33 AM Hannes Röst  hannesro...@gmx.ch]> wrote:Hello
>
> I am a contributor from Toronto and I have a question regarding how to
> treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
> I came across this lake here:
>
>
> https://www.openstreetmap.org/way/69275451[https://www.openstreetmap.org/way/69275451]
> https://www.openstreetmap.org/way/69277932
> https://www.openstreetmap.org/way/69745752
>
> Which is strangely split up into 3 parts and I wonder how to proceed:
> should we fix this and create a single way out of these 3 parts or is
> it beneficial (for comparison to future NRCan database entries) to
> keep them that way and create a relation out of the three? Also, does
> somebody know why the NRCan dataset does this, is this an import
> artefact (splitting into tiles?) and should be corrected when encountered
> or is it part of the original dataset?
>
> Best
>
> Hannes Rost
>
> ___
> 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
> 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] (no subject)

[James]

If it becomes over 2000 nodes in a single "way" or shape, it's recommended
to make it a multipolygon. The reason NRCan does this is probably because
it's on the edge of what they call "NTS Tiles" which is a grid that
organizes the data (see forests in Canada
https://wiki.openstreetmap.org/wiki/Canada#What.27s_with_the_forests_in_Canada.3F).
Importers just didnt join them back in the day, that's all

On Tue, Jul 7, 2020 at 5:02 AM Hannes Röst  wrote:

> Hello
>
> I am a contributor from Toronto and I have a question regarding how to
> treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
> I came across this lake here:
>
> https://www.openstreetmap.org/way/69275451
> https://www.openstreetmap.org/way/69277932
> https://www.openstreetmap.org/way/69745752
>
> Which is strangely split up into 3 parts and I wonder how to proceed:
> should we fix this and create a single way out of these 3 parts or is
> it beneficial (for comparison to future NRCan database entries) to
> keep them that way and create a relation out of the three? Also, does
> somebody know why the NRCan dataset does this, is this an import
> artefact (splitting into tiles?) or is it part of the original
> dataset?
>
> Best
>
> Hannes Rost
> ___
> 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] WikiProject Canada Post - franchise assessment

[James]

if the addresses are not geolocated via say the website/google maps, it
just becomes public domain as it's the address of the business on the
website but IANAL. If not you would never be able to scrape/collect phone
numbers or addresses for any business via their official website.

On Tue., Jun. 16, 2020, 10:18 a.m. john whelan, 
wrote:

> 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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Business data in northern Montreal

[James]

Man when you're north of the 25 in Montreal, it's either because you live
there or you are on your way to Québec City. Not a lot going on in the
northern tip of the island

On Sun., Jun. 14, 2020, 4:43 a.m. David Nelson via Talk-ca, <
talk-ca@openstreetmap.org> wrote:

> As part of my efforts to advance WikiProject Canada Post, I noticed that
> the portion of the Island of Montreal north of Autoroute 25 is missing
> quite a bit of business data.  When looking through our database for
> businesses that act as franchises for Canada Post outlets, I was not able
> to find more than half of them in the aforementioned part of Montreal.  Is
> it possible that any active mappers in that part of the city could go out
> and improve OSM's business coverage there?
>
>
>
> - 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

Re: [Talk-ca] Ça reste ouvert

[James]

Personellement  je trouve ça vraiement innutile, car dans 4 mois ou
presque, ces tags seront désuets et grossira la db pour rien. Il serait
plus simple de prendre les reglements tel que pharmacie ou épicerie et les
combiner avec les tags OSM tel que amenity=pharmacy et faire du post
processing avec une db à part.

Je ne supporte aucunement cette effort

On Fri., Apr. 10, 2020, 7:29 a.m. Pierre-Léo Bourbonnais, 
wrote:

> J'appuie à 100%
>
> Envoyé de mon iPhone
>
> Le 9 avr. 2020 à 20:22, Pierre Béland via Talk-ca <
> talk-ca@openstreetmap.org> a écrit :
>
> 
> En quelques semaines,  la communauté OSM-France a débuté le projet de
> carte Ça reste ouvert et traduit en plusieurs langues.  Une application
> Android est aussi développée. Et l'application permet de se connecter à OSM
> et ajouter des données.
>
> https://www.caresteouvert.fr/@48.854628,2.424893,13.48
> https://github.com/osmontrouge/caresteouvert
>
> Plus de 20 000 objets ont été édités en France seulement. Puis plusieurs
> pays ont été ajoutés : Allemagne, Suisse, Espagne, Andorre.
>
> Si des contributeurs canadiens sont intéressés à l'ajout du Canada au
> projet, ce serait l'occasion de faire la promotion d'OSM au Canada et
> d'ajouter rapidement de nombreux POI de commerces et producteurs locaux.
> Dans chaque province, nous pourrions faire la promotion du projet et
> inviter à participer.
>
> Je vois plusieurs projets organisés rapidement au Québec, mais je pense
> que si nous réagissons rapidement et ajoutons des commerces, cela pourrait
> susciter un intérêt pour utiliser OpenStreetMap.
>
> Qu'en pensez-vous?
>
> Pierre
>
>
> [OSMBC] WN507 changed: Ça reste ouvert | The map of open places during
> lockdown
> Yahoo/Boîte récept.
>
>-
>
> os...@openstreetmap.de 
> À :pierz...@yahoo.fr
> jeu. 9 avr. à 19 h 03
> Change in article of WN507
>
> Article Ça reste ouvert | The map of open places during lockdown
>  was changed by Claas
> Augner
> collection was changed
>
> https://www.bleibtoffen.de/ https://www.bleibtoffen.ch/
> https://www.bleibtoffen.at/ https://www.caresteouvert.fr/
> https://github.com/osmontrouge/caresteouvert_android
> https://apps.apple.com/app/ça-reste-ouvert/id1506199151
> https://taginfo.geofabrik.de/europe/france/keys/opening_hours%3Acovid19
> https://github.com/osmontrouge/caresteouvert/issues/new/choose
> markdownEN was changed
>
> Ça reste ouvert, the map of open places during the COVID-19 lockdown, has
> collected opening hours in France [for almost 20,000 objects](
> https://taginfo.geofabrik.de/europe/france/keys/opening_hours%3Acovid19)
> within three weeks. The French community collaborates with several
> communities and has added new countries to the map: Germany, Switzerland
> and Austria (as ["Bleibt offen"](https://www.bleibtoffen.de/)) as well as
> Spain and Andorra. Their GitHub repository provides [an issue template](
> https://github.com/osmontrouge/caresteouvert/issues/new/choose) to
> request coverage for your country. The French service provider TransWay has
> [published](https://apps.apple.com/app/ça-reste-ouvert/id1506199151) a
> mobile app for iOS. Eric Afenyo is [developing](
> https://github.com/osmontrouge/caresteouvert_android) one for Android.
>
> ___
> 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] Tagging sidewalks as separate ways and issues with bicycle routing

[James]

I mapped most the sidewalks in Ottawa with another person and we did it as
part of the community, no strings attached.

On Fri., Apr. 3, 2020, 4:26 p.m. 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
> anywhere. Happily I haven't yet encountered people cris-crossing the
> streets with footway connections to "make the routing work" in these
> countries. If you're in a country where you are only allowed to cross at
> marked crossings then that is easier.)
>
> All this is a sad state of affairs; if we had routing engines that could
> work well with simple "sidewalk" tags (and also make standard
> assumptions about which road types in which countries would usually have
> sidewalks even if not explicitly tagged), then we could save ourselves a
> *lot* of separately mapped sidewalks that really do not add valuable
> information, and just serve as crutches for routing engines.
>
> Personally I am very much opposed to the separate mapping of 

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

[James]

For example: Toronto has a bylaw if you are over 14 years old, you are not
allowed to ride bike ever on sidewalk, if you are 14 and under and feel
unsafe on road, you are allowed

At a certain point you need to use your judgement and know local laws

On Fri., Apr. 3, 2020, 11:37 a.m. Justin Tracey,  wrote:

> I was assuming cyclists can figure out a turn indication onto a sidewalk
> should instead be interpreted as onto the adjacent street; maybe that's
> more difficult than I'd assumed.
>
> The Region of Waterloo allows bicycles on sidewalks in some situations,
> but I believe at least most of the constituent cities in it do not. In any
> case, it's certainly not provincial law for Ontario.
>
> On Fri, Apr 3, 2020 at 3:16 PM Martin Chalifoux <
> martin.chalif...@icloud.com> wrote:
>
>> When you follow a route with a riding app, you get turn prompts that are
>> then incorrect because a sidewalk is selected rather than the street. The
>> route is not just a line on a map, it becomes a set of turn-by-turn
>> directions eventually.
>>
>> 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.
>>
>> On Apr 3, 2020, at 11:11, Justin Tracey  wrote:
>>
>> iD leaves all access tags undefined for sidewalks by default, what you're
>> seeing are the *implied* values (specifically, highway=footway implies
>> motor_vehicle=no, but does not make any implication about bicycle=*; scroll
>> down to the raw tags and you'll see both are left undefined). The reason
>> sidewalks cannot imply bicycle=no is that's not true in all legal
>> jurisdictions. The question is then whether routing engines should take
>> legal jurisdiction into account when deciding the default value for
>> bicycle=*, the way they do for maxspeed=*. The problem is that maxspeed=*
>> has defaults on a uniform provincial granularity, but bicycle=* has an
>> arbitrary granularity (any particular sidewalk could be subject to federal,
>> provincial, regional, or city laws).
>>
>> Personally, my approach has been noting when routing engines are taking
>> advantage of sidewalks they shouldn't be able to, and tagging those. Most
>> sidewalks run parallel to roads, and I assume cyclists/data consumers know
>> the respective rules they should be following, even if the routing engine
>> doesn't.
>>
>> On Fri, Apr 3, 2020 at 2:51 PM Martin Chalifoux via Talk-ca <
>> talk-ca@openstreetmap.org> wrote:
>>
>>> Maybe the issue is that in ID and I assume that is the Canadian default
>>> value, the bicycle access tag is left undefined. Why isn’t that tag
>>> defaulted to no as it is for cars ? Then an explicit yes tag can be added
>>> only to the odd place where cycling on a sidewalk is allowed. We are
>>> talking routing engines here, not the kid that plays on the street.
>>>
>>> On Apr 3, 2020, at 10:46, Nate Wessel  wrote:
>>>
>>> Which routing engines are causing problems exactly? Routing a bicycle on
>>> a sidewalk may be appropriate/reasonable in some cases and over short
>>> distances where one could be instructed to dismount and walk. I'd be
>>> interested to see some of the problematic routes that are being suggested
>>> to see if there isn't a more elegant way of resolving this.
>>>
>>> I personally only use explicit access tags where there is clear signage
>>> indicating some type of special access restriction. Otherwise the default
>>> should be assumed. Routing engines *should* be able to accommodate
>>> region differences in default values without needing to manually tag
>>> millions of ways. Whether they can or do allow that is a problem for the
>>> people developing the routing engines.
>>>
>>> Nate Wessel, PhD
>>> Planner, Cartographer, Transport Nerd
>>> NateWessel.com <https://www.natewessel.com/>
>>> On 2020-04-03 10:39 a.m., John Whelan wrote:
>>>
>>> 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 s

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

[James]

I think OSRM for bicycles prefer roads to sidewalks as a base value. And
prefer cycleways even more than roads

On Fri., Apr. 3, 2020, 11:01 a.m. Nate Wessel,  wrote:

> I've been using OSRM a lot for bicycle routing in Toronto and haven't seen
> many route suggestions that I would consider terribly unreasonable.
> Sidewalks only ever appear at the start/end of a route because they may be
> slightly closer to the requested destination.
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2020-04-03 10:51 a.m., Pierre-Léo Bourbonnais wrote:
>
> For our researches, we use the OSRM routing engine, in which the default
> profile for bicycle sets the footway to walking speed (5 km/h) instead of
> bicycle speed (around 15-20 km/h), which is the same as dismounting for
> routing purpose.
>
> On Apr 3, 2020, at 10:46, Nate Wessel  wrote:
>
> Which routing engines are causing problems exactly? Routing a bicycle on a
> sidewalk may be appropriate/reasonable in some cases and over short
> distances where one could be instructed to dismount and walk. I'd be
> interested to see some of the problematic routes that are being suggested
> to see if there isn't a more elegant way of resolving this.
>
> I personally only use explicit access tags where there is clear signage
> indicating some type of special access restriction. Otherwise the default
> should be assumed. Routing engines *should* be able to accommodate region
> differences in default values without needing to manually tag millions of
> ways. Whether they can or do allow that is a problem for the people
> developing the routing engines.
>
> Nate Wessel, PhD
> Planner, Cartographer, Transport Nerd
> NateWessel.com <https://www.natewessel.com/>
> On 2020-04-03 10:39 a.m., John Whelan wrote:
>
> 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, <
> 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 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
> --
> Sent from Postbox <https://www.postbox-inc.com/>
>
> ___
> 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] Tagging sidewalks as separate ways and issues with bicycle routing

[James]

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, <
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

Re: [Talk-ca] Importing buildings in Canada

[James]

Project #173. I've set you as an experienced mapper and you should be able
to see it.

http://tasks.osmcanada.ca/project/173

On Tue., Mar. 10, 2020, 1:05 p.m. Daniel @jfd553, 
wrote:

> Sounds good to me. Can we try it as if I don't have the data? I might then
> be able to clearly document the procedure in the wiki.
>
>
>
> Daniel
>
>
>
> *From:* James [mailto:james2...@gmail.com]
> *Sent:* Tuesday, March 10, 2020 10:38
> *To:* Daniel @jfd553
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> The task is setup in task manager, it was just more convenient serving
> data via the service. I can publish the task and invite those that have
> enough experience (they would need the orthoganalized data though) Which I
> could provide over slack(osm-ca.slack.com)
>
>
>
> On Tue., Mar. 10, 2020, 10:33 a.m. Daniel @jfd553, 
> wrote:
>
> Hi James,
>
> That is too bad, but there is no rush at this stage because we are simply
> refining the import procedure. In the meantime, I propose to act as “Task
> manager”. I can provide some tiles (task frame and orthogonalized
> buildings’ footprint) to those who wish to try the import procedure.
>
> I should start importing today with a first tile. If changes/additional
> information are needed to adjust the procedure, I suggest we discuss it on
> the import Talk page [1]
>
>
>
> Daniel
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Talk:Canada_-_The_Open_Database_of_Buildings
>
>
>
>
>
> *From:* James [mailto:james2...@gmail.com]
> *Sent:* Monday, March 09, 2020 20:13
> *To:* Daniel @jfd553
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Ok so I have some bad news, the data.osmcanada.ca server that was being
> hosted by a friend on AWS was shutdown and wiped. I will need to get time
> to get things setup on another server to host the microinstance:
> https://github.com/osmottawa/micro-data-service
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[James]

The task is setup in task manager, it was just more convenient serving data
via the service. I can publish the task and invite those that have enough
experience (they would need the orthoganalized data though) Which I could
provide over slack(osm-ca.slack.com)

On Tue., Mar. 10, 2020, 10:33 a.m. Daniel @jfd553, 
wrote:

> Hi James,
>
> That is too bad, but there is no rush at this stage because we are simply
> refining the import procedure. In the meantime, I propose to act as “Task
> manager”. I can provide some tiles (task frame and orthogonalized
> buildings’ footprint) to those who wish to try the import procedure.
>
> I should start importing today with a first tile. If changes/additional
> information are needed to adjust the procedure, I suggest we discuss it on
> the import Talk page [1]
>
>
>
> Daniel
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Talk:Canada_-_The_Open_Database_of_Buildings
>
>
>
>
>
> *From:* James [mailto:james2...@gmail.com]
> *Sent:* Monday, March 09, 2020 20:13
> *To:* Daniel @jfd553
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
>
>
> Ok so I have some bad news, the data.osmcanada.ca server that was being
> hosted by a friend on AWS was shutdown and wiped. I will need to get time
> to get things setup on another server to host the microinstance:
> https://github.com/osmottawa/micro-data-service
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[James]

Ok so I have some bad news, the data.osmcanada.ca server that was being
hosted by a friend on AWS was shutdown and wiped. I will need to get time
to get things setup on another server to host the microinstance:
https://github.com/osmottawa/micro-data-service

On Mon, Mar 2, 2020 at 7:00 PM Daniel @jfd553  wrote:

> Bonjour groupe :-)
>
> Since no one volunteered to be the local import manager for Squamish, I
> identified myself as such [1]. I have already contacted 22 local
> contributors I identified with Tim’s Overpass queries. I have modified the
> query to find users who have contributed buildings in the past 5 years. It
> is a GO for the two people who have answered me so far.
>
> I’ll wait others’ answer for the next two weeks and once the task will be
> set up (James is on it), I will start importing. I expect most of
> experienced JOSM users to also have a try in order to refine the import
> procedure.
>
>
>
> Daniel
>
>
>
> [1]
> https://wiki.openstreetmap.org/wiki/Canada_-_The_Open_Database_of_Buildings#British_Columbia
> ___
> 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] Grand-Montréal Utilisation de sidewalk pour cartographier pistes multi-usage

[James]

Je said pas si c'est pareil les MUPs à mtl qu'Ottawa/Gatineau(asphalte avec
ligne jaune dedans), mais nous le taggeons comme ceci:

https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide#Off-Road

highway =path

width =*
smoothness =*
segregated =no
surface =asphalt

centreline=yes

On Mon., Mar. 9, 2020, 1:05 p.m. Pierre Béland via Talk-ca, <
talk-ca@openstreetmap.org> wrote:

> Pour ceux d'entre-vous intéressés par la cartographie des pistes cyclables
> dans la région de Montréal,  Voir le changeset
> https://www.openstreetmap.org/way/775106882 que j'ai commenté. Jugez-vous
> souhaitable de demander à ce contributeur d'en discuter avec la communauté?
>
> Je doute que sidewalk soit approprié pour décrire les pistes
> multi-fonctionnelles adjacentes à la route. Tel qu'indiqué dans le
> changeset, le projet est de cartographier le grand-Montréal. Sur le
> boulevard Virginie-Roy a l'Île-Perrot, on observe une piste multi-fonction.
> Les attributs du chemin contiennent à la fois les attributs
> cycleway:left lane
> foot  use_sidepath
> oneway:bicycle no
> sidewalk   separate
> sidewalk:left no
> sidewalk:right  separate
>
>
> voir https://www.openstreetmap.org/way/775106882
>
>
> Pierre
> ___
> 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

[James]

if you have data and the extents I can setup tasks(send them to me somehow)

On Sat., Feb. 15, 2020, 5:07 p.m. Daniel @jfd553, 
wrote:

> Bonjour groupe,
>
> I should soon be able to feed the task manager with tiles containing no
> more than 200 buildings each.
>
>
>
> I will be using a Quadtree algorithm similar to what was used to split
> Canvec map sheets. The problem is that the algorithm creates tiles that
> keep the aspect ratio of the data bounding box. I am currently modifying
> the algorithm to generate square tiles instead, which is much more adapted
> for editing with JOSM.
>
>
>
> 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

[James]

I could set the task up to be seen only by validators+ which I then can sst
individual users as validators

On Thu., Jan. 16, 2020, 10:10 p.m. 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

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

[James]

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

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

[James]

Stats Can hosts it obviously. As for processed data, I can host it in the
tasking manager for approved regions.

On Wed., Jan. 15, 2020, 8:35 a.m. 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

[James]

Tell me when and where and the tasking manager project for xyz location
will be setup and hosted

On Sat., Jan. 4, 2020, 12:42 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 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 

Re: [Talk-ca] Importing buildings in Canada

[James]

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

Re: [Talk-ca] Parkings amb carsharing (opendata bcn)

[James]

Es el listo de email para el Canada. No esta para Catalan.

Mucho gracias

On Sun., Nov. 3, 2019, 8:03 p.m. Jarek Piórkowski, 
wrote:

> Hi Joan, this is the Canadian mailing list, not the Catalan one :)
>
> Thanks,
> --Jarek
>
> On Sun, 3 Nov 2019 at 19:59, Joan Quintana  wrote:
> >
> > Aquesta importació ha de ser fàcil, només són 25 parkings amb carsharing.
> > El dubte és l'etiqueta.
> > A [1] es proposa dues etiquetes:
> > 
> > amenity=parking
> > amenity=car_sharing
> > 
> > Però no es contempla la possibilitat de què un parking tingui un número
> reservat de places per carsharing.
> >
> > Com s'hauria de fer en aquest cas?
> > Joan Quintana
> >
> > [1]. https://wiki.openstreetmap.org/wiki/ES:Tag:amenity%3Dparking
> > ___
> > 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] Postcodes in Canada

[James]

>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.

Not necessarily. The first three characters are province, region
indicators. The last three are based on Canada Post's routes/delivery
zones. They create new ones all the time and probably not sequentially so
people need to subscribe to their shitty 5000$/year service

On Thu., Oct. 3, 2019, 12:23 a.m. Kyle Nuttall, 
wrote:

> I've found a good resource to use is a business website. Particularly a
> store with multiple locations, a mall directory, or a BIA. They have
> several postal codes that are associated with their respective addresses.
>
> Unfortunately it does require manual work (or you could pair a scrapper
> with a geocoder to do the tedious part) but given there is no available
> datasets we're licenced to use currently, it's the only public resource I
> know of where you can get pockets of postal codes.
>
> As more and more get added, the zones will begin to reflect their true
> shape more accurately and it'll be easier to extrapolate.
>
> I know it's not the best answer but any bit helps I suppose.
>
> On Oct. 2, 2019 21:33, John Whelan  wrote:
>
> 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  wrote:
>
> funny you should mention 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)
>
>

Re: [Talk-ca] Postcodes in Canada

[James]

funny you should mention 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, 
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  wrote:
> >
> > " 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 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] Ïle d'Orléan

[James]

Il se peut il y a eu une correction dans le dernier mois? Le cycle map est
une tierce partie qui le maintiens et est mise à jour ~au 30 jours.

On Mon., Jul. 8, 2019, 9:14 a.m. Pierre Boucher, 
wrote:

> Bonjour à tous,
>
> Comment ce fait-il que l'ïle d'Orléans n'apparaît pas lorsqu'on affiche
> les pistes cyclables?
>
> https://www.openstreetmap.org/#map=11/46.9266/-71.0239=C
> --
>
> *Pierre Boucher*
> Ste-Thérèse (Québec) Canada
> --
>
> *...Pensez à l'environnement avant d'imprimer ce courriel !.*
> ___
> 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

[James]

That way seems to be "tagged for the renderer".

1e Avenue is Première Avenue phonetically, but is probably 1e Avenue on the
sign.

As john has said it also depends on municipality, for example in
Orleans(french suburb of Ottawa) you can have street names like this
street(Maskinongé Crescent) https://www.openstreetmap.org/way/515701964 but
the french name is croissant du Maskinongé

On Fri., Jul. 5, 2019, 7:42 a.m. Steven Abrams,  wrote:

> 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
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Route verte besoin de corrections encore

[James]

Scuse, oui c'était bien la route 1, j'ai travaillé dessus aujourd'hui pour
complèter le plus possible

On Wed., Jul. 3, 2019, 6:53 p.m. Alouette955,  wrote:

> Pour avoir souvent réparé des relations, notamment la Route verte j’ai
> détecté  plusieurs causes aux trous (GAPs).
>
> Un , il y a des segments non encore complétés. Bien entendu, dans la
> notion de relation il est supposé qu’elle est continue mais pas dans ce
> cas-ci.
>
> Puis la Route verte tel que défini par Vélo Québec se distingue de la
> notion de relation OSM. Prenons simplement le fait qu’elle passe des Iles
> de la Madeleine à la Gaspésie. Bien entendu il n’y a pas de lien physique
> dans ce gap là. La Route verte 3 en construction est  truffée de segments
> non terminés.
>
> Et souvent des contributeurs re-fusionnent des  segments de routes qui
> avaient justement été segmentés pour définir correctement la relation.
> L’appartenance à la relation est alors étendu aux segments qui n’en font
> pas partie.
>
> En utilisant l’outil “Relation analyser” et son option “Analyze on map” on
> voit très bien les gaps ou erreurs dans la relation:
>
> http://ra.osmsurround.org/analyzeMap?relationId=416115
>
> Il suffit de zoomer sur chaque gap et on trouve l’explication et souvent
> la solution saute aux yeux.
>
> Selon moi la principale raison des erreurs dans les relations est la
> relative invisibilité des relations dans les outils. On ne nous dit pas
> toujours que ce qu’on touche impacte des relations. C’est très courant pour
> les relations de lignes de bus.
>
> Avec “Relation Analyser” on pourrait certainement s’en sortir en moins
> d’une heure pour corriger le tout.
>
> Claude
>
> *From:* Martin Chalifoux via Talk-ca
> *Sent:* Wednesday, July 3, 2019 6:02 PM
> *To:* Pierre Boucher
> *Cc:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Route verte besoin de corrections encore
>
> C’est la route verte 1 alors.
>
>
>
> On Jul 3, 2019, at 18:00, Pierre Boucher  wrote:
>
> Si on parle de la totalité que couvre la relation 416115 qui va de
> Pembroke en Ontario jusqu'en Gaspésie et aux Îles de la Madeleine elle est
> truffée de segments.
>
> "Split into several pieces
> For this relation type it is required that it exists as one piece."
>
> http://ra.osmsurround.org/analyzeMap?relationId=416115
>
> Pierre Boucher
>
> Le 2019-07-03 à 17:31, Martin Chalifoux via Talk-ca a écrit :
>
> On parle bien de Route Verte 5 ? Je vois pas vraiment de trous.
>
>
> On Jul 3, 2019, at 11:56, James mailto:james2...@gmail.com wrote:
>
> Il y a des trous dans la route verte(relation # 416115) encore et a besoin 
> d'être réparer de nouveau.
>
> J'ai essayer de remplir les trous dans l'est, mais l'ouest de Montreal a 
> beaucoup de trous.
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
> --
>
> *Pierre Boucher*
> 514.730.6211
> formation en navigation de plaisance
> Ste-Thérèse (Québec) Canada
> http://www.lavoile.com
> --
>
> *...Pensez à l'environnement avant d'imprimer ce courriel !.*
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-4885-b>
>  Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient_term=oa-4885-b>
>
> --
> ___
> 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] Route verte besoin de corrections encore

[James]

Il y a des trous dans la route verte(relation # 416115) encore et a besoin
d'être réparer de nouveau.

J'ai essayer de remplir les trous dans l'est, mais l'ouest de Montreal a
beaucoup de trous.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[James]

ODBL also has the annoying part where the data has to be fully licensed by
the data provider: if city buys data from 3rd party and they still retain
rights on it, then it becomes a problem

On Tue., Apr. 23, 2019, 12:09 p.m. Jarek Piórkowski, 
wrote:

> IANAL but as I understand it, you would have to have them release the
> data as public domain, under CC0, or under Open Database License (the
> latter is the OSM license). I don't think something like "permission
> for use in OpenStreetMap" would be sufficient, as the OSM licensing is
> intended to also allow use of OSM data in other projects.
>
> Some links:
>
> https://wiki.openstreetmap.org/wiki/Legal_FAQ#2b._XYZ_Organisation_has_data_for_free_download_under_licence_N._Can_I_use_it_in_OSM.3F
> https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility
> https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
> --Jarek
>
> On Tue, 23 Apr 2019 at 11:56, 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

[James]

While I don't see anything in the license that wouldn't be compatible with
OSM except maybe the attribution placement: as osm maintains licenses on
the wiki and not in the data it's kind of "not the same project" and you'd
have to ask city if attribution in the wiki would be sufficient then go
through the LegalWorkingGroup(4-6 months later) you might get an answer.

It would be simpler if as Kevin said, they contribute to Statstics Canada
open building database as the federal license has already been approved

On Mon., Apr. 22, 2019, 3:46 p.m. Kevin Farrugia, 
wrote:

> Hi Joshua,
>
> The national data that gets mentioned here is actually municipal data
> rolled up into one federated Federal dataset to avoid licensing issues
> since the federal license has been approved by OSM.
>
> As for the national import, that's for others to update you on 
>
> ---
> Kevin (Kevo)
>
> On Mon., Apr. 22, 2019, 3:42 p.m. 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] Building Import

[James]

If you could share the workbench it would be greatly appreciated.

Thanks

On Tue., Mar. 26, 2019, 1:11 p.m. Begin Daniel,  wrote:

> Hi Jarek,
> 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 ;-)
>
> Cheers,
> Daniel
>
> -Original Message-
> From: Jarek Piórkowski [mailto:ja...@piorkowski.ca]
> Sent: Tuesday, March 26, 2019 12:15
> To: Begin Daniel; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Building Import
>
> On Tue, 26 Mar 2019 at 11:58, Begin Daniel  wrote:
> > a first version of the cleaning tool is now functional.
> >
> > At this point, the tool is built to remove extra vertices, orthogonalize
> building footprints (when possible) and identify overlapped geometries.
> Details about the application are found in Canada Building Import
> discussion page …
> >
> >
> https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
> >
> > So far, Tim has looked at the result for Montréal (Import data) and
> Pierre for Toronto (OSM data). I understand from their comments that the
> tool generally does its job well. However, both whish to see more
> functionality added to the application (editing automation).
> >
> > Before going further, I would like to know if the community is at ease
> with the Pierre and Tim assessment, and is ready to go further in the
> import process discussion. I ask that because going further with editing
> automation will definitely be more complex, without any guarantee about the
> results.
>
> Hi Daniel,
>
> Thank you for your work on this.
>
> Are you able to share the application or code in any way? I did not
> see any links in the talk page. It is really not possible to say much
> without looking at what the code does with some of the buildings with
> geometries I'm familiar with.
>
> Alternatively shall we send you over an area we're familiar with and
> you could send over the results of the tool? But I am concerned that
> would scale really poorly.
>
> To give a concrete example, I would be curious about the output of the
> tool for area 43.6450,-79.4071,43.6358,-79.4289 - I know that the
> geometries already in OSM for the area are partially inaccurate or
> overly simplified, so I'm curious how the processed import data looks.
>
> Thanks again,
> --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] Microsoft has released its building outlines for Canada

[James]

I could serve the output using the microdataservice and the osncanada task
manager(multiple tasks)

https://github.com/osmottawa/micro-data-service

On Mon., Mar. 4, 2019, 7:16 p.m. Begin Daniel,  wrote:

> Tim,
>
> I have plenty of free time and I am interested in this import. I am about
> to complete a pre-processing tool that seems to “orthogonalize” building
> footprints pretty well using FME (safe software). I plan to present/discuss
> its functionalities next week on this list (vertex filtering, ensuring
> right angles, sorting building according to processing results, etc.). I
> have not examined how to break up building blocks into single units yet but
> I am interested to include it in the pre-processing tool if it is possible.
>
>
>
> Daniel
>
>
>
> *From:* Tim Elrick [mailto:o...@elrick.de]
> *Sent:* Saturday, March 02, 2019 19:58
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Microsoft has released its building outlines for
> Canada
>
>
>
> Hi Steve,
>
>
>
> As for Montreal: We will create an import plan on the wiki as soon as we
> have expanded the discussion about the Montreal import from our local
> face-to-face group to the Montreal OSM list and agreed on importing. Before
> we do this, we wanted to test the feasibility of the pre-processing first,
> as it involves quite some postgis coding to break up the building blocks
> into single buildings. Only thereafter, we will suggest an import (or not),
> depending on the feasibility of extracting single buildings. Otherwise we
> will follow the hand-drawn approach as usual (and as it is done on a daily
> basis at the moment by a couple of OSMappers).
>
>
>
> The Microsoft data set might still be useful for remote areas. Let's
> explore this altogether.
>
>
>
> Cheers,
>
> Tim
>
>
>
>
> On 2019-03-02 19:17, OSM Volunteer stevea wrote:
>
> On Mar 2, 2019, at 3:47 PM, John Whelan  
>  wrote:
>
> 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.
>
> Historical info is appreciated for context, however, the LWG found 
> Canada-wide city-by-city submissions for ODbL-compliance burdensome, given 
> LWG's limited bandwidth.  Assuming about events in the past is unhelpful, 
> first because it is assuming (seldom helpful) and second, these events are in 
> the past.  How Toronto imported (building) data can't really help us first 
> understand and second improve from what we learn until we know what we 
> learned.  That isn't presented here, but it could be.
>
>
>
> 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.
>
> I agree with Nate.  Perhaps first in Toronto, perhaps wider in talk-ca.  
> "Once more" seems limiting, though it's possible it could suffice.
>
>
>
> Tim I think is organising Montreal open data import.
>
> Please consider adding this (and links to user: wiki or Talk pages) to the 
> active Import wiki.  Generate communication using our media!
>
>
>
> 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.
>
> More discussion often yields consensus, especially as it "goes wide" (or as 
> wide as is practical).
>
>
>
> We also have Pierre who is unhappy because the imported building outlines 
> available have too many corners that are not right angles.
>
> More discussion often yields consensus.
>
>
>
> 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.
>
> More discussion often yields consensus.  Wide area (large cities, 
> province-wide, nationwide) imports are not easy to achieve consensus but can 
> often reach something approaching one as data are entered, not liked, 
> improved, liked better, et cetera.  These are often an interactive, iterative 
> process.
>
>
>
> Someone in Manitoba? mentioned there were no building outlines released for 
> Manitoba?  I apologise if I have the province name wrong.
>
> It is spelled correctly.  I am not Canadian and I know that; it isn't hard to 
> spell-check Manitoba.
>
>
>
> So we have a mixture of expectations which is only to be expected in a large 
> group.
>
> More discussion often yields consensus.  It might be part "mixture of 
> expectations" but I'm sure that everyone will agree that "high quality data 
> entering OSM" is expected.  What can be difficult is "what do we mean by high 
> quality?" (in addition to establishing and communicating clear goals for the 
> importation of the data).
>
>
>
> Microsoft's Open Data provides another source of 

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

[James]

M$ released data as ODbL so pretty sure license is compatible

On Sat., Mar. 2, 2019, 5:27 p.m. 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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Bike infrastructure in OSM

[James]

I know the bike enthusiasts have been using this tagging guide:
https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide

On Fri., Feb. 8, 2019, 5:06 p.m. Harald Kliems,  wrote:

> I just learned that US-based bike advocacy organization People for Bikes
> is going to expand their "Bicycle Network Analysis" (BNA) to the following
> Canadian cities: Toronto, Calgary, Winnipeg, Vancouver, Ottawa, Halifax,
> Saskatoon, Edmonton, Montreal, Hamilton, Mississauga, Brampton.
>
> What is the BNA? It uses data about the a number of characteristics of
> roads and paths (e.g. number of lanes, speed limit, existence of bike
> lanes) to calculate a "traffic level of stress." For more detail, you can
> watch this presentation at SOTM-US:
> https://www.youtube.com/watch?v=YgyynQDPQnQ
>
> The first round of BNA analysis happened last year in a large number of US
> cities: https://bna.peopleforbikes.org/#/
>
> Of course, the analysis can only be as good as the underlying data, and so
> I'd encourage everyone to improve the tagging of bike-relevant
> infrastructure in those cities. There is a tagging guide available here:
> https://docs.google.com/document/d/1HuAXQUnCEcv9aLZyIDHkLTJ5ZSKfB-U4MlJSmN-1BLk/edit
>
> Apparently the data pull will be on February 16. So not a lot of time.
>
> I think it's a great project, and we have used it for our bike advocacy
> work in Madison (Wisconsin). And of course having great data about bike
> infrastructure in OSM is desirable outside of the project as well.
>
> Cheers,
>  Harald (hobbesvsboyle)
>
> --
> GPG Key-ID: 0x34cb93972f186565
> ___
> 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] Talk-ca Digest, Vol 131, Issue 48

[James]

There is also fours states to a task..clear..no action, yellow...completed
and green: validated! (there's also unvalidated to flag a tile as not being
done again/not being validated) You can leave comments as well!

On Sat., Jan. 26, 2019, 7:53 p.m. Nate Wessel  I'm all for this, so long as it really is just for validation. I believe
> we can leave notes on tasks via the tasking manager (?), which might be a
> good way to catalogue any localized issues we see.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/26/19 2:16 PM, john whelan wrote:
>
> Perhaps a way forward at the moment would be to open the task manager up
> so the tiles imported so far can be validated.
>
> Having lived with computers for many years I'm in total agreement, they
> work very quickly but have no common sense what so ever.
>
> Cheerio John
>
> On Sat, Jan 26, 2019, 1:56 PM Nate Wessel 
>> Getting a clear idea of what needs to be fixed is what validation is all
>> about. Having a second set of eyes look through everyone's imported data in
>> a systematic way will give us ideas for what we need to fix moving forward.
>> It can't be just a matter of looking at a bunch of automated validation
>> script outputs and issuing a checkmark. Machines can do that - us humans
>> can do better, and that's a big part of the beauty of OSM: the human
>> element.
>>
>> If I may be permitted a tangent, I was fairly troubled at the last State
>> of the Map US conference that the focus of attention seemed to have turned
>> to a surprising degree toward "what cool things can machines do with data"
>> from the focus I saw in earlier years, which was much more "how can we get
>> more people engaged?". Machines don't make quality data - only consistent
>> errors. I'm glad the big tech companies were buying us all beers (there was
>> s much free beer...) but we shouldn't adopt their narrow focus on labor
>> efficiency and automation. I don't think efficiency is why we are all here.
>>
>> ...
>>
>> I was going to address some of your other points, but I think my little
>> digression actually highlighted some of the differences in the way we seem
>> to be approaching all of these issues. I'm not a fan of automation and
>> efficiency at the cost of quality (in this context), while that is a
>> compromise you and others seem willing to make. We may not be able to talk
>> our way out of that difference of opinion; the root of the issue is likely
>> just a different vision of OSM and why we each care about it.
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/26/19 12:48 PM, Danny McDonald wrote:
>>
>> 1. In terms of validation, it would be helpful to have a clear idea of
>> what sorts of problems need to be fixed.  I have re-validated almost all of
>> the areas I imported (and all of them in Central Toronto), and fixed all of
>> the building related errors/warnings I found (with a few exceptions) there
>> weren't many errors, and many pre-dated the import.  The only JOSM warning
>> I didn't fix is "Crossing building/residential area".  Yaro's and John's
>> areas don't seem to have many errors either, although there a few isolated
>> "Crossing building/highway" warnings (and some "building duplicated nodes"
>> errors).  I have also split big retail buildings in dense areas.
>> 2. I'm fine with simplification, I think we should just do it.  In terms
>> of orthogonalization, I don't understand why non-orthogonal buildings are a
>> problem.  If they are, JOSM allows them to be auto-fixed.
>> 3. I agree that the task manager squares are too big in central Toronto.
>> A separate task can be created for central Toronto only, with smaller
>> squares.  I think the square size is fine outside of Toronto, as long as
>> the squares are split appropriately.
>> 4. In terms of conflation, I agree that deleting and re-adding buildings
>> is not desirable, but I don't agree that that means it should never be
>> done, no matter the time cost.  The ideal solution here is some sort of
>> script/plugin that auto-merges new and recently added buildings -
>> basically, an iterated "replace geometry".
>> DannyMcD
>>
>>>
>>>
>> ___
>> Talk-ca mailing 
>> 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] Building Import update

[James]

I'm not installing postgesql for you to accept simplification, that YOU
said was required because there were 2x as many points(which was proved
wrong via the simplification) If you want to have fun with the file, go a
head.

On Sat., Jan. 26, 2019, 2:00 p.m. Nate Wessel  Building count doesn't really have anything to do with preserving
> topology, and I'm not sure a visual inspection would cut it - Can you look
> at the documentation for this tool and verify that it preserves the
> topology of polygon layers?
>
> This is a good illustration of the (potential) problem:
> https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/26/19 12:31 PM, James wrote:
>
> it does if you saw my analysis of building(polygon count) remains the same
> also visually inspected a few and there was preservation of them
>
> On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel 
>> Does that preserve topology between buildings that share nodes?
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com <http://natewessel.com>
>>
>> On 1/26/19 11:31 AM, James wrote:
>>
>> no need for scripts, qgis does this fine via the  Vector menu -> Geometry
>> tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
>> but I think 40cm is too aggressive.
>>
>> I already have scripts to compile it into the dataformat needed to be
>> served.
>>
>> On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel >
>>> Hi all,
>>>
>>> The wiki page is indeed looking a whole lot better right now - my thanks
>>> and congrats to everyone who contributed! There is a still a ways to go,
>>> but we seem to be getting there quickly.
>>>
>>> I'll echo John in saying that I would appreciate hearing from some of
>>> the other people who chimed in to express their doubts about the import.
>>> For my part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm
>>> thrilled that we're talking and working together in the open, and that
>>> addresses the biggest concern I had with the import.
>>>
>>> These are the big issues I see remaining:
>>>
>>> 1. *Validation*: Ideally I'd like to see a good chunk (more than half)
>>> of the data that has been imported already validated by another user before
>>> we proceed with importing more data. Validation is part of the import plan,
>>> so the import isn't done until validation is done anyway. My hope is that
>>> this will flag any issues that we can fix before moving forward, and give
>>> people time to chime in on the import plan who maybe haven't already. I
>>> don't want to see everything imported and only then do we start
>>> systematically checking the quality of our work, if ever. If no one wants
>>> to do it now, no one is going to want to do it later either, and that
>>> doesn't bode well.
>>>
>>> 2. *Simplification*: James' analysis showed that simplification could
>>> save several hundred megabytes (and probably more) in Ontario alone. This
>>> is totally worth doing, but we have to document the process and be very
>>> careful not to lose valuable data. I believe there was also a concern
>>> raised about orthogonal buildings being not quite orthogonal - this is
>>> something that we should handle at the same time, again, very carefully. We
>>> certainly don't want to coerce every building into right angles. With
>>> respect to James, I'm not sure this is something that can be done with a
>>> few clicks in QGIS. I would be willing to develop a script to handle this,
>>> but it would take me about a week or two to find the time to do this
>>> properly. We would need to simultaneously A) simplify straight lines B)
>>> orthogonalize where possible and C) preserve topology between connected
>>> buildings. This is not impossible, it just takes time and care to do
>>> correctly.
>>>
>>> 3. *Speed and Size*: To John's point, it seems like people certainly
>>> are not sticking to the areas they know, unless they get around a whole
>>> hell of a lot more than I do, and yes this is a problem. The whole Toronto
>>> region was basically imported by two people: DannyMcD seems to have done
>>> the entire west side of the region (hundreds of square kilometers) while
>>> zzptichka imported the entire east side of the region (again a truly
>>> massive area), b

Re: [Talk-ca] Building Import update

[James]

it does if you saw my analysis of building(polygon count) remains the same
also visually inspected a few and there was preservation of them

On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel  Does that preserve topology between buildings that share nodes?
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/26/19 11:31 AM, James wrote:
>
> no need for scripts, qgis does this fine via the  Vector menu -> Geometry
> tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
> but I think 40cm is too aggressive.
>
> I already have scripts to compile it into the dataformat needed to be
> served.
>
> On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel 
>> Hi all,
>>
>> The wiki page is indeed looking a whole lot better right now - my thanks
>> and congrats to everyone who contributed! There is a still a ways to go,
>> but we seem to be getting there quickly.
>>
>> I'll echo John in saying that I would appreciate hearing from some of the
>> other people who chimed in to express their doubts about the import. For my
>> part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm thrilled that
>> we're talking and working together in the open, and that addresses the
>> biggest concern I had with the import.
>>
>> These are the big issues I see remaining:
>>
>> 1. *Validation*: Ideally I'd like to see a good chunk (more than half)
>> of the data that has been imported already validated by another user before
>> we proceed with importing more data. Validation is part of the import plan,
>> so the import isn't done until validation is done anyway. My hope is that
>> this will flag any issues that we can fix before moving forward, and give
>> people time to chime in on the import plan who maybe haven't already. I
>> don't want to see everything imported and only then do we start
>> systematically checking the quality of our work, if ever. If no one wants
>> to do it now, no one is going to want to do it later either, and that
>> doesn't bode well.
>>
>> 2. *Simplification*: James' analysis showed that simplification could
>> save several hundred megabytes (and probably more) in Ontario alone. This
>> is totally worth doing, but we have to document the process and be very
>> careful not to lose valuable data. I believe there was also a concern
>> raised about orthogonal buildings being not quite orthogonal - this is
>> something that we should handle at the same time, again, very carefully. We
>> certainly don't want to coerce every building into right angles. With
>> respect to James, I'm not sure this is something that can be done with a
>> few clicks in QGIS. I would be willing to develop a script to handle this,
>> but it would take me about a week or two to find the time to do this
>> properly. We would need to simultaneously A) simplify straight lines B)
>> orthogonalize where possible and C) preserve topology between connected
>> buildings. This is not impossible, it just takes time and care to do
>> correctly.
>>
>> 3. *Speed and Size*: To John's point, it seems like people certainly are
>> not sticking to the areas they know, unless they get around a whole hell of
>> a lot more than I do, and yes this is a problem. The whole Toronto region
>> was basically imported by two people: DannyMcD seems to have done the
>> entire west side of the region (hundreds of square kilometers) while
>> zzptichka imported the entire east side of the region (again a truly
>> massive area), both in the matter of a week or two. They only stopped in
>> the middle where there were more buildings already and things got a bit
>> more difficult. The middle is where I live, and when I saw that wave of
>> buildings coming, I sounded the alarms.
>> This is way too fast - no one person should be able to import the GTA in
>> a couple weeks. A big part of the problem, IMO is that the task squares are
>> much too large, and allow/require a user to import huge areas at once. At
>> the least, some of the task squares in central Toronto are impossibly
>> large, including hundreds or thousands of buildings already mapped in OSM.
>> Conflation on these, if done properly would take the better part of a day,
>> and people are likely to get sloppy.
>> I would like to see the task squares dramatically reduced in size as a
>> way of slowing people down, helping them stick to areas they know well, and
>> keeping them focused on data quality over quantity. This would also make
>> the process much more accessible to local mappers who don't already

Re: [Talk-ca] Building Import update

[James]

no need for scripts, qgis does this fine via the  Vector menu -> Geometry
tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
but I think 40cm is too aggressive.

I already have scripts to compile it into the dataformat needed to be
served.

On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel  Hi all,
>
> The wiki page is indeed looking a whole lot better right now - my thanks
> and congrats to everyone who contributed! There is a still a ways to go,
> but we seem to be getting there quickly.
>
> I'll echo John in saying that I would appreciate hearing from some of the
> other people who chimed in to express their doubts about the import. For my
> part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm thrilled that
> we're talking and working together in the open, and that addresses the
> biggest concern I had with the import.
>
> These are the big issues I see remaining:
>
> 1. *Validation*: Ideally I'd like to see a good chunk (more than half) of
> the data that has been imported already validated by another user before we
> proceed with importing more data. Validation is part of the import plan, so
> the import isn't done until validation is done anyway. My hope is that this
> will flag any issues that we can fix before moving forward, and give people
> time to chime in on the import plan who maybe haven't already. I don't want
> to see everything imported and only then do we start systematically
> checking the quality of our work, if ever. If no one wants to do it now, no
> one is going to want to do it later either, and that doesn't bode well.
>
> 2. *Simplification*: James' analysis showed that simplification could
> save several hundred megabytes (and probably more) in Ontario alone. This
> is totally worth doing, but we have to document the process and be very
> careful not to lose valuable data. I believe there was also a concern
> raised about orthogonal buildings being not quite orthogonal - this is
> something that we should handle at the same time, again, very carefully. We
> certainly don't want to coerce every building into right angles. With
> respect to James, I'm not sure this is something that can be done with a
> few clicks in QGIS. I would be willing to develop a script to handle this,
> but it would take me about a week or two to find the time to do this
> properly. We would need to simultaneously A) simplify straight lines B)
> orthogonalize where possible and C) preserve topology between connected
> buildings. This is not impossible, it just takes time and care to do
> correctly.
>
> 3. *Speed and Size*: To John's point, it seems like people certainly are
> not sticking to the areas they know, unless they get around a whole hell of
> a lot more than I do, and yes this is a problem. The whole Toronto region
> was basically imported by two people: DannyMcD seems to have done the
> entire west side of the region (hundreds of square kilometers) while
> zzptichka imported the entire east side of the region (again a truly
> massive area), both in the matter of a week or two. They only stopped in
> the middle where there were more buildings already and things got a bit
> more difficult. The middle is where I live, and when I saw that wave of
> buildings coming, I sounded the alarms.
> This is way too fast - no one person should be able to import the GTA in a
> couple weeks. A big part of the problem, IMO is that the task squares are
> much too large, and allow/require a user to import huge areas at once. At
> the least, some of the task squares in central Toronto are impossibly
> large, including hundreds or thousands of buildings already mapped in OSM.
> Conflation on these, if done properly would take the better part of a day,
> and people are likely to get sloppy.
> I would like to see the task squares dramatically reduced in size as a way
> of slowing people down, helping them stick to areas they know well, and
> keeping them focused on data quality over quantity. This would also make
> the process much more accessible to local mappers who don't already have
> tons of experience importing.
>
> 4. *Conflation*: I don't think the current conflation plan is adequate(ly
> documented). In practice, what people are actually doing may be fine, but I
> really want to see some better thought on how to handle existing buildings.
> Right now the wiki says for example "*Before merging buildings data
> switch to OSM layer and see if there are any clusters of buildings without
> any meaningful tags you can delete to save time when merging*."
> With respect to whoever wrote this, this approach seems to value time over
> data integrity and I just don't think that's how OSM should operate. We
> need to be more careful with the existing data, and we nee

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

[James]

i haven't simplified because, no one gave me feedback on the data...Not
going to process a bunch of datafiles for someone to turn around and say
the simplification broke something.

On Sat., Jan. 26, 2019, 9:57 a.m. Danny McDonald  Personally, I'm eager to re-start importing, but I'd like to hear what
> Nate has to offer.  Nate, are you OK with the wiki import process as
> written?  If not, are there specific things you want changed?  The current
> process is the one Yaro followed, although John and I basically did the
> same thing (I didn't always replace existing building footprints unless the
> geometry was really bad).  It doesn't seem that the building data has been
> simplified, although this should be an easy fix.
>
> DannyMcD
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

 blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper offset can be difficult to establish in big
>>> cities where GPS signal is erratic. Pragmatically, I can tell you from
>>> personal experience that building data in lovingly-mapped Berlin is
>>> also worse than 1 meter accuracy. So again: best effort.
>>>
>>> What do we get from having buildings? A sense of land use (arguably
>>> replaceable with larger landuse areas). A way to roughly estimate
>>> population density. A way to gauge built-up density. A data source for
>>> locating buildings in possible flood zones, or fire risk. Statistics:
>>> as open data, queryable by APIs that are already used, in format
>>> more-or-less common worldwide.
>>>
>>> Examples were given of rowhouse- or de-facto rowhouse-buildings where
>>> a part is attached to the wrong building. This does not alter any of
>>> the above examples. It's wrong, but is it substantially more wrong
>>> than a blank subdivision, or one with only a few buildings mapped? Is
>>> it better to have a null, or be off by 5%? The legal truth is in
>>> property records, and we can't measure houses with a ruler, so OSM can
>>> only be a statistical source. And then there's the question of
>>> verifiability - some of these buildings are connected to their
>>> neighbour building inside. I've really struggled at distinguishing
>>> what exactly is a "building" on Old Toronto avenues even with
>>> street-side survey.
>>>
>>> Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
>>> and I'm sure many of you do as well. If we import, the question is:
>>> are we making it better?
>>>
>>> 1. Do we want this data?
>>> 2. Is it generally of acceptable quality?
>>> 3. Is there a mechanism to spot and reject where data is particularly
>>> bad?
>>>
>>> Cheers,
>>> Jarek, who should really get back to updating built-last-year stuff at
>>> Fort York
>>>
>>> On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall 
>>> wrote:
>>> >
>>> > The pilot project that took place in Ottawa for all these building
>>> imports is what got me hooked into OSM in the first place. I would make
>>> only very minor changes here and there. I even attempted to draw building
>>> footprints but got burnt out after only doing a single street, which was
>>> very discouraging for me to continue.
>>> >
>>> > When I saw the entire neighbourhood get flooded with new buildings
>>> that weren't there before, I was entirely intrigued and actually got on
>>> board with the locals to help with the process. I've been hooked since and
>>> have been to many meetups afterwards. Helping out with projects completely
>>> unrelated to the initial building import.
>>> >
>>> > I'm entirely of the belief that it is much more encouraging for a new
>>> user to make a minor change (eg. changing `building=yes` to
>>> `building=detached`) than it is to add every single minor detail to each
>>> object from scratch (visiting the location, drawing the building footprints
>>> manually, adding address data, etc.). It's just overwhelming for a new user.
>>> >
>>> > It is very much a cat-and-mouse type scenario with community driven
>>> projects like OSM. Apparently the issue with this import is the lack of
>>> community involvement but I can for sure tell you that this import will
>>> help flourish the community in the local areas. Especially if they only
>>> need to add or change minor tags than if they would have had to create all
>>> of this data by hand. With an import this size there is bound to be some
>>> errors that slip through. That's where the community comes through to
>>> correct these minor things.
>>> >
>>> > This is the whole point of OSM. A user creates an object with as much
>>> information as they know and the next user comes and adds onto that, and
>>> the next user adds and/or updates even more. Neither of those users on
>>> their o

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

Salut Pierre, peut-être c'est le lien de téléchargement qui fonctionne pas
bien, voici une alternative:
https://www.dropbox.com/s/5ciiex5w67ohwzy/ontario-simplified.tar.xz?dl=0

On Sun, Jan 20, 2019 at 4:19 AM Pierre Béland  wrote:

> Mon problème est dés le téléchargement. Cela m'indique que google ne peut
> effectuer l'analyse d'antivirus et m'offre de télécharger quand même. De
> là, message d'erreur.
> Voici le message avec Chrome
> Ce site ne peut pas fournir de connexion sécurisée
>
> *doc-08-3g-docs.googleusercontent.com
> <http://doc-08-3g-docs.googleusercontent.com>* a envoyé une réponse
> incorrecte.
>
>- Essayez d'exécuter les diagnostics réseau de Windows.
>
> ERR_SSL_PROTOCOL_ERROR
>
>
> Pierre
>
>
> Le samedi 19 janvier 2019 23 h 10 min 04 s HNE, James 
> a écrit :
>
>
> tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre
> bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou
> Linux), qui est servie via la Task Manager. Ce n'est pas la version
> originale de Stats Can, tu as raison, c'sst la version minifié sans les
> extras tag de merde qui sont aucunement utile à OSM.
>
> Je travaille sur les fichiers, car quelqu'un a dit les données était de la
> bouse de vache.
>
> On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland 
> James,
>
> Je pense que nous travaillons sur deux aspects différents. Tu te concentre
> sur la production / correction des fichiers d'import.
>
> A ma connaissance, tu n'a pas décrit le contenu du fichier
> ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import
> originales où tu apportes divers correctifs.
>
> De mon côté, je propose d'analyser le produit final dans la base OSM et
> mesurer pour les données déja téléchargées quelle proportion des bâtiments
> est avec angles droits (orthogonal), et les superspositions.  Cela
> permettrait simplement de comparer ces données avec ce que l'on retrouve
> ailleurs et rassurer sur la qualité globale de l'import par les différents
> contributeurs.
>
> Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec
> formes irrégulières,  sinon il faut regarder de plus près et expliquer
> pourquoi.  Mes analyses au cours des derniers 6 mois, incluant révision de
> Butembo en RDC montrent qu'avec une bonne révision on repère beaucoup de
> bâtiments qui ne correspondent pas à ce que l'on observe sur l'imagerie.
>
>
> Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à
> partir de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un
> script wget. Je ne sais si windows 10 peut ajouter des restrictions que
> d'autres OS n'ont pas.
>
> Pierre
>
>
> Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James 
> a écrit :
>
> Is there no one that will analyse the data I've posted here? 
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> or are we just email thread warriors?
>
>

-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre
bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou
Linux), qui est servie via la Task Manager. Ce n'est pas la version
originale de Stats Can, tu as raison, c'sst la version minifié sans les
extras tag de merde qui sont aucunement utile à OSM.

Je travaille sur les fichiers, car quelqu'un a dit les données était de la
bouse de vache.

On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland  James,
>
> Je pense que nous travaillons sur deux aspects différents. Tu te concentre
> sur la production / correction des fichiers d'import.
>
> A ma connaissance, tu n'a pas décrit le contenu du fichier
> ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import
> originales où tu apportes divers correctifs.
>
> De mon côté, je propose d'analyser le produit final dans la base OSM et
> mesurer pour les données déja téléchargées quelle proportion des bâtiments
> est avec angles droits (orthogonal), et les superspositions.  Cela
> permettrait simplement de comparer ces données avec ce que l'on retrouve
> ailleurs et rassurer sur la qualité globale de l'import par les différents
> contributeurs.
>
> Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec
> formes irrégulières,  sinon il faut regarder de plus près et expliquer
> pourquoi.  Mes analyses au cours des derniers 6 mois, incluant révision de
> Butembo en RDC montrent qu'avec une bonne révision on repère beaucoup de
> bâtiments qui ne correspondent pas à ce que l'on observe sur l'imagerie.
>
>
> Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à
> partir de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un
> script wget. Je ne sais si windows 10 peut ajouter des restrictions que
> d'autres OS n'ont pas.
>
> Pierre
>
>
> Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James 
> a écrit :
>
> Is there no one that will analyse the data I've posted here? 
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> or are we just email thread warriors?
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] OpenStreetMap, education and the buildings

[James]

That's french: France. Not french: Québec

On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan  From weeklyosm:
> Education
>
>- The new curriculum
>
> 
>(pdf) for French high schools states that all students should be introduced
>to geospatial data usage. One of the expected abilities in that domain is
>the ability to “contribute to OpenStreetMap in a collaborative way”.
>
> --
>
> What it means is we can expect to see more interest from schools in
> Canada.  Adding tags to buildings is fairly simple and less error prone
> than some activities.
>
> Using streetcomplete I think would work even without buildings.
>
> Thoughts please.
>
> Thanks John
>
>
>
>
>
> Sent from Postbox
> 
> ___
> 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] Canada building import - Simplification discussion

[James]

Original(1.4GB file size):
9.263 Average points per feature
Points:20346517
Features:2196329

Simplified (20cm) (1.2GB file size):
8.425 Average points per feature
Points:18504036
Features:2196329

Simplified (40cm) (1.1GB file size):
8.07
Points:17741477
Features:2196329

For better statistics on how it affects file size for ontario (which is the
biggest dataset by the way)
The previous link I provided was for the 20cm simplification, I can provide
a link to the 40cm simplification file if needed.
I don't think simplifying about 50cm would be safe/smart as that would be
getting into satellite imagery quality vs what the cities use (plane
overhead gathering high-res imagery)

On Sun, Jan 20, 2019 at 12:44 AM Nate Wessel  wrote:

> I'm changing the subject line to try and retain some clarity for the
> mailing list.
>
> James, thanks for the stats! I'm surprised this didn't remove more points.
>
> Steve, I mentioned earlier that 20cm is where I happened to draw the line
> for the data we imported in Hamilton County, Ohio and I'm not totally sure
> even that was ideal. A bit more than half of the buildings we've been
> importing there have one (damned) extra node which I've been trying to
> remove manually. I may have been a bit too conservative there, as I didn't
> want to lose any part of the geometry. Sometimes there are tiny bay windows
> and the like.
>
> I'm wondering if the scope of this data warrants some analysis of how
> simplification (and perhaps data quality generally) varies geographically.
> It seems quite likely that every municipality would have it's own quirks,
> and we might want to treat some places differently.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/19/19 7:24 PM, OSM Volunteer stevea wrote:
>
> On Jan 19, 2019, at 3:47 PM, James  
>  wrote:
> Resending because these emails are getting over 40KB in size and talk list is 
> spazzing out:
> Original:
> 9.263 Average points per feature
> Points:20346517
> Features:2196329
>
> Simplified (20cm): 8.425 Average points per feature
> Points:18504036
> Features:2196329
>
> Choosing 20cm or higher or lower is where the "improvement?" line gets drawn.
>
> In round numbers of nodes, call this a "10% reduction."  The question is, are 
> the results "improvement?"  If so, it seems worth doing.  (Only one person's 
> opinion, of course).
>
> Steve
>
> ___
> 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] 2020 building import wiki comment by Nate Wessel

[James]

Resending because these emails are getting over 40KB in size and talk list
is spazzing out:
Original:
9.263 Average points per feature
Points:20346517
Features:2196329

Simplified (20cm): 8.425 Average points per feature
Points:18504036
Features:2196329
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

use qgis or launch josm with java in 64bit mode(d64) with memory options
(Xms, Xmx), or it will crap out at 3.5GB

On Sat., Jan. 19, 2019, 5:13 p.m. OSM Volunteer stevea <
stevea...@softworkers.com wrote:

> On Jan 19, 2019, at 2:01 PM, James  wrote:
> > Is there no one that will analyse the data I've posted here?
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> or are we just email thread warriors?
>
> Well, slow down there, cowboy, it is gigabytes of data and I've been busy
> replying to talk-ca, though my CPU is hot decompressing and opening your
> file right now.  Though even with JOSM getting assigned multiple gigabytes
> of heap space (and I've got plenty dozens of GB of RAM), I'm still getting
> out-of-memory errors on trying to bite-and-chew this monster.
>
> Maybe some of ARE email thread warriors, but I am not "just" an email
> thread warrior.
>
> SteveA
> California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

Is there no one that will analyse the data I've posted here?
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
or are we just email thread warriors?

On Sat., Jan. 19, 2019, 4:29 p.m. Pierre Béland via Talk-ca <
talk-ca@openstreetmap.org wrote:

> Voici une compilation statistique à partir des changesets de OSM pour la
> grande région de Toronto (bbox=-80.8951,42.9142,-78.1046,44.3297).
> Depuis
>
> Pour respecter la politique de confidentialité de OSM, les contributeurs
> ne sont identifiés que selon leur uid.
>
> Depuis décembre, on compte 6 contributeurs, 889 changesets et 6,621,124
> objets édités (noeuds, chemins ou relations)
>
> 1 immeuble = 5 objets minimum
> Le fichier de changeset ne fournit que le nombre d'objets édités (var
> num_changes). On ne peut donc à cette étape-ci que grossièrement estimer le
> nombre d'immeubles, sans doute plus de 1 million déjà. A partir de
> Overpass, on ne peut facilement extraire les données. Je vais télécharger
> dans PostGIS un fichier récent de l'Ontario et sélectionner les données
> éditées depuis le 24 décembre (premier jour avec édition )  de ces 6
> contributeurs.  Mon script Qualité permettra également d'analyser la
> géométrie des bâtiments.
>
> lexique
> changeset nombre de changesets (sessions d'édition)
> num_changesnombre d'objets édités dans la session
> avg_changes moyenne, objets édités par changeset
>
> Tableau 1 - Objets édités par contributeur avec moyenne par changeset
>
> uid changesets num_changes avg_changes % cum
> 9266764 457 3,439,242 7,526 52.7%
> 215433 197 1,619,540 8,221 77.6%
> 5214232 151 815,541 5,401 90.1%
> 9343732 78 628,032 8,052 99.7%
> 3016192 3 17,710 5,903 100.0%
> 1919010 3 1,059 353 100.0%
>
> 889 6,521,124 7,335
>
>
> Tableau 2 - Objets édités par contributeur - jour avec moyenne par
> changeset
> uid jour changesets num_changes avg_changes
> 5214232 2018-12-28 3 10,324 3,441
> 5214232 2019-01-14 11 58,402 5,309
> 5214232 2019-01-17 9 57,738 6,415
> 9343732 2019-01-16 7 63,490 9,070
> 215433 2018-12-29 8 70,562 8,820
> 5214232 2019-01-16 25 176,942 7,078
> 5214232 2018-12-23 5 29,279 5,856
> 9343732 2019-01-14 5 39,000 7,800
> 5214232 2019-01-12 10 48,329 4,833
> 5214232 2018-12-24 9 54,888 6,099
> 215433 2019-01-08 13 77,332 5,949
> 9266764 2019-01-08 20 156,232 7,812
> 9266764 2019-01-01 9 67,167 7,463
> 9266764 2019-01-07 19 154,837 8,149
> 215433 2019-01-02 30 280,756 9,359
> 9266764 2018-12-24 11 66,162 6,015
> 5214232 2019-01-11 2 6,219 3,110
> 9343732 2019-01-15 10 75,020 7,502
> 9343732 2019-01-11 11 82,844 7,531
> 215433 2018-12-30 20 177,602 8,880
> 9266764 2018-12-31 30 195,300 6,510
> 9343732 2019-01-12 14 111,821 7,987
> 215433 2019-01-03 25 200,002 8,000
> 9266764 2019-01-10 33 260,886 7,906
> 215433 2019-01-09 17 138,489 8,146
> 215433 2018-12-31 21 169,903 8,091
> 5214232 2019-01-09 9 41,664 4,629
> 9266764 2019-01-13 32 266,247 8,320
> 9266764 2018-12-29 36 274,357 7,621
> 9343732 2019-01-10 14 112,606 8,043
> 1919010 2019-01-17 2 973 487
> 9266764 2018-12-26 29 216,701 7,472
> 215433 2019-01-07 12 93,825 7,819
> 5214232 2019-01-10 2 718 359
> 9266764 2019-01-09 25 216,885 8,675
> 5214232 2019-01-08 27 119,761 4,436
> 5214232 2018-12-25 2 10,528 5,264
> 9266764 2019-01-06 18 142,007 7,889
> 215433 2019-01-01 6 58,083 9,681
> 9266764 2019-01-04 7 39,155 5,594
> 1919010 2019-01-16 1 86 86
> 9266764 2019-01-11 22 174,419 7,928
> 9266764 2018-12-25 29 188,931 6,515
> 9266764 2018-12-27 10 67,593 6,759
> 3016192 2018-12-20 3 17,710 5,903
> 215433 2019-01-04 15 128,047 8,536
> 9266764 2018-12-30 14 108,068 7,719
> 9266764 2019-01-15 21 150,419 7,163
> 5214232 2019-01-15 19 116,812 6,148
> 9266764 2019-01-14 17 135,021 7,942
> 9343732 2019-01-13 17 143,251 8,427
> 9266764 2019-01-12 16 120,488 7,531
> 215433 2019-01-06 13 103,233 7,941
> 5214232 2019-01-13 11 57,670 5,243
> 5214232 2019-01-07 4 7,256 1,814
> 215433 2019-01-05 13 99,108 7,624
> 9266764 2019-01-05 4 25,286 6,322
> 9266764 2019-01-16 24 204,397 8,517
> 215433 2019-01-17 2 18,589 9,295
> 215433 2018-12-27 2 4,009 2,005
> 9266764 2019-01-02 13 71,064 5,466
> 9266764 2019-01-03 18 137,620 7,646
> 5214232 2018-12-27 3 19,011 6,337
>
>
> 889 6,521,124 7,335
>
>
> Pierre
>
> ___
> 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] 2020 building import wiki comment by Nate Wessel

[James]

You guys can analyze the simplified version of ontario:
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
If you think it's good, I can simplify the other files and process them
into mbtiles.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

I can run all the shapefiles through qgis simplify tool if this resolves
the issue...

On Fri., Jan. 18, 2019, 4:08 p.m. Nate Wessel  With default settings in JOSM, sure. In the import I was working on, we
> used a Douglas-Peucker algorithm with a 20cm threshold (before the import
> started) and it worked beautifully. We had many points that seemed to have
> been introduced in the shapefiles as some kind of data artifact - they
> didn't add any detail to the shape at all. This procedure removed almost
> all of them with no discernible reduction in quality.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 1/18/19 4:03 PM, James wrote:
>
> dare you to run simplify tool on anything remotely round, it will make it
> look like garbage
>
> On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  wrote:
>
>> The import mailing list was pointed to the correct page of the wiki.  The
>> initial post was to say this is what we were thinking of and there was a
>> comment saying we needed to change the comment line.
>>
>> >There is no mention of this proposed import on the import catalogue
>>
>>
>> The import process was reviewed by the person who set up the Ottawa
>> import did we miss that step on the Ottawa import as well?  Neither was it
>> raised as a concern on the import mailing list. I think this is very minor
>> and can be corrected.
>>
>> We learnt a fair bit on the Ottawa import and my expectation is since we
>> are using experienced mappers to do the import conflation would be either
>> handled by them or the building not imported. We aren't using new mappers
>> in a mapathon here and with experienced mappers then I think you have to
>> trust them.  The world isn't perfect. Think in terms of service level.
>>
>> >There are 2X more nodes than needed to represent the building accurately.
>>
>> The problem with correcting this is you are introducing approximations.
>> This will vary according to the source and this can be simplified or
>> corrected once its in OSM. I think this is a different issue of a
>> mechanical edit that needs to be considered separately.
>>
>> If we are concerned with database size then I suggest we change the
>> instructions to say put the source comment on the change set rather than on
>> the building outline.
>>
>> Cheerio John
>>
>>
>> Nate Wessel wrote on 2019-01-18 3:06 PM:
>>
>> John,
>>
>> You seem to be playing the long game with this data - it sounds like
>> you've been working with this a lot longer than I have, and you've put in
>> the time and effort to help make this actually-quite-incredible dataset
>> available to us. I don't want to stop the import from happening - quite the
>> opposite. I just want to make sure that the time is taken to do this right.
>> OSM deserves that. Your (our) long awaited victory will be the sweeter for
>> our patience now.
>>
>> There are several specific issues I see where the I's are not crossed,
>> nor the t's dotted. I've mentioned several already, so I'll try to be brief
>> (I really need to get back to working on my dissertation).
>>
>> 1) There was extremely limited discussion on the imports mailing list.
>> The initial email did not make clear the scope of the project. I read the
>> email and did not think twice at it, thinking it was entirely about Ottawa.
>> The link in that email was actually to the Ottawa import, and not this one,
>> which seems to have been only in draft at the time.
>> https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
>> As such, this project has NOT been reviewed by the imports list, which is
>> a requirement for proceeding with the import.
>>
>> 2) There is no mention of this proposed import on the import catalogue (
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue)
>> which is required in the imports guidelines. I suspect many other
>> guidelines have not been followed.
>>
>> 3) The wiki page describing the import is not adequate to assess the
>> quality of the data or of the proposed import. See for example:
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
>> The import guidelines call for a description of how conflation will be
>> handled. The fact that two of the major importers seem to have a
>> substantial disagreement about how to handle existing data indicates this
>> was not well discussed and I can see that it isn't well documented.
>>
>> 4) The

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[James]

dare you to run simplify tool on anything remotely round, it will make it
look like garbage

On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  The import mailing list was pointed to the correct page of the wiki.  The
> initial post was to say this is what we were thinking of and there was a
> comment saying we needed to change the comment line.
>
> >There is no mention of this proposed import on the import catalogue
>
>
> The import process was reviewed by the person who set up the Ottawa import
> did we miss that step on the Ottawa import as well?  Neither was it raised
> as a concern on the import mailing list. I think this is very minor and can
> be corrected.
>
> We learnt a fair bit on the Ottawa import and my expectation is since we
> are using experienced mappers to do the import conflation would be either
> handled by them or the building not imported. We aren't using new mappers
> in a mapathon here and with experienced mappers then I think you have to
> trust them.  The world isn't perfect. Think in terms of service level.
>
> >There are 2X more nodes than needed to represent the building accurately.
>
> The problem with correcting this is you are introducing approximations.
> This will vary according to the source and this can be simplified or
> corrected once its in OSM. I think this is a different issue of a
> mechanical edit that needs to be considered separately.
>
> If we are concerned with database size then I suggest we change the
> instructions to say put the source comment on the change set rather than on
> the building outline.
>
> Cheerio John
>
>
> Nate Wessel wrote on 2019-01-18 3:06 PM:
>
> John,
>
> You seem to be playing the long game with this data - it sounds like
> you've been working with this a lot longer than I have, and you've put in
> the time and effort to help make this actually-quite-incredible dataset
> available to us. I don't want to stop the import from happening - quite the
> opposite. I just want to make sure that the time is taken to do this right.
> OSM deserves that. Your (our) long awaited victory will be the sweeter for
> our patience now.
>
> There are several specific issues I see where the I's are not crossed, nor
> the t's dotted. I've mentioned several already, so I'll try to be brief (I
> really need to get back to working on my dissertation).
>
> 1) There was extremely limited discussion on the imports mailing list. The
> initial email did not make clear the scope of the project. I read the email
> and did not think twice at it, thinking it was entirely about Ottawa. The
> link in that email was actually to the Ottawa import, and not this one,
> which seems to have been only in draft at the time.
> https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
> As such, this project has NOT been reviewed by the imports list, which is
> a requirement for proceeding with the import.
>
> 2) There is no mention of this proposed import on the import catalogue (
> https://wiki.openstreetmap.org/wiki/Import/Catalogue)
> which is required in the imports guidelines. I suspect many other
> guidelines have not been followed.
>
> 3) The wiki page describing the import is not adequate to assess the
> quality of the data or of the proposed import. See for example:
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
> The import guidelines call for a description of how conflation will be
> handled. The fact that two of the major importers seem to have a
> substantial disagreement about how to handle existing data indicates this
> was not well discussed and I can see that it isn't well documented.
>
> 4) The buildings need to be simplified, quite a bit actually. Most
> buildings have multiple nodes representing straight lines. This bloats the
> database and makes things harder to edit by hand later. There are probably
> 2x more nodes than are needed to represent the data accurately, making it
> harder for editors and data consumers to work with down the road.This is a
> simple fix that will save countless hours later.
>
> ... I could go on, but I think this is plenty sufficient to justify
> pressing pause on all this.
>
> Again, I don't in any way want to disrespect the work that has gone into
> this effort already. We're all volunteers here and I know how much time
> this all takes. However. importing all/most of the buildings in Canada is a
> monstrously large task, which will have to dance around a lot of people's
> toes. We should expect this to take a really damn long time if we're going
> to do it right. We need to have the patience to learn from experience, from
> critique, and from the wisdom of the people who've learned from flawed
> imports in the past and have devised guidelines and processes so that we
> can have better experiences with this in the future.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 

Re: [Talk-ca] [Imports] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2

On Fri., Jan. 18, 2019, 3:02 p.m. Kevin Kenny  On Fri, Jan 18, 2019 at 2:54 PM Yaro Shkvorets 
> wrote:
> > JOSM offers very convenient way to do it called "Replace geometry".
> Select both ways, old and new, press Ctrl-Shift-G, merge any conflicting
> tags and you preserve the history, tags and have new improved outline in a
> couple of clicks.
>
> Good point. I use that a *lot* when updating the New York public land
> boundaries. Is it in a stock JOSM now? You used to have to install a
> plugin (with some uninformative name like 'Utilities') to get it. It's
> an absolute necessity for importers.
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't
shoot me) There has never been a GO-Nogo for imports, you bring it up on
the mailing lists with reasonable delay, is there no objections(in this
case no one was saying anything about it for 2-3 weeks) then email the list
that the import would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards  Along the lines of what Jarek said, sometimes silence just means tacit
> acceptance, or that it's not that controversial. There's quite a bit of
> government data here that is supposedly "open" but unavailable for OSM, so
> I'm very glad Stats Can was able to find a way to collect municipal data
> and publish it under one national license. I was surprised myself it hadn't
> got more attention, but I'm firmly onboard with more imports if done with
> care.
> Manually adding buildings - especially residential neighborhoods, is about
> the most boring task I can think of, yet it does add a lot to the map.
>
> I'll admit I hadn't looked at the data quality myself, but I just did
> review several task squares around BC and they look pretty good. Houses
> were all in the right place, accurate, and generally as much or even more
> detailed than I typically see. Issues seemed to be mostly the larger
> commercial buildings being overly large or missing detail, but in general
> these are the buildings most likely to be already mapped. To a large
> degree, it's up the individual importer to do some quality control, review
> against existing object, satellite, etc. If we have specific issues we can
> and should address them, but if the data is largely good then I see no need
> to abort or revert.
>
> alarobric
>
> On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
> wrote:
>
>> On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
>>  wrote:
>> > Thanks, Jarek.  Considering I am a proponent of "perfection must not be
>> the enemy of good" (regarding OSM data entry), I think data which are "darn
>> good, though not perfect" DO deserve to enter into OSM.  Sometimes "darn
>> good" might be 85%, 95% "good," as then we'll get it to 99% and then 100%
>> over time.  But if the focus on "how" isn't sharp enough to get it to 85%
>> (or so) during initial entry, go back and start over to get that number
>> up.  85% sounds arbitrary, I know, but think of it as "a solid B" which
>> might be "passes the class for now" without failing.  And it's good we
>> develop a "meanwhile strategy" to take it to 99% and then 100% in the
>> (near- or at most mid-term) future.  This isn't outrageously difficult,
>> though it does take patience and coordination.  Open communication is a
>> prerequisite.
>>
>> Thank you for this commitment. I wish others shared it. Unfortunately
>> the reality I've been seeing in OSM is that edits which are 90+% good
>> (like this import) are challenged, while edits which are 50+% bad
>> (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
>> wrong locations for _years_) go unchallenged or are laboriously
>> manually fixed afterward.
>>
>> --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

Re: [Talk-ca] Multiple university departments in one building

[James]

tim if you need an example of how to tag multiple levels via the indoor
tagging:

I did it at St-Laurent shopping mall:

https://openlevelup.net/?l=0#18/45.42184/-75.63833

everything is tagged using the simple indoor tagging schema. I highly
suggest using JOSM filter on level=

but then again josm now has a built in filter for levels

On Wed., Nov. 28, 2018, 12:41 p.m. Tim Elrick  Thank you, John and James.
>
> Place d'Orleans looks nice. And, of course, we do not map for the
> renderer. However, as the departments that I want to map are on
> different floor levels and not specifically in this or that corner of
> the building, the approach I have taken is still not pleasing.
>
> I guess, I will read into the Simple Indoor Tagging schema then and see
> how it works out.
>
> Cheers,
> Tim
>
> On 2018-11-28 07:37, john whelan wrote:
> Have a look at OSMand and see what it looks like.
>
> Generally it is considered bad practise to map for the renderer.
>
> As an alternative take a look at Place d'Orleans shopping center in
> Orleans Ontario each unit is mapped in outline with the appropriate tags
> added.
>
> If you look at mapping a building with floors I've seen office outlines
> before now.
>
> Cheerio John
>
> On Tue, 27 Nov 2018, 8:00 pm Tim Elrick  <mailto:o...@elrick.de> wrote:
>
>  Hello,
>
>  I am trying to contribute to filling the gaps on McGill campus on
>  OSM at
>  the moment and I ran into a problem which I haven't fund a
> satisfactory
>  answer for yet.
>
>  We have several buildings on campus which are home to multiple
>  departments, all buildings have a building name.
>
>  I looked the OSM wiki feature pages and in the OSM forum and found the
>  following approach as apparently standard procedure:
>  1) Map building outline with building = university , name= XYZ
>  building,
>  operator=McGill University
>  2) Add a node inside the building for each department with
>  office=university, description=department name
>  This produces irritating blue dots in the outline of the building, see
>  https://osm.org/go/cIrNt~j2u <https://osm.org/go/cIrNt%7Ej2u>
>
>  When I looked at other universities, I found e.g. a node with
>  amenity=university, name=department name. But when looking at the OSM
>  wiki feature page for universities[1] it says you only should use
>  amenity=university for the whole campus.
>
>  The office tag I found when looking for multiple businesses in one
>  building, but the blue dot aren't nice.
>
>  Any suggestions on how to map this elegantly?
>
>  Thank you,
>  Tim (aka AGeographer)
>
>  [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university
>
>  ___
>  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
> 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] Multiple university departments in one building

[James]

Yeah I did that with the indoor tagging schema

On Wed., Nov. 28, 2018, 7:40 a.m. john whelan  Have a look at OSMand and see what it looks like.
>
> Generally it is considered bad practise to map for the renderer.
>
> As an alternative take a look at Place d'Orleans shopping center in
> Orleans Ontario each unit is mapped in outline with the appropriate tags
> added.
>
> If you look at mapping a building with floors I've seen office outlines
> before now.
>
> Cheerio John
>
> On Tue, 27 Nov 2018, 8:00 pm Tim Elrick 
>> Hello,
>>
>> I am trying to contribute to filling the gaps on McGill campus on OSM at
>> the moment and I ran into a problem which I haven't fund a satisfactory
>> answer for yet.
>>
>> We have several buildings on campus which are home to multiple
>> departments, all buildings have a building name.
>>
>> I looked the OSM wiki feature pages and in the OSM forum and found the
>> following approach as apparently standard procedure:
>> 1) Map building outline with building = university , name= XYZ building,
>> operator=McGill University
>> 2) Add a node inside the building for each department with
>> office=university, description=department name
>> This produces irritating blue dots in the outline of the building, see
>> https://osm.org/go/cIrNt~j2u
>>
>> When I looked at other universities, I found e.g. a node with
>> amenity=university, name=department name. But when looking at the OSM
>> wiki feature page for universities[1] it says you only should use
>> amenity=university for the whole campus.
>>
>> The office tag I found when looking for multiple businesses in one
>> building, but the blue dot aren't nice.
>>
>> Any suggestions on how to map this elegantly?
>>
>> Thank you,
>> Tim (aka AGeographer)
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university
>>
>> ___
>> 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] canvec imports

[James]

not sure why Canvec always gets shat uppon, their water features are great
and pretty accurate, the forest/landcover on the other hand needs fixing
before import. I think it's clear enough on the canvec wiki page that only
experienced mappers/importers should attempt a canvec import.

On Tue., Nov. 27, 2018, 12:54 p.m. Andrew  FYI Canada
>
> I made a few imports to canada a while ago and apparently
> raised the ire of someone.
>
> Here we go again :-(
>
> ---
> This was the first message
>
> >>Please, fix issues caused by this changeset for example in region of
>
> Yup, that was it, I was like ok, whats wrong with the changeset? Found
> an overlapping way. Figured that was it :-)
>
> And now
>
> Where is documentation page of this import? Can you link to discussion
> done before this import started?
>
> And So On.
>
> ---
> Hi PurpleMustang,
>
> XXX X has sent you a message through OpenStreetMap with the
> subject Re: Canvec Import:
>
> XXX X
> On 2018-11-27 17:21:34 UTC PurpleMustang wrote:
>
> Hello: This import has been a work in progress for about 10 years now
> :-)
>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue
>
> https://wiki.openstreetmap.org/wiki/Geobase/Announcement
>
> Andrew
>
> Note that currently active import should have a wiki page describing
> what exactly is imported and how data is processed - see
> https://wiki.openstreetmap.org/wiki/Automated_
>
> 
>
> Oh Well Here we go again
>
> Andrew
> aka CanvecImports
>
>
> ___
> 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] Tagging paths that are snowploughed?

[James]

I know it's been linked before:
https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md

On Tue., Nov. 20, 2018, 10:55 a.m. John Whelan  Which means more tags on the map but at least you can see which are
> definitely cleared.
>
> Interesting since its Ottawa I'll follow this convention.
>
> Thanks John
>
> James wrote on 2018-11-20 10:53 AM:
>
> pathes that ARE cleared are tagged seasonal=no as they are NOT
> seasonal(closes during winter for example)
>
> On Tue., Nov. 20, 2018, 10:51 a.m. John Whelan  wrote:
>
>> I'm not sure exactly what you mean.  Paths that not cleared are tagged
>> seasonal=no or tags that are cleared get the tag seasonal=no?
>>
>> The default on winter_service is yes so only the ones that are not
>> cleared need to be tagged with winter_service=no
>>
>> Could you point me to a reference in map features that uses the seasonal
>> tag?
>>
>> Thanks John
>>
>> Amos Hayes wrote on 2018-11-20 10:20 AM:
>>
>>
>> FYI, the Ottawa cycling community is using "seasonal=no" on pathways to
>> indicate winter maintenance.
>>
>> --
>> Amos
>>
>>
>> On Mon, 19 Nov 2018 at 19:01, John Whelan  wrote:
>>
>>> Yes but for the path I'm thinking of that crosses a park specifically
>>> I'm interested in tagging it just for cycling not a more generic case.
>>>
>>> Do you have another suggestion than winter_service=yes|no I think the
>>> default is yes so just tagging the ones that aren't cleared would be
>>> sufficient.
>>>
>>> Thanks
>>>
>>> Cheerio John
>>>
>>> Pierre Béland wrote on 2018-11-19 6:41 PM:
>>>
>>> Il y a plusierus facettes à considérer ici, soit accès hivernal, état du
>>> sentier et services accessibles.
>>>
>>> La clé winter_service=yes indiquerait simplement que le sentier est
>>> disponible l'hiver et ne permettrait pas d'indiquer que le sentier est
>>> nettoyé facilitant l'accès aux velos.
>>>
>>> Voici un usage différent mais qui nous éclaire sur les clés utiliisées
>>> pour décrire un service hivernal.
>>>
>>> La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de
>>> service hivernal (Service abandonné l'hiver dernier suite à l'ouverture
>>> d'une nouvelle route).
>>>
>>> Dans ce deuxième cas, cette tant le service que la piste n'existent que
>>> l'hiver.
>>> Les clés OSM utilisées pour les décrire sont
>>> ice_road=yes
>>> surface=ice
>>>
>>> Pierre
>>>
>>>
>>> Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan
>>>   a écrit :
>>>
>>>
>>> Sounds perfect.
>>>
>>> Thanks John
>>>
>>> On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets >>
>>> winter_service=yes|no seems perfectly fine:
>>> https://wiki.openstreetmap.org/wiki/Key%3Awinter_service
>>>
>>>
>>> On Mon, Nov 19, 2018 at 4:54 PM john whelan 
>>> wrote:
>>>
>>> Locally some paths across parks etc are snow cleared some aren't.  The
>>> ones that are are useful for cycling in the winter.
>>>
>>> Any suggestions on tags?
>>>
>>> Thanks John
>>> ___
>>> 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
>>>
>>> ___
>>> 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
>>>
>>
>> --
>> 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] Tagging paths that are snowploughed?

[James]

pathes that ARE cleared are tagged seasonal=no as they are NOT
seasonal(closes during winter for example)

On Tue., Nov. 20, 2018, 10:51 a.m. John Whelan  I'm not sure exactly what you mean.  Paths that not cleared are tagged
> seasonal=no or tags that are cleared get the tag seasonal=no?
>
> The default on winter_service is yes so only the ones that are not cleared
> need to be tagged with winter_service=no
>
> Could you point me to a reference in map features that uses the seasonal
> tag?
>
> Thanks John
>
> Amos Hayes wrote on 2018-11-20 10:20 AM:
>
>
> FYI, the Ottawa cycling community is using "seasonal=no" on pathways to
> indicate winter maintenance.
>
> --
> Amos
>
>
> On Mon, 19 Nov 2018 at 19:01, John Whelan  wrote:
>
>> Yes but for the path I'm thinking of that crosses a park specifically I'm
>> interested in tagging it just for cycling not a more generic case.
>>
>> Do you have another suggestion than winter_service=yes|no I think the
>> default is yes so just tagging the ones that aren't cleared would be
>> sufficient.
>>
>> Thanks
>>
>> Cheerio John
>>
>> Pierre Béland wrote on 2018-11-19 6:41 PM:
>>
>> Il y a plusierus facettes à considérer ici, soit accès hivernal, état du
>> sentier et services accessibles.
>>
>> La clé winter_service=yes indiquerait simplement que le sentier est
>> disponible l'hiver et ne permettrait pas d'indiquer que le sentier est
>> nettoyé facilitant l'accès aux velos.
>>
>> Voici un usage différent mais qui nous éclaire sur les clés utiliisées
>> pour décrire un service hivernal.
>>
>> La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de service
>> hivernal (Service abandonné l'hiver dernier suite à l'ouverture d'une
>> nouvelle route).
>>
>> Dans ce deuxième cas, cette tant le service que la piste n'existent que
>> l'hiver.
>> Les clés OSM utilisées pour les décrire sont
>> ice_road=yes
>> surface=ice
>>
>> Pierre
>>
>>
>> Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan
>>   a écrit :
>>
>>
>> Sounds perfect.
>>
>> Thanks John
>>
>> On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets >
>> winter_service=yes|no seems perfectly fine:
>> https://wiki.openstreetmap.org/wiki/Key%3Awinter_service
>>
>>
>> On Mon, Nov 19, 2018 at 4:54 PM john whelan 
>> wrote:
>>
>> Locally some paths across parks etc are snow cleared some aren't.  The
>> ones that are are useful for cycling in the winter.
>>
>> Any suggestions on tags?
>>
>> Thanks John
>> ___
>> 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
>>
>> ___
>> 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
>>
>
> --
> Sent from Postbox
> 
> ___
> 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] Stats Canada new building outlines Open Data do we wish to import it?

[James]

As "Frederick Ramm" would say having external IDs is pointless when you can
do a spatial join to see what is there and what is not

On Nov. 5, 2018 3:05 p.m., "John Whelan"  wrote:

Something that has come up in the Netherlands is they did an import then
try to update the buildings once a month.  By having some sort of id tag on
the building their feeling is it makes it much easier to pick out new
buildings.

On the technical side would we have such an id on the building outline if
we should wish to separate out new buildings and import them later.
Currently I don't think we do and someone maybe able to work it out from
the position but is it something we should think about?


Cheerio John

John Marshall wrote on 2018-11-04 6:40 PM:

Great idea John

John

On Sun, Nov 4, 2018, 16:48 john whelan  I've started the process off by an introductory post to the import mailing
> list and we are working on a wiki page which will be based on the Stat
> Canada City of Ottawa import wiki page.
>
> Cheerio John
>
> On Fri, 2 Nov 2018, 7:34 pm James 
>> if anyone needs a TM or micro data service, I'm available for this
>>
>> On Fri., Nov. 2, 2018, 7:32 p.m. John Whelan > wrote:
>>
>>> This approach seems very sensible however Pierre has raised the issue of
>>> poorly mapped buildings and we are aware that some were mapped in a
>>> mapathon environment so whilst Ottawa used a "leave existing buildings
>>> alone" approach is this an area where some judgement should be used?  and
>>> yes I am aware that the official party line is to correct what is there to
>>> retain the history which means taking the "Ottawa" approach is less
>>> controversial but would probably give us more inaccuracies on the map.
>>>
>>> An alternative might be to import all the buildings with a different tag
>>> than building=yes then leave it to mappers to inspect each before turning
>>> the switch or change the tags to building=yes.  Those that overlap poorly
>>> mapped buildings could be left to some sort of clean up phase.
>>>
>>> Thanks John
>>>
>>> Matthew Darwin wrote on 2018-11-02 7:07 PM:
>>>
>>> I think we should identify who would like to be involved in import for
>>> each municipality.  (on a wiki page). On the page, identify roles, like:
>>>
>>>- coordinator
>>>- import data preparation
>>>- QA
>>>- import execution
>>>- data enrichment (commercial, residential, etc... tagging)
>>>- etc..
>>>
>>> Then we can see where we have gaps and how to fill them.  Perhaps some
>>> municipalities have local mappers who will be happy to do the tagging of
>>> building type (and can do some validation if the buildings look right), but
>>> no technical capability to execute the actual import.  And maybe some folks
>>> who did imports before will help areas where we have no technical expertise.
>>>
>>>
>>> On 2018-11-02 6:58 p.m., John Whelan wrote:
>>>
>>>
>>>
>>> So to paraphrase your reply.  A centralised import plan in the wiki
>>> which says the data is approved for import and should be tackled in chunks
>>> of some sort of region since we are a decentralized organization.  Which I
>>> think is similar to the way Task Manager works.  The project is broken into
>>> tiles and each tile is tackled completed separately. The 'Tiles' would of
>>> course be somewhat larger in area and there is a technical limitation as to
>>> how big an area can be downloaded from the OSM server.
>>>
>>> The local mappers certainly have a role to play and because the goal is
>>> not only to import the buildings but to enrich the tags with commercial etc
>>> so the tag enrichment would be a task that a mapathon could tackle.  I
>>> personally don't think a new mapper using iD in a mapathon has a role to
>>> play in importing the building outlines into OSM.
>>>
>>> The plan should include the technical steps to import the data.
>>>
>>> Thanks
>>>
>>> Cheerio John
>>>
>>> Pierre Béland wrote on 2018-11-02 6:35 PM:
>>>
>>> Pour le Québec, je retrouve les données de plusieurs municipalités
>>> Montréal, Longueuil, Repentigny, Shawinigan, Québec et Rimouski.
>>>
>>> Première observation rapide, aussi, elles sont de bonne qualité et
>>> proviennent je suppose des cadastres des municipalités. En milieu urbain,
>>> cela facilite beaucoup l'identification des immeubles juxtaposés.
>&g

Re: [Talk-ca] Talk-ca Digest, Vol 129, Issue 15

[James]

Saskatchewan has Regina data. That's it.

It's totally dependent on cities contributing to the open data effort

On Mon., Nov. 5, 2018, 9:21 a.m. keith hartley  Hi all,
> I'd love to do more imports - I have a group here that we get together to
> do mapping as well as know some locals. Of course we'd add a wiki to the MB
> page to show the project ect.  From what I can tell there's no stats can
> data for manitoba or sask though!
> Keith
> ___
> 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] Stats Canada new building outlines Open Data do we wish to import it?

[James]

if anyone needs a TM or micro data service, I'm available for this

On Fri., Nov. 2, 2018, 7:32 p.m. John Whelan  This approach seems very sensible however Pierre has raised the issue of
> poorly mapped buildings and we are aware that some were mapped in a
> mapathon environment so whilst Ottawa used a "leave existing buildings
> alone" approach is this an area where some judgement should be used?  and
> yes I am aware that the official party line is to correct what is there to
> retain the history which means taking the "Ottawa" approach is less
> controversial but would probably give us more inaccuracies on the map.
>
> An alternative might be to import all the buildings with a different tag
> than building=yes then leave it to mappers to inspect each before turning
> the switch or change the tags to building=yes.  Those that overlap poorly
> mapped buildings could be left to some sort of clean up phase.
>
> Thanks John
>
> Matthew Darwin wrote on 2018-11-02 7:07 PM:
>
> I think we should identify who would like to be involved in import for
> each municipality.  (on a wiki page). On the page, identify roles, like:
>
>- coordinator
>- import data preparation
>- QA
>- import execution
>- data enrichment (commercial, residential, etc... tagging)
>- etc..
>
> Then we can see where we have gaps and how to fill them.  Perhaps some
> municipalities have local mappers who will be happy to do the tagging of
> building type (and can do some validation if the buildings look right), but
> no technical capability to execute the actual import.  And maybe some folks
> who did imports before will help areas where we have no technical expertise.
>
>
> On 2018-11-02 6:58 p.m., John Whelan wrote:
>
>
>
> So to paraphrase your reply.  A centralised import plan in the wiki which
> says the data is approved for import and should be tackled in chunks of
> some sort of region since we are a decentralized organization.  Which I
> think is similar to the way Task Manager works.  The project is broken into
> tiles and each tile is tackled completed separately. The 'Tiles' would of
> course be somewhat larger in area and there is a technical limitation as to
> how big an area can be downloaded from the OSM server.
>
> The local mappers certainly have a role to play and because the goal is
> not only to import the buildings but to enrich the tags with commercial etc
> so the tag enrichment would be a task that a mapathon could tackle.  I
> personally don't think a new mapper using iD in a mapathon has a role to
> play in importing the building outlines into OSM.
>
> The plan should include the technical steps to import the data.
>
> Thanks
>
> Cheerio John
>
> Pierre Béland wrote on 2018-11-02 6:35 PM:
>
> Pour le Québec, je retrouve les données de plusieurs municipalités
> Montréal, Longueuil, Repentigny, Shawinigan, Québec et Rimouski.
>
> Première observation rapide, aussi, elles sont de bonne qualité et
> proviennent je suppose des cadastres des municipalités. En milieu urbain,
> cela facilite beaucoup l'identification des immeubles juxtaposés.
>
> Je vois ailleurs, aux États-Unis notamment avec les données de Microsoft,
> que les projets sont par région ou municipalité.
>
> Je pense qu'il faut éviter un projet trop centralisé tant pour assurer un
> meilleur contrôle du déroulement dans chaque municipalité, région que pour
> permettre aux communautés des provinces et communautés locales de
> s'impliquer.
>
> La rédaction d' une page wiki pour l'ensemble du Canada peut répondre aux
> exigences du groupe Import de OSM. Mais l'organisation doit être
> décentralisée.
>
> Le rôle de cette liste doit être un forum pour supporter les communautés
> des provinces et communautés locales. C'est une occasion de dynamiser ces
> communautés avec un projet très intéressant. De là, ils auront le goût de
> compléter la carte pour y décrire les infrastructures locales.
>
> Si trop de tâches sont initiées en parallèle sur un gestionnaire de
> tâches, il sera très difficile de coordonner, assurer le suivi, une
> progression coordonnée. Il faut éviter que des mapathons ou organisations
> externes s'invitent pour collaborer à de telles tâches avec les milliers et
> milliers de personnes qui viennent jardiner quelques heures sans
> organisation / formation réelle et laissent ensuite le tout sans dessus,
> dessous.
>
>
> --
> Sent from Postbox
> 
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
> --
> Sent from Postbox
> 
> ___
> Talk-ca mailing list
> 

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[James]

Begin, these datasets are from the cities themselves, not canvec. Stats can
is relicensing them under a common umbrella

On Fri., Nov. 2, 2018, 4:20 p.m. Begin Daniel  I would agree to one import plan with an appropriate validation mechanism.
> I am concerned that the buildings they provide in rural areas come from
> Canvec. Over the years I have deleted/modified thousands of them (Canvec
> buildings) and I would not like to see all of them coming back.
>
>
>
> Daniel
>
>
>
> *From:* James [mailto:james2...@gmail.com]
> *Sent:* Friday, November 2, 2018 16:07
> *To:* john whelan
> *Cc:* Talk-CA OpenStreetMap
> *Subject:* Re: [Talk-ca] Stats Canada new building outlines Open Data do
> we wish to import it?
>
>
>
> From my initial glance at the data...seems pretty good and accurate(again
> I didn't check all the cities nor do I expect them all to be having same
> level of accuracy)
>
>
>
> The two I've been eye balling are Kingston and Rimouski which seem to be
> very accurate at first assessment. If we do want to import them, a formal
> draft up will have to be done though
>
>
>
> On Fri., Nov. 2, 2018, 3:53 p.m. john whelan 
> This is just a formal post to get a feel.
>
>
>
> In Ottawa the building outlines were of high quality and I feel have
> enriched the map.
>
>
>
> If we do should we consider it one project across the country or leave it
> to the local chapters to make the decision?
>
>
>
> I'm thinking that Montreal, Toronto, Vancouver certainly have local groups
> of mappers.  There maybe others.
>
>
>
> The other thing to consider is there are remote locations that may not
> have a group of local mappers so taking a country wide stance would not
> leave these locations in limbo.
>
>
>
> Taking the decision across the country would mean only one import plan and
> approval and after the Ottawa experience with OpenStreetMap import red tape
> it might be easier than a dozen or so different import plans.
>
>
>
> I'm not thinking of the mechanics of the import yet.  That is a different
> issue.
>
>
>
> If you could reply saying you think its a good idea or shouldn't be
> touched with a barge pole also if you could indicate country wide or leave
> it to the local groups to make the decision I would be grateful.
>
>
>
> Thanks 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

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[James]

>From my initial glance at the data...seems pretty good and accurate(again I
didn't check all the cities nor do I expect them all to be having same
level of accuracy)

The two I've been eye balling are Kingston and Rimouski which seem to be
very accurate at first assessment. If we do want to import them, a formal
draft up will have to be done though

On Fri., Nov. 2, 2018, 3:53 p.m. john whelan  This is just a formal post to get a feel.
>
> In Ottawa the building outlines were of high quality and I feel have
> enriched the map.
>
> If we do should we consider it one project across the country or leave it
> to the local chapters to make the decision?
>
> I'm thinking that Montreal, Toronto, Vancouver certainly have local groups
> of mappers.  There maybe others.
>
> The other thing to consider is there are remote locations that may not
> have a group of local mappers so taking a country wide stance would not
> leave these locations in limbo.
>
> Taking the decision across the country would mean only one import plan and
> approval and after the Ottawa experience with OpenStreetMap import red tape
> it might be easier than a dozen or so different import plans.
>
> I'm not thinking of the mechanics of the import yet.  That is a different
> issue.
>
> If you could reply saying you think its a good idea or shouldn't be
> touched with a barge pole also if you could indicate country wide or leave
> it to the local groups to make the decision I would be grateful.
>
> Thanks 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

Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles

[James]

We were actually talking about that on the osmcanada slack channel this
morning.

If we wanted to use said data it would have to be evaluated city by city
not as a whole data source.

There are providers(Ottawa, Yellowknife, Montreal for example) that are
already pretty well mapped in OSM where others(Rimouski) that only have a
couple building in OSM.

And as the data quality can vary provider to provider, it would probably be
best to evaluate data quality city by city

On Thu., Nov. 1, 2018, 2:08 p.m. Alasia, Alessandro (STATCAN), <
alessandro.ala...@canada.ca> wrote:

> *Released today**!  /* *Diffus**é**e** aujourd**’h**ui *
> Share with your networks ! / Partagez avec vos réseaux !
>
>
> ***(EN)
> *Open Building Data: an exploratory initiative*
> This exploratory initiative aims at enhancing the use and harmonization of
> open building data from government sources for the purpose of contributing
> to the creation of a complete, comprehensive and open database of buildings
> in Canada. The outcome of this exploratory work is a first version of the 
> *Open
> Database of Buildings*
>  (ODB), a
> centralized and harmonized repository of building data made available under
> the *Open Government License - Canada*
> .
> This initiative originates from insights taken from the *Statistics
> Canada pilot project*
>  on
> data crowdsourcing, which used OpenStreetMap as a platform for integrating
> data on building footprints. In addition to the possible benefits of
> crowdsourcing, that project highlighted the potential of integrating open
> data from municipal, regional, and provincial governments to meet the needs
> of official statistics.
> In its current version (version 1.0), the ODB contains approximately
> 4.3 million building footprints.
> *https://www.statcan.gc.ca/eng/open-building-data/index*
> 
> *Open Database of Buildings*
>  (ODB),
>
> *** (FR)
> *Données ouvertes sur les immeubles : une initiative exploratoire*
> Cette initiative exploratoire vise à accroître l'utilisation et
> l'harmonisation des données ouvertes sur les immeubles provenant de sources
> gouvernementales en vue de contribuer à la mise en œuvre d'une base de
> données complète, exhaustive et ouverte sur les immeubles au Canada. Le
> travail exploratoire a mené à la création d'une première version de la *Base
> de données ouverte sur les immeubles*
> 
> (BDOI), un référentiel centralisé et harmonisé des données sur les
> immeubles rendu public en vertu de la *Licence du gouvernement ouvert du
> Canada*
> .
> Cette initiative est fondée sur les leçons tirées du *projet pilote de
> Statistique Canada*
> 
> sur l'approche participative en matière de données, qui avait employé
> OpenStreetMap comme plateforme d'intégration des données sur les empreintes
> d'immeubles. En plus des avantages potentiels de l'approche participative,
> ce projet a mis en lumière la possibilité d'intégrer les données ouvertes
> des administrations publiques municipales, régionales et provinciales afin
> de répondre aux besoins en matière de statistiques officielles.
> Dans sa version actuelle (version 1.0), la BDOI contient environ
> 4,3 millions d'empreintes d'immeubles.
> *https://www.statcan.gc.ca/fra/donnees-ouvertes-immeubles/index*
> 
>
> *Base de données ouverte sur les immeubles*
> 
> (BDOI)
>
>
> Alessandro Alasia
> Chief | Chef
> Data Exploration and Integration Lab (DEIL) | Lab pour l’exploration et
> l’intégration de données (LEID)
> Center for Special Business Projects | Centre des Projets Spéciaux sur les
> entreprises
> Statistics Canada | Statistique Canada
> *alessandro.ala...@canada.ca*  / (613)
> 796-6049
>
>
> ___
> 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] Hydro Network (inland water) question

[James]

because we have over 2 million lakes and rivers and we are a couple hundred
dedicated mappers that have the skill set to fix and import Canvec
dataand not everyone prioritizes lakes and rivers in remote areas.

On Thu., Sep. 27, 2018, 7:26 p.m. Peter R,  wrote:

> Hi Canada Import Team,
> I'd like to ask a question that I've been curious about for a few years
> now. What happened during the import of inland water data? Throughout
> Canada, I find instances where tiles are missing water data. This results
> in lakes and other water polygons being abruptly cut off. Some examples:
> https://www.openstreetmap.org/#map=9/55.4821/-65.2981 and
> https://www.openstreetmap.org/#map=9/54.8027/-97.5913
>
> I've also found an instance of rogue ocean tiles at zoom 10 and greater if
> you switch the map layer to Transport Map:
> https://www.openstreetmap.org/#map=10/56.3267/-99.3107=T
>
> I see that importing the Geobase National Hydro Network is still in the
> planning phase according to
> https://wiki.openstreetmap.org/wiki/Geobase/NHN_-_OSM_Map_Feature
>
> I'm just curious as to why water data throughout Canada is very hit or
> miss. I guess I've answered my own question with "it's still in progress"
> but I'm curious nonetheless. I did check the message archives going a year
> back and didn't see anything regarding inland water data.
>
> Cheers,
> Peter
> ___
> 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] Montréal: Inconsistency in Public Transportation Provider's Name

[James]

Résumé très facile: Paris ou la france ≠ Le Québec.
Le Québec fait les chose très différente de la France.

On Sun., Aug. 12, 2018, 8:36 p.m. OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des
> nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit
> "operator=RATP" et "name=RER B". Certains disent que la pure consistance
> est stupide. Je dis "trouver ce qui fonctionne et rester cohérent".
>
> Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se
> produit. Joli bavard avec toi, Canada.
>
> Etienne
> Californie
>
> > On Aug 12, 2018, at 3:45 PM, James  wrote:
> >
> > Personellement la STM est connu sous la STM sur toute la "branding"
> (bus, arrêts, site web(stm.ca), etc) La seule exception est que son nom
> légale est : Société de Transport de Montréal. Pareil pour la STO à
> Gatineau(Société de Transport  de l'Outaouais)
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[James]

Personellement la STM est connu sous la STM sur toute la "branding" (bus,
arrêts, site web(stm.ca), etc) La seule exception est que son nom légale
est : Société de Transport de Montréal. Pareil pour la STO à
Gatineau(Société de Transport  de l'Outaouais)

On Sun., Aug. 12, 2018, 7:39 p.m. OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> "Raise matters" isn't something I did, it is something I am doing, as in
> continuing dialog.  Donc, merci pour la suggestion, mes deux années
> d'écolier français devront suffire.  This discussion did start in English.
> If you think a wiki page with a simple table sketches out "here's how we do
> this" (we've got one here for BART,
> https://wiki.osm.org/wiki/Bay_Area_Rapid_Transit and it syncs with
> https://wiki.osm.org/wiki/California/Railroads ) as in "it doesn't take
> much effort to say 'do it like this,'" hey, great.  I'm all for that sort
> of documentation and consistency and "let's communicate well."
>
> Really, some guy in California and some guy in a larger neighboring
> country (with the longest, perhaps most lightly-protected border on Earth,
> displaying obvious trust, history and centuries of good will) having a
> discussion about improving/developing transport tagging doesn't seem it
> should feel this antagonistic.  Abbreviate, or don't.  Pay attention to
> infrastructure tagging, or don't.  More (or less) closely align with USA
> and OpenRailWay mapping conventions (there are differences, it makes sense
> for countries to say "here's how WE do it" and "here's how we AND OUR
> NEIGHBORS do it" makes sense for trains and bus schedules and bike routes.
> Or don't.  These things really are international and good dialog makes good
> protocols.  We're simply people talking on a mailing list; I happen to
> believe that it's good that we do.
>
> Good dialog is good OSM.
>
> SteveA
> California
>
> (DJT, not JDT, of course)
>
> > On Aug 12, 2018, at 3:15 PM, john whelan  wrote:
> >
> > If you wish to raise matters about local mapping in Montreal I suggest
> you use French as it is the language that most Montreal mappers are
> familiar with.
> >
> > Cheerio John
> >
> > On 12 August 2018 at 17:37, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> > John, especially in light that we both volunteer in a wonderful
> organization like OSM, I consider neither of us poor.  Truly, I mean that.
> >
> > It wouldn't be "confused" that I might be.  It would be much more
> leaning towards, if not firmly in, the camp of "abbreviating in OSM
> key:value pairs is frowned upon because it maps backwards incompletely."
> That is a fair logical/mathematical/linguistic/database point.  Getting
> line-renderers to pay attention to short_name or alt_name or local_name or
> coalesce on something sensible, sure, that's a happy place.  I'd love to
> see a transport renderer that is wicked-smart with v2 and even v3 savvy
> colors, naming, routes and a "visual pop" that a good map does simply as
> you look at it.  That starts with good tagging including good discussion
> about tagging.  Simple as walking.
> >
> > Politics aside and whether hordes flee JDT or not, I am talking about
> good tagging in OSM as transport networks and how they are named and "get
> smart" really is happening all over Earth.  Good protocols to "we're all
> paying attention together" works.  Whether ISO/UN/IEEE or other acronyms
> and how a committee really can get the phones to connect and the trains
> running on time, the ideas behind "let's agree on good language and
> tagging..." work, this is simply being good neighbors.  A big human family
> sharing a map acts like a big human family sharing a map.  We seem to
> continue to do that here in talk-ca, talk-us and so on.  Thank you.
> >
> > SteveA
> > California
> >
> > > On Aug 12, 2018, at 2:17 PM, john whelan 
> wrote:
> > >
> > > Good heavens you mean we should spell out OCtranspo as Ottawa Carleton
> Transpo in case any American tourists get confused?
> > >
> > > Unfortunately the locals will probably get confused with this and
> whilst we should cater to these foreign tourists I think what is on the
> signs locally will be less confusing to the locals unless of course we get
> many more people streaming in to escape Donald.
> > >
> > > Or have I misunderstood some poor American?
> > >
> > > Cheerio John
> > >
> > > On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, <
> stevea...@softworkers.com> wrote:
> > > Dusting off a month-old thread...
> > >
> > > Damien and Jarek, it seems the examples listed below both fit into a
> "citizen mappers coalescing on a local/regional way to do things" as well
> as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming,
> network and operator tag conventions" (maybe who reads our wikis, maybe who
> does OT queries...) can figure this out quickly and sensibly.  It's great
> to see that's where things have landed, pretty close to a
> sweet-spot/bullseye.
> > >
> > > However (if I have 

Re: [Talk-ca] sharrows

[James]

https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md

On Sat, Jul 14, 2018, 2:47 PM john whelan,  wrote:

> Ottawa has been adding these on one side of the highway and a cycle lane
> in the other.
>
> How should they be mapped?
>
> ​Specifically how do you map the pure cycle lane in one direction and the
> Sharrow in the other?
>
> Thanks 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

Re: [Talk-ca] BC2020i and Wikidata

[James]

There's already an initiative to add wiki data to osm there's a tool that
helps you find missing wikidata items in a location where you can validate
if they are correctly matched or not:

https://osm.wikidata.link/

On Thu, May 31, 2018, 5:50 PM Jonathan Brown,  wrote:

> Has anyone thought of using Wikidata to enhance the BC2020i project work
> with secondary and postsecondary students?
> https://www.wikidata.org/wiki/Wikidata:Main_Page
>
>
>
> How could structured, linked open data help municipalities and regions
> engage students in collaborative research projects? We are exploring ways
> to build on the Durham Mapathon event of May 3. At that event, Durham
> Region staff collaborated with senior secondary school teachers and
> students from Clarington Municipality on policy challenges. The Durham
> Region GIS staff provided the technical support.
>
>
>
> 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

Re: [Talk-ca] A new available source of trail data in the Nanaimo area

[James]

Hopefully the names of said trails are not so vulgar as past experiences.
If they have surveyed all of the trails themselves and are making the data
available, I don't see an issue with using it(other than it being grossly
inacurate)

On Wed, May 2, 2018, 9:19 PM Doug Hembry,  wrote:

> Greetings..
> I wanted to bring to the attention of Vancouver Island mappers a source of
> some trail data in the Nanaimo area that I don't feel competent to handle
> myself. On a recent vacation visit to friends in Nanaimo, I learned that an
> association called the Back Country Horsemen of British Columbia have
> surveyed many of their customary riding trails around McKay Lake, resulting
> in a shapefile that they are prepared to make available to OSM.
>
> Originally, hearing about this shapefile, and expecting just a few trails
> clustered around the lake, I offered to import the data to OSM myself, but
> was surprised to find that it described quite a large network of trails
> covering a significant area. On reflection, given that I'm based in the SF
> Bay area in CA, and have zero local knowledge, I abandoned that idea. With
> the permission of my contact in the association, I'm asking if any local
> mappers might be interested in looking at the data with a view to importing
> it to OSM.
>
> The GPS survey appears to have been carefully done, and displayed in JOSM
> it conforms closely to those parts of the trails that are visible in
> imagery. The downside is that information describing physical
> characteristics (type of highway: path, track, road?; width, surface,
> smoothness, etc) is mostly absent. As is information about permissions
> (horse, bike, ATVs, private or public, etc), jurisdiction, and supporting
> amenities (eg, car parks, signage, water). Some of the trails do have
> names.  So clearly some digging or surveying for the missing data would be
> necessary. (Possibly some association members might be willing to help, but
> I didn't bring up the possibility). But the point is, that this data
> describes real trails that are currently in use for equestrian recreation.
> And I believe (but am not certain) that the Trans-Canada trail (Great
> Trail?) intersects this trail network.
>
> So that's it... Anyone who is interested in looking into this source
> should feel free to contact Lynn deVries of Back Country Horsemen of BC at
> nese...@gmail.com who can provide a copy of the shapefile.
>
> Best..
> Doug Hembry
> ___
> 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] Question

[James]

Canada Post also regularly changes Postal Code locations to remain the
master of the postal codes  and be able to resell their 5000$/year database(
https://www.canadapost.ca/cpo/mc/assets/pdf/business/pc_latLong_specs_en.pdf).
They have also sued geocoder.ca for collecting user postal codes, which
resulted in many years of litigation and they finally gave up (non-win).

On Fri, Apr 27, 2018 at 5:26 PM, john whelan  wrote:

> Post codes are put in one at a time.  They aren't all there.
>
> If you could help clean them up that would be useful.
>
> Zip codes are different and belong in Donald's land.
>
> Cheerio John
>
>
>
>
> On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:
>
>> Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my
>> City using offline mode and the OBF file of the Province of Quebec. Every
>> time I search an address it can not find it! Sometime it offer me other
>> address, sometime not. It's like if only a tiny part of Quebec's address
>> had been insert in Open Street Map. But, it's not exactly the case because
>> is has more address in Open street Map website.
>>
>> Look at that example, searching: 2985 rue de la Broussaille.
>> Osmand can't find it by OSM web site gives:
>>
>> Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres,
>> Québec, Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada
>> 
>>
>> I think it has a problem there. A lot of information should not be there
>> and the zip code is bad. It should be G2C 1S1. If that address is in the
>> OBF, I supposed the app have difficulties to find it.
>>
>> The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1,
>> Canada
>>
>>
>> An other test: 920, rue Noël-Carter
>>
>> Osmand can't find it but OSM web site can:
>>
>>
>> École Centre de formation professionnelle Maurice-Barbeau, 920, Rue
>> Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération),
>> Capitale-Nationale, Québec, G1V 1X3, Canada
>> 
>>
>> The good address is
>>
>> CFP Maurice-Barbeau
>> 920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada
>>
>> An other zip code error and an other address full of "dust".
>>
>> Every-time I tried to find something it's the same thing. It's impossible
>> to use Osmand as a GPS in Quebec City. I think it's because the data in the
>> OBF of the Province of Quebec is bad.
>>
>> Is your work have been put in the OBF? Does is exist and other OBF for
>> the Province of Quebec than the OF we can find there?
>> https://download.osmand.net/list.php
>>
>> Tank-you
>>
>>
>>
>>
>> ___
>> 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] DigitalGlobe building footprints for sale in Canada

[James]

Digital Globe has been doing it for a while. They put machine learning on
their imagery and can extract buildings quite quickly and accurately

On Wed, Apr 11, 2018, 12:24 PM Bernie Connors, 
wrote:

>
> https://mailchi.mp/gogeomatics/canadian-building-footprints-now-available-off-the-shelf?e=b9f52af875
>
> I received this link by email today.  It looks like DigitalGlobe is trying
> to make some money from their building footprint data before it is
> available for free in OpenStreetmap.
>
> Bernie,
> --
> Bernie Connors
> New Maryland, NB
> ___
> 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] Trans-Canada Highway research

[James]

http://openstreetview.org/details/23187/73

No trans-canada naming in sight because the trans-canada is a meta road
composed of multiple highways. See road sign in OSV.

On Mon, Mar 26, 2018, 12:07 PM Kevin Farrugia, <kevinfarru...@gmail.com>
wrote:

> The proper name for the highways that are under the Kings Highway system
> (400-Series included) is "Highway xxx" or Highway xx, with the exception of
> the QEW.  Highways signs and government data follow the same rules.
>
> The Trans-Canada as a name/deaignation is almost inconsequential in
> Ontario and to Ontarians.
>
> ---
> Kevin Farrugia
>
>
> On Mon, Mar 26, 2018, 11:46 AM Viajero Perdido, <
> viajero.perdido.spam.buc...@gmail.com> wrote:
>
>> On 18-03-26 05:33 AM, talk-ca-requ...@openstreetmap.org wrote:
>> > Message: 3
>> > Date: Mon, 26 Mar 2018 11:33:14 +
>> > From: James <james2...@gmail.com>
>> > To: "Olivia Robu - (p)" <olivia.r...@telenav.com>
>> > Cc: Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>> > Subject: Re: [Talk-ca] Trans-Canada Highway research
>> > Message-ID:
>> >   <
>> cank4qi_u9uveodoc8try-mic-xgxsxbuuv0n9pssjo0v+jr...@mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > highway 417 should be tagged as highway 417 and not principally
>> transcanada
>> > way as this is how it's known locally. It can be tagged in transcanada
>> > relation, but it's mainly known as the 417
>>
>> I disagree.  "Highway 417" is a low-value name, because the "ref" tag
>> should already contain the number, causing numbered shields to be
>> shown.  "Highway 417" is just a verbosification of the number.
>> "Trans-Canada Highway", however, is a real name; it belongs in the name
>> field.
>>
>> This way, most maps would show both name and number.
>>
>> To me, the (completely separate) issue is whether ordinary numbered
>> highways should have a name tag at all, "Highway nnn", or simply nothing
>> because "ref" takes care of it.  I've been able to find no guidance on
>> this, and I've looked.  I've been leaving "Highway nnn" in place when I
>> see it, which is most of the time.  But that's another discussion for
>> another day.
>>
>> ___
>> 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] Trans-Canada Highway research

[James]

highway 417 should be tagged as highway 417 and not principally transcanada
way as this is how it's known locally. It can be tagged in transcanada
relation, but it's mainly known as the 417

On Mon, Mar 26, 2018, 7:22 AM Olivia Robu - (p), 
wrote:

> Hello,
>
> The Telenav Map team has done some research on the status of the ways and
> relations of Trans-Canada Highway.
>
> Here are some conclusions from this research:
>
>- The highway is formed from 30 routes;
>- Every route has different names for the name tag, such as: street
>names, other routes names or Trans-Canada highway name in different forms;
>- The issue above is repeating for the ref tag;
>- The name of Trans-Canada highway has more than one form
>(Trans-Canada Highway, TransCanada Highway, Trans Canada Highway, etc);
>- Another issue is the variety of names in other tags related to it
>(such as: name:en, name:fr, alt_name, alt_name:en, alt_name:fr, nat_name);
>- There are some routes that don’t have a route name only ref (5
>routes);
>- There are some routes that overlap:
>   - in Manitoba: - PTH 1 (MB Trans-Canada Highway) and Trans-Canada
>   Highway (Super);
>
>  - Yellowhead Highway
> and PTH 16 (MB Trans-Canada Highway);
>
>- in Alberta: Trans-Canada Highway (AB) and Trans-Canada Highway
>   (Super);
>   - in British Columbia: - Trans-Canada Highway (BC, Super) and
>   Trans-Canada Highway;
>
>
>- About 90% of these routes are broken;
>- About 80% of these routes have highway value flip flop (motorway,
>trunk, primary);
>
>
>
> We propose to make some improvements to standardize all the routes. We
> would like to get your thoughts and feedback on the following questions:
>
>- What is the correct form for the name that appears in the way name
>tag? For example: “Highway 417” is part of Trans-Canada Highway and has the
>name value tag “Highway 417”. To resolve this issue, we would need to
>standardize the ways’ name tag for all the provinces. The question is,
>should we modify the way names in to “Trans-Canada Highway”, or should we
>insert the name “Trans-Canada Highway” at the end of the name, like this:
>“Highway 417 (Trans-Canada Highway)”, or should we leave it like it is?
>- Another issue is related to the official name of the highway.
>According to our research the official name for Trans-Canada Highway is
>“Trans-Canada Highway”. In our research we have found several forms of this
>name: TransCanada Highway, Trans Canada Highway, etc. Should we change all
>the names to “Trans-Canada Highway”?
>
>
>- Another question is related to the priority of the names in the name
>value tag and also for the ref tag. If we have a way that has a street name
>(“Old Highway 16” or “North York River Road”) and two routes that overlap
>(ex: Trans-Canada Highway and Highway 11). What is the name and the ref
>that should appear in the way name tag and ref tag?
>- In case of overlapping identical routes (ex: in Manitoba there is
>two routes for Trans-Canada Highway). What should be the best approach?
>- In case of highway value flip flop (motorway, trunk, primary), there
>are several segments like this outside the cities (ex.: Route “Ontario
>Highway 17 (Blind River to North Bay) (ID 3739829)”, or Route “Trans Canada
>Highway 104” (ID 1732797)). For areas outside the cities we propose to
>change the highway value into motorway/trunk. What do you think about this
>issue?
>
>
>
> We think that one approach to resolve the first problem could be to add
> “Trans-Canada Highway” or “Highway 417 (Trans-Canada Highway)” to the way
> name for all the routes, and the ref number correspondent to each route
> that forms the Trans-Canada Highway.
>
>
>
> We look forward to hearing your feedback and hope to improve the situation
> together.
>
>
>
> Here is the link to github ticket that we created:
> https://github.com/TelenavMapping/mapping-projects/issues/57
>
>
>
> Regards,
>
> Olivia Robu
> ___
> 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] BC2020 Calgary Challenges and Best Practices

[James]

tested on ff, same issue boundary box no longer shows

On Fri, Mar 23, 2018, 11:18 AM john whelan, <jwhelan0...@gmail.com> wrote:

> So firefox would be fine?
>
> Thanks John
>
> On 23 March 2018 at 11:12, James <james2...@gmail.com> wrote:
>
>> depends if you are using chrome or not, seems like a mixed content
>> error(tm is http and osm is https) chrome now blocks mixed content.
>>
>> Last time I tried to enable HTTPS on TM2 it broke syncing with JOSM as it
>> would try to open up a self signed cert(not accepted by default) on port
>> 8112 with no errors or feedback. So I either brake ID boundaries or
>> JOSM(unless a user knows how to accept cert)
>>
>> On Fri, Mar 23, 2018, 11:01 AM Jonathan Brown, <jonab...@gmail.com>
>> wrote:
>>
>>> It would be good to have a screen shot demonstrating these kinds of
>>> errors. We could use these screen shots of good and bad examples to
>>> demonstrate good practices. James, will the TM2 issue affect our March 29
>>> mapathon?
>>>
>>>
>>>
>>> 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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 Calgary Challenges and Best Practices

[James]

depends if you are using chrome or not, seems like a mixed content error(tm
is http and osm is https) chrome now blocks mixed content.

Last time I tried to enable HTTPS on TM2 it broke syncing with JOSM as it
would try to open up a self signed cert(not accepted by default) on port
8112 with no errors or feedback. So I either brake ID boundaries or
JOSM(unless a user knows how to accept cert)

On Fri, Mar 23, 2018, 11:01 AM Jonathan Brown, <jonab...@gmail.com> wrote:

> It would be good to have a screen shot demonstrating these kinds of
> errors. We could use these screen shots of good and bad examples to
> demonstrate good practices. James, will the TM2 issue affect our March 29
> mapathon?
>
>
>
> 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

Re: [Talk-ca] Poorly drawn buildings #GEOG231-W18; #BC2020; #UCalgary-GEOG231; #BC2020-UCalgary

[James]

negative, it launches a new tab to openstreetmap.org in the ID editor. So
there are no compatibility issues between TM and ID, especially that TM3 is
not production ready(based on Github issues)

On Thu, Mar 22, 2018, 8:43 AM Tim Elrick, <o...@elrick.de> wrote:

> At our mapathon on Tuesday the Canada tasking manager did not show
> boundaries in iD editor. We tested the HOT TM which worked fine (however,
> they are using TM3, I guess).
>
> @James: Might this all have to do with Canada TM being based on TM2 which
> might not work well with last changes to iD editor?
>
> Best,
> Tim
>
> On 2018-03-21 14:11, john whelan wrote:
> Is this recent or was it part of the Geo week mapping?
>
> Thanks John
>
> On 21 March 2018 at 14:08, Matthew Darwin <matt...@mdarwin.ca> wrote:
>
>> Today I found that people using the same hashtags 
>> (#GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary)
>> are drawing buildings on top of each other.  Eg duplicates.  Using ID
>> editor.  There appears to be an ongoing problem here.
>> On 2018-03-19 10:53 AM, john whelan wrote:
>>
>> I think Pierre has already identified the problem some time ago and it
>> has been raised with Stat Can and others who are involved with BC2020 not
>> that anyone admits to being responsible for BC2020 and Geoweek. So
>> hopefully we won't be adding more low quality buildings.
>>
>> Cheerio John
>>
>> On 19 March 2018 at 10:42, Matthew Darwin <matt...@mdarwin.ca> wrote:
>>
>>> Hi all,
>>>
>>> I noticed some poorly drawn (not-square) buildings in Calgary tagged
>>> with the hashags #GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary.
>>> If you are involved in this project, you might want to review the quality.
>>> I added a "fixme" tag to the problems I happen to notice.
>>>
>>> ___
>>> 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] Emergency Request for Tasking Manager Trainer

[James]

Seems Durham already had a project created for it:
http://tasks.osmcanada.ca/project/85
I'll archive project 116

On Fri, Mar 9, 2018 at 11:56 AM, john whelan <jwhelan0...@gmail.com> wrote:

> If you let us know the time and date if one or two of use are around we
> can run an eye over the work as it is done.  Technical term is validation
> basically it is to give feedback to help with the data quality side.
>
> Cheerio John
>
> On 9 March 2018 at 11:44, Jonathan Brown <jonab...@gmail.com> wrote:
>
>> Thanks, James. I added one building to project 116 with request for
>> review. We may not have time to set up  a wiki to support the specific
>> building tags to use for the Durham Region policy challenges (e.g., access
>> to fresh food or financial bank machines), but will give it a try. The goal
>> is to “add meaning to the geographic objects” (
>> https://taginfo.openstreetmap.org/about) the students will be mapping on
>> March 29 based on their local knowledge.
>>
>>
>>
>> Jonathan
>>
>>
>>
>> *From: *James <james2...@gmail.com>
>> *Sent: *Friday, March 9, 2018 11:02 AM
>> *To: *Jonathan Brown <jonab...@gmail.com>
>> *Cc: *john whelan <jwhelan0...@gmail.com>; Matthew Darwin
>> <matt...@mdarwin.ca>; Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>; Rob
>> Halko <rob.ha...@durham.ca>; Brock Baker <brock_ba...@kprdsb.ca>
>> <brock_ba...@kprdsb.ca>; Alasia, Alessandro (STATCAN)
>> <alessandro.ala...@canada.ca>
>> *Subject: *Re: [Talk-ca] Emergency Request for Tasking Manager Trainer
>>
>>
>>
>> http://tasks.osmcanada.ca/project/116
>>
>> Copied information from task #91
>>
>>
>>
>>
>>
>
>
> ___
> 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] Emergency Request for Tasking Manager Trainer

[James]

http://tasks.osmcanada.ca/project/116

Copied information from task #91

On Thu, Mar 8, 2018 at 2:44 PM, Jonathan Brown <jonab...@gmail.com> wrote:

> Excellent. The OSM community’s support is much appreciated.
>
>
>
> Jonathan
>
>
>
> *From: *john whelan <jwhelan0...@gmail.com>
> *Sent: *Thursday, March 8, 2018 2:16 PM
> *To: *Jonathan Brown <jonab...@gmail.com>
> *Cc: *Matthew Darwin <matt...@mdarwin.ca>; Talk-CA OpenStreetMap
> <talk-ca@openstreetmap.org>; Rob Halko <rob.ha...@durham.ca>; Brock Baker
> <brock_ba...@kprdsb.ca> <brock_ba...@kprdsb.ca>; Alasia, Alessandro
> (STATCAN) <alessandro.ala...@canada.ca>
> *Subject: *RE: [Talk-ca] Emergency Request for Tasking Manager Trainer
>
>
>
> I think Matthew or James are the people to talk to.  I suspect it might
> take them an hour or so which means there is an excellent chance of it
> being made available before March 29th.
>
>
>
> Cheerio John
>
>
>



-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[James]

is addr:province even needed? province boundaries are  pretty well defined
and could be dropped

On Mar 8, 2018 11:28 PM, "Matthew Darwin"  wrote:

>
> So I've tidied up the addr:province/state tags, now using only
> addr:province, leaving anything that would be generally considered
> "correct" either spelt out in full or using English provincial abbreviation
> as you might use in a mailing address. Also left "Quebec" (no accent).
> I would rather like to clean this up further, however, I have stopped just
> at tidying up things that were mis-spelt or had inconsistent case.
>
> Is there any view on where to go next?
>
> These are the current counts:
>
> 69008   Nova Scotia
> 39668   ON
> 33280   British Columbia
>  7788   Alberta
>  6584   AB
>  4771   BC
>  4520   Québec
>  3772   Ontario
>  2791   QC
>  2140   NB
>  1744   SK
>  1285   NU
>  1066   NL
>  1022   Manitoba
>   879   New Brunswick
>   527   Quebec
>   307   PE
>   234   NS
>   222   MB
>   163   Saskatchewan
>23   Nunavut
>14   NT
>11   YT
> 9   Yukon
> 3   Northwest Territories
>
> ___
> 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] Emergency Request for Tasking Manager Trainer

[James]

I'll have a project up by tomorrow.

On Mar 8, 2018 8:03 PM, "Tim Elrick" <o...@elrick.de> wrote:

> Hi Jonathan & Rob,
>
> As John mentioned task #91, the one that we set up last, and we are about
> to set up another one for our next mapathon on March 20th (on Khairpur in
> Pakistan though), I am happy to help out too.
>
> For preparing the areas of interest (aoi) the project manager needs either
> a geojson or a kml or a shapefile. If you want to draw on James' offer to
> set up the tasking manager and just don't have the aoi as geojson, I am
> happy to convert it and send it to James.
>
> All the best for your mapathon (if Durham wasn't so far from MTL, I would
> have joined in)!,
>
> Tim
>
> On 2018-03-08 14:44, Jonathan Brown wrote:
>
> Excellent. The OSM community’s support is much appreciated.
>
>
>
> Jonathan
>
>
>
> *From: *john whelan <jwhelan0...@gmail.com>
> *Sent: *Thursday, March 8, 2018 2:16 PM
> *To: *Jonathan Brown <jonab...@gmail.com>
> *Cc: *Matthew Darwin <matt...@mdarwin.ca>; Talk-CA OpenStreetMap
> <talk-ca@openstreetmap.org>; Rob Halko <rob.ha...@durham.ca>; Brock Baker
> <brock_ba...@kprdsb.ca> <brock_ba...@kprdsb.ca>; Alasia, Alessandro
> (STATCAN) <alessandro.ala...@canada.ca>
> *Subject: *RE: [Talk-ca] Emergency Request for Tasking Manager Trainer
>
>
>
> I think Matthew or James are the people to talk to.  I suspect it might
> take them an hour or so which means there is an excellent chance of it
> being made available before March 29th.
>
>
>
> Cheerio John
>
>
>
>
> ___
> 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] Emergency Request for Tasking Manager Trainer

[James]

Doesnt have to be precise, I just dont know those places.

On Mar 8, 2018 2:28 PM, "Jonathan Brown"  wrote:

> do you have a geojson extent of the area you want to cover?
>
>
>
> -
>
>
>
> Rob Halko can answer that question for Durham Region, the priority area
> for March 29. I’ll need to ask the other regions.
>
>
>
> Jonathan
>
>
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Emergency Request for Tasking Manager Trainer

[James]

do you have a geojson extent of the area you want to cover?

On Mar 8, 2018 2:06 PM, "Jonathan Brown"  wrote:

> If we could clone the http://tasks.osmcanada.ca/project/91 so that it
> could be used to tag information for existing buildings in the regions of
> Durham, Northumberland and Niagara Falls, then that would be great. Can
> that be done in time for March 29?
>
> Jonathan
>
>
>
> On 8 March 2018 at 10:40, Jonathan Brown  wrote:
>
> Thanks, Matthew. We are finalizing the mapping task on a conference call
> this afternoon at 3 pm if you have time to join in. At the Toronto OSM
> Meetup they recommended using one of the HOT Tasking Manager tasks. I
> looked at this one and found the “Project Specific Notes” helpful:
> https://tasks.hotosm.org/project/4234#bottom
>
>
>
> Could we not set up a similar project using the BC2020i framework so that
> municipalities and regions could use OSM to track local use of buildings
> for food security and other types of sustainable development projects?
>
>
>
> Splitting up the work for completion in a short period of time is exactly
> what high school teachers and non-profit agencies in rural communities
> need. The Ontario Ministry of Agriculture, Food and Rural Affairs is
> working on this kind of capacity building with rural communities and youth.
>
>
>
> Could the OSM Tasking Manager not be used to support those municipalities
> that have limited GIS open data capacity to sustain this type of activity?
> We want to have an OSM training session like the one you describe below in
> the morning (2-5 to 3 hours) and then give teams a task to map where they
> would be adding points of interest based on prior knowledge gathering
> before the event. The prior knowledge would be related to information about
> their school building that ties into information about municipal buildings
> in the surrounding neighbourhoods.
>
>
>
> The combined information would allow them to visualize some aspect of
> local land use. Rob will be able to demonstrate how Durham Region uses
> spatial analysis for local planning purposes. In the follow-up event in the
> fall we could bring these schools back for an event that demonstrates how
> crowdsourcing and citizen science works at the local level.
>
>
>
> Jonathan
>
>
>
> *From: *Matthew Darwin 
> *Sent: *Wednesday, March 7, 2018 11:19 PM
> *To: *Jonathan Brown ; talk-ca@openstreetmap.org
> *Subject: *Re: [Talk-ca] Emergency Request for Tasking Manager Trainer
>
>
>
> [prune CC list so this gets posted to the list]
>
> Hi Jonathan,
>
> I'm probably missing something, but you don't link training videos from
> the tasking manager.   The tasking manager is about splitting up some
> pre-defined mapping jobs (eg trace outline of building from bing satellite
> image), into small chunks that people can finish in a short amount of
> time.  So people don't work on things other people are already working on.
>
> If people are adding what they already know, then you don't need a tasking
> manager.  People just go ahead and add it, if it is not already there
> (checking if it is already there is important so we don't get duplicate
> things).  Presumably beginners are only going to add one thing at a time in
> ID editor, and they're all in the same room, so scope for conflict is small
> (easily solved with everyone announcing what they are doing before starting
> it).
>
> For your session later this month, it sounds to me like you want someone
> to
>
>- introduce the topic of mapping in OSM
>- introduce the ID editor
>- go through some samples of things to be added
>- then everybody get on their laptop and start trying to edit things,
>with the leader checking what is going on
>
> (this is how my introductory session went last April when I joined a
> meetup group in Ottawa)
>
> The task manager is not needed in this scenario.
>
> But please correct me if I totally missed your point.
>
> On 2018-03-07 08:55 AM, Jonathan Brown wrote:
>
> We want to run the mapathon by setting up a task in the Tasking Manager
> with links to the OSMLearning video tutorials and use cases for the
> instruction section. We want to make the task as simple as possible (e.g.,
> adding points of interest based on participants’ local knowledge augmented
> with information from social services and NGOs who will be participating).
>
>
>
> The goal is to have the participants apply OSM morning training to a
> problem solving task in the afternoon, similar to what Sterling Quinn did
> for the Philly Fresh Food Mapathon: http://2017.phillytechweek.
> com/events/philly_mapathon
>
>
>
> We would need to add tasks to the OSM Tasking Manager that encompass the
> school boards and schools within the geography to be mapped - Durham
> Region, Niagara Region, Northumberland County, and Greater Peterborough
> area. For March 29 the priority is for Durham Region and Northumberland
> County.
>
>

Re: [Talk-ca] BC2020i Mapathon Event

[James]

one impotant take away from past experiences is to tell them not to map the
same element twice. For example, someone else maps it first, dont add it on
top as well(duplicate item mapping)
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Manitoba buildings, addresses and high school work

[James]

Before Scruss comes out and says it:
1. Wiki documentation
2. You need to get LWG to approve license as it's not a standard license.
Explicit permission can certainly help our case.

After license is approved we could move on to approval of data quality,
then submit it for revue on import list(p.s. if it's crappy data they are
going to tell you about how it's crappy)

After all that(maybe 1-2 years later) can we move on to the serving of data
via a tasking manager and start the import

On Feb 28, 2018 11:54 AM, "john whelan" <jwhelan0...@gmail.com> wrote:

> Similar to does not mean the same unless it is the TB Open Data license
> but I suspect it predates that one.  Given that Stats Canada has said it
> will make the data available through the Federal Government's Open Data
> portal real soon now I suspect that an email from the city even to yourself
> would be acceptable.
>
> There is an import process speak nicely to James and he may be kind enough
> to handhold you through it.
>
> The LWG will give an opinion on the license but it could take some
> considerable time to do so.
>
> The import needs to be approved by a the local community.  In Ottawa two
> or three local mappers gathered together over coffee to approve it.  I
> think there were more than three.
>
> Given your suspected time frames its probably best to document the import
> fairly quickly.  That way it allows for those mappers who feel imports are
> terrible to have their say.
>
> Cheerio John
>
> On 28 February 2018 at 10:31, keith hartley <keith.a.hart...@gmail.com>
> wrote:
>
>> Hi OSM'ers
>>
>> I am working on adding buildings to OSM in Manitoba and have a few
>> questions. I was just offered an updated building footprint and address
>> shape file from the City of Brandon, and agreement that it can be used in
>> OSM. I understand that the license needs to be compliant with the OSMs of
>> course, and will email the licensing group. The City uses a open data
>> license similar to Ottawa's (can be seen here
>> http://opengov.brandon.ca/terms.aspx) I can get  written consent in an
>> email if need be as well. Currently the buildings are from the Manitoba
>> land initiative website (MLI) and I can see that the city of Brandon Data
>> is much more accurate (in both attributes and position) I will review the
>> current data. Is there anything else I should be doing before I upload
>> this?
>>
>> The plan is to have high school students look at the map and using
>> walking maps or equivalent data capture (android app) to find what is
>> accessible for people with mobility issues around their schools. I'll write
>> the results on a wiki to show our successes. Anyone else have good ideas
>> how to get students to add to the map? (with teacher oversight of course!)
>>
>> Cheers,
>> Keith
>>
>>
>> ___
>> 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] Formatting of Municipality Names in Ontario

[James]

usually if its included in name its: Xyz Township not township of xyz

On Feb 26, 2018 3:24 PM, "OSM Volunteer stevea" 
wrote:

> Hi Matthew:
>
> You do fine work here, yet I have a concern about "Township."  I don't
> know if in Canada, a Township is a bit of an "odd duck" like it is in the
> USA.  In the USA, we have county as admin_level=6, township as
> admin_level=7 (in about one-third of states) and city/town/village as
> admin_level=8.  The reason for 7 has to do with the way that a county might
> assign "home rule" responsibilities, which flow from the state extending
> its political administration to the counties, then a county might push this
> through to a "township," a crucial component being that township
> jurisdictions can often (but do not always) cover the ENTIRE county, rather
> than a portion of it, like a city does.  It's a little complicated, it
> varies from state to state, in our Midwest Region it often has to do with
> the way that state surveys were done (not the same in our New England
> Region) and OSM doesn't always align with the US Census Bureau's
> methodologies and/or results, (but does most of the time, there are good
> reasons for why OSM has reached the consensus we have in those exceptional
> cases, and we document these in our wikis).
>
> If Canada (its provinces, actually, I believe) has this same or a similar
> concept of "township," (you might, you might not), then admin_level=7 might
> be correct on Canadian "Township of..." boundaries.  If not, I'm blowing a
> lot of smoke into the equation and I'll thank you for reading and apologize
> for wasting time on this thread.
>
> Yes, they are USA-specific, but we have https://wiki.osm.org/wiki/
> United_States_admin_level (prescriptive, comprehensive) and
> https://wiki.osm.org/wiki/WikiProject_United_States/Boundaries
> (descriptive, rather more user-friendly/novice-oriented).  You might
> check these out (especially https://wiki.osm.org/wiki/
> WikiProject_United_States/Boundaries#Civil_townships) if Canada has
> "townships" as "potentially completely subdivided county entities" and see
> how we do it here (basically, they are admin_level=7).
>
> Looking at the Canada row in https://wiki.osm.org/wiki/Tag:
> boundary%3Dadministrative and https://wiki.osm.org/wiki/
> WikiProject_Canada#Administrative_Boundaries I don't see this, I see that
> "Townships" are agglomerated together with "cities, villages, etc."  If
> that's correct, again, all of this I'm spouting about "Township" can be
> ignored, as it is effectively another word to describe an admin_level=8
> entity and you seem to be fine leaving things that way.
>
> Regards,
> SteveA
> ___
> 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] Formatting of Municipality Names

[James]

My favourite is Moose Factory. I think Canadian typonomy was the consesus
last time we had the same subject come up

On Feb 16, 2018 7:14 PM, "Matthew Darwin"  wrote:

> In my OSM map updates to remove of "City of" and similar prefixes from
> locality names, I will not be expanding any "St", "Ste" or any other
> abbreviations of those names.  If the name (minus the prefix to be removed)
> matches what is in NRCan database, I will remove the prefix; if it doesn't,
> I will bring it back up here for review.
>
> I occasionally get "Saint John, NB" and "St. John's, NL" confused, so
> personally I do not want the city name in Newfoundland expanded to add to
> my confusion.   :-)
>
> What's your favourite locality name in Canada?  I have to go with
> "Saint-Louis-du-Ha! Ha!"
>
>  On 2018-02-16 05:56 PM, Jarek Piórkowski wrote:
>
> With "street" in a street name, it's clear to most everyone that Pine St
> is an abbreviation and Pine Street is the correct unabbreviated Canadian
> English version. It is not clear to me that "Saint Catharines" is the
> correct unabbreviated version of the city's name. In fact it looks
> incorrect to me.
>
>
>
> ___
> 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] Formatting of Municipality Names

[James]

the only expanded version of the city name was in french, and on wikipedia:
https://fr.m.wikipedia.org/wiki/Sault-Sainte-Marie_(Ontario)

Maybe because people(English) have trouble spelling "Sainte"?

On Feb 16, 2018 5:38 PM, "Tristan Anderson" 
wrote:

> I'm going to make here to the unpopular argument that in OSM tagging "St."
> should always be written as "Saint".
>
> I know that you will never see "Sault Sainte Marie" on a sign, map or
> official document and that seeing it written like that looks weird and even
> wrong to local residents.  In much the same way when I started editing OSM,
> "Pine Street" looked weird, even wrong, to me.  After all, street suffixes
> are abbreviated on every sign and map; even when they are referenced in
> articles.  I have since come to accept and embrace the unabbreviated street
> suffix, even to the point writing them out in full in my day-to-day life,
> such as when I enter in my home address.  I think we can all agree that
> there is nothing incorrect about Maple Boulevard, and by extension that an
> abbreviation's ubiquity does not in and of itself make the full version
> incorrect.
>
> There are a lot of streets that begin with Saint.  In one neighbourhood of
> Niagara Falls, for example, there is (using the names recognised by Canada
> Post) a Saint Marys Avenue, St. John St, St Paul Avenue, St Patrick Avenue,
> St. Peter Avenue, and Saint George Avenue.  I doubt that whoever named
> those streets intended for that specific combination of St/St./Saint and I
> can be certain that the abbreviations were merely ever there out of
> convenience, one that's made obsolete by digital maps not needing to cram a
> bunch of street names onto limited space.  I find it hard to see anybody
> having a problem with beginning all six of these names with "Saint".
>
> The "St" abbreviation may particularly problematic for data consumers as
> it could mean Street, Saint, or if you check out the Wikipedia
> disambiguation page, dozens of other things.  Sure it's obvious to a human
> that there is no city called Street Thomas, but a computer might have a bit
> of trouble there.  And don't get me started on the absurdity that St is a
> contraction, not an abbreviation.
>
> I'm not going to rush out and change any existing tagging but I think this
> is one instance where rational thought needs to override tradition.
>
> From: OSM Volunteer stevea 
> Sent: February 16, 2018 4:03 PM
> To: Jarek Piórkowski; talk-ca
> Subject: Re: [Talk-ca] Formatting of Municipality Names
>
>
> I stand corrected, thank you everybody.
>
> BTW I do my best not to abbreviate thinks like "DC" for District of
> Columbia, but I now better understand that "St." in many cases has now
> truly become the official name, abbreviation included.
>
> SteveA
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> openstreetmap.org%2Flistinfo%2Ftalk-ca=02%7C01%7C%
> 7C0929b2c013ed48ddd99b08d57580cc04%7C84df9e7fe9f640afb435
> %7C1%7C0%7C636544118392215285=RLRrzWsO83vlhjicXTPgQumstpl4u%
> 2FyhY3ciiFEmAuU%3D=0
>
> ___
> 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] Formatting of Municipality Names

[James]

Checked for Toronto and Ottawa they do not have "City of" :
http://www4.rncan.gc.ca/search-place-names/search?q=Toronto[]=985=O
I agree with what Bernie said, unless it's the official name. It seems it's
a classification.

On Mon, Feb 12, 2018 at 9:02 PM, Bernie Connors 
wrote:

> I see the use of "City of" as indicating the official name of a
> municipality as it is defined in legislation. Here in New Brunswick the
> Municipalities Act‎ defines the official names of municipalities. Some opt
> to use "City of ", "Town of ", etc in the Municipalities Act and some
> don't. But when it comes to names on maps we should be more concerned with
> toponyms and not official names. The use of "City of ", "Town of ", etc is
> very rare in toponyms.  Here is a query on the Canadian Geographic Names
> Database searching for the term "of" in the "populated places" category -
> http://www4.rncan.gc.ca/search-place-names/search?q=
> of%5B%5D=985=O
>
> I only see two examples that include "City of ", "Town of ", etc across
> the entire country:
> City of Brant, ON
> Village of Queen Charlotte, BC
>
> Bernie.
>
> On Mon, Feb 12, 2018 at 7:45 PM, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
>
>> I smell a harmonization with admin_level...not that there's anything
>> wrong with that.
>> SteveA
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
>
> --
> Bernie Connors
> New Maryland, NB
>
> ___
> 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] Formatting of Municipality Names

[James]

i believe "city of" is redundant as its a classification vs a name.

Would we say "village of maniwaki"? nope.

On Feb 12, 2018 5:51 PM, "Matthew Darwin"  wrote:

> Hi,
>
> I am now reviewing the *addr**:city* tag.   Seems we are not very
> consistent how we use it.  For example, Toronto:
>
>  110707 City of Toronto
>9603 Toronto
>   4 North York, Toronto
>   2 Toronto, ON
>   2 toronto
>   1 York, Toronto
>   1 Torontoitalian
>   1 Toronto;City of Toronto
>   1 Toronto
>
> Which is correct?  "*City of **Toronto*" or "*Toronto*"?   I would think
> "Toronto"???   Why do people pick one over the other?
>
> There are more than 7000 unique names in Canada.  Below are the top 50.
> Ottawa is not on the top of the list because there was a local decision to
> not include the addr:city tag during address addition as there there are
> many different "city" names since almagamation. (The official Canada Post
> address still has the old municipality name prior to amalgamation while the
> City of Ottawa works through de-duplicating street names).
>
>  110707 City of Toronto
>  100066 Gatineau
>   82606 Montréal
>   79191 Surrey
>   71932 Edmonton
>   51096 Québec
>   45716 City of Hamilton
>   37232 Mississauga
>   35763 Laval
>   32029 Dartmouth
>   30969 Kamloops
>   27234 City of London
>   25393 City of Brampton
>   22881 Municipality of Chatham-Kent
>   18534 Saguenay
>   17921 Lévis
>   17251 City of Vaughan
>   16929 City of St. Catharines
>   16796 Town of Markham
>   16592 City of Kawartha Lakes
>   16403 Trois-Rivières
>   16086 City of Thunder Bay
>   15788 Oakville
>   15335 Sherbrooke
>   14787 City of Niagara Falls
>   14338 Norfolk County
>   13966 City of Kingston
>   13939 Fredericton
>   12085 City of Oshawa
>   11966 Saanich
>   11950 Calgary
>   11382 Terrebonne
>   11332 Richmond Hill
>   11321 City of Barrie
>   11080 Town of Fort Erie
>   10986 Cole Harbour
>   10981 City of Burlington
>   10641 Town of Whitby
>   10635 Saint-Jean-sur-Richelieu
>   10455 Drummondville
>   10347 City of Guelph
>9906 Municipality of Clarington
>9666 City of Brantford
>9603 Toronto
>9487 Shawinigan
>9384 City of Sarnia
>9380 Red Deer
>9102 City of Windsor
>9044 City Of Sault Ste. Marie
>8466 Sudbury
>
>
> --
> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.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] Postal Code cleanup

[James]

Canapost uses

A#A #A#

Seeing as they were trying to copyright it's usage (see lawsuit vs
geocode.ca) I think thats the format we should use

On Feb 7, 2018 8:02 PM, "Matthew Darwin"  wrote:

Hi all,

Below are the 10 top postal code formats in Canada as seen in
*addr:postcode*. When I get bored of tidying up phone numbers, I'll tackle
some postal codes.

I hope we can all agree that "A#A #A#", which is the most popular, is the
correct format that should be used.  The ones that just have 'A#A' (the
"Forward Sortation Area") I will leave as well.   There are more than 60
unique formats in use today and funny enough I see phone numbers in the
postal code field arrh!

I am open to comments/suggestion on this, as always.

  20271 'A#A #A#'
   1454 'A#A#A#'
 96 'a#a#a#'
 37 'A#A #A# '
 29 'a#a #a#'
 28 'A#A'
 24 'A#A #a#'
 23 'AA A#A #A#'
 17 'A#A-#A#'
 12 'A#A #A#'

___
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] Buildings in Montreal

[James]

https://i.imgur.com/CaBiPKW.png

I can see what Charles was saying about the linesits going to be such a
PITA to 1. Convert DWG to say geojson and 2. Try to make polygons out of
these lines. It would almost be quicker to process the LIDAR and extract
buildings from that

That map is useful for spotting missing buildings

On Jan 30, 2018 4:43 PM, "john whelan" <jwhelan0...@gmail.com> wrote:

> Thanks so I can see areas without buildings.  We need to think about
> importing those either from NRC data or Montreal's Open Data.  I don't
> think the NRC data is ready yet.
>
> Note to James from a technical point of view any suggestions?
>
> Thanks John
>
> On 30 January 2018 at 13:10, Pierre Choffet <p...@wanadoo.fr> wrote:
>
>> Le 30/01/2018 à 11:23, Charles Basenga Kiyanda a écrit :
>> > What we're missing is manpower. Doing an automated
>> > import would be quite arduous. We're not sure where to start in order to
>> > take the dwg data and automatically reconstruct closed polygons that
>> > correspond to individual buildings.
>> Contributeurs motivés par le dessin bâtiment par bâtiment, vous pouvez
>> utiliser le fond présent sur la carte d'évaluation des données de la
>> ville¹ que nous avions mis en ligne (activez la couche Bâtiments via le
>> menu en haut à droite).
>>
>> 1 : http://carte.osmqc.ca/montreal/
>>
>> Pierre
>>
>>
>>
>> ___
>> 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] Buildings in Montreal

[James]

sorry, they do have buildings. but its combined with a bunch of other
things in DWG format called "Cartographie de base"

On Jan 30, 2018 8:34 AM, "James" <james2...@gmail.com> wrote:

they seem to only have addresses and lidar.

On Jan 30, 2018 8:30 AM, "john whelan" <jwhelan0...@gmail.com> wrote:

> But do they have a buildings outline file?
>
> Thanks John
>
> On 30 Jan 2018 7:52 am, "James" <james2...@gmail.com> wrote:
>
>> I was looking at license on the montreal site and they even say for OSM
>> to use their data:
>>
>> http://donnees.ville.montreal.qc.ca/portail/license/
>> (scroll down)
>>
>> On Jan 30, 2018 6:57 AM, "john whelan" <jwhelan0...@gmail.com> wrote:
>>
>>> Since Montreal would appear to have an acceptable licence and Open Data
>>> does it have a building outline file that technically could be imported?
>>>
>>> The second part would be does it have local mappers who would be willing
>>> to support such an import?
>>>
>>> On the more technical side I would imagine it would need to be done in
>>> sections and I'm unsure how many buildings are already mapped.  The more
>>> there are the more complex the import would be.
>>>
>>> Thanks 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

Re: [Talk-ca] Buildings in Montreal

[James]

they seem to only have addresses and lidar.

On Jan 30, 2018 8:30 AM, "john whelan" <jwhelan0...@gmail.com> wrote:

> But do they have a buildings outline file?
>
> Thanks John
>
> On 30 Jan 2018 7:52 am, "James" <james2...@gmail.com> wrote:
>
>> I was looking at license on the montreal site and they even say for OSM
>> to use their data:
>>
>> http://donnees.ville.montreal.qc.ca/portail/license/
>> (scroll down)
>>
>> On Jan 30, 2018 6:57 AM, "john whelan" <jwhelan0...@gmail.com> wrote:
>>
>>> Since Montreal would appear to have an acceptable licence and Open Data
>>> does it have a building outline file that technically could be imported?
>>>
>>> The second part would be does it have local mappers who would be willing
>>> to support such an import?
>>>
>>> On the more technical side I would imagine it would need to be done in
>>> sections and I'm unsure how many buildings are already mapped.  The more
>>> there are the more complex the import would be.
>>>
>>> Thanks 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

Re: [Talk-ca] Buildings in Montreal

[James]

I was looking at license on the montreal site and they even say for OSM to
use their data:

http://donnees.ville.montreal.qc.ca/portail/license/
(scroll down)

On Jan 30, 2018 6:57 AM, "john whelan"  wrote:

> Since Montreal would appear to have an acceptable licence and Open Data
> does it have a building outline file that technically could be imported?
>
> The second part would be does it have local mappers who would be willing
> to support such an import?
>
> On the more technical side I would imagine it would need to be done in
> sections and I'm unsure how many buildings are already mapped.  The more
> there are the more complex the import would be.
>
> Thanks 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

Re: [Talk-ca] Preferred phone number format

[James]

personally I prefer:

RFC 3966/NANP  pattern

as its more commonly used for telephone numbers(less the country
code(unless long distance). Especially in white pages(back in the day we
had paper copies)

On Jan 28, 2018 8:24 PM, "Matthew Darwin"  wrote:

> Hi all,
>
> Is there a preferred phone number format we use in Canada?
>
> I noticed a bunch of phone numbers in Ottawa don't follow the
> recommendations in https://wiki.openstreetmap.org/wiki/Key:phone, namely:
>
>- phone=*number* where the *number* should be in international (ITU-T
>E.164 ) format
>   - phone=+  , following the ITU-T
>   E.123  and the DIN 5008
>    pattern
>   - (phone=+--, following the
>   RFC 3966/NANP  pattern)
>
> Is there a preference which of these formats is used?   Can anyone run a
> query and see which is more popular in the country?
>
> The reason I'm asking is that since a bunch of phone numbers leave off the
> +1 (and have other errors), I want to align them to the recommended
> format.   I am wondering if I should have them in the format of "+1 999 555
> 1234" or "+1-999-555-1234".If there is no existing preference adopted
> in OSM Canada, I will use the latter to cleanup the non-compliant phone
> numbers.
>
> Comments?
>
> I am also assuming we prefer "phone" over "contact:phone" as per
> https://wiki.openstreetmap.org/wiki/Key:contact
>
> ___
> 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] BC2020 OD_tables wiki and project status

[James]

LWG blog post about CC-BY

https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

as long as you have explicit permission to add data from city. It become
compatible.
I used "may" as in "should remain on the list because explicit permission
was already obtained."

On Jan 28, 2018 5:53 PM, "OSM Volunteer stevea" <stevea...@softworkers.com>
wrote:

On Jan 28, 2018, at 2:39 PM, James <james2...@gmail.com> wrote:
> CC Attribution is compatible with explicit permission, so Gatineau and
Montreal may remain on the list.

Oh, how I sometimes dislike the word "may!"

I know, I know, our good talk-ca dialog intends to help wider understanding
and consensus.  This can be challenging, lengthy, repeat-oriented /
loquacious and seem like it runs in circles!  It gets better.

James, I hereby ask you to change status from red to green once you know.
Perhaps also undo the strikeout type (delete the  brackets in the
markup language) in Contributors for those two cities, too (updating the
one or two lines of text it takes to do that).  That goes for anybody
posting here and/or reading this.

To all, wiki what you know, please!  Though, sometimes, conversations here,
or in email, or "in the map" or... are more appropriate.

I'm saying "wiki when wiki is right."

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

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[James]

CC Attribution is compatible with explicit permission, so Gatineau and
Montreal may remain on the list.

On Jan 28, 2018 5:20 PM, "OSM Volunteer stevea" 
wrote:

> On Jan 28, 2018, at 1:27 PM, Matthew Darwin  wrote:
> > Steve A,
> > I suspect nobody fully knows the current status of licences... So I
> would agree with the action that you wrote:
> > every city except for Ottawa rightfully should be removed to end the
> confusion, updating both wikis.
>
> OK, now done.
>
> In Contributors, following the existing example of Toronto, I have used
> strikeout type.  To be clear, I ONLY did this for eight of the ten
> "Canadian Municipalities" listed there, leaving Ottawa in plain type
> indicating "Contains information licensed under the Open Government Licence
> – City of Ottawa." and its embedded link.  (I left Yellowknife yellow, it
> is 100% done, that may or may not be the correct color, it might be red).
> I did NOT change Canadian Provinces (of which British Columbia is the only
> one listed) nor Natural Resources Canada.  Whew.
>
> PLEASE, I ask others to double- or triple- or multiple-check me here!  Do
> these (local licenses in Canada) reflect the current state of reality?  We
> (here in talk-ca) believe they do, we (OSM) welcome any updates directly to
> the Contributors wiki.  Thank you.
>
> In the BC2020 OD wiki, they are all red except for Ottawa, which remains
> green and Yellowknife which remains yellow as it is 100% done, though it
> may be conflation for me to be thinking that way and perhaps it goes red,
> meaning, license not approved.  Hm, Yellowknife to red but left as done,
> both true apparently.  Uh
>
> This does lead to (at least me asking) "hm, how did 80% done get into
> Edmonton and Yellowknife 100%, I'll leave that alone for now.  (I'm
> guessing "via Bing or other visual layer, and JOSM and maybe a plug-in and
> a toolchain and so on...).  Two separate issues:  local licenses and "how
> much is done anyway."  I'm putting pieces together, disassembling
> stovepipes, as it were.  A wider (than Canada) OSM community does better
> understand some status via our wiki.
>
> It is likely that we simply need a total run-through of what is
> everybody's understanding up and down our wiki, toolchains, processes,
> lines of communication, etc.  A sort of thing that is done on a talk page
> and via wikis.  It appears to be a national conversation.
>
> Steady ahead.
>
> SteveA
> ___
> 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] BC2020 OD_tables wiki and project status

[James]

*Denis and I. No usb was shared, only a datafile for download.

On Jan 28, 2018 3:18 PM, "john whelan" <jwhelan0...@gmail.com> wrote:

The Ottawa building outlines were identified as a possibility by Tracey at
a meeting between Stats Can City of Ottawa and a few people from OSM plus a
few others by phone who had done something similar.

Most of the enriching of OSM from Ottawa's Open Data came through their
portal such as the GTFS file.  Martin and James have done most of the work
integrating what they could find.

Once we had the license lined up then I understand the building outline
file was supplied separately to the Open Data portal but with the same
licence.  I think James would know if it came on a USB stick or not.

The Stats Can building project has had a lot of interest from
municipalities.  I think Kingston was very keen.  Its value is the mixture
of Open Data and the enrichment that comes from the OSM side to give the
number of levels etc.

TB are supposed to have an Open data kit for municipalities real soon now
and that is supposed to include information about the TB 2.0 Open Data
Licence that Ottawa is using.

Cheerio John

On 28 January 2018 at 14:42, Jonathan Brown <jonab...@gmail.com> wrote:

> Okay, I know the Open Data folks and Open Government folks in Ontario.
> It’s their job to connect to and support the data stewards within
> government who are releasing data through the Open Data Portal. The federal
> open government folks are holding a meeting in Toronto this Monday where
> the provincial and city folks are likely to be in attendance. I can raise
> this licensing issue and how this is a barrier to crowdsourcing and citizen
> science, something that they are keen on embracing. It would be good to
> show them a working example. Has the BC2020i OSM data been integrated into
> the Ottawa Open Data Portal?
>
>
>
> Jonathan
>
>
>
> *From: *john whelan <jwhelan0...@gmail.com>
> *Sent: *Sunday, January 28, 2018 2:29 PM
> *To: *Jonathan Brown <jonab...@gmail.com>
> *Cc: *talk-ca@openstreetmap.org
> *Subject: *Re: [Talk-ca] BC2020 OD_tables wiki and project status
>
>
>
> If you map from Bing imagery there is no issue.  If you do map from Bing
> please use the building_tool plugin in JOSM.  We tend to find new mappers
> using iD are not very accurate.
>
> If the city has an Open Data file of the building outlines then it must be
> available under a licence that OpenStreetMap can accept.  Part of the
> problem is you can use OpenStreetMap for anything.
>
> The Canadian Federal Government noticed there were problems with their
> Open Data licence for OpenStreetMap amongst others they came up with
> version 2.0.  Ottawa was the first municipality to adopt the new license
> and it took about five years to get it sorted out from start to finish.
>
> I was involved in the original import and was under the impression that
> since we were importing CANVEC data and that was available under the 2.0
> license that the municipal equivalent license was acceptable. Some Stats
> Canada addresses had been imported from the TB open data portal in Toronto
> and they were under the same impression.
>
> It became apparent that the CANVEC imports were not done under the 2.0
> license in OSM's eyes.
>
> The TB 2.0 and the Ottawa Open Data license was referred to the LWG for
> their opinion.  Their opinion was they were acceptable.  However they
> wished to view any other Open Data licenses in Canada before giving their
> benediction.
>
> Some Open Data licenses say and if we don't like what you are doing you
> must remove our data.  This is an example on something that OSM would find
> unacceptable.
>
> Once the outlines are in place then other tags can be added.
>
> Cheerio John
>
>
>
> On 28 January 2018 at 13:50, Jonathan Brown <jonab...@gmail.com> wrote:
>
> If we have a description of the scope of the work involved in updating the
> BC2020 OD tables, I don’t mind trying to find some senior students who
> could be trained to take on this task for locations in Ontario. It would be
> a very small start, of course. Also, can someone explain to me the
> licensing issue? How do datasets released under the open government license
> not meet the legal requirements of the OSM license?
>
>
>
> 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

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[James]

not only that but sometimes they add things that make it more or less
compatible(previously bc and their unique privacy or something else)

On Jan 28, 2018 2:14 PM, "OSM Volunteer stevea" <stevea...@softworkers.com>
wrote:

> On Jan 28, 2018, at 10:50 AM, Jonathan Brown <jonab...@gmail.com> wrote:
> > If we have a description of the scope of the work involved in updating
> the BC2020 OD tables, I don’t mind trying to find some senior students who
> could be trained to take on this task for locations in Ontario. It would be
> a very small start, of course. Also, can someone explain to me the
> licensing issue? How do datasets released under the open government license
> not meet the legal requirements of the OSM license?
>
> Then, On Jan 28, 2018, at 10:57 AM, James <james2...@gmail.com> wrote:
> > license is federal, cities must modify it to apply to municipal, thus
> creating new license
>
> SO, please ladies and gentleman, "figure out" what your licensing status
> is, and document it.  First in https://wiki.osm.org/wiki/
> Contributors#Canadian_Municipalities where it is now said these entries
> are incorrect (except for Ottawa).  Second in https://wiki.osm.org/wiki/
> WikiProject_Canada/Building_Canada_2020/building_OD_tables, which now
> refers back to that page in all the "green" cells.
>
> This is what OSM (partly) is:  documenting in a wiki (for all to see and
> share in the knowledge of) the status of licensing, a link to an Import
> Plan, helpful steps to take when you get stuck and don't know what to do, a
> place to propose streamlined or improved methodology, a way to capture the
> status of a project (whether with or without Task Manager links) perhaps
> using red/yellow/green color-coded cells, or cells that have "80% done" in
> them, as appropriate, et cetera.
>
> The "scope of the work involved in updating the BC2020 OD tables" is not
> hard, it is this:
>
> 1)  View OD_tables wiki (the second link above)
> 2)  Click the Log In link (upper right) and enter your OSM wiki
> credentials (different than your OSM credentials)
> 3)  Click the Edit Source link (ditto), I don't recommend the
> usually-more-friendly-user-interface Edit link, as you are editing TABLES
> here, and (in my opinion) our wiki's raw (lightweight, relatively easy)
> markup language is the only sane choice here to edit table data entries
> 4)  Edit the table data for each cell which is now green (yes), but which
> should be red (no) or perhaps something in the middle, yellow (partial).
> There are 11 colored cells now, 7 are green, 4 are yellow.  It seems 1
> should be green (Ottawa) and therefore left alone, but the other ten should
> be changed to red or yellow.  So, GO!
>
> OTHERS reading this list (not me!) must properly decide what these
> colors/statuses are, as I'm merely some guy in the USA who wants to see the
> project go forward, but the licenses, and importantly, their statuses as
> communicated to the rest of OSM via the Contributors page and the
> WikiProject BC2020 OD tables page are now confused/outdated/wrong and so
> these must be updated so they are correct for 2018, now and going forward.
>
> > I offer to "change from green to red" wiki table status for all cities
> (except Ottawa), although I'd also like to see Contributors be updated
> (with only Ottawa) as I suggest.  Teamwork, anybody?  Simply to keep our
> project-wide communication current?  It's neither difficult nor
> time-consuming and shares present status with "the rest of us."
>
> And my offer still stands, I just have no clue what is going on with these
> licenses.  Does anybody here?  Please, let's not kick this into "well, it's
> sorta lost in the LWG..." unless that is REALLY true.  It seems this is a
> Canadian initiative to move forward with these and I'm left with little to
> do from here to push it forward any differently than I have been.
>
> Thank you,
> SteveA
> California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[James]

license is federal, cities must modify it to apply to municipal, thus
creating new license

On Jan 28, 2018 1:52 PM, "Jonathan Brown"  wrote:

> If we have a description of the scope of the work involved in updating the
> BC2020 OD tables, I don’t mind trying to find some senior students who
> could be trained to take on this task for locations in Ontario. It would be
> a very small start, of course. Also, can someone explain to me the
> licensing issue? How do datasets released under the open government license
> not meet the legal requirements of the OSM license?
>
>
>
> Jonathan
>
>
>
>
>
> *From: *talk-ca-requ...@openstreetmap.org
> *Sent: *Sunday, January 28, 2018 7:00 AM
> *To: *talk-ca@openstreetmap.org
> *Subject: *Talk-ca Digest, Vol 119, Issue 16
>
>
>
> Send Talk-ca mailing list submissions to
>
> talk-ca@openstreetmap.org
>
>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> or, via email, send a message with subject or body 'help' to
>
> talk-ca-requ...@openstreetmap.org
>
>
>
> You can reach the person managing the list at
>
> talk-ca-ow...@openstreetmap.org
>
>
>
> When replying, please edit your Subject line so it is more specific
>
> than "Re: Contents of Talk-ca digest..."
>
>
>
>
>
> Today's Topics:
>
>
>
>1. weeklyOSM #392 2018-01-16-2018-01-22 (weeklyteam)
>
>2. Re: BC2020 OD_tables wiki and project status
>
>   (OSM Volunteer stevea)
>
>
>
>
>
> --
>
>
>
> Message: 1
>
> Date: Sat, 27 Jan 2018 08:21:47 -0800 (PST)
>
> From: weeklyteam 
>
> To: talk-ca@openstreetmap.org
>
> Subject: [Talk-ca] weeklyOSM #392 2018-01-16-2018-01-22
>
> Message-ID: <5a6ca71b.d4951c0a.8ae59.9...@mx.google.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> The weekly round-up of OSM news, issue # 392,
>
> is now available online in English, giving as always a summary of all
> things happening in the openstreetmap world:
>
>
>
> http://www.weeklyosm.eu/en/archives/9884/
>
>
>
> Enjoy!
>
>
>
> weeklyOSM?
>
> who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages
>
> where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-
> produced-in_56718#2/8.6/108.3
>
>
>
> --
>
>
>
> Message: 2
>
> Date: Sat, 27 Jan 2018 12:41:23 -0800
>
> From: OSM Volunteer stevea 
>
> To: "Stewart C. Russell" , talk-ca
>
> 
>
> Subject: Re: [Talk-ca] BC2020 OD_tables wiki and project status
>
> Message-ID: <1145fd9b-205b-4d3d-a8c8-0b2f5846a...@softworkers.com>
>
> Content-Type: text/plain;charset=utf-8
>
>
>
> On Jan 26, 2018, at 8:12 PM, Stewart C. Russell  wrote:
>
> > On 2018-01-26 09:56 PM, OSM Volunteer stevea wrote:
>
> >> What I did was to "back-populate" the list of "approved" (by whom?
> when?  how did these get here?) list of Canadian cities from
>
> >> https://wiki.osm.org/wiki/Contributors#Canadian_Municipalities into
> OSM's BC2020 wiki.
>
> >
>
> > These are very old and pre-date the formal import documentation process.
>
> > The Toronto permission e-mail from 2011 or so amounted to not much more
>
> > than “Sure ;-)” [smiley included in original]. I don't think the process
>
> > would pass muster now.
>
>
>
> OK, so "correct" is to immediately remove from https://wiki.osm.org/wiki/
> Contributors#Canadian_Municipalities EVERY SINGLE CITY (except Ottawa).
> If it was an error to list them then, (that's what I read above) it is an
> error to list them now.  Anyone with an OSM wiki account can do this — and
> now, someone should, preferably someone in Canada with a sense of ownership
> that this process of entering additional Canadian cities into Contributors
> went awry.  This could be a majority of people reading this post:  any
> takers?
>
>
>
> > Unfortunately, none of us are lawyers, the OSMF's lawyers are very busy
>
> > and naturally conservative, and slogging through licence work (and
>
> > myriad outdated wiki pages) is no fun for anyone, least of all
> volunteers.
>
>
>
> Some of us are lawyers (I'm not), though any OSM volunteer should strive
> to "do the right things," especially in matters related to "proper
> licensing."  Proper OD licensing is one task which has emerged as an
> "obstacle" (so documented in WikiProject BC2020) from the desire to see
> continuing project forward momentum.
>
>
>
> To go forward, if wiki pages are outdated (and Stewart says above that
> they are), well, please update outdated wiki pages.  You don't have to be a
> lawyer to do that, especially as the data are known to be outdated or
> wrong.  "Slogging through license work," partly DOES require being a lawyer
> (at least within OSM's LWG) and for the project to go forward, yes, that is
> a longer-term task to complete.  (I hesitate to say