Re: [Talk-ca] Ça reste ouvert

[Martin Chalifoux via Talk-ca]

Je suis plutôt d’accord avec James. C’est bien du travail pour quelque chose de 
temporaire. Les gens regarderont Google de toute manière. Si le but est de 
recruter des mappers vaudrait mieux leur faire faire quelque chose qui a une 
valeur durable dans le temps. OSM est simplement pas un outil pensé pour les 
choses temporaires tel que le traffic ou ces choses. De plus une tonne de 
mappers junior qui débarque veut généralement dire plein de merdouille à 
corriger par la suite...

Je suis certain que Google fait les choses d’une manière à ce qui quand les 
fermetures finissent il pressent un bouton et leur BD revient a la normale.

Enfin mon choix personnel est de construire pour le long terme. Bidouiller pour 
le court terme m’intéresse pas. 

De grâce faites en sorte que ça vient pas interférer avec l’usage habituel de 
la BD OSM.

Bonne chance.

> On Apr 10, 2020, at 07:36, James  wrote:
> 
> 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 > > 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  
>> mailto: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 
>> 

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

[Martin Chalifoux via Talk-ca]

I agree with you in principle. And I know for a fact that statistics and 
studies done in universities are very useful to justify new infrastructures.  
But concretely I don’t see the parallel. Great things were done for the cycling 
infrastructure and it came a long way. The OSM map is not a mess because of it. 
  The ways were not all duplicated three times to show a bike can ride on a 
street. I and others are just questioning if what is being done now is the way 
to go. Now is the time to do that before it perhaps becomes too late because 
there is no undo or redo button.

> On Apr 3, 2020, at 16:50, Pierre-Léo Bourbonnais  wrote:
> 
> Be very careful here, as universities and non-profit organizations did 
> support and encourage better cycling and pedestrian infrastructure. There are 
> a great amount of traffic calming and cycling path construction that were 
> justified by research projects. Without precise data in OpenStreetMap, it is 
> very difficult to justify such projects with the governments. Also, people 
> that needs universal accessibility greatly benefit from precise pedestrian 
> data (wheelchairs, deaf or blinded people).
> 
> Universities and researchers are your allies here.
> 
> Because of hard work by a lot of researchers in the transportation domain, we 
> can save lives (vision Zero for instance) and increase overall security in 
> urban and rural environement. That is not superfluous at all.
> 
> The more data we have when presenting to elected officials and governemnt 
> agencies, the more we can justify cycling paths and sidewalk construction. 
> Without good complete and precise data, they will not even listen to us.
> 
> 
> 
>> On Apr 3, 2020, at 16:39, Pierre Boucher > <mailto:pbouc...@lavoile.com>> wrote:
>> 
>> Martin
>> 
>> Envoyé par BlueMail <http://www.bluemail.me/r?b=15824>
>> Le 3 avr. 2020, à 16:26, Martin Chalifoux via Talk-ca 
>> mailto:talk-ca@openstreetmap.org>> a écrit:
>> 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 >> <mailto:bike...@gmail.com>> 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
>>> Plann

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

[Martin Chalifoux via Talk-ca]

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 <https://www.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 explicit

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

[Martin Chalifoux via Talk-ca]

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. I however found a bit of that 
scheme in San-Francisco.  I am not sure where this idea is coming from, who is 
backing this implementation and who it does service to, but it sure is a mess 
in many ways. And when the people adding that stuff will go away, who will 
maintain that complexity, the volunteers ? The use of tags as you suggest would 
be much cleaner and easier. The OSM database is used by a large community of 
navigation apps that will all have to deal with this one way or another to 
still provide meaningful navigation prompts that are not just like “walk on 
path, in 100m turn left on path, in 300m turn right on path", perhaps by 
filtering out these ways from their apps, I really don’t know. Otherwise 
everybody will move to Google Maps which sure won’t bother with that stuff. 
Anyhow, have to go back to self-quarantine, I feel a fever :-)

Happy mapping.

> On Apr 3, 2020, at 13:15, Niels Elgaard Larsen  wrote:
> 
> Martin Chalifoux via Talk-ca:
>> It is not hard Justin, just inadequate. The app then tell you “turn right on 
>> path”
>> rather than “turn right on Main Street”. Close enough.
>> 
>> I was assuming pedestrians can figure to use a sidewalk without it being 
>> added to a
>> map, but maybe that’s more difficult than I’d assumed.
> 
> 
> Routing software might prefer roads with sidewalks.
> 
> And if there is only sidewalks on one side of the road that might make a 
> difference
> for routing.
> 
> But that is why we can tag roads with sidewalk=both/left/right
> 
> Which I think is most of the time a much better solution.
> 
> I have had to change or delete a lot of individual sidewalks in Canada 
> because of
> topology problems. But there is still a lot left.
> 
> For example:
> https://www.openstreetmap.org/way/138463840
> and all the other sidewalks next to it.
> 
> These sidewalks are not connected to anything. And that is a big problem.
> If you start your walking journey from inside one of these blocks, you will 
> not go
> anywhere because the router will know that you are on a way that is not 
> connected to
> anything. No route to destination.
> Or you get routes like this:
> https://www.openstreetmap.org/directions?engine=graphhopper_foot=42.99484%2C-81.18224%3B42.99590%2C-81.18204#map=18/42.99581/-81.17946
> 
> I have experienced this IRL and it is very frustrating.
> 
> Ottawa is better.
> But consider a route like this:
> https://www.openstreetmap.org/directions?engine=graphhopper_foot=45.38337%2C-75.64155%3B45.38313%2C-75.64109
> 
> That is not how you would actually visit you neighbor.
> Adding a lot of driveways or paths connecting the sidewalk to the road helps.
> But most real users would not let one meter of grass stop them from crossing 
> the road.
> 
> -- 
> Niels Elgaard Larsen
> 
> ___
> 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

[Martin Chalifoux via Talk-ca]

Sure. Kids however do not use OSM and maps and routing. So what should OSM do 
for it’s users ?

> On Apr 3, 2020, at 11:43, James  wrote:
> 
> 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,  <mailto:j3tra...@gmail.com>> 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  <mailto: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 > <mailto:j3tra...@gmail.com>> 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 
>> mailto: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 >> <mailto:bike...@gmail.com>> 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.  

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

[Martin Chalifoux via Talk-ca]

It is not hard Justin, just inadequate. The app then tell you “turn right on 
path” rather than “turn right on Main Street”. Close enough.

I was assuming pedestrians can figure to use a sidewalk without it being added 
to a map, but maybe that’s more difficult than I’d assumed.

> On Apr 3, 2020, at 11:36, 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  <mailto: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 > <mailto:j3tra...@gmail.com>> 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 
>> mailto: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 >> <mailto:bike...@gmail.com>> 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 cours

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

[Martin Chalifoux via Talk-ca]

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 
> mailto: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 > <mailto:bike...@gmail.com>> 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, 
>>>> mailto:talk-ca@openstreetmap.org>> 

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

[Martin Chalifoux via Talk-ca]

Take ORS as an example in bicycle mode. If you happen to pick any sidewalk when 
clicking your route points it will route to the sidewalks. Since the sidewalk 
and street ways are so close this happen all the time unless you totally 
zoom-in to add any routing point . If the sidewalk had bicycle=no I am not sure 
if it would just snap to the closest allowed street but I would think so. Of 
course if you don’t add any intermediate points and you only route from A to B 
this won’t happen, but in real life cyclist do more complex routes than this 
when planning a trip or ride.

> 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 
> 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, 
>>> mailto:talk-ca@openstreetmap.org>> wrote:
>>> Hi!
>>> 
>>> I would like to start a discussion on how we should deal with sidewalks 
>>> tagged separately, like it is is done in downtown Ottawa and like we are 
>>> starting to do in the Montreal region.
>>> 
>>> The issue is that by default highway=footway with or without 
>>> footway=sidewalk should have an implicit bicycle=no by default according to 
>>> this page: 
>>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions
>>>  
>>> 
>>> 
>>> However, some osm users told me I should tag them with bicycle=no 
>>> everywhere because routing engines use sidewalks for bicycle routing which 
>>> is illegal in most part of Canada.
>>> 
>>> What are your thoughts on this ? Should we adapt to routing engines or 
>>> should routing engines fix the issue themselves?
>>> 
>>> Thanks!
>>> 
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> 
>>> 
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> 
>> 
>> -- 
>> Sent from Postbox 
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> 
> ___
> 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

[Martin Chalifoux via Talk-ca]

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 
> 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, 
>>> mailto:talk-ca@openstreetmap.org>> wrote:
>>> Hi!
>>> 
>>> I would like to start a discussion on how we should deal with sidewalks 
>>> tagged separately, like it is is done in downtown Ottawa and like we are 
>>> starting to do in the Montreal region.
>>> 
>>> The issue is that by default highway=footway with or without 
>>> footway=sidewalk should have an implicit bicycle=no by default according to 
>>> this page: 
>>> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions
>>>  
>>> 
>>> 
>>> However, some osm users told me I should tag them with bicycle=no 
>>> everywhere because routing engines use sidewalks for bicycle routing which 
>>> is illegal in most part of Canada.
>>> 
>>> What are your thoughts on this ? Should we adapt to routing engines or 
>>> should routing engines fix the issue themselves?
>>> 
>>> Thanks!
>>> 
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> 
>>> 
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> 
>> 
>> -- 
>> Sent from Postbox 
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> 
> ___
> 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] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

Ce que tu as fait me semble une bonne idée. Il me semble que ce que j’avais 
crée était une ligne et non une surface, mais c’était une ligne fermée alors 
possiblement que certains engins l’interprète différemment. De scinder une 
ligne fermée est toujours une bonne idée, il y a deja eu des problèmes par 
exemple avec des boundary si ils étaient d’une seule ligne fermée et il fallait 
les briser.

Le sens du waterway visait plus a indiquer le sens du sentier qui est horaire 
si ma mémoire est bonne (le sens qu’ils veulent que les embarcations 
circulent), et non le courant. Mais il y  a aucune convention là-dessus donc ça 
pas d’importance et le courant ça va.

J’ai ce-matin remarqué que toutes les iles problématiques touchaient une meme 
zone wetland. Alors je l’ai brisée en deux parties et on verra si ça change 
quelle iles sont mal rendues. 

Je peux recoompiler avec mkgmap demain matin.

> On Mar 31, 2020, at 17:11, Pierre Béland  wrote:
> 
> Nouvelle tentative, cette fois-ci avec le Sentier Nautique balisé 
> (way=578081572).  Pour décrire cet itinéraire, Martin avait créé  un polygone 
> encerclant les îles avec clé waterway=canal. 
> 
> Si on y regardes de plus près en sélectionnant le style humanitaire avec zoom 
> zone élargie, les contours de la zone bleu suivent le sentier nautique sauf 
> aux extrémités où j'ai légèrement déplacé les noeuds.
> 
> J'ai scindé le chemin en deux sections qui maintenant chacune suit le sens du 
> courant + attribut waterway=fairway
> Selon la façon que ce sentier est balisé, il serait possible d'ajouter la clé 
> seamark:type
>  
> 2ième section Sentier Nautique balisé (way=786356588)
> 
> 
> Pierre 
> 
> 
> Le lundi 30 mars 2020 09 h 17 min 55 s UTC−4, Pierre Béland via Talk-ca 
>  a écrit :
> 
> 
> 
> Indication aussi qu'il y a encore des problèmes avec les limites territoire 
> et parc, malgré mes modifications hier soir, recherche Nominatim :> parc 
> national des îles-de-boucherville
> ne retrouve pas correctement les limites de Boucherville. 
> Donne plutôt : Zone protégée Parc national des Îles-de-Boucherville, Rue 
> Sainte Anne, Pointe-aux-Trembles, Rivière-des-Prairies–Pointe-aux-Trembles, 
> Montréal, Agglomération de Montréal, Montréal (06), Québec, H1B 3C7, Canada 
> 
>  
> Pierre 
> 
> 
> Le lundi 30 mars 2020 09 h 10 min 06 s UTC−4, Martin Chalifoux 
>  a écrit :
> 
> 
> Le test est pas conclent. Je constate qu’au zoom level approché c’est bugé 
> mais si je zoom out c’est correct dans Basecamp.
> ___
> 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] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

1)
>> - Fleuve Saint-Laurent, Estuaire moyen (2427871) 
>> - Fleuve Saint-Laurent, Estuaire maritime (4555382)
>> 
>> 
>> Je vais aussi scinder à Beauharnois, un endroit étroit plus facile pour 
>> scinder.
>> 
>> De cette façon, il sera beaucoup plus facile de maintenir ces relations et 
>> les Styles OSM auront moins de problème à rendre ces relations de contour. 
>> 
>>  
>> Pierre 
>> 
>> 
>> Le vendredi 27 mars 2020 13 h 13 min 48 s UTC−4, Pierre Boucher 
>> mailto:pbouc...@lavoile.com>> a écrit :
>> 
>> 
>> Il est aussi problématique sur les cartes produites par Free worldwide 
>> Garmin maps from OpenStreetMap.:-\
>> 
>> Le 2020-03-27 à 12:38, Martin Chalifoux a écrit :
>> 
>> En passant j’utilise mkgmap pour produire une map pour les Garmin Edge. Je 
>> viens de voir que ce rendu est aussi problématique. Il y a donc quelque 
>> chose de tricky avec ces iles. Je vais regarder encore plus tard.
>> 
>>> On Mar 27, 2020, at 12:36, Martin Chalifoux >> <mailto:martin.chalif...@icloud.com>> wrote:
>>> 
>> 
>> Je viens d’ajouter quelques element a la relation du fleuve st-laurent mais 
>> j’y vais avec beaucoup de précautions. Cette relation est énorme et 
>> lorsqu’on la bousille c’est une sapré bataille de la remettre en ordre. 
>> 
>>> On Mar 27, 2020, at 12:33, Pierre Béland >> <mailto:pierz...@yahoo.fr>> wrote:
>>> 
>>> Martin a révisé il y a un an Chemin : Île de la Commune (40579175)  Et de 
>>> mon côté j'ai révisé il y a 4 mois, Chemin : Île à Pinard (232592375) et me 
>>> suis assuré que les Îles soient visibles avec style principal du site osm.  
>>> Et effectivement le tout est encore ok.
>>> 
>>> A voir effectivement si le style Cyclo  a été mis a jour depuis pour cette 
>>> zone au cours de la dernière année. 
>>> 
>>> Pierre, tu peux ouvrir un ticket sur le site Github de cycloosm-carto-style 
>>> et décrire le problème
>>> 
>>> https://github.com/cyclosm/cyclosm-cartocss-style/issues 
>>> <https://github.com/cyclosm/cyclosm-cartocss-style/issues>
>>> 
>>> Par ailleurs, un contributeur a ajouté un tracé nautique circulaire bizarre 
>>> avec waterway = canal
>>> Chemin : Sentier Nautique balisé (578081572) 
>>> 
>>>  
>>> Pierre 
>>> 
>>> 
>>> Le vendredi 27 mars 2020 12 h 03 min 45 s UTC−4, Martin Chalifoux via 
>>> Talk-ca mailto:talk-ca@openstreetmap.org>> a 
>>> écrit :
>>> 
>>> 
>>> Il y avait ce bug de rendu sur openstreetmap.org 
>>> <http://openstreetmap.org/> il y a quelques mois. Je l’ai réglé il y a un 
>>> petit bout de temps et ce rendu est maintenant correct. Quelqu’un avait 
>>> bousillé des relations. A quelle fréquence www.cyclosm.org 
>>> <http://www.cyclosm.org/> met a jour son rendu ? Se pourrait-il que ce site 
>>> rende encore une vieille copie des données OSM ? Comme openstreetmap.org 
>>> <http://openstreetmap.org/> n’a pas ce problème de rendu présentement ceci 
>>> me semble davantage un problème avec le rendering engine de cyclosm.org 
>>> <http://cyclosm.org/> que les données OSM comme tel.
>>> 
>>> Martin.
>>> 
>>> 
>>>> On Mar 27, 2020, at 11:55, Pierre Boucher >>> <mailto:pbouc...@lavoile.com>> wrote:
>>>> 
>>> 
>>> Quelqu'un peut-il régler ce problème d'affichage qui existe depuis 
>>> longtemps?
>>> J'en suis incapable.
>>> 
>>> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
>>> <https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm>
>>> 
>>> Boff II
>>> Pierre Boucher
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>>> 
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> <https://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 <http://www.lavoile.com/>
>> ...Pensez à l'environnement avant d'imprimer ce courriel !.
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca
> 

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

Re: [Talk-ca] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

; suis assuré que les Îles soient visibles avec style principal du site osm.  
>> Et effectivement le tout est encore ok.
>> 
>> A voir effectivement si le style Cyclo  a été mis a jour depuis pour cette 
>> zone au cours de la dernière année. 
>> 
>> Pierre, tu peux ouvrir un ticket sur le site Github de cycloosm-carto-style 
>> et décrire le problème
>> 
>> https://github.com/cyclosm/cyclosm-cartocss-style/issues 
>> <https://github.com/cyclosm/cyclosm-cartocss-style/issues>
>> 
>> Par ailleurs, un contributeur a ajouté un tracé nautique circulaire bizarre 
>> avec waterway = canal
>> Chemin : Sentier Nautique balisé (578081572) 
>> 
>>  
>> Pierre 
>> 
>> 
>> Le vendredi 27 mars 2020 12 h 03 min 45 s UTC−4, Martin Chalifoux via 
>> Talk-ca mailto:talk-ca@openstreetmap.org>> a 
>> écrit :
>> 
>> 
>> Il y avait ce bug de rendu sur openstreetmap.org <http://openstreetmap.org/> 
>> il y a quelques mois. Je l’ai réglé il y a un petit bout de temps et ce 
>> rendu est maintenant correct. Quelqu’un avait bousillé des relations. A 
>> quelle fréquence www.cyclosm.org <http://www.cyclosm.org/> met a jour son 
>> rendu ? Se pourrait-il que ce site rende encore une vieille copie des 
>> données OSM ? Comme openstreetmap.org <http://openstreetmap.org/> n’a pas ce 
>> problème de rendu présentement ceci me semble davantage un problème avec le 
>> rendering engine de cyclosm.org <http://cyclosm.org/> que les données OSM 
>> comme tel.
>> 
>> Martin.
>> 
>> 
>>> On Mar 27, 2020, at 11:55, Pierre Boucher >> <mailto:pbouc...@lavoile.com>> wrote:
>>> 
>> 
>> Quelqu'un peut-il régler ce problème d'affichage qui existe depuis longtemps?
>> J'en suis incapable.
>> 
>> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
>> <https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm>
>> 
>> Boff II
>> Pierre Boucher
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> <https://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 <http://www.lavoile.com/>
> ...Pensez à l'environnement avant d'imprimer ce courriel !.
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca 
> <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] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

Super. Le snapshot geofabrik apparait vers 20h. Je pourrai tester le tout tard 
ce-soir ou demain matin. Je te laisse savoir ce que ca donne. 

> On Mar 29, 2020, at 11:58, Pierre Béland  wrote:
> 
> Bonjour Martin
> 
> J'ai complété les modifications et nous avons maintenant des relations plus 
> faciles à gérer. A surveiller si ce contributeur répète de telles actions.  
> 
> En ce qui a trait aux noms, je les ai laissées uniquement pour les lacs 
> Saint-Louis et Saint-Pierre. A noter que le nom du fleuve est défini sur le 
> linéaire.  Je ne crois pas que Haut et Bas-Saint-Laurent soient mentionnés 
> dans la toponymie.
> 
> La relation 1775822 allant du Pont Samuel-de-Champlain à Sorel contient 123 
> membres, ce qui sera plus facile à gérer. J'y ai transféré les modifications 
> récentes à l'archipel des Îles de Boucherville.
> 
> Vérifie maintenant si les marais sont bien tracés dans l'Archipel des Îles de 
> Boucherville.
> 
> À surveiller ...
>  
> Pierre 
> 

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

Re: [Talk-ca] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

Merci pierre. 

Martin868


> On Mar 28, 2020, at 18:00, Pierre Béland via Talk-ca 
>  wrote:
> 
> 
> Au départ la relation 4641113 allait du Lac Ontario à Cornwall et contenait 
> quelque 450 membres.
> 
> J'ai pu consulter l'historique de la relation avec JOSM. En août 2019, YanikB 
> a ajouté les sections jusqu'à l'Île d'Anticosti, ce qui a considérablement 
> augmenté le nombre de membres, complexifié la relation et dupliquait avec 
> diverses sections existantes : Lac Saint-Louis, Lac Saint-Pierre, et les 3 
> sections de l'Estuaire à partir de Trois-Rivières.
>  
> Je vais donc poursuivre le découpage en conservant les sections qui 
> existaient avant août 2019.
> 
> Pierre 
> 
> 
> Le samedi 28 mars 2020 12 h 24 min 03 s UTC−4, Pierre Béland via Talk-ca 
>  a écrit :
> 
> 
> Simplification étape 1, j'ai réduit nombre de membres dans la relation 
> 4641113 de quelques 2200 à 1121 membres en excluant les contours déja dans 
> les relations 2426031, 2427871, 4555382.
> 
> De fait, en plus du style Cycleosm, il y a aussi des problèmes de rendu de 
> l'Archipel de Boucherville avec les styles transport et humanitaire. A voir 
> lors de la mise a jour des styles si la réduction de la taille de la relation 
> aura pour effet de corriger.
>  
> Pierre 
> 
> 
> Le vendredi 27 mars 2020 17 h 32 min 58 s UTC−4, Pierre Béland 
>  a écrit :
> 
> 
> 
> Après revérification, je constate que la Relation  4641113 est oui trop 
> complexe.Je prévois la scinder et attends vos réactions. Voici mon analyse.
> 
> J'ai vérifié la Relation  4641113 à l'aide de JOSM.  Les rôles outer sont ok 
> avec boucle fermée. Les rôles inner sont aussi ok.  Les quelques 20 chemins 
> faisant les contours des îles et marais dans l'archipel des 
> Îles-de-Boucherville sont dans la relation.
> 
> Cette relation comprend  2200 membres allant du Lac Ontario jusqu'à l'Île 
> d'Anticosti pour décrire les contours (rôles outer) et les îles (rôles 
> inner).  Le Lac Saint-Pierre est absent et les relations pour les 3 segments 
> de l'Estuaire du Fleuve après le lac Saint-Pierre font duplication
> Relations 
> 
> - Lac Saint-Pierre (1797099) 
> - Fleuve Saint-Laurent, Estuaire fluvial (2426031)
> - Fleuve Saint-Laurent, Estuaire moyen (2427871) 
> - Fleuve Saint-Laurent, Estuaire maritime (4555382)
> 
> 
> Je vais aussi scinder à Beauharnois, un endroit étroit plus facile pour 
> scinder.
> 
> De cette façon, il sera beaucoup plus facile de maintenir ces relations et 
> les Styles OSM auront moins de problème à rendre ces relations de contour. 
> 
>  
> Pierre 
> 
> 
> Le vendredi 27 mars 2020 13 h 13 min 48 s UTC−4, Pierre Boucher 
>  a écrit :
> 
> 
> Il est aussi problématique sur les cartes produites par Free worldwide Garmin 
> maps from OpenStreetMap.:-\
> 
> Le 2020-03-27 à 12:38, Martin Chalifoux a écrit :
> 
> En passant j’utilise mkgmap pour produire une map pour les Garmin Edge. Je 
> viens de voir que ce rendu est aussi problématique. Il y a donc quelque chose 
> de tricky avec ces iles. Je vais regarder encore plus tard.
> 
>> On Mar 27, 2020, at 12:36, Martin Chalifoux  
>> wrote:
>> 
> 
> Je viens d’ajouter quelques element a la relation du fleuve st-laurent mais 
> j’y vais avec beaucoup de précautions. Cette relation est énorme et lorsqu’on 
> la bousille c’est une sapré bataille de la remettre en ordre. 
> 
>> On Mar 27, 2020, at 12:33, Pierre Béland  wrote:
>> 
>> Martin a révisé il y a un an Chemin : Île de la Commune (40579175)  Et de 
>> mon côté j'ai révisé il y a 4 mois, Chemin : Île à Pinard (232592375) et me 
>> suis assuré que les Îles soient visibles avec style principal du site osm.  
>> Et effectivement le tout est encore ok.
>> 
>> A voir effectivement si le style Cyclo  a été mis a jour depuis pour cette 
>> zone au cours de la dernière année. 
>> 
>> Pierre, tu peux ouvrir un ticket sur le site Github de cycloosm-carto-style 
>> et décrire le problème
>> 
>> https://github.com/cyclosm/cyclosm-cartocss-style/issues
>> 
>> Par ailleurs, un contributeur a ajouté un tracé nautique circulaire bizarre 
>> avec waterway = canal
>> Chemin : Sentier Nautique balisé (578081572) 
>> 
>>  
>> Pierre 
>> 
>> 
>> Le vendredi 27 mars 2020 12 h 03 min 45 s UTC−4, Martin Chalifoux via 
>> Talk-ca  a écrit :
>> 
>> 
>> Il y avait ce bug de rendu sur openstreetmap.org il y a quelques mois. Je 
>> l’ai réglé il y a un petit bout de temps et ce rendu est maintenant correct. 
>> Quelqu’un avait bousillé des relations. A quelle fréquence www.cyclosm.org 
>> met a 

Re: [Talk-ca] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

En passant j’utilise mkgmap pour produire une map pour les Garmin Edge. Je 
viens de voir que ce rendu est aussi problématique. Il y a donc quelque chose 
de tricky avec ces iles. Je vais regarder encore plus tard.

> On Mar 27, 2020, at 12:36, Martin Chalifoux  
> wrote:
> 
> Je viens d’ajouter quelques element a la relation du fleuve st-laurent mais 
> j’y vais avec beaucoup de précautions. Cette relation est énorme et lorsqu’on 
> la bousille c’est une sapré bataille de la remettre en ordre. 
> 
>> On Mar 27, 2020, at 12:33, Pierre Béland > <mailto:pierz...@yahoo.fr>> wrote:
>> 
>> Martin a révisé il y a un an Chemin : Île de la Commune (40579175)  Et de 
>> mon côté j'ai révisé il y a 4 mois, Chemin : Île à Pinard (232592375) et me 
>> suis assuré que les Îles soient visibles avec style principal du site osm.  
>> Et effectivement le tout est encore ok.
>> 
>> A voir effectivement si le style Cyclo  a été mis a jour depuis pour cette 
>> zone au cours de la dernière année. 
>> 
>> Pierre, tu peux ouvrir un ticket sur le site Github de cycloosm-carto-style 
>> et décrire le problème
>> 
>> https://github.com/cyclosm/cyclosm-cartocss-style/issues 
>> <https://github.com/cyclosm/cyclosm-cartocss-style/issues>
>> 
>> Par ailleurs, un contributeur a ajouté un tracé nautique circulaire bizarre 
>> avec waterway = canal
>> Chemin : Sentier Nautique balisé (578081572) 
>> 
>>  
>> Pierre 
>> 
>> 
>> Le vendredi 27 mars 2020 12 h 03 min 45 s UTC−4, Martin Chalifoux via 
>> Talk-ca mailto:talk-ca@openstreetmap.org>> a 
>> écrit :
>> 
>> 
>> Il y avait ce bug de rendu sur openstreetmap.org <http://openstreetmap.org/> 
>> il y a quelques mois. Je l’ai réglé il y a un petit bout de temps et ce 
>> rendu est maintenant correct. Quelqu’un avait bousillé des relations. A 
>> quelle fréquence www.cyclosm.org <http://www.cyclosm.org/> met a jour son 
>> rendu ? Se pourrait-il que ce site rende encore une vieille copie des 
>> données OSM ? Comme openstreetmap.org <http://openstreetmap.org/> n’a pas ce 
>> problème de rendu présentement ceci me semble davantage un problème avec le 
>> rendering engine de cyclosm.org <http://cyclosm.org/> que les données OSM 
>> comme tel.
>> 
>> Martin.
>> 
>> 
>>> On Mar 27, 2020, at 11:55, Pierre Boucher >> <mailto:pbouc...@lavoile.com>> wrote:
>>> 
>> 
>> Quelqu'un peut-il régler ce problème d'affichage qui existe depuis longtemps?
>> J'en suis incapable.
>> 
>> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
>> <https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm>
>> 
>> Boff II
>> Pierre Boucher
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-ca 
>> <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] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

Je viens d’ajouter quelques element a la relation du fleuve st-laurent mais j’y 
vais avec beaucoup de précautions. Cette relation est énorme et lorsqu’on la 
bousille c’est une sapré bataille de la remettre en ordre. 

> On Mar 27, 2020, at 12:33, Pierre Béland  wrote:
> 
> Martin a révisé il y a un an Chemin : Île de la Commune (40579175)  Et de mon 
> côté j'ai révisé il y a 4 mois, Chemin : Île à Pinard (232592375) et me suis 
> assuré que les Îles soient visibles avec style principal du site osm.  Et 
> effectivement le tout est encore ok.
> 
> A voir effectivement si le style Cyclo  a été mis a jour depuis pour cette 
> zone au cours de la dernière année. 
> 
> Pierre, tu peux ouvrir un ticket sur le site Github de cycloosm-carto-style 
> et décrire le problème
> 
> https://github.com/cyclosm/cyclosm-cartocss-style/issues 
> <https://github.com/cyclosm/cyclosm-cartocss-style/issues>
> 
> Par ailleurs, un contributeur a ajouté un tracé nautique circulaire bizarre 
> avec waterway = canal
> Chemin : Sentier Nautique balisé (578081572) 
> 
>  
> Pierre 
> 
> 
> Le vendredi 27 mars 2020 12 h 03 min 45 s UTC−4, Martin Chalifoux via Talk-ca 
>  a écrit :
> 
> 
> Il y avait ce bug de rendu sur openstreetmap.org <http://openstreetmap.org/> 
> il y a quelques mois. Je l’ai réglé il y a un petit bout de temps et ce rendu 
> est maintenant correct. Quelqu’un avait bousillé des relations. A quelle 
> fréquence www.cyclosm.org <http://www.cyclosm.org/> met a jour son rendu ? Se 
> pourrait-il que ce site rende encore une vieille copie des données OSM ? 
> Comme openstreetmap.org <http://openstreetmap.org/> n’a pas ce problème de 
> rendu présentement ceci me semble davantage un problème avec le rendering 
> engine de cyclosm.org <http://cyclosm.org/> que les données OSM comme tel.
> 
> Martin.
> 
> 
>> On Mar 27, 2020, at 11:55, Pierre Boucher > <mailto:pbouc...@lavoile.com>> wrote:
>> 
> 
> Quelqu'un peut-il régler ce problème d'affichage qui existe depuis longtemps?
> J'en suis incapable.
> 
> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
> <https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm>
> 
> Boff II
> Pierre Boucher
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-ca 
> <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] Iles de Boucherville

[Martin Chalifoux via Talk-ca]

Il y avait ce bug de rendu sur openstreetmap.org  il 
y a quelques mois. Je l’ai réglé il y a un petit bout de temps et ce rendu est 
maintenant correct. Quelqu’un avait bousillé des relations. A quelle fréquence 
www.cyclosm.org  met a jour son rendu ? Se pourrait-il 
que ce site rende encore une vieille copie des données OSM ? Comme 
openstreetmap.org  n’a pas ce problème de rendu 
présentement ceci me semble davantage un problème avec le rendering engine de 
cyclosm.org  que les données OSM comme tel.

Martin.


> On Mar 27, 2020, at 11:55, Pierre Boucher  wrote:
> 
> Quelqu'un peut-il régler ce problème d'affichage qui existe depuis longtemps?
> J'en suis incapable.
> 
> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
> 
> 
> Boff II
> Pierre Boucher
> ___
> 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] Parc des Ïles de Boucherville

[Martin Chalifoux via Talk-ca]

Tu as sans doute cassé des relations. La relation du fleuve st-laurent est très 
complexe et personne devrait jouer avec. Comme on dit, if it works don’t fix 
it. Je pense que quelqu’un est en train de corriger, alors je vais pas jouer 
dedans pour le moment. Si ce-soir c'est pas corrigé je vais jeter un coup 
d’oeil.

> On Dec 12, 2019, at 12:11 , Pierre Boucher  wrote:
> 
> Bonjour,
> 
> Certaines îles du Parc des Îles de Boucherville n'apparaissent pas sur la 
> carte...
> Île de la Commune
> Île à Pinard
> Île Saint-Jean
> J'ai essayé de corriger la situation mais sans succès.  Quelqu'un peut-il 
> corriger et/ou m'expliquer...
> 
> https://www.cyclosm.org/#map=13/45.6068/-73.4803/cyclosm 
> 
> 
>  Joyeuses Fêtes
> 
> Boff II
> Pierre Boucher
> 
> ...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] Documentation du Réseau Vélo Métropolitain

[Martin Chalifoux via Talk-ca]

Bon matin,

C’était mon impression que ces axes sont seulement des voeux pieux sur papier 
mais rien de réel. A part l’axe 20 reliant Oka à St-Hilaire qui lui est réel, 
mis en place pour le 375e anniversaire de Montréal, j’ai jamais vu un seul 
panneau de signalisation et rien de tangible ou réel pour d’autres axes. Est-ce 
que les choses ont évolué ? Je suis peut-être en retard sur les nouvelles.

Si ces axes ont aucune signalisation sur le terrain je vois mal comment 
justifier les ajouter à OSM. 

Martin868

> On Nov 25, 2019, at 11:12, Alouette955  wrote:
> 
> Bonjour,
>  
> Comme suite à mon précédent message j’ai créé les relations concernant l’Axe 
> 49 du Réseau Vélo Métropolitain afin d’avoir vos commentaires.
>  
> Ces relations ont été créées en conformité de la documentation suivante:
>  
> 
> https://wiki.openstreetmap.org/wiki/FR:R%C3%A9seau_v%C3%A9lo_m%C3%A9tropolitain
>  
> 
>  
> que je soumets pour validation.
>  
> J’ai choisi l’axe 49 (qui va de Rosemère jusqu’au canal Lachine à Montréal) 
> parce qu’il contient de grands segments existants ainsi que plusieurs petits 
> segments à compléter. On remarque que les segments complétés apparaissent en 
> lignes continues alors que le “à construire” apparait en pointillé sur les 
> cartes.
>  
> Le rafraichissement de tuiles n’est pas complété mais on commence à les voir 
> à divers niveau de zoom:
>  
> Exemples:
>  
>- https://www.cyclosm.org/#map=12/45.5288/-73.6496/opencyclemap 
> 
>  
>- https://www.cyclosm.org/#map=19/45.57975/-73.78757/cyclosm 
> 
>  
>- https://www.cyclosm.org/#map=17/45.49578/-73.64286/cyclosm 
> 
>  
>  
> Des commentaires sur cette proposition de documentation du réseau seraient 
> appréciés.
>  
> Merci,
>  
> Claude
> ___
> 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] lcn=yes et RM20

[Martin Chalifoux via Talk-ca]

Si la route RM20 est une route régionale il n’est pas fondamentalement 
redondant que des segments soient aussi dans un réseau local. Un segment peut 
très bien faire partie de plusieurs routes du même niveau ou de niveau 
différent. 

> 
> On Oct 24, 2019, at 10:25, Pierre Boucher  wrote:
> 
>  
> Bonjour,
> 
> J'ai remarqué que certaines sections (pas toutes) de la Relation RM20 (Réseau 
> vélo métropolitain - Axe 20) ont dans leurs "attributs" lcn=yes.  Dans un tel 
> cas lcn=yes n'est-il pas superflue.  Si tel est le cas existe-t-il un moyen 
> rapide de faire le ménage?
> Pierre Boucher
> 
> ...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] Carte velo CyclOSM et Référence Route Verte

[Martin Chalifoux via Talk-ca]

Personnellement je laisserait le TCT tel-quel pour que ce soit cohérent sur 
tout le pays. On est pas a un acronyme anglais près. Mais pour la route verte 
l’idée me semble bonne de changer le référence de 1 à RV1, ce serait pas mal 
plus parlant et lisible. Personnellement je laisserait tomber le -, c’est 
jamais très lisible et ça ajoute rien (on écrit en général  l’autoroute A15, 
pas A-15).

En ce qui concerne la réseau métropolitain et son seul trajet, le 20 de Oka à 
St-Hilaire, il me semble que la relation avait été crée au niveau local car la 
convention prise au Canada est que National c’est pour le pays, Régional pour 
les privinces et il reste Local pour le reste. Là je vois qu’il est maintenant 
Regional. Le principe de base est que les réseaux régionaux je se chevauchent 
pas, comme pour les routes - chaque territoire a sa nomenclature. Ici on dit 
que plusieurs réseaux régionaux vont se chevaucher, nommément RV (provincial) 
et RCM (la CMM). Changer sa référence de 20 à RM20 serait cohérent avec la 
suggestion précédente pour la RV. La plupart des rendus ne montrent pas la 
référence pour les routes de niveau local. Le mettre Regional me semble pas un 
gros péché et ça le fera mieux ressortir. Mais il faut se poser la question à 
savoir quelle est la règle. Si un tas de routes plutôt locales (veloute 
Bellechase, Cheminot à Quebec, Estriade, Montégériage, etc) passent toutes au 
status Regional la RV ressortira de moins en moins du lot. Les conséquences? je 
suis pas certain.

Pour ce qui est des routes dites Local, il me semble qu’il y a un peu d’abus 
dans OSM. Des gens crée de telles routes pour des pistes qui sont 
essentiellement locales a un quartier ou une petite région. L’i’dee d’une route 
demeure de marquer une voie qui permet de voyager sur une bonne distance, pas 
juste aller à l’école du quartier. Les termes local et route sont un peu 
antagonistes. Si la moindre petite piste cyclable devient une route la map 
cyclable deviendra rapidement illisibles et confuse. La voie peut avoir les 
tags cycleway sans qu’une route soit ajoutée.

Cheers.

> On Sep 30, 2019, at 13:00, Alouette955  wrote:
> 
> Je n’étais pas encore contributeur lorsque la RV a été initialement 
> cartographiée dans OSM. J’ai alors pris pour acquis que les discussions 
> avaient eu lieu et j’ai continué dans le même sens. Comme nouveau 
> contributeur on me (nous) disait de ne pas cartographier pour le rendu alors 
> j’étais très prudent 
>  
> Depuis il y a eu le premier segment du Réseau Vélo Métropolitain dont le 
> numéro est 20 et qu’on ne peut discriminer de la RV.
>  
> Je suis maintenant un peu plus aguerri et plutôt d’accord avec ta proposition 
> mais aimerais laisser pour quelques jours la chance aux initiateurs de se 
> prononcer.
>  
> Si pas de réponses je corrigerai d’ici peu pour la RV.
>  
> Pour la route TCT, elle court sur l’ensemble du Canada et elle est définie 
> dans des relations cyclables englobantes.
>  
> De plus si j’ai bien compris la TCT n’est que partiellement cyclable, il y 
> aurait des sections TCT randonnées. Ont-elles été cartographiées dans des 
> relations?
>  
>   ref: https://wiki.openstreetmap.org/wiki/Canada#Trans_Canada_Trail <>
>  
> Serait-il acceptable de ne renommer que les segments du Québec TC? J’aimerais 
> l’avis des initiateurs ...
>  
> Salutations,
>  
> Claude
>  
> From: Pierre Béland via Talk-ca <>
> Sent: Sunday, September 29, 2019 2:27 PM
> To: Talk-CA OpenStreetMap <>
> Subject: [Talk-ca] Carte velo CyclOSM et Référence Route Verte
>  
> CyclOSM, une nouvelle carte vélo est disponible
> https://www.cyclosm.org/#map=14/45.5167/-73.5464/cyclosm 
> 
>  
> Et voici quelques commentaires pour les collègues du Québec, dont Claude, qui 
> font un suivi des réseaux de velo.
>  
> Sur les cartes de Velo, quoique la Route verte est bien tracée, il n'est pas 
> possible de l'identifier à partir de la référence puisque le no. est indiqué.
> Cela ne permet pas de clairement identifier ce réseau de vélo qui traverse 
> tout le Québec.  
>  
> Pour la clé-osm reference, je suggère donc d'ajouter le préfixe RV-
> Nous aurions donc
> ref=RV-1
>  RV-2 ...
>  
> Le sentier Trans-Canadien est lui identifié avec la référence TCT. Dans ce 
> cas, on pourrait indiquer ref=TC ce qui éviterait d'utiliser l'abbréviation  
> anglaise ou française (ie. STC, TCT).
> 
>  
> Pierre 
> 
>  
> 
>  Virus-free. www.avg.com 
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> 

Re: [Talk-ca] Ïle d'Orléan

[Martin Chalifoux via Talk-ca]

That’s fine. Better would be to have a cycle route relation of type Local and 
identify the four official loops advertised locally with they given name. That 
would be four relations to create. I might get to do it one day. But they are 
just documented routes with no infrastructure to speak of 

Martin Chalifoux
E martin.chalif...@icloud.com
C 514-233-9701

> On Jul 8, 2019, at 20:27, Jarek Piórkowski  wrote:
> 
> The routes that are blue on Cycle Map on ïle d'Orléans are not mapped as bike 
> paths, but rather highway=secondary + bicycle=designated e.g. 
> https://www.openstreetmap.org/way/118535448 and a route=bicycle "lcn" or 
> local cycle network https://www.openstreetmap.org/relation/2393203
> 
>> On Mon, 8 Jul 2019 at 10:48, Martin Chalifoux  
>> wrote:
>> Je viens juste de faire le tour de l’île. Il y a zéro piste cyclable. On 
>> peut y créer une route mais svp pas mettre de lane ou track. Il y en a pas 
>> du tout. 
>> 
>> Martin Chalifoux
>> E martin.chalif...@icloud.com
>> C 514-233-9701
>> 
>>> On Jul 8, 2019, at 09:25, Jarek Piórkowski  wrote:
>>> 
>>> I don't know if that is the case here, but I've also seen objects 
>>> straight-up missing from the cycle map layer. I think its import of new and 
>>> changed ways is sometimes buggy. 
>>> https://www.openstreetmap.org/#map=19/43.64972/-79.41785=C is an 
>>> example I'm familiar with, 
>>> https://www.openstreetmap.org/#map=19/43.64580/-79.41198=C another 
>>> around the corner. In the latter case it's been 4 months since the missing 
>>> paths were edited.
>>> 
 On Mon, 8 Jul 2019 at 09:12, 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
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ïle d'Orléan

[Martin Chalifoux via Talk-ca]

Je viens juste de faire le tour de l’île. Il y a zéro piste cyclable. On peut y 
créer une route mais svp pas mettre de lane ou track. Il y en a pas du tout. 

Martin Chalifoux
E martin.chalif...@icloud.com
C 514-233-9701

> On Jul 8, 2019, at 09:25, Jarek Piórkowski  wrote:
> 
> I don't know if that is the case here, but I've also seen objects straight-up 
> missing from the cycle map layer. I think its import of new and changed ways 
> is sometimes buggy. 
> https://www.openstreetmap.org/#map=19/43.64972/-79.41785=C is an 
> example I'm familiar with, 
> https://www.openstreetmap.org/#map=19/43.64580/-79.41198=C another 
> around the corner. In the latter case it's been 4 months since the missing 
> paths were edited.
> 
>> On Mon, 8 Jul 2019 at 09:12, 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
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Martin Chalifoux via Talk-ca]

Intéressant cet outil, je ne le connaissais pas. J'ai fait quelques 
corrections. Ca me dérange pas de compléter les correctifs de la RV1 au cours 
des prochains jours.

> On Jul 3, 2019, at 18:52, 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 
> <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 
>> <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 list
>>>> Talk-ca@openstreetmap.org <>
>>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org <>
>>> https://lists.openstreetmap.org/listinfo/talk-ca 
>>> <https://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 <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 
>> <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

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

[Martin Chalifoux via Talk-ca]

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

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

[Martin Chalifoux via Talk-ca]

On parle bien de Route Verte 5 ? Je vois pas vraiment de trous.

> On Jul 3, 2019, at 11:56, James  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 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] Saints in street names in Ontario

[Martin Chalifoux via Talk-ca]

I think the osm database should use proper words. Abbreviating is a rendering 
issue and many rendering engines can do that. Space constraints on signage 
dictate the use of abbreviations for those. 



> On Mar 15, 2019, at 12:50, Kevin Farrugia  wrote:
> 
> Hi Jarek,
> 
> I agree that of the sign has a short form for saint then it should be that 
> way on the map too, as the sign text comes from the official records of 
> street names. 
> 
> I think St. Is better with a period as it makes it less ambiguous to it being 
> an abbreviation and it may help screen readers or spoken directions in maps 
> provide the right information.
> 
> ---
> Kevin F
> 
> 
>> On Fri, Mar 15, 2019, 12:44 PM Jarek Piórkowski  wrote:
>> Hi all,
>> 
>> A couple of months back we established a consensus [1] that "St." in
>> Canadian English city names should not be expanded.
>> 
>> I have been thinking of having the same for street names, and would
>> like to ask people's opinions.
>> 
>> My main motivation is St. Clair Avenue in Toronto. Every city source I
>> could find and every street sign I saw in Mapillary says "St. Clair"
>> or "St Clair". The TTC stations and routes are consistently "St
>> Clair". The City uses "St. Clair Avenue West" in official documents
>> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
>> Avenue", and "St Helens Avenue". Currently most of the street is named
>> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
>> for some parts of the road every now and then.
>> 
>> As a local mapper I would say that "St. Clair Avenue West" is the full
>> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
>> an abbreviation.
>> 
>> Across the Golden Horseshoe names starting with "St. " or "St " seem
>> to be a bit more common [3] than "Saint" [4], I gather the
>> acronym-expanders have not looked as much outside of Toronto.
>> 
>> Would we have Ontario community consensus for a statement along the lines of:
>> "Where "St." or "St" is normally used in the full street name, it
>> should not be expanded to "Saint" even if pronounced so"?
>> 
>> (I don't know what the naming conventions are in other provinces, so I
>> focus on Ontario for now. Apologies for being Ontario-centric, but I
>> don't know of a better venue that is Ontario-specific. I'll post links
>> to this message in wiki talk pages for Ontario, WikiProject_Canada,
>> and Canadian_tagging_guidelines.)
>> 
>> As part of my checks I also looked at London UK, which I gather might
>> be the most-intensively-mapped English-speaking city. (Recommendations
>> for better-mapped English-speaking cities welcome). Searching for
>> "St." in road names [5], it has street names for bigger streets like
>> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
>> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
>> Compare with searching for "Saint" [7] which also has some hits,
>> suggesting that both can be valid depending on what is signed and
>> used. (Or maybe it's just inconsistent.)
>> 
>> [1] 
>> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
>> [2] https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
>> [3] https://overpass-turbo.eu/s/H1M
>> [4] https://overpass-turbo.eu/s/H1P
>> [5] https://overpass-turbo.eu/s/GPh
>> [6] https://osm.org/way/230843467
>> [7] https://overpass-turbo.eu/s/GPi
>> 
>> Thanks,
>> --Jarek
>> 
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Martin Chalifoux via Talk-ca]

The word is definitely Saint. St is a contraction and neither proper English or 
French. It has the same Latin roots as sanctification and similar words. 

Similarly Av is a contraction for Avenue and not a word. 


https://en.m.wikipedia.org/wiki/Abbreviation



> On Mar 15, 2019, at 12:42, Jarek Piórkowski  wrote:
> 
> Hi all,
> 
> A couple of months back we established a consensus [1] that "St." in
> Canadian English city names should not be expanded.
> 
> I have been thinking of having the same for street names, and would
> like to ask people's opinions.
> 
> My main motivation is St. Clair Avenue in Toronto. Every city source I
> could find and every street sign I saw in Mapillary says "St. Clair"
> or "St Clair". The TTC stations and routes are consistently "St
> Clair". The City uses "St. Clair Avenue West" in official documents
> like [2]. Geobase in Toronto has "St Clair Avenue West" , "St Clarens
> Avenue", and "St Helens Avenue". Currently most of the street is named
> "Saint Clair Avenue West/East" in OpenStreetMap, but this is changed
> for some parts of the road every now and then.
> 
> As a local mapper I would say that "St. Clair Avenue West" is the full
> name. Unlike with "Av", "Ave", "W", the "St" in "St Clair" is IMO not
> an abbreviation.
> 
> Across the Golden Horseshoe names starting with "St. " or "St " seem
> to be a bit more common [3] than "Saint" [4], I gather the
> acronym-expanders have not looked as much outside of Toronto.
> 
> Would we have Ontario community consensus for a statement along the lines of:
> "Where "St." or "St" is normally used in the full street name, it
> should not be expanded to "Saint" even if pronounced so"?
> 
> (I don't know what the naming conventions are in other provinces, so I
> focus on Ontario for now. Apologies for being Ontario-centric, but I
> don't know of a better venue that is Ontario-specific. I'll post links
> to this message in wiki talk pages for Ontario, WikiProject_Canada,
> and Canadian_tagging_guidelines.)
> 
> As part of my checks I also looked at London UK, which I gather might
> be the most-intensively-mapped English-speaking city. (Recommendations
> for better-mapped English-speaking cities welcome). Searching for
> "St." in road names [5], it has street names for bigger streets like
> "St. John Street" and "St. Pancras Way"; [6] has name="St. Paul's
> Road" + not:name="Saint Paul's Road" and has had so for 5 years.
> Compare with searching for "Saint" [7] which also has some hits,
> suggesting that both can be valid depending on what is signed and
> used. (Or maybe it's just inconsistent.)
> 
> [1] 
> https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Municipality_Names
> [2] https://www.toronto.ca/legdocs/mmis/2016/ey/bgrd/backgroundfile-92339.pdf
> [3] https://overpass-turbo.eu/s/H1M
> [4] https://overpass-turbo.eu/s/H1P
> [5] https://overpass-turbo.eu/s/GPh
> [6] https://osm.org/way/230843467
> [7] https://overpass-turbo.eu/s/GPi
> 
> Thanks,
> --Jarek
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Martin Chalifoux via Talk-ca]

I certainly agree with that statement ! Importing should be much more rigorous 
and careful, as mistakes or poor execution is costly. 

> On Mar 15, 2019, at 11:29, Nate Wessel  wrote:
> 
> There is a massive difference between making edits without review and 
> importing millions of buildings without review. 
> 
> 

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

Re: [Talk-ca] Help please

[Martin Chalifoux via Talk-ca]

Merci Pierre d’avoir pris le temps de soulever le problème sur le forum. Bien 
des gens auraient simplement rien dit.

Ton problème était simplement qu’après tes manipulations le tag water=pond 
était resté attaché au wood et ça faussait le rendu. Je l’ai effacé et j’en ai 
profité pour faire un peu de menage dans la zone. J’ai mis un étang mais plutôt 
sous forme de wetland=swamp ce qui me semble indiqué. J’ai aussi mis la 
chevreuil en sentier de marche, je pense pas ce ce soit une piste cyclable 
proprement dite.

Ça peut prendre un petite heure pour que les tuiles se régénèrent mais tout 
devrait rentrer dans l’ordre.

> On Feb 6, 2019, at 15:43, Pierre Boucher  wrote:
> 
> I am sorry but I think - I am shure - I am sorry - but I did something wrong 
> in this area:
> 
> https://www.openstreetmap.org/#map=16/45.8074/-74.0316=C
> 
> the link shows the area (cycling map) as it was before an unfortunalely 
> attemp to add a small pond wich exist close to "Le Chevreuil" trail that did 
> not show properly so I decided to delite it
> 
> You can see the result if you switch to the "standard map"
> 
> https://www.openstreetmap.org/#map=16/45.8074/-74.0316
> 
> I looked at the history of changesets and note that the latest changeset 
> before my mistakes is 61130886 by kartler 6 month ago.
> 
> I know that a revert can be done but I have no idea how to do that.
> 
> Can some one help,
> 
> S  sorRy
> Mille excuses.
> 
> Pierre Boucher alias Boff II
> Ste-Therese (Quebec) Canada
> 
> ___
> 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 Place Reclassification needs to be stopped, possibly reverted

[Martin Chalifoux via Talk-ca]

I know in Quebec the place=village tag has been adopted to tag the 
municipalities other than town, cities and suburb, regardless of population. I 
think, but don’t know for sure, the main reason for this is actually the 
rendering engine(s). The place=village tag get a nice rendering that allow to 
identify the municipalities visually on the map. When the municipality, label  
and other tags are used (instead of village), they render very small and are 
not useful. There is a need for municipality names to stand out at a descent 
zoom level on the map, regardless of population. That is important for 
navigating the territory. So I guess my bit of advise is to not only look at 
the pure logic of OSM tagging to understand what is being done in the field and 
also how rendering is done and maybe you will get a better understanding of why 
people do that they do. Now there are tons of rendering engines beside 
openstreetmap.org  but that one is a good place to 
start with.

I also agree that a more consistent scheme needs to be worked out. It is hard 
to maintain the current one. In Quebec there has been mergers over the years 
and often multiple villages are now in one municipality and both informations 
need to show in OSM somehow.

Martin

> On Jan 24, 2019, at 13:24, Danny McDonald  wrote:
> 
> Repeating this, since it seemed to get bumped by all the building import 
> talk.  Now with a catchier subject line. 
> DannyMcD
> 
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.  Place=suburb is for large parts of urban 
> settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether to 
> classify a place as a place=city/town/village or place=suburb depends on the 
> facts on the ground (I.e. whether a place is part of a larger urban 
> settlement), and not primarily on municipal/administrative boundaries.   
> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.  The main way that municipal names are mapped is through admin 
> boundary relations, not place nodes (although many municipalities have the 
> same name as their largest urban settlement, of course).  The way to 
> distinguish between a place=city, place=town, and place=village is population 
> size, with nearby places shading things a bit (so a smaller population size 
> qualifies for a place=town in Northern Ontario).  Very roughly, a city has 
> population >50k, a town has population 5k-50k, and a village is <5k.
> 
> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, consider Minto 
> (https://www.openstreetmap.org/relation/7486154 
> ) in southwest Ontario.  It 
> has two distinct population centres, Harriston and Palmerston.  In the OSM 
> scheme, both are tagged as place=town, and the municipality name Minto (since 
> it does not correspond to a distinct urban settlement) does not get a place 
> tag (except perhaps as a place=municipality at the municipal offices).  The 
> mistaken scheme is to tag Harriston and Palmerston as place=suburb, and 
> create a place=town node for Minto.
> 
> Any thoughts?
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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