[Talk-ca] Pont Gouin Saint-Jean-sur-Richelieu, Révision relations routes vélo empruntant le Pont - Travaux 2020

[Pierre Béland via Talk-ca]

A noter que le nouveau pont comprend une piste à une voie côté nord et une 
piste à deux voies côté sud. J'ai vérifié aujourd'hui, ce qui confirme que les 
travaux ne sont complétés que pour la voie côté nord et la voie côté sud ne 
sera pas opérationnelle avant l'automne. Aucun accès à proximité sauf détours 
via rue Champliain. Un circuit temporaire emprunte la rue Champlain pour l'été 
2020. J'ai donc révisé les relations affectées tel que décrit ci-dessous.
Deviation de l'écluse 9 vers Rue Champlain et piste nord du Pont Gouin
- Relation : Route Verte 1 https://www.openstreetmap.org/relation/416115 - 
Relation : TCT   https://www.openstreetmap.org/relation/7633543
Déviation vers Rue Champlain jusqu'à rue Saint-Jacques, puis portion 1 vers de 
l'écluse 9, et portion 2 ver piste nord du Pont Gouin
- Relation : Champlain Bikeway / Route Champlain 
https://www.openstreetmap.org/relation/2328456
Déviation de intersection Rue Champlain / Saint-Jacques, puis  piste nord du 
pont  Gouin
- Relation : La Montérégiade https://www.openstreetmap.org/relation/2226211
Déviation vers Rue Champlain jusqu'à rue Saint-Jacques
- Relation : Route Verte 2 https://www.openstreetmap.org/relation/416124
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] NRCan lakes

[Pierre Béland via Talk-ca]

e wiki pages are quite old (10 years or so) and its not clear 
whether they still all apply and contain current policy.
 
In your example it seems that the import produced duplicated ways sometimes 
where the lake and the multipolygone (inner) were identical.In this case I see 
that they can be found with the JOSM validator 
(org.openstreetmap.josm.data.validation.tests.DuplicateWays and can then be 
merged (Shift-J) but its 4 clicks for each merge so quite some work and a 
script could potentially fix that automatically.
 

When I look more closely, however, I think this is partially an import artefact 
and partially a problem in the input data. Take for example the case of 
https://www.openstreetmap.org/way/129592036 and 
https://www.openstreetmap.org/way/129592039 which has the same issue (one 
tagged as "inner" and one as water) and I look in the current CanVec data 
031L03 0.3.3 then I only see a single way with 14 nodes at that position. In 
the same tile I find the ways  https://www.openstreetmap.org/way/129592307 and  
https://www.openstreetmap.org/way/129592315 are duplicated both in OSM as well 
as in the input CanVec data tile 031L03 0.3.3 (one is inner of wetland, the 
other inner of wood). I am not sure where this error comes from but it clearly 
highlights the need for manual fixup of the imported data.
 
> Ici on peut  par exemple ne conserver que le lac (way/60852636) et effacer le 
> doublon pour le role inner (way/60854569) et réviser la relation 
> multipolygone pour y indiquer way/60852636 avec role=inner.
 
Yes I think that is possible with JOSM by selecting both and hitting Shift-J 
and then making sure to click "Keep" in the relation. But its a lot of work 
because it is currently done manually and it seems this could easily be done by 
a script (this was already discussed several years back, especially doing this 
automatically but nothing seems to have happened [1]).
 
Another issue that I found in the import is with highways: the "almost 
connected but not connected" ways, luckily they can be found by Osmose but 
create a ton of warnings:  
http://osmose.openstreetmap.fr/en/map/#zoom=12=46.0489=-77.5019==1==
 
What I also dont understand is differences between CanVec imports, for example 
looking at the same tile as above ( 031L03 0.3.3 ) there are several waterways 
that are missing in the CanVec data, for example 
https://www.openstreetmap.org/way/129591734 (tagged with NRCan-CanVec-8.0) is 
not present any more in the tiles that I downloaded from [2] - is there some 
error here, was the stream removed on purpose in the newer CanVec data? In the 
ESRI and Bing satellite data I can clearly see a feature there in the woods 
that looks very much like a waterway, so it looks like some sort of stream is 
there, but not in other images from Maxar (maybe its only part of the year?). 
So why is it missing in newer CanVec data? How should we deal with these cases 
in OSM ?
 
Best
 
Hannes
 
1.  https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007225.html
2. https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/osm/
 

Gesendet: Dienstag, 07. Juli 2020 um 12:18 Uhr
Von: "Pierre Béland" 
An: "Talk-CA OpenStreetMap" 
Cc: "Hannes Röst" 
Betreff: Re: [Talk-ca] NRCan lakes

Petit rappel pour ceux moins familiers avec les imports Canvec. Il est bon de 
bien connaître la structure des données et doublons éventuels à corriger. Aussi 
JOSM est très utile pour repérer les chemins en doublon et corriger.
 
Les développeurs OSM mentionnent régulièrement des multipolygones bois (imports 
Canvec) très grands et complexes qui causent des problèmes de traitement de 
données dans la base de données OSM.  Il faut donc éviter de jumeler les 
multipolygones bois, et plutôt simplifier lorsque possible. 
Aussi, on rencontre souvent des chemins en doublon pour décrire et le lac et 
les zones à exclure d'un multipolygone. Tobermory Lake (60852636) est un 
exemple intéressant à ce sujet. Avec JOSM, on clique sur les bords du lac pour 
voir si des doublons existent.
 
Ici- le lac https://www.openstreetmap.org/way/60852636
- la zone à exclure du multipolygone (role=inner)  
https://www.openstreetmap.org/way/60854569[https://www.openstreetmap.org/way/60854569]
- le multipolygone  
https://www.openstreetmap.org/way/946291[https://www.openstreetmap.org/way/946291]

De plus, on retrouve un polygone couvrant une partie du lac pour le marécage 
adjacent au lac (natural=wetland).
https://www.openstreetmap.org/way/60852071[https://www.openstreetmap.org/way/60852071]
 
Ici on peut  par exemple ne conserver que le lac (way/60852636) et effacer le 
doublon pour le role inner (way/60854569) et réviser la relation multipolygone 
pour y indiquer way/60852636 avec role=inner.
 
 
Pierre
 
 

Le mardi 7 juillet 2020 11 h 34 min 08 s UTC−4, James  a 
écrit :
 
 

___
Talk-ca mailing list
Talk-ca@openstre

Re: [Talk-ca] NRCan lakes

[Pierre Béland via Talk-ca]

 Petit rappel pour ceux moins familiers avec les imports Canvec. Il est bon de 
bien connaître la structure des données et doublons éventuels à corriger. Aussi 
JOSM est très utile pour repérer les chemins en doublon et corriger.
Les développeurs OSM mentionnent régulièrement des multipolygones bois (imports 
Canvec) très grands et complexes qui causent des problèmes de traitement de 
données dans la base de données OSM.  Il faut donc éviter de jumeler les 
multipolygones bois, et plutôt simplifier lorsque possible.

Aussi, on rencontre souvent des chemins en doublon pour décrire et le lac et 
les zones à exclure d'un multipolygone. Tobermory Lake (60852636) est un 
exemple intéressant à ce sujet. Avec JOSM, on clique sur les bords du lac pour 
voir si des doublons existent.
Ici- le lac https://www.openstreetmap.org/way/60852636
- la zone à exclure du multipolygone (role=inner) 
https://www.openstreetmap.org/way/60854569
- le multipolygone https://www.openstreetmap.org/way/946291

De plus, on retrouve un polygone couvrant une partie du lac pour le marécage 
adjacent au lac (natural=wetland).
https://www.openstreetmap.org/way/60852071


Ici on peut  par exemple ne conserver que le lac (way/60852636) et effacer le 
doublon pour le role inner (way/60854569) et réviser la relation multipolygone 
pour y indiquer way/60852636 avec role=inner.

 
Pierre 
 

Le mardi 7 juillet 2020 11 h 34 min 08 s UTC−4, James  
a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  I don't think canvec is updating these things on a regular basis, OSM after 
corrections are usually more accurate than canvec anyways and doubt would 
update data from Canvec to fix outdated data
On Tue., Jul. 7, 2020, 11:27 a.m. Hannes Röst,  wrote:

Dear Adam and Daniel

Thanks a lot, so this answers the question that these are import artefacts and 
not intended. One question still remains, namely whether we should clean them 
up and how (joining ways makes sense from the OSM data model but may make a 
future update based on CANVEC files much harder while adding all ways into a 
relation would preserve the import but the resulting shape will look funny). My 
instinct is still to fix the ways unless there is a strong reason against this. 
One reason I ran into this was trying to match OSM to Wikidata items and of 
course having 3 ways all called the same name makes this difficult. Let me know 
what you think

Another issue I found was with nodes such as these: 1279897592, 1279898654 and 
1279896951 which also seem to come from an import (see [1] for overpass query). 
I am not sure whether these are duplicate imports or whether they are supposed 
to indicate the extent of a feature (most east and most western point) of the 
channel. The wiki indicates to either map this as "natural=strait" and use 
either a single node, a line or a multipolygon [2] but not as multiple nodes 
with the same name. Honestly, in this case its a bit hard to see where the 
supposed "channel" should be, but connecting the nodes to a line would seem 
sensible here to me, any thoughts?

Best

Hannes

[1] 
http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B
[2] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map
 

Gesendet: Dienstag, 07. Juli 2020 um 09:56 Uhr
Von: "Adam Martin" 
An: "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
Betreff: Re: [Talk-ca] NRCan lakes

As mentioned by Daniel, this is due to the nature of the CANVEC data import.  
CANVEC shapefile data is based on tiles and these will chop practically 
anything into pieces - lakes are just ones of the more noticeable.  I have 
corrected some of these myself as I've come across them.  Just be careful in 
cases where the lake pieces are part of different relations in the area - you 
will need to adjust those to make sure nothing breaks.
 
Adam 

On Tue, Jul 7, 2020 at 2:33 AM Hannes Röst 
mailto:hannesro...@gmx.ch]> wrote:Hello

I am a contributor from Toronto and I have a question regarding how to
treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
I came across this lake here:

https://www.openstreetmap.org/way/69275451[https://www.openstreetmap.org/way/69275451]
https://www.openstreetmap.org/way/69277932
https://www.openstreetmap.org/way/69745752

Which is strangely split up into 3 parts and I wonder how to proceed:
should we fix this and create a single way out of these 3 parts or is
it beneficial (for comparison to future NRCan database entries) to
keep them that way and create a relation out of the three? Also, does
somebody know why the NRCan dataset does this, is this an import
artefact (splitting into tiles?) and should be corrected when encountered
or is it part of the original dataset?

Best

Hannes Rost

[Talk-ca] Import du Réseau Vélo Métropolitain

[Pierre Béland via Talk-ca]

Un contributeur a démarré la discussion Montreal Bike lanes import sur la liste 
Import  dans le but d'importer les données du réseau métropolitain.  Je l'ai 
invité a venir discuter sur la liste Talk-ca, qui me semble la première place 
où discuter avant de soumettre à la liste import.
voir https://lists.openstreetmap.org/pipermail/imports/2020-July/006291.html
 
Pierre 
 

Le mercredi 13 novembre 2019 15 h 56 min 00 s UTC−5, Alouette955 
 a écrit :  
 
 Bonjour, En examinant les documents de la CMM (Communauté Métropolitaine de 
Montréal) je réalise que plusieurs segments du futur Réseau Vélo Métropolitain 
existent déjà et peuvent être utilisés pour créer le squelette de ce réseau en 
développement. J’ai adapté la page décrivant le réseau:    
https://wiki.openstreetmap.org/wiki/FR:R%C3%A9seau_v%C3%A9lo_m%C3%A9tropolitain 
afin de faciliter le travail collaboratif et guider le travail. Afin de ne pas 
encombrer cette liste je suggère à ceux que ça intéresse de discuter ce 
document grâce à l’onglet “Discussion” de cette page afin de l’améliorer et de 
finalement en approuver le fonctionnement. Il pourrait être pertinent de 
l’ajouter à votre liste de suivi (la petite étoile en haut du document). 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] Business data in northern Montreal

[Pierre Béland via Talk-ca]

Bonjour David
Pour voir de tels projets progresser, faire le point de temps en temps peut 
motiver les contributeurs à participer. Et l'accès à des outils pour faciliter 
l'édition / ajout de données. Par exemple, où sont les données géoréférencées 
des bureaux de poste existants à ajouter à OSM ?

Pour les bureaux de poste, la page wiki 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada_Post  contient des liens 
intéressants dont les statistiques par province. On observe une très bonne 
couverture dans l'ouest (au dela de 90%), et nettement moindre dans l'est 
incluant le Québec  (40% et moins) 
(https://docs.google.com/spreadsheets/d/1gj1E9R_daWsEg5_sDH1gH9C9WO79jkZIMwrx5YuncYk/edit#gid=0).


Un autre site intéressant est https://www.pagesjaunes.ca / 
https://www.yellowpages.caIls utilisent la carte OpenStreetMap. Il y a là un 
interêt commun. Si quelqu'un pouvait les convaincre de permettre aux 
contributeurs OSM d'accéder à leur répertoire géoréférencé, imaginez tous les 
commerces que nous pourrions ajouter à la carte. Cela motiverait aussi à 
ajouter les batiments correspondants.
 
Pierre 
 

Le dimanche 14 juin 2020 04 h 43 min 06 s UTC−4, David Nelson via Talk-ca 
 a écrit :  
 
 
As part of my efforts to advance WikiProject Canada Post, I noticed that the 
portion of the Island of Montreal north of Autoroute 25 is missing quite a bit 
of business data.  When looking through our database for businesses that act as 
franchises for Canada Post outlets, I was not able to find more than half of 
them in the aforementioned part of Montreal.  Is it possible that any active 
mappers in that part of the city could go out and improve OSM's business 
coverage there?

  

- David E. Nelson


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

Re: [Talk-ca] Carte uMap Établissements CHSLD et RPA au Québec où plus de 15% des résidents avec COVID-19

[Pierre Béland via Talk-ca]

Bonjour Pierre-Léo,
Pour des maisons de retraire RPA et CHSLD, j'utilise plutôt la clé capacity.  A 
discuter, ce qui serait le mieux.  Cela pourrait être fait systématiquement 
plus tard à l'aide des registres du gouvernement du Québec.  J'ai demandé au 
début de la crise sur le site du gouvernement, mais on m'a répondu ne pas avoir 
de temps pour répondre à ma requête. 

 
Pierre 
 

Le dimanche 19 avril 2020 20 h 35 min 13 s UTC−4, Pierre-Léo Bourbonnais 
 a écrit :  
 
 Merci!
Si possible, mettez aussi: building:flats avec le nombre de logements, ça nous 
aidera pour plein d’analyses par la suite.


On Apr 19, 2020, at 17:44, Pierre Béland via Talk-ca 
 wrote:
Le gouvernement du Québec publie une liste mise-à-jour quotidiennement des 
établissements concernés par la COVID-19 
https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Problemes_de_sante/covid-19/Tableau-milieux-de-vie-COVID-19.pdf
À partir de cette liste, j'ai ajouté / révisé dans la base OpenStreetMap les 
établissements  où plus de 15% des résidents sont touchés par la COVID-19. J'ai 
aussi publié une carte uMap de ces établissement et prévois maintenir à jour 
cette carte.
Il y a encore beaucoup d'établissements à ajouter ou réviser (ceux en jaune 
dans la liste de Santé-Québec). Pour chacun, il faut géolocaliser en 
recherchant l'adresse, puis ajouter coordonnées, tel, etc.
Si vous voulez contribuer à ajouter les établissements, je vous demande 
d'utiliser les clés OSM suivantes:
amenity=social_facilitysocial_facility_for:=seniorsocial_facility=group_home  
(RPA)social_facility=nursing_home  (CHSLD)

Je n'ai pas systématiquement ajouté l'opérateur (privé ou instances 
régionales). Dans un premier temps, on peut ne pas ajouter.

La Carte uMap des établissements montre une forte concentration dans la région 
de Montréal
Voir 
https://twitter.com/pierzen/status/1251986792284409858http://umap.openstreetmap.fr/fr/map/liste-des-chsld-et-rpa-concernes-par-le-covid-19-d_445831
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

[Talk-ca] Carte uMap Établissements CHSLD et RPA au Québec où plus de 15% des résidents avec COVID-19

[Pierre Béland via Talk-ca]

Le gouvernement du Québec publie une liste mise-à-jour quotidiennement des 
établissements concernés par la COVID-19 
https://cdn-contenu.quebec.ca/cdn-contenu/sante/documents/Problemes_de_sante/covid-19/Tableau-milieux-de-vie-COVID-19.pdf
À partir de cette liste, j'ai ajouté / révisé dans la base OpenStreetMap les 
établissements  où plus de 15% des résidents sont touchés par la COVID-19. J'ai 
aussi publié une carte uMap de ces établissement et prévois maintenir à jour 
cette carte.
Il y a encore beaucoup d'établissements à ajouter ou réviser (ceux en jaune 
dans la liste de Santé-Québec). Pour chacun, il faut géolocaliser en 
recherchant l'adresse, puis ajouter coordonnées, tel, etc.
Si vous voulez contribuer à ajouter les établissements, je vous demande 
d'utiliser les clés OSM suivantes:
amenity=social_facilitysocial_facility_for:=seniorsocial_facility=group_home  
(RPA)social_facility=nursing_home  (CHSLD)

Je n'ai pas systématiquement ajouté l'opérateur (privé ou instances 
régionales). Dans un premier temps, on peut ne pas ajouter.

La Carte uMap des établissements montre une forte concentration dans la région 
de Montréal
Voir 
https://twitter.com/pierzen/status/1251986792284409858http://umap.openstreetmap.fr/fr/map/liste-des-chsld-et-rpa-concernes-par-le-covid-19-d_445831
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Ça reste ouvert

[Pierre Béland via Talk-ca]

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.48https://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 
lockdownYahoo/Boîte récept.   
   - 
os...@openstreetmap.de À :pierzenh@yahoo.frjeu. 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_androidhttps://apps.apple.com/app/ça-reste-ouvert/id1506199151https://taginfo.geofabrik.de/europe/france/keys/opening_hours%3Acovid19https://github.com/osmontrouge/caresteouvert/issues/new/choose

markdownEN was changed

Ça reste ouvert, the map of open places during the COVID-19 lockdown, has 
collected opening hours in France [for almost 20,000 
objects](https://taginfo.geofabrik.de/europe/france/keys/opening_hours%3Acovid19)
 within three weeks.The French community collaborates with several communities 
and has added new countries to the map: Germany, Switzerland and Austria (as 
["Bleibt offen"](https://www.bleibtoffen.de/)) as well as Spain and Andorra. 
Their GitHub repository provides [an issue 
template](https://github.com/osmontrouge/caresteouvert/issues/new/choose) to 
request coverage for your country.The French service provider TransWay has 
[published](https://apps.apple.com/app/ça-reste-ouvert/id1506199151) a mobile 
app for iOS. Eric Afenyo is 
[developing](https://github.com/osmontrouge/caresteouvert_android) one for 
Android.

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

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

[Pierre Béland via Talk-ca]

Bonjour Pierre-Léo,
Divers éléments de la base OSM représentent bien sûr des avantages pour  divers 
groupes.  Par contre du point de vue de la communauté, comment progresser de 
façon à assurer une certaine viabilité du projet. Certains ont intérêt à ce que 
tous les bâtiments soient tracés, d'autres veulent les trottoirs etc. 

La question qui est posée ici, pourrons nous comme communauté supporter de tels 
projets, quels sont les priorités. Malheureusement la communauté n'est pas 
aussi développée qu'en Europe.  Et des groupes comme le tiens arrivent avec des 
projets fort louabes.  Mais voyez-vous la possibilité de vous engager à 
supporter ces projets à long terme, à assurer la qualité, corriger les 
problèmes, bien documenter ?  Avez-vous les outils pour faire le suivi de tels 
schémas tel ajout de trottoirs, et bien suivre l'édition de ces données?  Ou 
comme pour beaucoup d'autres projets,  vous vous dites que la communauté saura 
ensuite supporter, corriger le tout?
 
Pierre 
 

Le vendredi 3 avril 2020 16 h 51 min 42 s UTC−4, Pierre-Léo Bourbonnais 
 a écrit :  
 
 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.

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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

je ré-envoi à la liste - texte était trop long avec commentaires précédents + 
image

 
Pierre 
 

Le jeudi 2 avril 2020 15 h 22 min 38 s UTC−4, Pierre Béland 
 a écrit :  
 
 Martin 

J'ai corrigé le problème avec l'ïle Bellevue dans le lac Saint-Louis il y a 
quelques jours.  A chaque fois, cela prend du temps avant que les différents 
styles carto soient mis à jour (ie. périodicité de mise à jour variable).  Je 
vois à Boucherville que style transport a été mis à jour plus rapidement que 
humanitaire et cyclo.

On peut donner une petit coup de pouce en demandant une mise à jour d'une tuile 
particulière. Je l'ai fait pour quelques tuiles à Boucherville et Île Bellevue, 
mais travail fastidieux. 
C'est de cette façon que j'ai pu présenter une image avant/après correction à 
Boucherville.
Exemple avec le navigateur firefox, où je dois cliquer sur une zone tel que 
Panneau des couches à droite avec bouton droit et sélectionner «Informations 
sur la page» (Dans la carte, j'obtiens plutôt un menu contextuel OSM). Je 
sélectionne l'onglet Medias et obtiens la liste / et voit chaque png 
représentant une tuile. Je copie, ajoute /dirty (instruction de 
rafraichissement) et utilise ceci comme lien url dans navigateur. J'obtiens 
confirmation de réception de requête et attends parfois 24h selon comment le 
serveur de tuiles est surchargé.Exemple 
https://tile-a.openstreetmap.fr/hot/17/38609/46942.png/dirtyhttps://tile-a.openstreetmap.fr/hot/14/4847/5854.png/dirty
 
Pierre 
 

Le jeudi 2 avril 2020 14 h 37 min 50 s UTC−4, Martin Chalifoux 
 a écrit :  
 
 L’ile bellevue était correct dans le snapshot d’hier soir. Sur 
openstreetmap.org en ce moment les tuiles sont pas consistantes, comme si 
quelqu’un venait de la modifier ou modifier le lac St-Louis et que les tuiles 
sont en cours de reconstruction. A voir comment ca se stabilise.


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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

Et cela fonctionne ! voir le avant / après avec style humanitaire. Les tuiles 
seront mise à jour progressivement.
https://twitter.com/pierzen/status/1245364617221754880
 
Pierre 
 

Le mercredi 1 avril 2020 09 h 13 min 29 s UTC−4, Daniel @jfd553 
 a écrit :  
 
 +1


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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

Bonnes nouvelles.  Pour ce qui est du circuit canot,  j'ai créé une relation 
route=canoe. Il en existe déjà 549.  J'ai indiqué rôles forward / backward. À 
voir si cela est correct pour indiquer le sens du parcours. 

voir https://www.openstreetmap.org/relation/10947406 
Pierre 
 

Le mercredi 1 avril 2020 06 h 27 min 59 s UTC−4, Martin Chalifoux 
 a écrit :  
 
 Victoire on dirait. Bonne chose de réglée. Merci.  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

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=fairwaySelon 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

[Pierre Béland via Talk-ca]

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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

Martin, je viens de faire quelques corrections à l'Île-Sainte-Marguerite, mais 
elles ne seront peu-être pas dans fichier geofabrik de ce soir.
J'ai constaté que des polygones se croisaient et que cela peut parfois causer 
des soucis de rendu ou autre.  Je me suis assuré que le polygone bois ne coupe 
pas contour de l'Île.  En ce qui a trait aux relations de limite admin et parc, 
j'ai ajouté un point à chaque endroit ou ces polygones croisaient les contours 
de l'Île.

 
Pierre 
 

Le dimanche 29 mars 2020 12 h 05 min 58 s UTC−4, Martin Chalifoux 
 a écrit :  
 
 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

[Pierre Béland via Talk-ca]

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 duplicationRelations 

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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

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 duplicationRelations 

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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

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 duplicationRelations 

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

Re: [Talk-ca] Iles de Boucherville

[Pierre Béland via Talk-ca]

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

Re: [Talk-ca] Grand-Montréal Utilisation de sidewalk pour cartographier pistes multi-usage

[Pierre Béland via Talk-ca]

Bonjour Pierre-Léo
oui on voit bien le trottoir et je ne vois pas de problème à cet endroit pour 
la piste vélo sur la voie publique, et la piste piéton sur le trottoir. 

Les problèmes sont plutôt à partir de la Rue Antoine De La Fresnaye. Pour 
distinguer la piste vélo/piéton de la rue,  deux chemins parallèles sont 
tracés. Le premier représentant la rue, highway=tertiary (id=42304636) réfère 
avec une série d'attributs don use_sidepath au deuxième chemin (id=) qui lui 
décrit la section en bordure de la rue pour les  piéton/vélos. 

Ce schéma est lourd et pourrait  être simplifié en enlevant les références 
piéton/velo sur le chemin principal et indiquant sur le deuxième chemin 
highway=footway, foot=designated, bicycle=designated de façon similaire à ce 
que l'on retrouve sur le chemin, rue Saint-Joseph.  De même sur la rue 
Saint-Joseph, on devrait enlever sur le chemin principal les références au 
sentier piéton/vélo. 

Il serait aussi possible de tout garder sur un seul chemin. Mais je peux 
comprendre que l'on préfère dissocier et utiliser deux chemins même si ceux-ci 
se partagent la même chaussée.


rue Antoine De La Fresnaye

Chemin : Rue Antoine De La Fresnaye (42304636)  Attributs : 
    "sidewalk"="separate"
    "sidewalk:left"="separate"
    "lanes"="2"
    "maxspeed"="40"
    "name"="Rue Antoine De La Fresnaye"
    "sidewalk:right"="no"
    "highway"="residential"
    "foot"="use_sidepath"
 Et en parrallèleChemin : 766531240
  Attributs : 
    "highway"="footway"
    "maxspeed"="40"
Boulevard 
Saint-Joseph---
Chemin : Boulevard Saint-Joseph (683782639)
  Attributs : 
    "sidewalk"="separate"
    "bicycle"="use_sidepath"
    "sidewalk:left"="no"
    "surface"="asphalt"
    "lanes"="2"
    "maxspeed"="60"
    "name"="Boulevard Saint-Joseph"
    "sidewalk:right"="separate"
    "highway"="tertiary"
    "foot"="use_sidepath"
Et en parrallèle
Chemin : Boulevard Saint-Joseph (766027404)  Attributs : 
    "name"="Boulevard Saint-Joseph"
    "bicycle"="designated"
    "highway"="cycleway"
    "cycleway"="lane"
    "foot"="designated"

 
Pierre 
 

Le mardi 10 mars 2020 13 h 36 min 03 s UTC−4, Pierre-Léo Bourbonnais 
 a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  Voici une photo aérienne haute résolution de l’endroit pour mieux évaluer le 
contexte. C’est vraiment un cas particulier, car il y a aussi un trottoir à 
droite. J’ai ajouté une note sur ce way.
https://drive.google.com/open?id=1Y0CsomNZLCEEVlX-CDHsv4yplKWxkLOJ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Grand-Montréal Utilisation de sidewalk pour cartographier pistes multi-usage

[Pierre Béland via Talk-ca]

Pour ceux d'entre-vous intéressés par la cartographie des pistes cyclables dans 
la région de Montréal,  Voir le changeset 
https://www.openstreetmap.org/way/775106882 que j'ai commenté. Jugez-vous 
souhaitable de demander à ce contributeur d'en discuter avec la communauté?

Je doute que sidewalk soit approprié pour décrire les pistes 
multi-fonctionnelles adjacentes à la route. Tel qu'indiqué dans le changeset, 
le projet est de cartographier le grand-Montréal. Sur le boulevard Virginie-Roy 
a l'Île-Perrot, on observe une piste multi-fonction. Les attributs du chemin 
contiennent à la fois les attributs 
cycleway:left     lane
foot      use_sidepath
oneway:bicycle     no
sidewalk       separate
sidewalk:left     no
sidewalk:right      separate


voir https://www.openstreetmap.org/way/775106882
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] OSM relation analyser

[Pierre Béland via Talk-ca]

Pierre
Les sites d'analyse de relations visent davantage je pense le multipolygones.  
Tout comme dans l'édition JOSM de telles relations, on  y indique où le 
linéaire est brisé pour les différents blocs avec role inner ou outer sont 
fermés. 

Au cas ou  ces infos peuvent t'être utilies. Pour les relations de route, il y 
a dans JOSM le greffon Route. Il y a aussi des greffons de transport public.
àhttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/Routeshttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/public_transport
 Et le contributeur Polyglot a publié infos dans son Journal 
OSMhttps://www.openstreetmap.org/user/Polyglot/diary/38980
Une recherche avec mots clés permet de voir pages wiki ou conférences SOTM où 
Polyglot a traité du sujet- polyglot osm relation route bicycle

Pierre 
 

Le lundi 2 mars 2020 13 h 28 min 02 s UTC−5, Pierre Béland via Talk-ca 
 a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  Il y a aussi sur le site osm_fr 
analyser.openstreetmap.fr/cgi-bin/index.py?relation=7508532 qui ne fonctionne 
pas.  J'ai aussi souvent eu des problèmes d'accès.
Pour le site http://ra.osmsurround.org/analyzeRelation?, tu devrais pouvoir 
rejoindre les développeurs sur la liste dev (communication en anglais) pour 
indiquer que tu ne réussis pas à obtenir de 
résultat.https://lists.openstreetmap.org/pipermail/dev/
Pour le site analyser.openstreetmap.fr, tu peux communiquer via la liste 
francophone https://lists.openstreetmap.org/pipermail/talk-fr/ 
Pierre 
 

Le lundi 2 mars 2020 12 h 51 min 48 s UTC−5, Pierre Boucher 
 a écrit :  
 
   Ça ne fonctionne pas
 
 http://ra.osmsurround.org/analyzeRelation?relationId=7508532
 
 Quelqu'un peut-il y faire quelque chose?
 
 Merci.
 
 Boff II ___
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] OSM relation analyser

[Pierre Béland via Talk-ca]

Il y a aussi sur le site osm_fr 
analyser.openstreetmap.fr/cgi-bin/index.py?relation=7508532 qui ne fonctionne 
pas.  J'ai aussi souvent eu des problèmes d'accès.
Pour le site http://ra.osmsurround.org/analyzeRelation?, tu devrais pouvoir 
rejoindre les développeurs sur la liste dev (communication en anglais) pour 
indiquer que tu ne réussis pas à obtenir de 
résultat.https://lists.openstreetmap.org/pipermail/dev/
Pour le site analyser.openstreetmap.fr, tu peux communiquer via la liste 
francophone https://lists.openstreetmap.org/pipermail/talk-fr/ 
Pierre 
 

Le lundi 2 mars 2020 12 h 51 min 48 s UTC−5, Pierre Boucher 
 a écrit :  
 
   Ça ne fonctionne pas
 
 http://ra.osmsurround.org/analyzeRelation?relationId=7508532
 
 Quelqu'un peut-il y faire quelque chose?
 
 Merci.
 
 Boff II ___
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] W3C Maps on the Web workshop

[Pierre Béland via Talk-ca]

Bonjour Peter,
Il vaut mieux à mon avis s'adresser à la liste OSM internationale pour un tel 
sujet. Pour pouvoir discuter, il est facile de s'inscrire avec adresse de 
courriel sur https://lists.openstreetmap.org/listinfo/talk et éventuellement de 
paramétrer pour ne pas recevoir toutes les discussions.

En plus des responsables des pages web du site OSM, divers groupes sont 
susceptibles de s'intéresser à un tel sujet, par exemple équipe du style Carto 
et développeurs de diverses applications de géovisualisation.
 
Pierre 
 

Le mardi 28 janvier 2020 14 h 13 min 37 s UTC−5, Rushforth, Peter 
(NRCan/RNCan)  a écrit :  
 
  
Dear Open Street Map community,
 
  
 
I apologize if this email gets duplicated. I sent it once without joining the 
list.  Please ignore a second version if it gets released.
 
  
 
My name is Peter Rushforth, and I’m with the Canada Centre for Mapping and 
Earth Observation, at Natural Resources Canada (a Canadian government 
department).  We are planning a World Wide Web Consortium (W3C) workshop on 
maps in the Web platform (specifically HTML), together with the W3C and the 
Open Geospatial Consortium (OGC).  The workshop will be collocated with the OGC 
Technical Committee meeting, June 15-17 2020 in Montreal, Quebec.
 
  
 
I am sending this email to see if Open Street Map (especially the Web client 
development teams) might be interested in being invited to participate (by 
presenting a short position paper, in person) in this workshop on the concept 
of better integrating mapping into the Web platform standards, and if so, how 
does Open Street Map see this.  Even if you believe that the Web platform 
standards are already good enough for mapping, it might be worthwhile staking 
that out as a position. If you are interested, though, we would certainly 
welcome OSM to also be part of the program committee.
 
  
 
The objective of the workshop will be to start the conversation between the 
geospatial (and geospatial standards) and Web platform communities, about how 
Web standards could better serve the needs of Web mapping and most especially 
users of Web maps and the Web in general.
 
  
 
Some topics of potential interest include:
 
  

   - a native map viewer, similar to that provided for video content
   - standards for how such a map widget might integrate with map services and 
APIs
   - accessibility of browser maps
   - privacy of user location information
   - security of browser-based maps
   - Integration / relationship of maps and location with other browser APIs, 
e.g. geo-video, geolocation API, forms, SVG
   - crawling, indexing and searching map information
   - standardized browser elements and APIs
   - CSS styling of maps and map features
   - Map feature creation / input forms
   - federated map services with linking - aka the Web
 
  
 
Mostly the agenda will be driven by position papers, and what organizations 
like yours want to discuss.  If OSM is interested in sending one or two people 
to present a position, please reply directly to me, and I will ensure that you 
/ they are invited. 
 
  
 
  
 
Cheers,
 
Peter
 
  
 
  
 
Peter Rushforth
 
  
 
Technology Advisor
 
Canada Centre for Mapping and Earth Observation
 
Natural Resources Canada / Government of Canada
 
peter.rushfo...@canada.ca / Tel: 613-759-7915
 
  
 
Conseiller technique
 
Centre canadien de cartographie et d’observation de la Terre
 
Ressources naturelles Canada / Gouvernement du Canada
 
peter.rushfo...@canada.ca / Tél: 613-759-7915
 
  
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


| 
| 
|  | 
talk Info Page


 |

 |

 |



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

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

John,
Exprime tu simplement une opinion, ou as-tu vérifié les procédures d'import 
incluant correction des données et validé la qualité des données importées aux 
États-Unis ? Considères-tu la qualité des données dans la base OSM aux 
États-Unis comparable à ce qui s'est fait au Canada l'an dernier ? 

La qualité des données Microsoft peut sans doute varier selon divers facteurs 
dont la qualité et précision des données aériennes utilisées.
De mon côté, j'ai regardé du côté de Dallas, Texas. En consultant le 
gestionnaire de tâches US, il est possible d'y repérer les tâches créées pour 
cartographier des bâtiments.
https://tasks.openstreetmap.us/contribute?difficulty=ALL=ARCHIVED=BUILDINGS
Dans ces zones, j'ai constaté en général une bonne qualité des données.  Je ne 
connais pas les procédures utilisées, ni regardé le connu des fichiers de 
données Microsoft pour ces zones, mais la tâche ci-dessous montre un processus 
de validation où il était demandé d'orthogonaliser les 
bâtiments.https://tasks.openstreetmap.us/project/164#bottom 
Pierre 
 

Le vendredi 17 janvier 2020 13 h 02 min 20 s UTC−5, john whelan 
 a écrit :  
 
 > As stated before, I don't consider the Microsoft dataset being close tothe 
 >minimum quality requirements I would expect from any automated
building entry into OSM.
Well yes that is one opinion but we do have a range of opinions in 
OpenStreetMap and from the number of buildings that have already been imported 
into OpenStreetMap from Microsoft, there seems to be a large number in the US 
for example, it would appear there are those who disagree with you which is not 
surprising given the number of mappers.
To me the buildings are of more interest once they get enriched with more tags 
and the place that happens is in OpenStreetMap.  Streetcomplete I think is 
either the most popular editor these days or very close to it.  You can't add 
tags if the buildings are not in OpenStreetMap.  Yes you can display the 
outlines by using the Microsoft data but that does not show tags such as 
building type, building levels, etc etc. and streetcomplete is a tool that can 
be used to introduce OpenStreetMap to many people.
I think perhaps we should concentrate our efforts on the current import for the 
moment but I suspect that some Microsoft buildings will start to be imported in 
Canada even if they don't have an official import plan.
Cheerio John 

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

Hi John,

As stated before, I don't consider the Microsoft dataset being close to 
the minimum quality requirements I would expect from any automated 
building entry into OSM. If you just want to display buildings, you can 
download the MS dataset and use it right away - no need to import into 
OSM. I think, the MS dataset has value as proof of concept and to count 
the number of buildings in a given area (e.g. to estimate market size 
for roofers, estimate number of persons living there for desaster 
relief, etc.). I also think, when Microsoft feeds its algorithm with 
higher resolution data than they did (I don't recall, but I think they 
only used the regular Bing data) they will probably end up with building 
footprints that will meet our/my quality requirements for import into 
OSM one day.

For me, the value of OSM is having accurate information in terms of tags 
and geometry. Otherwise, we could join Wikimapia; they don't care too 
much about geometry accuracy but emphasize on content/tags of objects. 
Pretty interesting project, but different from OSM.

Cheers,
Tim

On 2020-01-17 10:40, john whelan wrote:
  >first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

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

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, mailto:o...@elrick.de>> wrote:

     I would assume in most cases the imported building footprint will be
     more precise than existing data. For me, this would be a reason to
     replace already existing objects. However, I think this is a case by
     case decision. However, I think it is important to keep tags and
     history
     of buildings already existent in OSM. This is how I would
     read/interpret
     the import guideline stated by Nate: "If you are importing data where
     there is already some data in OSM, then *you need to combine this data*
     in an appropriate way or suppress the import of features with overlap
     with existing data." (emphasis added by me)

     However, that just means, the import, hence, is nothing easy and could
     not be achieve quickly, I would assume. One way of making sure that
     this
     is dealt with diligently, would be setting the tasking manager to
     'experienced mappers only'. We 

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

Bonjour Nate,
Cette approche avec taille et forme variable des tâches est intéressante pour 
contrôler le nombre de bâtiments à valider.  Pour éviter les conflits 
d'édition, est-t-il possible de s'assurer qu'un bâtiment se retrouvera dans une 
seule tâche ?  

Si des bâtiments se retrouvent sur la ligne de contour de la tâche, il seront 
sélectionnés dans deux tâches différentes. Voir par exemple 
http://tasks.osmcanada.ca/project/168#task/152
Une façon d'éviter cela serait de s'aligner le plus possible sur les routes.

 
Pierre 
 

Le dimanche 5 janvier 2020 11 h 40 min 49 s UTC−5, Nate Wessel 
 a écrit :  
 
  
The task size, and even shape is totally customizable. I've set up a couple 
that are entirely based on the density of the data:
 http://tasks.osmcanada.ca/project/168
 https://tasks.openstreetmap.us/project/107
 
Best,
 
  
 Nate Wessel, PhD
 Planner, Cartographer, Transport Nerd
 NateWessel.com 
   ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Parc des Ïles de Boucherville

[Pierre Béland via Talk-ca]

Pierre,
Je ne sais pas si tu voulais dessiner un circuit pour pédalos :-)

Il y a plusieurs iles et marécages autour de l'archipel de Boucherville.  Et 
Martin a aussi édité le secteur.
 Il existe déja Chemin : 77938080    "natural"="wetland"
plus un autre à l'intérieur qui décrit une ile.
Il existait aussi une Île de la Commune que j'ai conservé et ajouter avec rôle 
inner dans relation eau (puis enlever lien pour chemins ci-dessous).

Tu as créé deux nouveaux Chemins que j'ai effacé
 Île de la Commune (40616848)
    "name"="Île de la Commune" qui correspond à l'ïle qui existait déja

Puis tu as créé une deuxième instance de l'Île cette fois-ci englobant 
plusieurs Îles.
 : Île de la Commune (653906078)    "name"="Île de la Commune"

J'ai corrigé rapidement - Petits messages d'erreurs sur les rôles dans relation 
eau que je vérifierai ce soir. Je dois maintenant m'absenter.


 
Pierre 
 

    Le jeudi 12 décembre 2019 13 h 29 min 00 s UTC−5, Pierre Béland via Talk-ca 
 a écrit :  
 
 Ce que je vois à partir de JOSM, il y a doublons- 3 chemins superposés pour 
décrire le contour de l'ile

Je suis a corriger. attendre avant d'éditer a nouveau.
 
Pierre 

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

Re: [Talk-ca] Parc des Ïles de Boucherville

[Pierre Béland via Talk-ca]

Ce que je vois à partir de JOSM, il y a doublons- 3 chemins superposés pour 
décrire le contour de l'ile

Je suis a corriger. attendre avant d'éditer a nouveau.
 
Pierre 
 

Le jeudi 12 décembre 2019 12 h 23 min 42 s UTC−5, Martin Chalifoux via 
Talk-ca  a écrit :  
 
 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
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] cyclosm.org

[Pierre Béland via Talk-ca]

Les développeurs de osm-fr ont partiellement rétabli. 

Voir discussions à ce sujet sur talk-fr 
https://lists.openstreetmap.org/pipermail/talk-fr/2019-November/094895.html
Si autres problèmes n'hésitez pas à leur signaler sur talk-fr. 
Pierre 

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

Re: [Talk-ca] cyclosm.org

[Pierre Béland via Talk-ca]

confirmation que inopérant avec exemple de requête de tuile
https://dev.c.tile.openstreetmap.fr/cyclosm/12/2076/1412.png Je vais signaler 
le problème sur talk-fr

Pierre 
 

Le mardi 12 novembre 2019 15 h 33 min 43 s UTC−5, Alouette955 
 a écrit :  
 
 En effet la couche CyclOSM de cette carte ne se rafraichit plus. En activant 
l’icone “Information” à gauche on peut lire, entre autre:
 The tile server hosting this demonstration is provided by 
Peut-être est-ce là la raison et espérons que ça passera le stade de 
démonstration. En attendant je vous invite ici à y activer les couches 
OpenStreetMap.org surtout en ajoutant la couche Waymarked trail. On y voit 
toutes les relations NCN, RCN, LCN en surcouche. Isolés comme ça il est facile 
de trouver les segments non “relationnalisés”. J’y apprend la création des RM19 
et RM23 sur l’île Perrot ... probablement à titre de test??? Claude From: 
Pierre Boucher Sent: Tuesday, November 12, 2019 2:45 PMTo: 
talk-ca@openstreetmap.org Subject: [Talk-ca] cyclosm.org La carte cyclosm.org 
semble avoir un problème...  




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

[Talk-ca] Saint-Jean-sur-Richelieu, Qc le nouveau pont Gouin est ouvert depuis ce matin

[Pierre Béland via Talk-ca]

J'ai édité la zone autour du pont et transféré les diverses relations vers le 
nouveau pont pour les bus, velo et les restrictions routières ajoutées par 
Telenav.
voir https://www.openstreetmap.org/#map=18/45.30591/-73.24926

J'invite ceux qui connaissent les itinéraires vélos à les réviser. À noter que 
la route Champlain était incomplète + contenait plus d'un itinéraire dans le 
vieux Saint-Jean + un détour jusqu'à Chambly.
J'invite également les contributeurs de Telenav à s'assurer que leurs relations 
de restrictions routières sont fonctionnelles.
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] lcn=yes et RM20

[Pierre Béland via Talk-ca]

Je suis aussi d'avis qu'il faut utiliser des relations.  De cette façon, nous 
pouvons clairement identifier chaque itinéraire, cela incluant les zones où les 
itinéraires se chevauchent.
dans un tel cas, deux relations une régionale, une nationale peuvent 
représenter ces circuits avec les clés OSM de réseau vélo ajoutées aux 
relations et non pas sur les chemins.



 
Pierre 
 

Le jeudi 24 octobre 2019 11 h 52 min 35 s UTC−4, Alouette955 
 a écrit :  
 
 En effet même en éliminant lcn=yes et en créant des routes locales il est fort 
plausible qu’une route régionale n’emprunte qu’une partie d’une route locale et 
bifurque sur une route locale d’une autre municipalité. C’est le propre d’une 
route régionale de se faire un chemin au travers les municipalités. Le mot 
“route” a plusieurs définitions différentes et ambigües en français. Dans la 
page Wiki en français concernant les routes cyclables on utilise le terme 
“itinéraires cyclables” pour lesquels on privilégie la création de relations.   
 https://wiki.openstreetmap.org/wiki/FR:Itin%C3%A9raires_cyclables Claude From: 
Martin Chalifoux via Talk-ca Sent: Thursday, October 24, 2019 10:45 AMTo: 
Pierre Boucher Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] lcn=yes et 
RM20 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



|  | 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
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] Pertinence de lcn=yes pour le Québec

[Pierre Béland via Talk-ca]

Je trouve sensiblement la même chose- 8 099 chemins
-      90 relations
 Pour ce qui est de la clé lcn=yes sur les chemins, cela me semble aussi 
inutile.  On peut distinguer les réseaux plus importants (niveau local ou 
autre) en créant une relation regroupant divers segments.
Sans doute plusieurs contributeurs ne font que suivre la liste sans intervenir. 
Bonne occasion de commenter même brièvement ou indiquer simplement votre accord 
avec ceci.
Pour les révisions Route Verte peu nombreuses, je pense qu'il est possible de 
procéder dès maintenant.
Pour les révisions lcn sur les chemins, je suggère d'attendre une semaine ou 
deux pour donner le temps à d'autres contributeurs de réagir.
Pierre 

 

Le jeudi 3 octobre 2019 12 h 53 min 48 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, J’extrais et isole ici le sujet “lcn=yes” et vous remarquerez le 
changement d’objet de la conversation. Le message original couvrant les autres 
sujets se trouve ici: 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009443.html Afin 
de bien mesurer l’ampleur j’ai sorti ces données concernant l’utilisation du 
lcn=yes dans les chemins (ways) et network=lcn dans les relations pour le 
Québec. Je crois avoir bien circonscrit les données au Québec dans 
overpass-turbo. Si quelqu’un veut vérifier ces chiffres pour corroborer ma 
démarche. J’ai trouvé:   
   -  8106 chemins avec l’attribut lcn=yes présumé non pertinent puisque cet 
attribut serait réservé aux routes dans des relations. Ces attributs dans les 
chemins devraient alors être systématiquement enlevés. Une vérification 
régulière de la situation pourrait ensuite être faite pour éviter qu’il ne 
réapparaisse de la part de contributeurs non informés.   
  
   -  90 relations avec network=lcn. Il resterait à vérifier la pertinence des 
ces 90 relations après avoir défini ce qui est une route lcn pour le Québec 
puis, sur une certaine période, créer les relations qui correspondraient aux 
routes absentes.
 Ceci touche le travail passé de dizaines sinon centaines de contributeurs qui 
ont cartographié les pistes cyclables et déployé l’usage de lcn=yes. Comment 
les joindre pour avoir leur avis et implanter une nouvelle façon de faire?  Et 
comme le disait Pierre quels critères retenir pour définir ce qu’est une route 
lcn surtout avec la diversité des façons de faire dans les municipalités. En 
l’absence d’une structure provinciale pour avoir cette discussion est-ce qu’une 
discussion à 3 est  satisfaisante. Claude P.S. L’avis des autres contributeurs 
aux réseaux cyclables du Québec présents sur cette liste serait apprécié. From: 
Pierre Béland Sent: Tuesday, October 1, 2019 4:09 PMTo: Talk-CA OpenStreetMap 
Cc: Martin Chalifoux ; Alouette955 Subject: Re: [Talk-ca] Carte velo CyclOSM et 
Référence Route Verte  Le wiki résume la réflexion à un certain moment donné et 
il faut être capable de le réviser si nécessaire. Tout comme pour le réseau 
routier, il y a place à l'interprétation lorsque nous hiérarchisons un réseau.  
Il faut lui donner du sens, et puis oui réduire le bruit avec tous les petits 
segments très locaux. 
 1- L’utilisation de lcn=yes
Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.
 ___
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

[Pierre Béland via Talk-ca]

Le wiki résume la réflexion à un certain moment donné et il faut être capable 
de le réviser si nécessaire. Tout comme pour le réseau routier, il y a place à 
l'interprétation lorsque nous hiérarchisons un réseau.  Il faut lui donner du 
sens, et puis oui réduire le bruit avec tous les petits segments très locaux. 

1- L’utilisation de lcn=yes
Je suis d'accord qu'il faut limiter l'utilisation des références réseau lcn au 
niveau local. On ne devrait oui ne retenir que ce qui correspond a l'ossature 
principale au niveau local. Mais quels critères retenir. Routes connectées à 
ossature principale ? Avec nom ou no ?.
2- LCN, RCN ou NCN
Le réseau Route Verte parcourt l'ensemble du Québec. Des relations nationales 
telles que la Trans-Canadienne ne fait que fédérer ces réseaux provinciaux et y 
ajouter son label.  Je suis d'accord pour classer la route verte comme niveau 
NCN.  La classification RCN pourrait elle être réservée à des routes plus 
régionales, traversant quelques municipalités par exemple.
3. Abbréviation RVD'accord pour enlever tiret. Cela est superflu et prend trop 
de place.
4. TCT
STC En Français TCT en anglais, la meilleure façon d'harmoniser à travers le 
Canada  c'est d'utiliser TC. Cela sera aussi plus court et permettra de mieux 
distinguer route verte lorsque les deux réseaux sont mentionnés.
Je suggère donc d'utiliser TC au Québec. Et nos collègues des autres provinces 
pourront décider à leur tour s'ils souhaitent harmoniser avec TC, plus neutre, 
non relié à une langue particullère.

 
Pierre 
 

Le mardi 1 octobre 2019 13 h 22 min 47 s UTC−4, Alouette955 
 a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  Martin soulève 2 problèmes déjà soulignées par le passé qui méritent chacun 
d’être abordé, peut-être dans des “threads” séparés. 1- L’utilisation de 
lcn=yes Très peu de relations de type lcn existent au Québec. Ça semble 
culturel. Contrairement à Toronto où les routes sont des entités connues avec 
une signalisation numérotée claire (ça se voit sur la carte cyclable: 
https://osm.org/go/ZX4unwl--?layers=C), au Québec on a des pistes cyclables 
locales qui tout au plus portent le nom de la rue sur laquelle elle sont 
tracées. Quand j’ai commencé à m’intéresser aux réseaux cyclables j’avoue avoir 
fait preuve de mimétisme ... lcn (Local Cycle Network) était surtout appliqué 
aux chemins et non à des relations. On semblait vouloir indiquer que la piste 
est de responsabilité municipale (locale). J’ai alors pris ça pour la règle. 
C’était une erreur et je l’admets. Depuis lors j’utilise lcn=yes pour démontrer 
qu’une piste cyclable assez longue permet de transiter entre les quartiers. Il 
serait préférable de créer des relations plutôt mais nous n’avons pas de 
signalisation municipale sur quoi se baser. J’aimerais qu’on puisse discuter un 
correctif. Pourrait-on retirer lcn=yes des chemins afin de créer par la suite 
les routes pertinentes. Gros travail en vue. 2- LCN, RCN ou NCN Martin souligne 
que RCN devrait être réservé aux routes provinciales mais la 
“Canada_tagging_guidelines” dit:
  Signed cycling routes are tagged using the Cycle routes#Relations scheme. 
network=lcn is used for routes within an urban agglomeration, network=rcn 
between agglomerations, and network=ncn for routes spanning an entire province 
or more.
Je sais qu’on peut trouver des indications contradictoires sur le wiki. 
Peut-être ne suis-je pas encore tombé sur la règle expliquée par Martin. J’ai 
donc considéré rcn les routes qui traversent des agglomérations sur une longue 
distance comme celles indiquées par Martin. Et évidemment lcn celles de la 
responsabilité d’une agglomération comme Montréal, Laval, Québec, etc ... 
Doit-on revoir collectivement cette façon de faire?  Claude___
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

[Pierre Béland via Talk-ca]

Merci Claude,
En ce qui a trait au Sentier Trans-Canada, j'ai repéré les relations suivantes :

Relation : Trans Canada Trail (Montreal to Gatineau) (2890229) 
Relation: Trans Canada Trail (Montreal to Sherbrooke) (7633543)
Relation: Trans Canada Trail (Sherbrooke to Quebec City) (7373910)Relation: 
Trans Canada Trail (Quebec City to Beaupré) (7377607)Relation: Trans Canada 
Trail (Beaupré to New Brunswick) (7639926) 
Cette relation est incomplète, il manque la portion Beaupré à Saint-Siméon
 
Pierre 
 

Le lundi 30 septembre 2019 13 h 00 min 42 s UTC−4, Alouette955 
 a écrit :  
 
 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 PMTo: 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 doncref=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
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Carte velo CyclOSM et Référence Route Verte

[Pierre Béland via Talk-ca]

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

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

Je comprends que c'est la saison des tomates. Mais essayons de les utiliser 
pour nos conserves et non comme argument pour convaincre les autres 
contributeurs !  ;)
Comme les autres l'ont exprimé, c'est à ceux qui proposent de faire des imports 
de bien documenter le processus, non l'inverse. Et les menaces d'agir de façon 
impériale et négliger les communautés locales, cela ne tient évidemment pas la 
route.
Pour discuter sur la qualité des données, il est nécessaire de pouvoir 
facilement examiner les données. Et je ne penses pas que les données soient 
comparables d'un endroit à l'autre. La qualité des images, la densité du bâti 
en milieu urbains sont autant de facteurs.
 Les fichiers accessibles aussi bien pour StatCan que Microsoft sont très gros. 
Simplement pour analyser les données de nos municipalités respectives, il faut 
traiter de gros fichiers et tenter d'extraire les données. Ce qui n'est pas 
nécessairement facile et va bien sûr limiter la participation.
Question de donner des exemples sur les limites d'observation des images par 
les technique de AI, j'ai publié des images avec les 2 tweets suivants montrant 
des bâtiments au centre de Toronto :
https://twitter.com/pierzen/status/1177976517902684160
https://twitter.com/pierzen/status/1177978125377884160
On voit bien qu'il ne suffit pas de valider si les angles sont droits. Ces 
exemples montrent bien comment le tracé peut varier significativement vs la 
réalité au sol. Et tout comme les humains, les techniques de AI ont de la 
difficulté à identifier les bâtiments individuels.

cordialement 
Pierre 
 

Le vendredi 27 septembre 2019 22 h 52 min 59 s UTC−4, Jarek Piórkowski 
 a écrit :  
 
 On Fri, 27 Sep 2019 at 11:45, john whelan  wrote:
> ...
> About that time an American mapper, Nate, who was living in Toronto ...

Sorry, one more thing.

Nate was an active editor in Toronto at the time of the initial import
conflict/objection and has remained so as regularly as we can ask of
any community member. In Toronto we call people living here and
contributing to the community "Torontonians".

As you will recall, I disagree with Nate about the suitability of
initial building import data. Notwithstanding, the description quoted
above reads unfairly dismissive to me. You can maybe make arguments
about Torontonians discussing what shouldn't be imported in rest of
Canada, or about whether we should expect mappers to be subscribed to
talk-ca, but let's leave places of birth out of this.

--Jarek

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

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

[Pierre Béland via Talk-ca]

Bonjour John,
De mon côté je n'ai pas encore complété le travail pour réaliser une fonction 
PostGIS pour orthogonaliser les bâtiments.  

Voici cependant une solution possible pour corrger les angles à partir de JOSM 
pour les bâtiments déja importés tel que décrit dans le ticket JOSM 
https://josm.openstreetmap.de/ticket/18171
On y indique :
Since #18000 the test only operates for ways belonging to the download area. 
When using overpass download you don't get complete data, so we don't set 
download bounds in this case. Just make a regular download and you will see 
results (make sure to also enable information level, it has been downgraded in 
#16280 until the autofix works correctly)

Cela fourni les polygones qui ont des angles quasi-rectangulaires.  Les 
paramètres ci-dessous, indiquent de considerer variation de 1 a 10 degres vs 
angle=90   
   -  validator.RightAngleBuilding.maximumDelta=1
   -  validator.RightAngleBuilding.maximumDelta=10

Le raccourci «Q» permet de rendre rectangulaire. Lorsque plusieurs batiments se 
touchent (ie. partagent nodes), on doit tout les sélectionner avant d'appuyer 
sur touche Q.
 
Pierre 
 

Le mardi 24 septembre 2019 18 h 58 min 13 s UTC−4, John Whelan 
 a écrit :  
 
 Where are we up to with imported buildings in Canada?

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

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

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

Thanks John

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

 Bonjour, 
 Je suis de retour du SOTM-2019 à Heidelberg où j'ai pu me rendre grâce à un 
Scholarship de la Fondation OSM.  Des présentations et rencontres fort 
intéressantes. Les videos des présentations sont déja disponibles à partir du 
lien https://media.ccc.de/b/conferences/sotm2019 
 Vous pouvez voir le video de ma présentation «OSM Quality Mapping : Metrics to 
monitor Buildings outbounds» 
 à l'adresse 
https://media.ccc.de/v/sotm2019-1046-osm-quality-mapping-metrics-to-monitor-buildings-outbounds
Les diapos sont disponibles sur le Blog OpendatalRDC. Je prévois aussi y 
publier au cours des prochaines semaines les analyses détaillées des projets 
analysés. 
https://github.com/opendatalabrdc/Blog/blob/master/SOTM_2019-OSM-Quality-Mapping--Metrics-to-monitor-Buildings-outbounds_Pierre_Beland.odp
Je vais aussi réviser le contenu du répertoire OQ_Analysis sur Github avec la 
nouvelle version des fonctions PostGIS contenant les nouvelles variables 
d'analyse que j'ai ajouté au projet.
Lors de la présentation, j'y ai fait une brève comparaison d'imports de données 
comparant Toronto et Dallas (import Microsoft). L'image Microsoft auquelle je 
fait référence pour l'Afrique dans ma présentations est accessible sur 
l'article de Blog  Microsoft releases 18M building footprints in Uganda and 
Tanzania to enable AI Assisted Mapping 
https://blogs.bing.com/BingBlogs/media/MapsBlog/2019/09/Extractions_MusomaTanzania.jpg
Sur cette image, Les données vectorielles de bâtiments observées sont en 
général rectangulaires. Par contre on observe certaines inexactitudes dans les 
géométries dérivées par les technique d'intelligence artificielle (angles 
inexacts ou plusieurs bâtiments regroupés).  J'en ai discuté avec les 
développeurs de Microsoft et nous avons convenu que ceci semble s'expliquer 
dans ce cas spécifique pour la Tanzanie par une moins grande qualité des images 
satellites.

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


Pierre 

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

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

[Pierre Béland via Talk-ca]

Bonjour,
Je suis de retour du SOTM-2019 à Heidelberg où j'ai pu me rendre grâce à un 
Scholarship de la Fondation OSM.  Des présentations et rencontres fort 
intéressantes. Les videos des présentations sont déja disponibles à partir du 
lien https://media.ccc.de/b/conferences/sotm2019
Vous pouvez voir le video de ma présentation «OSM Quality Mapping : Metrics to 
monitor Buildings outbounds» 
 à l'adresse 
https://media.ccc.de/v/sotm2019-1046-osm-quality-mapping-metrics-to-monitor-buildings-outbounds
Les diapos sont disponibles sur le Blog OpendatalRDC. Je prévois aussi y 
publier au cours des prochaines semaines les analyses détaillées des projets 
analysés. 
https://github.com/opendatalabrdc/Blog/blob/master/SOTM_2019-OSM-Quality-Mapping--Metrics-to-monitor-Buildings-outbounds_Pierre_Beland.odp
Je vais aussi réviser le contenu du répertoire OQ_Analysis sur Github avec la 
nouvelle version des fonctions PostGIS contenant les nouvelles variables 
d'analyse que j'ai ajouté au projet.
Lors de la présentation, j'y ai fait une brève comparaison d'imports de données 
comparant Toronto et Dallas (import Microsoft). L'image Microsoft auquelle je 
fait référence pour l'Afrique dans ma présentations est accessible sur 
l'article de Blog  Microsoft releases 18M building footprints in Uganda and 
Tanzania to enable AI Assisted Mapping 
https://blogs.bing.com/BingBlogs/media/MapsBlog/2019/09/Extractions_MusomaTanzania.jpg
Sur cette image, Les données vectorielles de bâtiments observées sont en 
général rectangulaires. Par contre on observe certaines inexactitudes dans les 
géométries dérivées par les technique d'intelligence artificielle (angles 
inexacts ou plusieurs bâtiments regroupés).  J'en ai discuté avec les 
développeurs de Microsoft et nous avons convenu que ceci semble s'expliquer 
dans ce cas spécifique pour la Tanzanie par une moins grande qualité des images 
satellites.

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


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

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

[Pierre Béland via Talk-ca]

Cela semble bien préciser, mais les collègues d'Ontario pourront mieux répondre.
Pierre

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le lun., sept. 9 2019 à 3:11 PM, Jarek Piórkowski a 
écrit :   Hi Pierre,

(I responded via email at first, but realized one more thing, so
adding on and sending to talk-ca:)

The proposed wiki addition does start with "In Ontario". However
thanks bringing this up, as I realized I forgot to account for parts
of Ontario where streets will be named in French - this change should
not apply to those.

I am changing the suggested wording to:

    In parts of **Ontario** that primarily name streets in English,
street and road names containing initial "St." or "St" should only be
expanded to "Saint" when "Saint" is common usage for that street. To
be clear, this overrides the general rule
https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
for "St." which does not stand for "street". As with other names in
OSM, factors you might want to consider when determining common usage
include spellings posted on street signs ("on the ground" rule),
spellings used in local media, GeoBase street name data, and spellings
used by official municipal sources including open data datasets. See
discussion on talk-ca [0].

Would this wording be fine for Ottawa and other bilingual areas, or am
I missing a pitfall?

Thanks,
--Jarek

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

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

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

[Pierre Béland via Talk-ca]

Marek
Ces instructions ne s'appliquent pas à toutes les provinces. Il faudrait donc 
indiquer sur la page wiki à quelles provinces elles s'appliquent
Pierre

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le lun., sept. 9 2019 à 2:51 AM, Jarek Piórkowski a 
écrit :   Hello,

I'm following up on the thread about saints and lack thereof in street
names from a couple of months ago (see archives [1] [2]).

I would like to suggest the following wording added to Canadian
tagging guidelines at
https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Street_names
:

    In Ontario, street and road names containing initial "St." or "St"
should only be expanded to "Saint" when "Saint" is common usage for
that street. To be clear, this overrides the general rule
https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
for "St." which does not stand for "street". As with other names in
OSM, factors you might want to consider when determining common usage
include spellings posted on street signs ("on the ground" rule),
spellings used in local media, GeoBase street name data, and spellings
used by official municipal sources including open data datasets. See
discussion on talk-ca [0].

where [0] would be a link to this message/thread archive. (Comments on
the wording and suggestions appreciated!)

Is anyone opposed to this change?

I have attempted to advertise/announce this proposed change. This was:
- posted in this mailing list in March/April of this year (some quoted
below, see list archives for more discussion)
- I posted a note https://www.openstreetmap.org/note/1741334 in
Toronto with a link to this thread (supportive responses from Kevo and
DannyMcD)
- on April 10, sent a message [2] with a link to the note to editors
who were showing up as top editors on
http://osmstats.neis-one.org/?item=countries=Canada
(they aren't necessarily representative of the community, but it's
really the closest we can reasonably do given our current tooling) [3]
(no private message responses)
- posted on OSM Canada Slack on 17 August
https://osm-ca.slack.com/archives/CASP8UQNT/p1566053199044200
(supportive responses from Matthew Darwin and Eric Geiler)
- on August 27, sent a few more private messages to editors in top 50
on the stats page who had done Ontario edits [4] (no private message
responses)

If you know of anyone else who might have a further opinion on this,
please forward as possible.

Thanks,
--Jarek

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

Re: [Talk-ca] Inconsistencies in names for admin_level=5 boundaries in Québec

[Pierre Béland via Talk-ca]

Bonjour Matthew, 

l'Office de toponomie du Québec (http://www.toponymie.gouv.qc.ca) que nous 
utilisons comme référence pour les noms de lieux au Québec publie une page avec 
les noms de régions 
http://www.toponymie.gouv.qc.ca/ct/normes-procedures/regles-ecriture/comment-ecrire-region-administrative-touristique.html


vs m-dash vs n-dash to separate names (compare Gaspésie–Îles-de-la-Madeleine vs 
Abitibi-Témiscamingue)

Les noms sont écrits avec des tirets plutot que des espaces, et les noms 
composés de deux sous-régions sont séparés par double tiret.

- Saguenay–Lac-Saint-Jean qui regroupe Saguenay et Lac-Saint-Jean  (j'ai 
corrigé selon commission de toponymie et enlevé espace blanc)
- Gaspésie–Îles-de-la-Madeleine

Il y a une exception semble-t-il à la règle (ou oubli?) pour 
Abitibi–Témiscamingue,
vs bracketed numbers appended to the name (Laval, Montréal)
Noms + Numéro, lorsque ville et région portaient le même nom, j'ai ajouté le 
no. de région- Laval (13)
- Montréal (06)
vs spaces between names (compare Abitibi-Témiscamingue vs Saguenay - 
Lac-Saint-Jean
on devrait enlever les espaces
 
Pierre 
 

Le lundi 2 septembre 2019 11 h 24 min 08 s UTC−4, Matthew Darwin 
 a écrit :  
 
   
Hello,
 
I was looking at the admin_level=5 boundaries in Québec, and I notice they 
appear to not be named consistently (list below).  Possible issues:

   - m-dash vs n-dash to separate names (compare Gaspésie–Îles-de-la-Madeleine 
vs Abitibi-Témiscamingue)
   - spaces between names (compare Abitibi-Témiscamingue vs Saguenay - 
Lac-Saint-Jean
   - bracketed numbers appended to the name (Laval, Montréal)
 
I am not an expert in how admin_level=5 boundaries in Québec, were setup, so I 
am just going to point out the difference here and leave it to someone else to 
adjust as necessary.
 
(The reason I'm looking at this is to consider to make Québec regsion into 
multiple parts for faster processing in OSMOSE, based on admin_level=5)
 
 

 
 
Abitibi-Témiscamingue
 Bas-Saint-Laurent
 Capitale-Nationale
 Centre-du-Québec
 Chaudière-Appalaches
 Côte-Nord
 Estrie
 Gaspésie–Îles-de-la-Madeleine
 Lanaudière
 Laurentides
 Laval (13)
 Mauricie
 Montérégie
 Montréal (06)
 Nord-du-Québec
 Nunavik
 Outaouais
 Saguenay - Lac-Saint-Jean
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Pierre Béland via Talk-ca]

Bonjour Steven
Au Québec, nous suivons les conventions de noms établies par la Commission de 
toponymie http://www.toponymie.gouv.qc.ca

Soit abbreviation 1re pour Première, 2e pour Deuxième, etc.

Votre projet est intéressant mais je pense qu'il y a des solutions qui 
éviterait de modifier la base OSM pour l'adapter à votre application Microsoft 
Soundscape. 

Vous pourriez créer une table de conversion qui indiquerait comment convertir 
les nos de rue avec de telles spécificités

code     fr     en1re     Premère avenue First avenue2e 
   Deuxième avenue    Second avenue
 
Pierre 
 

Le vendredi 5 juillet 2019 07 h 41 min 21 s UTC−4, Steven Abrams 
 a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  Hi all, I am working with Microsoft Research and we have an app called 
Microsoft Soundscape (on iPhone only currently) for the Visually Impaired and 
Blind communities. The app provides a 3D map experience and calls out to the 
user several points of interest and road names, all based on OSM data.In Canada 
we have noticed that in the French speaking cities and areas of Quebec, that 
roads may be named "1e Avenue" or "1er Avenue".I am assuming that this should 
be called out as "Première Avenue" in French and "First Avenue" in English. Is 
this correct?But I have noticed that there is no translation for both 
languages. Is it possible for some local OSM mappers to consider providing 
these translations so that apps can callout the names of roads accurately? i.e. 
a user using the French Language & Voice settings would hear "Première" and 
users using the English Language & Voice settings would hear "First"?I have 
included a link to such a road where I have added the English translation. 
https://www.openstreetmap.org/way/20443208What are the thoughts here?
Thanks
Steven___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Inauguration pont Samuel de Champlain

[Pierre Béland via Talk-ca]

Le Ponjt Champlain direction Rive-Sud ferme à 22h ce soir et le nouveau pont 
sera totalement opérationnel lundi 1er juillet. Je viens de réviser le tracé en 
conséquence.  Il ne reste plus pour Claude qu'à réviser les relations de bus 
direction Montréal.

 
Pierre 
 

Le dimanche 23 juin 2019 11 h 42 min 24 s UTC−4, alouette955 
 a écrit :  
 
 Merci Pierre, 
Modifications des lignes de bus direction Montréal effectuées.
Vérification finale à faire demain avec  OSM Inspector.
La suite (direction sud) la fin de semaine prochaine.
Claude



 Message d'origine 
De : Pierre Béland  
Date : 2019/06/22 18:24 (GMT-05:00) 
À : talk-ca , Alouette955  
Objet : Re: [Talk-ca] Inauguration pont Samuel de Champlain 

Claude 

Étant donné que pont déja fermé direction Montréal, J'ai fait les 
modifications. J'ai validé affichage et nouveau pont bien affiché direction  
Montréal. La navigation routière sera sans doute révisée dans les prochaines 
heures.

Tu peux de ton coté modifier les relation de bus direction Montréal.
 
Pierre 
 

Le samedi 22 juin 2019 08 h 06 min 49 s UTC−4, Pierre Béland 
 a écrit :  
 
 Bonjour Claude
Je suis à préparer les modifications pour le côté allant vers Montréal.  Je 
t'indiquerai lorsque complété.

 
Pierre 
 

Le vendredi 21 juin 2019 13 h 16 min 28 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, L’inauguration du pont Samuel de Champlain sur 2 fins de semaine 
exigera les adaptations nécessaires aux données OSM.  Quelqu’un s’y est-il 
préparé? (je suppose que oui puisque les chemins “en construction” existent 
déjà). Pour ma part j’aimerais savoir à quel moment ce sera fait puisque cette 
opération n’inclura probablement pas le déménagement des relations de lignes de 
bus de l’ancien au nouveau pont. Je voudrais m’en occuper en autant qu’on 
m’informe du moment où tout sera “connecté” correctement. 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] Inauguration pont Samuel de Champlain

[Pierre Béland via Talk-ca]

Claude 

Étant donné que pont déja fermé direction Montréal, J'ai fait les 
modifications. J'ai validé affichage et nouveau pont bien affiché direction  
Montréal. La navigation routière sera sans doute révisée dans les prochaines 
heures.

Tu peux de ton coté modifier les relation de bus direction Montréal.
 
Pierre 
 

Le samedi 22 juin 2019 08 h 06 min 49 s UTC−4, Pierre Béland 
 a écrit :  
 
 Bonjour Claude
Je suis à préparer les modifications pour le côté allant vers Montréal.  Je 
t'indiquerai lorsque complété.

 
Pierre 
 

Le vendredi 21 juin 2019 13 h 16 min 28 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, L’inauguration du pont Samuel de Champlain sur 2 fins de semaine 
exigera les adaptations nécessaires aux données OSM.  Quelqu’un s’y est-il 
préparé? (je suppose que oui puisque les chemins “en construction” existent 
déjà). Pour ma part j’aimerais savoir à quel moment ce sera fait puisque cette 
opération n’inclura probablement pas le déménagement des relations de lignes de 
bus de l’ancien au nouveau pont. Je voudrais m’en occuper en autant qu’on 
m’informe du moment où tout sera “connecté” correctement. 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] Inauguration pont Samuel de Champlain

[Pierre Béland via Talk-ca]

Bonjour Claude
Je suis à préparer les modifications pour le côté allant vers Montréal.  Je 
t'indiquerai lorsque complété.

 
Pierre 
 

Le vendredi 21 juin 2019 13 h 16 min 28 s UTC−4, Alouette955 
 a écrit :  
 
 Bonjour, L’inauguration du pont Samuel de Champlain sur 2 fins de semaine 
exigera les adaptations nécessaires aux données OSM.  Quelqu’un s’y est-il 
préparé? (je suppose que oui puisque les chemins “en construction” existent 
déjà). Pour ma part j’aimerais savoir à quel moment ce sera fait puisque cette 
opération n’inclura probablement pas le déménagement des relations de lignes de 
bus de l’ancien au nouveau pont. Je voudrais m’en occuper en autant qu’on 
m’informe du moment où tout sera “connecté” correctement. 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] Batiments - Fonctions orthogonales

[Pierre Béland via Talk-ca]

Bonjour Jarek
extring === external ring groupe de batiments "building.geojson",  batiments 
individuels
exemple  https://www.openstreetmap.org/way/661895520
"building_extring.geojson" batiments adjacents qui partagent des nodesexemple 
http://overpass-turbo.eu/s/JAe
geojson si on clique sur polygone
vars :
| ways_id | 
661895520,639843855,661895517,661895518,661895519,661895521,661895522,661894733 
|
| grp_poly | 7 |


"building_extring_orthogonal.geojson"
Orthogonal === Avec correction orthogonale (squarred result)  A noter version 
préliminaire et améliorations a venircorrection orthogonale - actuellement tous 
les batiments - correction (squarring) si 80 < angle < 100 - aucun filtre 
actuellement 
building_orthogonal.geojson  correction batiments individuels  - on observe 
parfois rotation du batiment - cela pourrait être corrigé en identifiant 
aligmement général du batiment (coté le plus long ?)   et aligner ensuite 
autres cotés.  JOSM, code java fonction orthogonale, si je comprends que c'est 
la procédure suivie


|  * Estimate the direction of the segments, given the first segment points in 
the |
|


|  * direction pInitialDirection. |
|


|  * Then sum up all horizontal / vertical segments to have a good guess for 
the |
|

 * heading of the entire way.
https://github.com/stefanocudini/orthogonalize-js/blob/master/OrthogonalizeAction.josm.java

 
Pierre 
 

Le vendredi 31 mai 2019 17 h 49 min 21 s UTC−4, Jarek Piórkowski 
 a écrit :  
 
 Hi Pierre,

Thanks for sending these out.

Can you briefly confirm what the "building.geojson",
"building_extring.geojson", "building_extring_orthogonal.geojson"
files represent? I'm not really familiar with the terms, perhaps
because I don't have much of a GIS or geometry background. Is the
"extring" file only those buildings that don't have superfluous nodes?
"extring_orthogonal" contains only those that are square and don't
have superfluous nodes?

I guess OSM data is used for easy testing? I remain very interested as
to how the Statcan building footprints for that area look like when
cleaned up - I hope for better accuracy than trying to estimate from
low-res or off-vertical imagery.

It doesn't help that Github GeoJSON preview evidently uses a super-old
version of OSM data for base map...

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

Re: [Talk-ca] Batiments - Fonctions orthogonales

[Pierre Béland via Talk-ca]

Voici des tests supplémentaires qui couvrent la zone proposée par Daniel
source https://github.com/jfd553/OrthogonalizingBuildingFootprint
Les fichiers geojson suivants sont 
disponibleshttps://github.com/pierzen/OQ_Analysis/blob/master/sql/test/geojson/oq_on_toronto_jarek_s2a_building.geojson
https://github.com/pierzen/OQ_Analysis/blob/master/sql/test/geojson/oq_on_toronto_jarek_s2a_building_extring_orthogonal.geojson
https://github.com/pierzen/OQ_Analysis/blob/master/sql/test/geojson/oq_on_toronto_jarek_s2b_building_extring.geojson
https://github.com/pierzen/OQ_Analysis/blob/master/sql/test/geojson/oq_on_toronto_jarek_s2b_building_extring_orthogonal.geojson








 
Pierre 
 

Le lundi 27 mai 2019 13 h 45 min 30 s UTC−4, Pierre Béland via Talk-ca 
 a écrit :  
 
 J'ai progressé dans le développement des fonctions pour orthogonaliser les 
bâtiments.  Ce n'est qu'une version préliminaire, incomplète, mais pour ceux 
intéresés par ces développements, il y a déja sufffisamment de fonctions de 
disponibles pour voir la progression et les défis que cela représente.
J'ai  transféré cette version préliminaire sur Github.  La méthodologie est 
relativement simple conceptuellement, mais il y a beaucoup d'obstacles à 
opérationnaliser avec les outils actuels.  
Une fonction de rotation permet la rotation d'un coté de bâtiment pour rendre 
orthogonal l'angle avec le segment précédent.  Un pivot central au centre du 
segment est utilisé.  Cette méhode peut être rafinée de multiples façons. Mais 
c'est un début.

Je regarde toujours la possibilité d'utiliser les fonctions topologiques pour 
éviter des croisements de bâtiments.
Je vais aussi ajouter de la documentation supplémentaire, et décrire la méthode 
en créant une page wiki dans le répertoire github.
N'hésitez pas à commenter ces développements.
voir 
Fonctions PostgreSQL-PostGIS  Orthogonalisation
https://github.com/pierzen/OQ_Analysis/tree/master/sql/Orthogonal

échantillons et tests
https://github.com/pierzen/OQ_Analysis/tree/master/sql/test

résultats fichiers geojson
https://github.com/pierzen/OQ_Analysis/tree/master/sql/test/geojson 
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Batiments - Fonctions orthogonales

[Pierre Béland via Talk-ca]

J'ai progressé dans le développement des fonctions pour orthogonaliser les 
bâtiments.  Ce n'est qu'une version préliminaire, incomplète, mais pour ceux 
intéresés par ces développements, il y a déja sufffisamment de fonctions de 
disponibles pour voir la progression et les défis que cela représente.
J'ai  transféré cette version préliminaire sur Github.  La méthodologie est 
relativement simple conceptuellement, mais il y a beaucoup d'obstacles à 
opérationnaliser avec les outils actuels.  
Une fonction de rotation permet la rotation d'un coté de bâtiment pour rendre 
orthogonal l'angle avec le segment précédent.  Un pivot central au centre du 
segment est utilisé.  Cette méhode peut être rafinée de multiples façons. Mais 
c'est un début.

Je regarde toujours la possibilité d'utiliser les fonctions topologiques pour 
éviter des croisements de bâtiments.
Je vais aussi ajouter de la documentation supplémentaire, et décrire la méthode 
en créant une page wiki dans le répertoire github.
N'hésitez pas à commenter ces développements.
voir 
Fonctions PostgreSQL-PostGIS  Orthogonalisation
https://github.com/pierzen/OQ_Analysis/tree/master/sql/Orthogonal

échantillons et tests
https://github.com/pierzen/OQ_Analysis/tree/master/sql/test

résultats fichiers geojson
https://github.com/pierzen/OQ_Analysis/tree/master/sql/test/geojson 
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

Merci Daniel, je vais consulter la documentation.

 
Pierre 
 

Le mardi 7 mai 2019 16 h 06 min 40 s UTC−4, Begin Daniel 
 a écrit :  
 
 Tim, Pierre and all,
I have just published the documentation about orthogonalizing building 
footprints on Github. People can then easily access it as it evolves. I have 
made the code available with the test dataset proposed by Jarek. 

So far, I have documented the different concepts behind the approach I use. The 
next step is to detail the different algorithm used to process the building 
footprints.

Running FME requires a licence. However, since the application could eventually 
be translated in an open-source code, the repository could be used for both FME 
and an open-source code.

The repository will also be used to show results on expected problematic 
footprints people would like to see processed, like the test area proposed by 
Jarek.

Thanks,
Daniel

https://github.com/jfd553/OrthogonalizingBuildingFootprint

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Wednesday, May 01, 2019 15:13
To: Tim Elrick; talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: RE: [Talk-ca] Importing buildings in Canada

Bonjour Tim,
Je ne sais pas si Pierre souhaite fusionner les approches, mais il démontre un 
intérêt à programmer. Pour ma part, je n’aime pas beaucoup programmer (python, 
scripts SQL, etc.), mais j’aime bien développer des processus (d’où 
l’utilisation de FME). 

Je vais rendre à terme la documentation du processus (de l’algorithme) et des 
exemples sur Github. Par la suite, ceux qui sont intéressés à développer 
l’application en open source seront les bienvenus et je serai heureux de 
répondre aux questions et d’en discuter :-)

Daniel 

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Tuesday, April 30, 2019 13:30
To: talk-ca@openstreetmap.org; Begin Daniel; Pierre Béland
Subject: Re: [Talk-ca] Importing buildings in Canada

Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.

Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
  de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).

Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

Thanks John


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


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

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

Bonjour à tous
Je suis à tester les fonctionnalités Topologie de PostGIS qui tient compte des 
relations entre les différents polygones.  Cela est prometteur  et je pense 
aussi arriver à une solution très bientôt.

Les fonctions PostGIS et la documentation sont disponibles à 
https://github.com/pierzen/OQ_Analysis 


Pierre 
 

Le mardi 30 avril 2019 13 h 29 min 37 s UTC−4, Tim Elrick  
a écrit :  
 
 Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.

Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
  de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).

Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

Thanks John


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


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

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

[Pierre Béland via Talk-ca]

Une carte détaillée est aussi disponible à partir des liens reçus plus tot.voir 
https://open.canada.ca/data/en/fgpv_vpgf/7a5cda52-c7df-427f-9ced-26f19a8a64d6

Dans le cas de désastres, cette information est sûrement utile notamment pour 
localiser les habitations isolées, les zones inondables. Une grande partie du  
bassin de la rivière Outaouais est déja couverte.
Mais pour l'import dans OSM, il nous reste d'abord à évaluer la qualité des 
données et corriger si nécessaire.

 Pierre 
 

Le samedi 27 avril 2019 14 h 12 min 59 s UTC−4, François Paquette 
 a écrit :  
 
 
HI 

  

>From NRCan web site  
>https://www.nrcan.gc.ca/earth-sciences/geography/topographic-information/free-data-geogratis/whats-new/21747

  

“Natural Resources Canada is pleased to announce its new data layer on 
OpenMaps. The richness of this new data layer comes from information on height 
and elevation of the buildings that will help support Canadian governments 
priorities such as emergency management, particularly for flood and earthquake 
risk analysis. This release contains close to 1 million building footprints. We 
will expand this coverage as more LiDAR data becomes available over Canada.”

  

See the Lidar coverage (in green) 
https://www.nrcan.gc.ca/earth-sciences/geography/topographic-information/free-data-geogratis/whats-new/21742

  

NRCan will continu to add new building

  

Thank you 

  

François Paquette 

  

De : keith hartley [mailto:keith.a.hart...@gmail.com] 
Envoyé : samedi 27 avril 2019 10:54
À : John Whelan
Cc : Alessandro (STATCAN); Talk-CA OpenStreetMap
Objet : Re: [Talk-ca] NRC building footprints - from lidar

  

I think its where there's good lidar data and imagry for extraction in selected 
parts of Canada. The extents are here 
https://open.canada.ca/data/en/fgpv_vpgf/7a5cda52-c7df-427f-9ced-26f19a8a64d6

MB, Nova Scotia, Alberta and BC 

May want to update the building import project as this is a really good source! 

  

On Sat, Apr 27, 2019 at 9:42 AM John Whelan  wrote:


Is it just Manitoba or all of Canada?

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

Thanks John

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



Hi all, 

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

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

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

  

>From what I can tell when placing the data over imagery it's very bang on. 
>Highly accurate, good shapes (unlike the bing files) and well placed. As far 
>as I can tell no one else has uploaded these to OSM. The areas in manitoba are 
>mainly where there's little to no other building info. 

I can write an upload plan on Manitoba wiki as the data is complaint license 
wise. Anything else I should be looking for? The local mappers here are pretty 
excited about it.

  

Keith 

  

  

  

  
___Talk-ca mailing 
listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
  

-- 

Sent from Postbox

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

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Bonjour Tim
À partir de ce protoype développé par Daniel, il serait intéressant oui 
d'orienter le développement vers un outil OpenSource.  Il me ferait plaisir de 
participer avec toi, Daniel et d'autres si intéressés à développer un tel outil.

De mon côté, je ne suis pas un expert SIG ni en PostGIS mais maitrise bien la 
chaine de données Import Osmosis, et les traitements PostgreSQL/PostGIS. 
Pierre 
 

Le mercredi 27 mars 2019 10 h 33 min 09 s HAE, Tim Elrick  
a écrit :  
 
 Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps


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

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur 
Sourceforge et vers un document décrivant la 
méthode.https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool
Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction 
similaire permettrait de réviser les coordonnées de chaque point du polygone.
 http://postgis.net/docs/ST_ShortestLine.html 

Pierre 



 

Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca 
 a écrit :  
 
 Bonjour Tim
Mon outil d'analyse Qualité dont les données sont publiées sur OpenDataLabRDC 
est basé sur PostgreSQL-Postgis.   Je suis à nettoyer / documenter le code et 
prévoit le publier sur github.  J'ai commencé à regarder les outils possibles, 
mais peu de documentation disponible. On parle par exemple de OpenCarto, mais 
l'info n'est plus disponible. A voir si possible à l'aide de Grass. 
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library
 
Pierre   ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Bonjour Tim
Mon outil d'analyse Qualité dont les données sont publiées sur OpenDataLabRDC 
est basé sur PostgreSQL-Postgis.   Je suis à nettoyer / documenter le code et 
prévoit le publier sur github.  J'ai commencé à regarder les outils possibles, 
mais peu de documentation disponible. On parle par exemple de OpenCarto, mais 
l'info n'est plus disponible. A voir si possible à l'aide de Grass. 
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library
 
Pierre 
 

Le mardi 26 mars 2019 21 h 33 min 39 s HAE, Tim Elrick  a 
écrit :  
 
 I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data quality 
(as it orthogonalized the buildings). Even difficult buildings were 
treated well [1].

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

Tim

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

On 2019-03-26 13:45, Jarek Piórkowski wrote:
On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
> 
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

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

Some general thoughts regarding tooling as raised upthread:

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

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

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

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

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

--Jarek

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



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

Re: [Talk-ca] FW: Building Import

[Pierre Béland via Talk-ca]

Voir https://github.com/opendatalabrdc/Documentation/tree/master/topology où 
nous avons entreposé des fichiers geojson du projet de OpenDatalabRDC pour 
consultation.voir par 
exemplehttps://github.com/opendatalabrdc/Documentation/blob/master/topology/topology-irregular-forms-OC_Kampala_hotosm_4360_2018_04_07.geojson
La création d'un répertoire similaire facilliterait la consultations par tous 
des données.  Lors de la consultatin, on clique sur un polygone pour consulter 
les variables d'analyse.
 
Pierre 



 

Le mardi 26 mars 2019 17 h 34 min 24 s HAE, Begin Daniel 
 a écrit :  
 
 Screenshots? A good idea for having everyone seeing the results over 
complicated polygons (I will try keep objective in my selection ;-)

I am working to get it right on multiple adjacent polygons. I'll make the 
results available after I got them.

Daniel

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

Hi Daniel,

If you are interested, some more potentially complicated areas around
Golden Horseshoe for testing. Each is roughly one screen on z16. I
don't know some of these as much, you might want to post results as
data files or screenshots for others to also look at to increase
buy-in.

- Spadina Chinatown and Kensington Market in Toronto, small buildings
tight in against each other, many semi-detached or attached, and some
larger ex-industrial buildings: 43.6569,-79.3868,43.6477,-79.4086
- University of Waterloo, with smaller attached residence buildings
that might have somewhat complicated shapes, as well as large
interconnected school buildings: 43.4740,-80.5362,43.4648,-80.5580
- downtown Kitchener, using a variety of grid alignments and some
buildings that might not be square: 43.4562,-80.4782,43.4470,-80.5000
- downtown Hamilton also has streets that aren't at right angles:
43.2619,-79.8572,43.2527,-79.8790
- St. Catharines might also be not square: 43.1640,-79.2322,43.1547,-79.2540
- Unionville, older area of Markham: 43.8717,-79.2993,43.8625,-79.3211

You will notice a trend of downtowns with non-square grids. I'm sure
others will be happy to contribute more examples of areas with
geometries they'd consider tricky. Bigger buildings might be more
likely to not be square if they're built out to max out the available
lot. I imagine only-slightly-non-square grids will be most
challenging...

--Jarek

On Tue, 26 Mar 2019 at 16:49, Begin Daniel  wrote:
>
> As usual, missed the reply all …
>
>
>
> From: jfd...@hotmail.com
> Sent: Tuesday, March 26, 2019 16:26
> To: 'John Whelan'
> Subject: RE: [Talk-ca] Building Import
>
>
>
> It is really kind to consider my background ;-)
>
> You are right regarding the "black box" approach; this is why a large 
> approval from the community is required before I go further.
>
>
>
> Daniel
>
>
>
> From: John Whelan [mailto:jwhelan0...@gmail.com]
> Sent: Tuesday, March 26, 2019 16:04
> To: Begin Daniel
> Cc: Jarek Piórkowski; talk-ca@openstreetmap.org; keith hartley; Alessandro 
> (STATCAN)
> Subject: Re: [Talk-ca] Building Import
>
>
>
> I think my concerns are to do with the "black box" approach.  Knowing your 
> background I trust your work but others might not.
>
> On a technical side I get the impression that cites with buildings that are 
> close to each other are problematical.  I assume that small locations with a 
> population of say under 125,000 this is an insignificant problem?
>
> The other issue is I'd like to either see buy in from Nate or at least some 
> Toronto mappers to get an indication that something will happen at the end of 
> the day as it is a fair chunk of Daniel's time to work out how do the 
> preprocessing.
>
> I think some BC mappers expressed some doubts as well so perhaps they would 
> like to think about if they are happy or would prefer BC to be outside of the 
> import project and express their views.
>
> Out of interest if it does move ahead are we including the Microsoft data for 
> areas where we do not have data from Stats Canada?  If so we will need to 
> amend the project plan.
>
> My personal view is realistically I think having building information even if 
> its a meter or two out is better than not having the building outlines.
>
> What would be nice is if we could have some indication from places such as 
> Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario excluding 
> Toronto and the other provinces and territories whether they are happy with 
> importing the buildings either from Stats or Microsoft.
>
> I seem to recall Keith is in Manitoba, so any views other than it wasn't 
> present in the first release from Stats?
>
> Note to Alessandro this is just background stuff.
>
> Thanks
>
> Cheerio John
>
> Begin Daniel wrote on 2019-03-26 3:29 PM:
>
> Jarek,
>
> The area you proposed in quite interesting and will force me to look further 
> at buildings with sharing 

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Voici les observations que j'ai fait à Daniel a partir des données du premier 
test qu'il a effectué pour Toronto.

Un premier examen visuel pour le BBOX utilisé montre que l'outil a produit 
correctement les formes orthogonales en général. J'ai constaté cependant des 
cas où un des angles n'aurait pas du être corrigé.   exemple 
https://www.openstreetmap.org/way/285346662
En milieu urbain dense, je constate aussi de nombreux chevauchements de 
polygones avec des bâtiment très prés ou  qui préalablement partagaient un 
vertice commun. Le traitement d'un bloc d'immeuble pourrait être une solution 
pour éviter les chevauchements. Cependant, si on retrouve des angles non 
rectangulaires avec plus de 10 degrés d'écart, il faudrait conserver ces angles 
tels quels.Exemple, batiment 540, qui fait angle non rectangulaires sur un coin 
de rue. https://www.openstreetmap.org/way/661895522
 
Pierre 
 

Le mardi 26 mars 2019 15 h 30 min 13 s HAE, Begin Daniel 
 a écrit :  
 
 Jarek, 
The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.
Daniel  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

John, 

les contributeurs de Ottawa, vous semblez en général d'accord pour poursuivre 
les imports et avez la capacité technique de faire des imports rapides, ce que 
vous avez démontré.  Il ne manque qu'un petit pas à franchir et discuter de la 
qualité des données et accepter de tenir compte des communautés en général.
Essaies tu de dire que les 6 contributeurs qui ont fait des imports se sont 
limités à des territoires locaux, voire leur province et ont discuté avec les 
communautés locales sur la méthodologie satisfaisante pour corriger les données 
avant l'import ?   Pour le Québec, je peux te dire que non.

Je constate plutot un refus de discuter et une volonté de poursuivre malgré les 
opinions divergentes. Et la qualité ?  J'ai clairement démontré il me semble 
que les tracés imprécis étaient clairement visibles.  Et si je comprends bien, 
nous avons maintenant un million de nouveaux bâtiments que l'on pourrait 
«blanchir» si n'importe qui met un tampon approuv dessus.  Je dois dire que 
l'argument est difficile à avaler.
 
Pierre 
 

Le vendredi 15 mars 2019 14 h 02 min 23 s HAE, John Whelan 
 a écrit :  
 
 Which I think comes back to defining the local mappers.

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

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

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

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

Thanks

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

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

[Pierre Béland via Talk-ca]

Réponse immédiate avec refus de discussion de la part de DannyMcD_imports. 
Celui-ci indique qu'il prévoit continuer l'import.voir 
https://www.openstreetmap.org/changeset/67686901
| 
There was a discussion, issues were raised, the problems (to the extent that 
they existed at all) have been addressed. I plan to continue importing, unless 
a *specific* valid issue is raised. Please do not contact me again unless you 
have such an issue.
 |


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

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

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

[Pierre Béland via Talk-ca]

Bonjour Jarek
Ce n'est malheureusement pas le seul contributeur qui agit ainsi.  J'estime en 
divisant (Objets/5) que depuis le 1er février, 6 contributeurs ont importé près 
de 1 million de bâtiments. Selon les commentaires, 5 provinces ont été 
couvertes. Cette information est parfois inexacte. Un fichier json des bbox de 
chaque changeset nous fournirait une information plus précise.Voir par exemple 
https://www.openstreetmap.org/changeset/67725913 
J'ai joint ci-dessous un tableau sommaire et la liste des changesets par 
contributeur.

Nous faisons face à un import massif. Ce ne sont pas des débutants qui font ces 
imports et ces contributeurs doivent justifier leurs actions depuis le début 
février et expliquer la méthode suivie pour corriger les données. 
Je viens juste d'aviser chacun de ces contributeurs de cesser les imports et 
venir en discuter sur la liste.
https://www.openstreetmap.org/changeset/67725913
https://www.openstreetmap.org/changeset/68043362
https://www.openstreetmap.org/changeset/68112880
https://www.openstreetmap.org/changeset/67956418
https://www.openstreetmap.org/changeset/67686901
https://www.openstreetmap.org/changeset/68131003

    Imports Statcan depuis le 1er février - Nombre d'objets par 
province

| 
 | OSM Uiid | 
 | 
 | 
 | 
 | 
 | 
 |
| Province | 215433 | 1919010 | 5214232 | 5323321 | 9266764 | 9444677 | Total |
| Alberta | 152 033 | 
 | 
 | 474 276 | 
 | 586 403 | 1 212 712 |
| BC | 44 115 | 
 | 
 | 1 833 617 | 
 | 506 552 | 2 384 284 |
| New Brunswick | 389 750 | 
 | 
 | 
 | 
 | 
 | 389 750 |
| Ontario | 
 | 2 758 | 
 | 
 | 470 608 | 
 | 473 366 |
| Québec | 297 444 | 
 | 110 484 | 753 | 
 | 
 | 408 681 |
| Total | 883 342 | 2 758 | 110 484 | 2 308 646 | 470 608 | 1 092 955 | 4 868 
793 |


Liste des changesets par contributeurUid 215433 Alberta 67665215, 67665288, 
67665341, 67665453, 67665483, 67665545, 67665602, 67665808, 67665875, 67666001, 
67666180, 67669204, 67669252, 67669308, 67669354, 67669452, 67669522, 67669613, 
67670220, 67670247, 67670273, 67670311, 67670349, 67670387, 67670421, 67670458, 
67670536, 67670908, 67670939BC 67508204, 67508256, 67508291, 67508458, 
67508490, 67508513, 67508622, 67508649, 67508697New Brunswick 67507944, 
67508112, 67508134, 67530245, 67530288, 67530337, 67530387, 67530430, 67530474, 
67530523, 67530791, 67530835, 67531044, 67531220, 67531330, 67531597, 67531938, 
67532009, 67532116, 67532730, 67532743, 67569125, 67569223, 67569803, 67569881, 
67569899, 67569919, 67569960, 67602916, 67603189, 67603261, 67603269, 67603307, 
67603335, 67603367, 67603432, 67603554, 67603678, 67603804, 67604023, 67604270, 
67604320, 6779, 67700103, 67700186, 67700343, 67701266, 67701566, 67704840, 
67704865, 67704907, 67705047, 67705069, 67705120, 67705156, 67705204, 67705284, 
67705553, 67705562, 67705602, 67705662, 67705703, 67705762, 67705815, 67705920, 
67705931, 67706273, 67706329, 67706346, 67706464, 67706503, 67706521, 67719310, 
67719682, 67720148, 67720387, 67720605, 67720722, 67720888, 67720980, 67721152, 
67721270, 67723337, 67724221, 67724317, 67724413, 67724441, 67724618, 67724667, 
67724722, 67724746, 67724785, 67724876, 67724959, 67725077, 67725194, 67725830, 
67725849, 67725878, 67725913, 67725961, 67787993Québec 67498534, 67498609, 
67498689, 67498757, 67498912, 67505394, 67505479, 67505545, 67505558, 67505578, 
67505614, 67505972, 67506005, 67506059, 67506089, 67506346, 67506485, 67506686, 
67506719, 67506875, 67506907, 67506934, 67506947, 67506976, 67507006, 67507027, 
67507041, 67507049, 67507068, 67507105, 67507117, 67507136, 67507160, 67507175, 
67507185, 67507195, 67507202, 67507216, 67507260, 67507285, 67507297, 67507312, 
67507320, 67507331, 67507344, 67507355, 67507356, 67507363, 67520439, 67520589, 
67521376, 67521445, 67521517, 67522086, 67522182, 67523774, 67523861, 67523987, 
67524091, 67524121, 67524132, 67524260, 67524661, 67524728, 67524805, 67525070, 
67525203, 67525335, 67525528, 67526340, 67526436, 67526514, 67526916, 67527123, 
67527293, 67527489, 67527970, 67528040, 67528316, 67528511, 67528581, 67528645, 
67528686, 67528728, 67528787, 67528860, 67528901, 67528967, 67529024, 67529042, 
67529077, 67529173, 67529225, 67529262, 67529307, 67529347, 67529374, 67529413
Uid 1919010 Ontario 68042707, 68042895, 68043362, 68043390, 68043779, 68043921, 
68044088
Uid 5214232 Québec 67957273, 67957348, 67957729, 67958923, 67959011, 67986700, 
67986777, 68069537, 68069649, 68078450, 68078523, 68112014, 68112112, 
68112880Uid 5323321 Alberta 66858409, 66858508, 66858697, 66931104, 66931208, 
66931808, 66932459, 66937105, 66944951, 66945388, 66945814, 66945894, 66946017, 
66946173, 66946358, 66960875, 66961117, 66961283, 66961447, 66962026, 66962184, 
66963495, 66963589, 67022393, 67033345, 67033434, 67033507, 67037604, 67037672, 
67037926, 67038133, 67046475, 67046558, 67046687, 67047191, 67047267, 67047343, 
67047419, 67048115, 67048188, 67048931, 67048997, 67049058, 67049627, 67050230, 
67050277, 

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

[Pierre Béland via Talk-ca]

Danny
Voici un exemple à partir des données d'Ottawa pour tester la fonction de 
correction du Validateur. La requête Overpass ci-dessous permet d'extraire des 
bâtiments jumelés pour les résidences Brookds sur le campus de l'Université 
d'Ottawa.http://overpass-turbo.eu/s/FPT
La correction individuelle de chaque bâtiment à l'aide de la fonction Réparer 
du Validateur JOSM ne corrige que les angles externes et laisse telles quelles 
les nodes partagées avec d'autres bâtiments.   Après correction de tous les 
bâtiments, on constate que les bâtiments ne sont pas orthogonaux là où nodes 
partagées. Et relance lors de la du Validateur, cela n'est pas détecté.
Dans un tel cas, je pense qu'il est mieux de sélectionner un bloc de plusieurs 
bâtiments jumelés et d'utiliser la touche de raccourci «Q» pour orthogonaliser 
l'ensemble. Seul problème, avec le premier bloc de trois bâtiments du haut où 
le bâtiment du centre, le 100 Thomas Moore, a une forme arrondi dans le bas qui 
doit être retracée après l'orthogonalisation. 

Il y a aussi des situations où il semble aussi nécessaire de réviser la forme 
des bâtiments. Voir, par exemple, le 342 Wilbrod street.  La fonction Réparer 
du Validateur JOSM ne donne pas de bons résultats. Après orthogonalisation de 
l'ensemble des trois bâtiments à l'aide de la touche «Q», il est ensuite 
possible selon l'interprétation de l'imagerie de réviser le bâtiment du centre 
à l'aide par exemple de la touche «X».
 
Pierre 
 

Le lundi 4 février 2019 10 h 32 min 17 s HNE, Danny McDonald 
 a écrit :  
 
 In JOSM, open the preferences dialog (F12), go to the data validator tab, and 
click the "show informational level" checkbox (it is third from the top).  Any 
validation done will then check for "Building with an almost square angle", 
which will appear under the Other tab.  "Building with an almost square angle" 
used to cause a Warning, but it was downgraded to Other due to complaints - see 
https://josm.openstreetmap.de/ticket/16280.Danny
On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.

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

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

[Pierre Béland via Talk-ca]

J'ai constaté la même chose a tester CATools. Décevant.

Et merci à Dany, cette fonctionnalité est intéressante.La requête Overpass 
ci-dessous extrait de grands immeubles à Ottawa, certains avec des formes 
rectangulaires, d'autres avec des formes plus complexes, moitié rectangulaire, 
plus divers angles.http://overpass-turbo.eu/s/FNY

Ce qui manque pour corriger de telles géométrie, c'est un outil qui permettrait 
de redresser partiellement, de mettre en parallèle certains cotes, ou redresser 
un angle à 90 degrés, voire 60, 45 a un certain point.  

Pour les demi-cercles, on sélectionne  3 points et outil / Arc de cercle.
 
Pierre 
 

Le lundi 4 février 2019 10 h 50 min 02 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Thanks, it works. Need to run it a few times it looks like. On a random 
Markham block went from 88 warnings down to 4 without ruining geometries, which 
is acceptable IMO. May need to look into its parameters 
(validator.RightAngleBuilding.maximumDelta and 
validator.RightAngleBuilding.minimumDelta) to tweak it for our data.
I've looked into CADTools and BuildingGeneralization plugins but unfortunately 
they don't work properly destroying geometries and rotating polygons.
-- 
Best Regards,
          Yaro Shkvorets  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Pierre Béland via Talk-ca]

En faisant une recherche josm + orthogonal, je trouve ce greffon qui semble 
intéressanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/CADTools Il 
contient différentes fonctions pour corriger les polygones. Je vois que l'on 
utilise une tolérance 85-95 pour les angles droits. Il est aussi possible de 
modifier les paramètres.


Pierre 
 

Le lundi 4 février 2019 09 h 46 min 17 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes. 

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce cas on retrouve des angles qui 
s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement 
facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la 
touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un 
angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le 
greffon ToDo est très utilie pour réviser successivement des données et 
s'assurer de toutes les réviser.

A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous avec 
beaucoup d'angles se rapprochant de 90 degrés mais avec une variance plus 
grande que +-5 degrés. Pour détecter davantage de bâiments quasi-orthogonaux, 
il serait possible de tenir compte de cette situation uniquement pour angles à 
90 avec critère tolérance +-10 degrés. Je vais tester cette option et voir si 
cela permettrait de détecter un grand nombre de cas.angles entre 82.6 et 94.5 
degrés
{82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
https://www.openstreetmap.org/way/479048070
Pierre 
 

Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan 
 a écrit :  
 
 I accept the nicest way is to check the data beforehand.  Scripting it is 
fairly simple.  Are you suggesting a two stage process of take the data and run 
the script first then task manager the data to be imported to manually correct 
the data?  My eyesight isn't good enough to pick out none right angled corners 
so is there some way someone can come up with to feed them into a JOSM todo 
list?

However we have a fairly large number of building outlines that have already 
been imported.  The issue here is different as extra tags have been added.  Can 
the questionable ones be identified in such a way that a JOSM todo list can be 
used to correct them rather than throw out all the work that has been done 
adding tags?
I think you are assuming a more top down management arrangement than exists 
with volunteer Canadian mappers.

Thanks John
  


  

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

John
Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier la 
donnée avant l'importation. Des critères comme ceux que j'ai présenté 
pourraient être utilisés dans un script pour simplifier les polygones qui sont 
quasi orthogonaux. 

Pour simplifier la procédue d'import, deux fichiers distincts pourraient être 
produits :
1. Formes géométriques quasi-orthogonales corrigées - import plus rapide - mais 
a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
2. Formes géométriques irrégulières - Import avec révision / correction plus 
serrée. 

Il reste à ceux qui mènent le projet de faire ces développements logiciels. Et 
pourquoi pas, de proposer des outils que les communautés locales pourront 
ensuite utiliser. Par contre éviter qu'un petit groupe importe rapidement les 
données et ignore le rôle des communautés locales. 

Et l'argument, si tu t'opposes, tu est responsable pour ta communauté, nous ont 
fait le reste du pays, à mon avis cela ne tient pas la route.
 
Pierre 
 

Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan 
 a écrit :  
 
 So you're proposing that a script is run to correct minor deviations in the 
remaining data which sounds a reasonable approach to me and would improve data 
quality.
So run the data through the script.  Then import and run overpass to pick out 
those that need manual adjustment?
If we do this though then I think we need to stay with the single import plan 
rather than have individual import plans popping up that didn't use the scripts.
I have no control over the number of mappers importing or the rate at which 
they import and I'm not sure how you would mange this other than having a 
person identified in the wiki as leading a particular area and there is 
provision or rather was I'm not sure what the latest version says.
Even with smaller import plans there would be nothing to stop one mapper 
bringing in building outlines very quickly.
Cheerio John


 


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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

De tes exemples sortis du chapeau ne font pas avancer la discussion. 

J'attends la démonstration de John que les données d'import pour Ottawa 
représentent bien le contour des bâtiments et sont des données de qualité.
 
Pierre 
 

Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan 
 a écrit :  
 
 From OSMweekly 445 and I'm not sure if it is relevant or not.
Cheerio John


Imports
   
   - Frederik Ramm suggested reverting a four-year-old building import in 
Ulster County, New York State, because only simple squares had been imported 
instead of the correct building outlines. Two years ago the import was featured 
by Worst of OSM.

On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

  
If they weren't hand traced, how were they made? I don't believe I've actually 
seen any documentation on this. Do we know how these buildings footprints were 
made? Just because we didn't trace them from imagery ourselves doesn't mean 
someone working for a city GIS department didn't do exactly the same thing some 
time ago. 
 
 
We're concerned with squaring because buildings generally have right angles. If 
the data don't have right angles too, then like you said it likely indicates 
poor quality data. 
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
  On 2/2/19 10:48 AM, Danny McDonald wrote:
  
 On squaring buildings, no one has yet been explained why buildings should be 
square.  My understanding is that non-square buildings are a warning sign for 
mapathons with hand-traced buildings - the lack of squaring is often noticeable 
for hand-traced buildings, and indicative of generally poor building 
footprints. That doesn't apply here, since the buildings involved are not 
hand-traced (at least in Toronto).  In fact, the imported footprints are 
generally extremely accurate, much better than would (or could) be done by 
hand. 
  It seems like the automated verification tool (of checking whether buildings 
are square or not) is being misapplied in this case. 
  DannyMcD  
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

 Le «acid test» de John, avec une architecture aussi irrégulière, a abimé les 
«Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur Orléans 
à l'extérieur de la zone étudiée ! Une analyse plus approfondie de la zone du 
centre-ville nous montre qu'il y a peu de telles architectures. Cette réponse 
ne tient pas la route et n'explique pas le ratio élevé de polygones avec formes 
irrégulières dans la base OSM.

Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à 
corriger pour orthognaliser. voir 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html

Ce que je comprends bien aux réactions de John depuis le début, c'est laissons 
les données telles qu'elles.  Plusieurs évitent de se pronconcer. Cela ne me 
convainct pas de l'urgence pour un petit groupe de se hâter à importer les 
données sans tenir compte de problèmes de qualité importants.

J'ai révisé mon script qualité pour cerner davantage les formes régulières. Il 
tenait compte jusqu'ici des angles à 90 degrés et des autres formes régulières 
(hexagones, octogones, etc). Je l'ai révisé au cours des derniers jours 
acceptant une tolérance jusqu'à 5 degrés. Les angles à 45 degrés  (ie. 45, 135, 
225, 315) sont maintenant pris en compte. 

Ces modifications ont eu peu d'impact sur le nombre de bâtiments identifiés 
avec formes irrégulières. Cela confirme qu'il a a des polygones avec formes qui 
s'éloignent sensiblement de formes régulières.

Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments peuvent 
être orthogonalisés automatiquement à l’aide de scripts. Ou encore il serait 
possible de réviser tous les bâtiments avec tolérance de 1 à 5 degrés (ceux à 
moins de 1 degrés resteraient tels quels. Malgré tout, Il reste toujours 25% 
des bâtiments qui doivent être analysés manuellement et voir si des corrections 
sont nécessaires.

 Pierre 
 

Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan 
 a écrit :  
 
 I can't think of a way to pull in all the suspect buildings but if you have a 
look here:
https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696

556, 558, 560 are all examples that I think would fail your test.  However they 
are the shape of the buildings.
As far as I am aware we haven't had any outraged users complaining about the 
building shapes in Ottawa and that I think is the acid test.  The Ottawa 
building import has been useful certainly in gaining new mappers and adding 
tags to the outlines.
Your test originally was to pick out very badly mapped buildings that had been 
done in iD and I would agree with you that some were very bad.  Sometimes 3 or 
4 times the size of the building and some very odd shapes indeed.  From memory 
most were done on HOT tasks with the iD editor.
These I think we should definitely aim to avoid but where the representation of 
the building is reasonably accurate then I think they are acceptable.  We are 
using reasonably experienced mappers who would balk at importing some of the 
stuff we saw in Nepal etc and rightly so.  They'd almost certainly be very 
vocal about the quality of the data.
There is a case to be made that most residential buildings would be acceptable 
if they were mapped with the JOSM buildings_tool plugin and all the small blobs 
take up database size.  There is also a case that you get a better sense of the 
building with the small blobs, bay windows etc.  I don't have strong feelings 
either way but I strongly suspect there are examples of both already in OSM in 
Canada.
I note that both Google and Bing have most buildings these days and it has 
almost become a map user expectation.  Certainly there are apps that guide 
blind people that use the building outlines in OSM.  There is a case that says 
to keep up with the competitors we really ought to have buildings.
I think someone else has commented that parts of the Microsoft building outline 
from scanned images in the US is problematic.
So given the results in Ottawa are comparable to Ontario and in my opinion 
Ottawa is acceptable then I think the rest is also acceptable.  Certainly 
Kingston where not all building angles were right angles weren't noticeable to 
me by eye or perhaps my eyesight is just getting worse with age.
Cheerio John


On Thu, 31 Jan 2019 at 19:51, Pierre Béland  wrote:

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173 Batiments avec superposition
Req Overpass 
voirhttps://www.dropbox.com/s/fp1cimouhhfbm9s/on_Ottawa_centre_2019-01-31_batiments_superposes_OSM_req_Overpass.txt?dl=0

11,534 Bâtiments avec formes irrégulières  (56.6%)
Req Overpass voir 
https://www.dropbox.com/s/c68nb9dbudtp679/on_Ottawa_centre_2019-01-31_batiments_irreg_OSM_req_Overpass.txt?dl=0





-

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Ok John,
je vais lancer le script pour Ottawa. Mais je dois régler petit soucis 
d'instabilité  windows avec java et osmosis.  Ne peut mettre a jour java. Et 
powershell refuse parfois de reconnaitre commandes exe.

Parmi tous les scripts de conversion de raster / vectoriel, il serait oui 
intéressant de trouver un script opensource qui corrige les problèmes 
d'orthogonalisation. 

Un défi supplémentaire, lorsque des batiments adjacents partagent des lignes de 
contour. Dans JOSM, lorsque je vois de telles situations, je traite si possible 
en bloc tous les batiments et réoriente ensuite si nécessaire pour mieux 
correspondre à l'imagerie.

 
Pierre 
 

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John
On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
Est-ce un polygone irrégulier ou un effet de perspective? Comment le 
représenter?
"59879471"    "22"    "FB_irreg"    
"{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"    
"{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"

Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
"657790097"    "5"    "FB_irreg"    "{o,o,ir,o,o}"    "{90,91,177.6,91.4,90}" 
Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un premier 
contributeur le voit et dit cela ne semble pas normal et y ajoute un peu de 
distorsion. Un deuxième décide d'y ajouter un point et d'étirer le tout. Si on 
poursuit le dessin dans ce sens, cela finira par ressembler à un clown!


Pierre 
 

Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan 
 a écrit :  
 
 If you take a look at 942 Bridle Path Crescent for example whilst it isn't 
exactly square the deviations from 90 degrees to me are relatively minor.  I 
assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
Are we expecting too high a standard?
Cheerio John

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Nate je viens juste de publier les résultats pour Kingston. Un ratio de 66% de 
polygones avec formes irrégulières. A voir si la simplification éliminerait les 
noeuds qui ont pour effet de créer des formes irrégulières. 

Je n'ai pas encore regardé de près les résultats. Cependant, m on expérience en 
République démocratique du Congo depuis l'an dernier, Kisenso et récemment 
Butembo, a montré qu'a partir de ces diagostics, la validation / correction si 
nécessaire des polygones permettait de réduire fortement les ratios, et ce sous 
les 3% des bâtiments.
Je pense aussi qu'il faut prendre le temps de corriger les données qui risque 
de ne pas être modifiées par la suite. 


 
Pierre 
 

Le samedi 26 janvier 2019 21 h 06 min 39 s HNE, Nate Wessel 
 a écrit :  
 
  
James, 
 
 
It does seem that someone will need to properly simplify the data since you 
don't seem willing to do the necessary work. I've already offered to help, but 
I can't do it today, or tomorrow for that matter. My suggestion, again, is that 
we slow down and take the time to do this right. Rushing ahead can only lead to 
hurt feelings, angry emails, and extra work for everyone. Given how much 
editing goes on in the areas I know, many of these imported buildings might not 
be touched again for another decade - can't we make them right the first time?
 
 
I think Pierre is on the right track here with his thoughtful analysis of the 
buildings that have been imported so far - this is the kind of stuff that I'm 
talking about when I say we need some validation. Some questions that I'd like 
to see answered (Pierre, when you have some more time!): just how many 
buildings imported so far are not orthogonal, but seem like they should be? 
What percentage of buildings would benefit from simplification, and is the 
problem worse/better in some areas compared to others?
 
I actually don't think the problem is technically difficult to solve - we just 
have to understand the nature and extent off the problem before we rush to 
solutions. That's the point of validation - understanding what the problems are.
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Voici mon analyse de la géométrie des bâtiments pour Kingston.  À partir des 
uid des contributeurs ayant participé à l'import, j'ai téléchargé pour Kingston 
5,261 batîments créés ou modifiés par eux depuis le 24 décembre. Le fichier 
résultat montre 5,253 batiments, quelques polygones en erreur éliminés.
Requête Overpass http://overpass-turbo.eu/s/FzI 
Fichier OSM et Résultats d'analyse  
https://www.dropbox.com/s/1dn76c7gmk996ql/on_kingston.import_2018_12_24.osm.zip?dl=0
L'analyse de la géométrie des bâtiments ci-haut révèle que 66% d'entre eux  
(3,475 / 5,261) ont des formes irrégulières.  Ce ratio de géométries 
irrégulières est très élevé, bien au delà de ce à quoi on devrait normalement 
s'attendre. 


méthodologie
À noter que l'analyse qualité avec JOSM permet de détecter de nombreux 
problèmes, incluant les doublons, superpositions.  Mais aucune analyse de la 
géométrie n'est effectuée.  

Mais il est possible malgré tout de d'analyser les géométries et développer des 
indicateurs qui permettent de lever un Drapeau Regarder de plus près au-dela 
d'un certain niveau. J'identifie les formes régulières comme ci-dessous et 
accepte une tolérance de 2.2% plus ou moins avant de signaler comme forme 
irrégulière.

Polygones avec formes régulières
- forme avec angles droits (90 degrés, 270 degrés)- forme avec angles constants 
(hexagone, octogone, etc)

C'est un domaine où on ne peut mesurer à partir d'une simple formule les 
géométries valides même si avec des formes irrégulières.Par contre, tout ratio 
supérieur à 5 % mérite à mon avis d'être analysé de plus près pour expliquer 
les écarts.

Mon script qualité tient compte de tous les noeuds sauf angle=180 degrés pour 
évaluation géométrie.  Vous pourrez comparer dans le fichier analyse les 
diagnostics individuels pour chaque polygone et pour chacun les angles 
correspondants.

ci-dessous, voici des exemples de résultas de l'analyse des 3,475 bâtiments 
avec formes irrégulières. 

 id nb_angles    forme   type angle angles

"56709982"    "5"    "FB_irreg"    "{o,ir,ir,o,o}"    
"{90,174.9,94.6,90.1,90.3}"
id ci-haut a un 5ième angle presque a 180 degrés. faire zoom-in pour voir.

"56997713"    "14"    "FB_oo"    "{oo,oo,o,o,o,o,o,o,o,o,o,o,o,o}"    
"{92.8,92.2,89.9,90.3,89.9,90.4,90,89.7,89.5,89.5,89.3,88.9,89.2,90.1}"id 
ci-haut, 14 angles, très pres de 90 degrés, mais imprécis
À noter que le script est en développement. Si vous trouvez des incohérences, 
me le signaler.
o et r :     formes régulièresFB_oo et FB_rr : formes presque 
régulièresFB_irreg    formes irrégulières

Pierre 

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

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

[Pierre Béland via Talk-ca]

Bonjour James
Je réponds rapidement et reviendrai plus tard avec une analyse quantitative 
pour Kingston où j'observe visuellement beaucoup de formes irrégulières. Pour 
une analyse argumentée, il faut régler les petits soucis. Mon ordinateur plante 
lors de lecture du gros fichier geojson dans QGIS ou JOSM et je n'ai pas de 
script pour le fractionner en fichiers plus petits. J'ai donc fait des extraits 
osm des données importées récemment.

J'analyse donc les données à partir de OSM pour voir les formes irrégulières et 
celles qui pourraient être corrigées.  J'ai fait quelques extraits dans 
différentes villes d'Ontario mais n'ai pas eu le temps de calculer la 
proportion de formes irrégulières.

Pour ce qui est des angles, je ne parles pas ici de que quelques décimales que 
seuls les ordinateurs peuvent déceler !

On doit évidemment ignorer les bâtiments dont les images révèlent une 
architecture de formes irrégulières.  L'analyse consiste davantage à identifier 
les bâtiments mal tracés, dont les angles sont presque droits mais tracés avec 
des angles différents.

L'imagerie Esri haute résolution i a un certain offset vs Bing mais permet de 
zoomer davantage et mieux comparer les formes. Ðans cette zone à Kingston, je 
vois plusieurs bâtiments presque a angle droit. Il est facile dans un tel cas 
de corriger a 90 degrés. 
https://www.openstreetmap.org/#map=21/44.2369514/-76.4905765
Formes régulières dont les angles presque droits devraient être 
corrigésexemplesway(id: 657792023, 657792735, 55652473, 657791586, 61429073, 
657793764); out meta; >; out meta;

Pour angles a 180 degrés, il est possible d'enlever les noeuds à condition que 
non partagés avec bâtiment adjacent. Par contre, ce n'est sans doute pas facile 
à programmer.

Je vois aussi des cas où un bâtiment apparait rectangulaire mais près d'un 
angle un point avec un angle prononcé semble inutile et crée une forme 
irrégulière. Parfois c'est une question d'interprétation lorsque en particulier 
des images ne sont pas prises à la verticale. Un toit, comme ici sur image 
DigitalGlobe Premium laisse croire qu'il y a un angle. Par contre bien tracé 
dans OSM.
http://openstreetmap.org/way/657793764
Et l'architecture d'une ville à l'autre, d'une époque à l'autre crée des formes 
aux géométries très différentes. Cependant mon analyse au cours des derniers 
mois de la géométrie des bâtimemts me fait dire que si le ratio ( batiments 
irréguliers (non orthogonal) / Total bâtiments) est plus grande que 5%, c'est 
un signal qu'il faut analyser les données de près et expliquer pourquoi tant de 
bâtiments ont des formes irrégulières. 

Exemples où je vois des corrections possibles 
way(id: 657794001, 55652494, 657790090, 657794217); out meta; >; out meta;


 
Pierre 
 

Le samedi 26 janvier 2019 10 h 01 min 25 s HNE, James  
a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  i haven't simplified because, no one gave me feedback on the data...Not going 
to process a bunch of datafiles for someone to turn around and say the 
simplification broke something.
On Sat., Jan. 26, 2019, 9:57 a.m. Danny McDonald https://lists.openstreetmap.org/listinfo/talk-ca

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

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

[Pierre Béland via Talk-ca]

Mon problème est dés le téléchargement. Cela m'indique que google ne peut 
effectuer l'analyse d'antivirus et m'offre de télécharger quand même. De là, 
message d'erreur.Voici le message avec Chrome
Ce site ne peut pas fournir de connexion sécurisée

doc-08-3g-docs.googleusercontent.com a envoyé une réponse incorrecte.
   
   - Essayez d'exécuter les diagnostics réseau de Windows.
ERR_SSL_PROTOCOL_ERROR
 
Pierre 
 

Le samedi 19 janvier 2019 23 h 10 min 04 s HNE, James  
a écrit :  
 
 tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre 
bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou 
Linux), qui est servie via la Task Manager. Ce n'est pas la version originale 
de Stats Can, tu as raison, c'sst la version minifié sans les extras tag de 
merde qui sont aucunement utile à OSM.
Je travaille sur les fichiers, car quelqu'un a dit les données était de la 
bouse de vache.
On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland  a 
écrit : 

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


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

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

[Pierre Béland via Talk-ca]

James,

Je pense que nous travaillons sur deux aspects différents. Tu te concentre sur 
la production / correction des fichiers d'import.
A ma connaissance, tu n'a pas décrit le contenu dufichier 
ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import 
originales où tu apportes divers correctifs.
De mon côté, je propose d'analyser le produit final dans la base OSM et mesurer 
pour les données déja téléchargées quelle proportion des bâtiments est avec 
angles droits (orthogonal), et les superspositions.  Cela permettrait 
simplement de comparer ces données avec ce que l'on retrouve ailleurs et 
rassurer sur la qualité globale de l'import par les différents contributeurs. 

Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec formes 
irrégulières,  sinon il faut regarder de plus près et expliquer pourquoi.  Mes 
analyses au cours des derniers 6 mois, incluant révision de Butembo en RDC 
montrent qu'avec une bonne révision on repère beaucoup de bâtiments qui ne 
correspondent pas à ce que l'on observe sur l'imagerie.

Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à partir 
de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un script wget. 
Je ne sais si windows 10 peut ajouter des restrictions que d'autres OS n'ont 
pas.

Pierre 


Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James  a 
écrit : 

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

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

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

[Pierre Béland via Talk-ca]

Effectivement James,
Comme ailleurs en Europe, les communautés OSM sont beaucoup plus organisées.
La communauté OSM-France a mis en place des serveurs qui permettent l'accès à 
la carte OSM. On y retrouve aussi Osmose, uMap et l'hébergement du style 
humanitaire.  Au SOTM-Fr à chaque année,  quelque 100 personnes de tous 
horizons convergent pour y participer. Aussi, beaucoup de projets, notamment 
avec les organisations locales et autres. Et depuis longtemps, ils organisent 
localement des journées OSM avec écoles, municipalités et autres intervenants.

Ils ont donc la capacité de gérer de tels projets, de se coordonner avec les 
établissement scolaires. Ce sera intéressant de voir ce qui sera réalisé dans 
le monde scolaire.
 
Pierre 
 

Le samedi 19 janvier 2019 20 h 47 min 15 s HNE, James  
a écrit :  
 
 That's french: France. Not french: Québec
On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan From weeklyosm:


Education
   
   - The new curriculum (pdf) for French high schools states that all students 
should be introduced to geospatial data usage. One of the expected abilities in 
that domain is the ability to “contribute to OpenStreetMap in a collaborative 
way”.
-- 

What it means is we can expect to see more interest from schools in Canada.  
Adding tags to buildings is fairly simple and less error prone than some 
activities. 

Using streetcomplete I think would work even without buildings.

Thoughts please.

Thanks John





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

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

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

[Pierre Béland via Talk-ca]

Voici une compilation statistique à partir des changesets de OSM pour la grande 
région de Toronto (bbox=-80.8951,42.9142,-78.1046,44.3297).  Depuis 
Pour respecter la politique de confidentialité de OSM, les contributeurs ne 
sont identifiés que selon leur uid.
Depuis décembre, on compte 6 contributeurs, 889 changesets et 6,621,124 objets 
édités (noeuds, chemins ou relations) 
1 immeuble = 5 objets minimumLe fichier de changeset ne fournit que le nombre 
d'objets édités (var num_changes). On ne peut donc à cette étape-ci que 
grossièrement estimer le nombre d'immeubles, sans doute plus de 1 million déjà. 
A partir de Overpass, on ne peut facilement extraire les données. Je vais 
télécharger dans PostGIS un fichier récent de l'Ontario et sélectionner les 
données éditées depuis le 24 décembre (premier jour avec édition )  de ces 6 
contributeurs.  Mon script Qualité permettra également d'analyser la géométrie 
des bâtiments.
lexique
changeset         nombre de changesets (sessions d'édition)num_changes    
nombre d'objets édités dans la sessionavg_changes     moyenne, objets édités 
par changeset
Tableau 1 - Objets édités par contributeur avec moyenne par changeset

| uid | changesets | num_changes | avg_changes | % cum |
| 9266764 | 457 | 3,439,242 | 7,526 | 52.7% |
| 215433 | 197 | 1,619,540 | 8,221 | 77.6% |
| 5214232 | 151 | 815,541 | 5,401 | 90.1% |
| 9343732 | 78 | 628,032 | 8,052 | 99.7% |
| 3016192 | 3 | 17,710 | 5,903 | 100.0% |
| 1919010 | 3 | 1,059 | 353 | 100.0% |
| 
 | 889 | 6,521,124 | 7,335 | 
 |



Tableau 2 - Objets édités par contributeur - jour avec moyenne par changeset

| uid | jour | changesets | num_changes | avg_changes |
| 5214232 | 2018-12-28 | 3 | 10,324 | 3,441 |
| 5214232 | 2019-01-14 | 11 | 58,402 | 5,309 |
| 5214232 | 2019-01-17 | 9 | 57,738 | 6,415 |
| 9343732 | 2019-01-16 | 7 | 63,490 | 9,070 |
| 215433 | 2018-12-29 | 8 | 70,562 | 8,820 |
| 5214232 | 2019-01-16 | 25 | 176,942 | 7,078 |
| 5214232 | 2018-12-23 | 5 | 29,279 | 5,856 |
| 9343732 | 2019-01-14 | 5 | 39,000 | 7,800 |
| 5214232 | 2019-01-12 | 10 | 48,329 | 4,833 |
| 5214232 | 2018-12-24 | 9 | 54,888 | 6,099 |
| 215433 | 2019-01-08 | 13 | 77,332 | 5,949 |
| 9266764 | 2019-01-08 | 20 | 156,232 | 7,812 |
| 9266764 | 2019-01-01 | 9 | 67,167 | 7,463 |
| 9266764 | 2019-01-07 | 19 | 154,837 | 8,149 |
| 215433 | 2019-01-02 | 30 | 280,756 | 9,359 |
| 9266764 | 2018-12-24 | 11 | 66,162 | 6,015 |
| 5214232 | 2019-01-11 | 2 | 6,219 | 3,110 |
| 9343732 | 2019-01-15 | 10 | 75,020 | 7,502 |
| 9343732 | 2019-01-11 | 11 | 82,844 | 7,531 |
| 215433 | 2018-12-30 | 20 | 177,602 | 8,880 |
| 9266764 | 2018-12-31 | 30 | 195,300 | 6,510 |
| 9343732 | 2019-01-12 | 14 | 111,821 | 7,987 |
| 215433 | 2019-01-03 | 25 | 200,002 | 8,000 |
| 9266764 | 2019-01-10 | 33 | 260,886 | 7,906 |
| 215433 | 2019-01-09 | 17 | 138,489 | 8,146 |
| 215433 | 2018-12-31 | 21 | 169,903 | 8,091 |
| 5214232 | 2019-01-09 | 9 | 41,664 | 4,629 |
| 9266764 | 2019-01-13 | 32 | 266,247 | 8,320 |
| 9266764 | 2018-12-29 | 36 | 274,357 | 7,621 |
| 9343732 | 2019-01-10 | 14 | 112,606 | 8,043 |
| 1919010 | 2019-01-17 | 2 | 973 | 487 |
| 9266764 | 2018-12-26 | 29 | 216,701 | 7,472 |
| 215433 | 2019-01-07 | 12 | 93,825 | 7,819 |
| 5214232 | 2019-01-10 | 2 | 718 | 359 |
| 9266764 | 2019-01-09 | 25 | 216,885 | 8,675 |
| 5214232 | 2019-01-08 | 27 | 119,761 | 4,436 |
| 5214232 | 2018-12-25 | 2 | 10,528 | 5,264 |
| 9266764 | 2019-01-06 | 18 | 142,007 | 7,889 |
| 215433 | 2019-01-01 | 6 | 58,083 | 9,681 |
| 9266764 | 2019-01-04 | 7 | 39,155 | 5,594 |
| 1919010 | 2019-01-16 | 1 | 86 | 86 |
| 9266764 | 2019-01-11 | 22 | 174,419 | 7,928 |
| 9266764 | 2018-12-25 | 29 | 188,931 | 6,515 |
| 9266764 | 2018-12-27 | 10 | 67,593 | 6,759 |
| 3016192 | 2018-12-20 | 3 | 17,710 | 5,903 |
| 215433 | 2019-01-04 | 15 | 128,047 | 8,536 |
| 9266764 | 2018-12-30 | 14 | 108,068 | 7,719 |
| 9266764 | 2019-01-15 | 21 | 150,419 | 7,163 |
| 5214232 | 2019-01-15 | 19 | 116,812 | 6,148 |
| 9266764 | 2019-01-14 | 17 | 135,021 | 7,942 |
| 9343732 | 2019-01-13 | 17 | 143,251 | 8,427 |
| 9266764 | 2019-01-12 | 16 | 120,488 | 7,531 |
| 215433 | 2019-01-06 | 13 | 103,233 | 7,941 |
| 5214232 | 2019-01-13 | 11 | 57,670 | 5,243 |
| 5214232 | 2019-01-07 | 4 | 7,256 | 1,814 |
| 215433 | 2019-01-05 | 13 | 99,108 | 7,624 |
| 9266764 | 2019-01-05 | 4 | 25,286 | 6,322 |
| 9266764 | 2019-01-16 | 24 | 204,397 | 8,517 |
| 215433 | 2019-01-17 | 2 | 18,589 | 9,295 |
| 215433 | 2018-12-27 | 2 | 4,009 | 2,005 |
| 9266764 | 2019-01-02 | 13 | 71,064 | 5,466 |
| 9266764 | 2019-01-03 | 18 | 137,620 | 7,646 |
| 5214232 | 2018-12-27 | 3 | 19,011 | 6,337 |
| 
 | 
 | 889 | 6,521,124 | 7,335 |



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

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

[Pierre Béland]

John,
Il y a local et local. Compte-tenu des différences culturelles Québec vs Canada 
en général et que les contributeurs du Québec ne fréquentent pratiquement pas 
cette liste, vous ne devriez pas prendre pour acquis que vous représentez cette 
communauté et pouvez démarrer des projets en son nom.
 
Pierre 
 

Le vendredi 18 janvier 2019 13 h 11 min 37 s HNE, john whelan 
 a écrit :  
 
 I know of no other way to contact him but he made an interesting comment that 
the project is on hold in the wiki pending review.
Would he care to comment on who is supposed to be reviewing the project?
My understanding is that the import was raised in talk-ca before it commenced 
for comment and these were generally favourable.  I took that as the local 
mappers to Canada had been consulted and they are the "local mappers" authority 
in this case.
I understand he has concerns about local mappers making decisions but in Canada 
we have been importing similar data through CANVEC for some time.  CANVEC data 
comes from a number of sources including municipal data.
Is he suggesting that each of the 3,700 municipalities in Canada should form a 
group of local mappers who can make individual decisions on whether their 
municipal data should be imported and we should end up with 3,700 import plans?
Thanks John

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

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude, 

je penses oui que c'est bon maintenant. C'est une procédure déja documentée 
pour l'import de ces itinéraires. Hâte de voir le résultat.
 
Pierre 
 

Le samedi 1 décembre 2018 14 h 58 min 00 s HNE, Alouette955 
 a écrit :  
 
 Merci Pierre, J’ai suivi tes conseils et écrit à la liste 
impo...@openstreetmaps.org:    
https://lists.openstreetmap.org/pipermail/imports/2018-November/005836.html il 
y a deux semaines et j’ai inscrit mon projet sur la page Imports/Catalogue du 
wiki. De plus un lien sur la page du wiki pointe vers une traduction en anglais 
de la page qui explique l’import. N’ayant pas reçu de commentaires au sujet de 
mon projet je me propose d’y aller avec l’import pour les réseaux dont j’ai 
obtenu l’autorisation. Une dernière chance de réagir ... Merci, Claude From: 
Pierre Béland Sent: Wednesday, November 14, 2018 5:26 PMTo: talk-ca ; 
Alouette955 Subject: Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM 
Bonjour Claude, Il faut malheureusement être patients avec les imports. A 
noter, selon la procédure de la Fondation OSM, cette consultation, n'est que la 
première étape. Avant d'importer, il faut écrire sur la liste 
imp...@openstreetmap.org. De là, attend une semaine pour donner le temps de 
réagir.
 Indiques que suite à consultation de la communauté sur talk-ca et obtention 
d'autorisation, tu présentes le projet sur import@osm (voir page wiki contenant 
liens vers autorisations, certaines à venir).

Mentionnes le but de l'import et que méthode est décrite sur la page wiki. 
L'import sera fait par quelques contributeurs seulement qui connaissent le 
schéma de données pour les transports.

Pierre 
  Le mercredi 14 novembre 2018 16 h 48 min 48 s HNE, Alouette955 
 a écrit :   Bonjour, J’ai récemment soumis ici une 
proposition d’import des arrêts d’autobus de l’ARTM pour discussion en 
attendant l’autorisation des opérateurs de réseaux de l’ARTM. Je viens de 
recevoir l’autorisation du Réseau de Transport Métropolitain (exo) et j’ai mis 
à jour la page proposant l’import:    
https://wiki.openstreetmap.org/wiki/FR:Import_arr%C3%AAts_d%27autobus,_ARTM_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 Ayant reçu des commentaires sur ma méthode et l’ayant adaptée en conséquence 
je vais la mettre en oeuvre à moins d’un dernier commentaire de votre part. 
Merci, Claude___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


|  | Virus-free. www.avg.com  |

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

Re: [Talk-ca] BC2020 and School Mappers

[Pierre Béland]

http://jakobmiksch.eu/post/openstreetmap_overview/



 
Pierre 
 

Le samedi 24 novembre 2018 10 h 24 min 06 s HNE, John Whelan 
 a écrit :  
 
 http://teachosm.org/en/

Might be of some use.

Cheerio John

Jonathan Brown wrote on 2018-11-22 7:45 PM:



Alessandro had some engineering profs from the University of Rome working with 
a local high school for testing the mobile app used for BC2020. 

  

Here’s a Comenius program for Life Long Learning of the European Union EU. The 
official title of the project is: "To boost local and international tourism 
with OpenStreetMap". The project's acronym is: "BoostOSM" 
https://wiki.openstreetmap.org/wiki/Life_Long_Learning_Mapping_Project 

  

Jonathan

  

From: John Whelan
Sent: Thursday, November 22, 2018 7:08 PM
To: Jonathan Brown
Cc: Talk-CA OpenStreetMap
Subject: Re: BC2020 and School Mappers

  

I hadn't thought about the programming side but C# certainly can be useful.

https://www.jatws.org/openstreetmap/openstreetmap.html

It needs visual studio 2017 but it has a sample program from which other 
programs looking for other things could be written.

I think that would be high school level though.

There has been some work in creating activities for schools in OSM but they 
would need chasing down.

Cheerio John

Jonathan Brown wrote on 2018-11-22 6:33 PM:




Climate change planning would be good. That topic could be linked to the UN 
sustainable development goals. Also, in Ontario there is a big need to 
incorporate math skills into learning by doing (e.g., 
http://www.barbareeduke.com/ccmath/mathactivities.htm (adapted for OSM), or for 
postsecondary GIS and programming for computer science courses.

At CivicTech Toronto Meetup last Tuesday someone pointed out David MacKay’s 
book Sustainable Energy: Without Hot Air https://withouthotair.com/ 

Jonathan 

 

 

From: john whelan
Sent: Thursday, November 22, 2018 5:46 PM
To: Jonathan Brown
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] BC2020 and School Mappers

 

So what do we need?

 

A hook of some type to build on?

 

An inventory of buildings for climate change planning?  I understand in many 
cities some 80% of apartment buildings are forty years old now and identifying 
them and upgrading them would help with climate change emissions.  
Unfortunately they tend to be privately owned and coaxing landlords to invest 
money is not easy.

 

An introduction to basic stats?

 

I'm not a teacher but I'm sure we can sort something out.

 

We do have a tasking manager that covers Canada so tiles can be set up for a 
local area.

 



I suggest an import first then something after that.

 

Thoughts

 

Thanks John

 

On Thu, 22 Nov 2018, 5:22 pm Jonathan Brown https://lists.openstreetmap.org/listinfo/talk-ca

 


  

-- 

Sent from Postbox

  

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

Re: [Talk-ca] BC2020 and School Mappers

[Pierre Béland]

Peut-être commencer par proposer aux écoles, universités etc. des informations 
leur permettant de s'initier à la cartographie numérique actuelle. Éditer, cela 
est très pointu comme initiation et la très grande majorité quittent après 
quelques heures laissant des données de mauvaise qualité
De fait, ne s'intéressent-ils pas d'abord à ce fameux Web 2.0, OpenSource, 
OpenData avec internet, ordinateurs, téléphones et tabletes, et les nouveaux 
modes sociaux de collaboration?  Il y a aussi les outils d'analyse tel QGIS, 
les outils de requête, toutes les thématiques préssentes sur OSM. Ce domaine 
évolue rapidement et les contributeurs OSM et développeurs collaborent avec 
gouvernements, organismes internationaux etc.
Il est aussi possible d'initier avec des journées thématiques où on visite un 
quartier ou village pour mieux le documenter. De telles journées sont aussi 
l'occasion d'initier par des discussions au monde de la cartographie numérique. 
 

Les projets cartographiques devraient venir ensuite et être mieux planifiés, en 
proposant du matériel et démarche pour un minimum de formation avant de 
cartographier.  Beaucoup de contributeurs OSM sont réticents aux opérations 
marketing de HOT où on invite tous et chacun à venir tracer sur la carte.  De 
grands chiffres de conribution. Mais quelle qualité ?
Les organisateurs de mapathons ne devraient pas avoir des connaissances 
limitées d'OSM. Ils devraient aussi avoir un plan de formation. Le risque comme 
on l'a vu trop souvent est que de nouveaux contributeurs s'initient à OSM en 
démarrant immédiatement la cartographie sans aucune connaissance et quittent 
après quelques heures, laissant souvent un nombre élevé d'erreurs. Avez-vous vu 
l'Analyse Qualité de la géométrie que j'ai produite à partir de 25 projets 
cartographiques HOT  ? 
Habituellement dans une municipalité, on ne retrouve qu'un faible pourcentage, 
nettement moins de 10% d'immeubles avec formes irrégulières (angles autres que 
90°). Beaucoup de projets avaient des taux supérieurs à 10%.
https://lists.openstreetmap.org/pipermail/talk/2018-September/081392.html 


Pierre 



 

Le jeudi 22 novembre 2018 17 h 21 min 27 s HNE, Jonathan Brown 
 a écrit :  
 
 
“Should we try to tailor the information on Building 2020 towards inexperienced 
mappers to make it easier for schools etc to get involved?”

  

Good idea, John. We need a process similar to HOT for local beginners and maybe 
a way of connecting the mapping to a sustainable development challenge in the 
community.

  

Jonathan 

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

Re: [Talk-ca] Tagging paths that are snowploughed?

[Pierre Béland]

Il y a plusierus facettes à considérer ici, soit accès hivernal, état du 
sentier et services accessibles. 

La clé winter_service=yes indiquerait simplement que le sentier est disponible 
l'hiver et ne permettrait pas d'indiquer que le sentier est nettoyé facilitant 
l'accès aux velos.
Voici un usage différent mais qui nous éclaire sur les clés utiliisées pour 
décrire un service hivernal.
La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de service 
hivernal (Service abandonné l'hiver dernier suite à l'ouverture d'une nouvelle 
route).
Dans ce deuxième cas, cette tant le service que la piste n'existent que l'hiver.
Les clés OSM utilisées pour les décrire sont
ice_road=yessurface=ice

Pierre 
 

Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan 
 a écrit :  
 
 Sounds perfect.
Thanks John
On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets https://wiki.openstreetmap.org/wiki/Key%3Awinter_service

On Mon, Nov 19, 2018 at 4:54 PM john whelan  wrote:

Locally some paths across parks etc are snow cleared some aren't.  The ones 
that are are useful for cycling in the winter.
Any suggestions on tags?
Thanks John___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca



-- 
Best Regards,
          Yaro Shkvorets___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude,
Il faut malheureusement être patients avec les imports. A noter, selon la 
procédure de la Fondation OSM, cette consultation, n'est que la première étape. 
Avant d'importer, il faut écrire sur la liste imp...@openstreetmap.org. De là, 
attend une semaine pour donner le temps de réagir.

Indiques que suite à consultation de la communauté sur talk-ca et obtention 
d'autorisation, tu présentes le projet sur import@osm (voir page wiki contenant 
liens vers autorisations, certaines à venir).

Mentionnes le but de l'import et que méthode est décrite sur la page wiki. 
L'import sera fait par quelques contributeurs seulement qui connaissent le 
schéma de données pour les transports.
 
Pierre 
 

Le mercredi 14 novembre 2018 16 h 48 min 48 s HNE, Alouette955 
 a écrit :  
 
 Bonjour, J’ai récemment soumis ici une proposition d’import des arrêts 
d’autobus de l’ARTM pour discussion en attendant l’autorisation des opérateurs 
de réseaux de l’ARTM. Je viens de recevoir l’autorisation du Réseau de 
Transport Métropolitain (exo) et j’ai mis à jour la page proposant l’import:    
https://wiki.openstreetmap.org/wiki/FR:Import_arr%C3%AAts_d%27autobus,_ARTM_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 Ayant reçu des commentaires sur ma méthode et l’ayant adaptée en conséquence 
je vais la mettre en oeuvre à moins d’un dernier commentaire de votre part. 
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] Exit with name on node *and* destination

[Pierre Béland]

Je ne suis pas favorable à lancer une action MapRoulette. Cela ressemblerait à 
une opération pour imposer un schema OSM particulier, voire pour mieux 
contrôler le rendu sur la carte.

J'ai modifié au cours des dernières années ces objets et les noms y sont 
revenus. Peut-être vaut-il mieux alerter les communautés locales et leur 
laisser le temps de décider quoi faire ?
Pierre

   Le mardi 6 novembre 2018 14 h 12 min 01 s HNE, Martijn van Exel 
 a écrit : 

 I did create a MapRoulette challenge to review these named junction nodes for 
the United States just now. See 
https://maproulette.org/mr3/challenge/3253/task/588146c. If you find it useful 
I’d be happy to create one for Canada as well. Or show you how you can do it 
yourself.

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

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Petit test rapide avec Overpass. J'observe que les clés suivantes sont 
utiliséeshighway=serviceservice=emergency_accessaccess=noexemple 
https://www.openstreetmap.org/way/19692719
La Requête Overpass ci-dessous avec paramètre around, détecte les voies de 
service à proximité d'autoroutes sans clé  service=emergency_access ou 
access=no.  Sélection d'un grand bbox requiert long délais d'exécution.  Et 
d'autres chemins de service se retrouvent dans les résultats, notamment les 
voies de service pour haltes routières.
https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450 
Pierre 
 

Le mardi 6 novembre 2018 10 h 33 min 37 s HNE, Martijn van Exel 
 a écrit :  
 
 Is there an Overpass or other query that could detect all these situations? I 
could make a MapRoulette challenge out of them so we can look at them together 
and remove the name on nodes where it's not appropriate / redundant.

I'll ask on IRC as well.. I am not that much of an expert in Overpass.
-- 
  Martijn van Exel
  m...@rtijn.org

On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> Yep, so in this case removing the name and keeping the ref on the
> junction node sounds appropriate.
> 
> While we're at it, the service road
> https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> any of the current imagery in iD. Does it still exist?
> 
> --Jarek
> 
> On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> >
> > Je disais précédemment
> > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > > Il est plus informatif d'afficher le no de sortie (ref=15)
> >
> >
> > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > la carte, la numérotation de la sortie était «noyée» sous le texte.
> >
> >
> > Pierre
> >  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

C'est un Import Canvec. Je ne sais pas quelle est la règle pour ces chemins de 
service de façon générale sur les autoroutes. Les ajoute-t-on systématiquement. 
Si oui, il faudrait ajouter access=no, et sans doute emergency=yes.

Je vois une telle route de service 1km plus au sud, au km 10.  

 
Pierre 
 

Le lundi 5 novembre 2018 20 h 24 min 32 s HNE, Jarek Piórkowski 
 a écrit :  
 
 Yep, so in this case removing the name and keeping the ref on the
junction node sounds appropriate.

While we're at it, the service road
https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
any of the current imagery in iD. Does it still exist?

--Jarek

On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
>
> Je disais précédemment
> > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > Il est plus informatif d'afficher le no de sortie (ref=15)
>
>
> Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur la 
> carte, la numérotation de la sortie était «noyée» sous le texte.
>
>
> Pierre
>  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je disais précédemment> Je ne sais pour les autres provinces, mais au Québec 
les no. de sorties 
> correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> Il est plus informatif d'afficher le no de sortie (ref=15) 

Ici c'est sortie 11pour km 11,  et non 15 comme j'ai dit précédemment. Sur la 
carte, la numérotation de la sortie était «noyée» sous le texte.

 
Pierre 

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

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
correspondent aux bornes kilométriques de la route (ici 15 pour km 15). Il est 
plus informatif d'afficher le no de sortie (ref=15) sur cette node et d'éviter 
d'ajouter le nom de chemin(s) de destination. La destination apparait plutot 
sur le chemin juste après cette node tel qu'il a été fait ici.  Destination= 
Montée Henrysburg

https://www.openstreetmap.org/way/39158262#map=15/45.1094/-73.4699
Il y a quelques années, on voyait souvent le nom sur la node highway_jonction. 
Je pense qu'il est plus approprié de ne mettre que ref. Et les outils de 
navigation savent identifier la clé destination et indiquer le nom des 
destinations pour cette sortie.

voir https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction
 
Pierre 
 

Le lundi 5 novembre 2018 15 h 00 min 57 s HNE, Jarek Piórkowski 
 a écrit :  
 
 I have seen this used in Germany for "junction names", e.g.
https://www.openstreetmap.org/node/30249931 is one of the exits making
up "Frankfurter Kreuz" which is the major interchange near Frankfurt
and has its own (quite extensive) Wikipedia page:
https://de.wikipedia.org/wiki/Frankfurter_Kreuz

I don't know if naming interchanges is common in Quebec. The nearest
thing to named interchanges I can think of off the top of my head in
Ontario is the Basketweave on the 401. This example might be a bit of
tagging for the renderer to get the exit name to show up on the
default OSM.org layer.

--Jarek
On Mon, 5 Nov 2018 at 14:47, Martijn van Exel  wrote:
>
> Hi,
>
> I just came across this
>
> https://www.evernote.com/l/AVCmW6jzawZAoqDxpQTxFydcW-0mCP1Lyqw
>
> The exit _link[0] has destination tagging that reflects what is on the exit 
> sign[1], which is correct.
> But the junction node[2] also has the same destination name in its name tag. 
> Is there some special tagging case that I am missing or should the name tag 
> be removed in this case?
>
> Martijn
>
> [0] https://www.openstreetmap.org/way/39158262#map=16/45.1090/-73.4694
> [1] http://openstreetcam.com/details/1153269/386/edit-osm
> [2] https://www.openstreetmap.org/node/147228435#map=16/45.1090/-73.4667
>
> ___
> 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] Stats Canada new building outlines Open Data do we wish to import it?

[Pierre Béland]

Pour le Québec, je retrouve les données de plusieurs municipalitésMontréal, 
Longueuil, Repentigny, Shawinigan, Québec et Rimouski.
Première observation rapide, aussi, elles sont de bonne qualité et proviennent 
je suppose des cadastres des municipalités. En milieu urbain, cela facilite 
beaucoup l'identification des immeubles juxtaposés.
Je vois ailleurs, aux États-Unis notamment avec les données de Microsoft, que 
les projets sont par région ou municipalité. 

Je pense qu'il faut éviter un projet trop centralisé tant pour assurer un 
meilleur contrôle du déroulement dans chaque municipalité, région que pour 
permettre aux communautés des provinces et communautés locales de s'impliquer. 

La rédaction d' une page wiki pour l'ensemble du Canada peut répondre aux 
exigences du groupe Import de OSM. Mais l'organisation doit être décentralisée.
Le rôle de cette liste doit être un forum pour supporter les communautés des 
provinces et communautés locales. C'est une occasion de dynamiser ces 
communautés avec un projet très intéressant. De là, ils auront le goût de 
compléter la carte pour y décrire les infrastructures locales.  

Si trop de tâches sont initiées en parallèle sur un gestionnaire de tâches, il 
sera très difficile de coordonner, assurer le suivi, une progression 
coordonnée. Il faut éviter que des mapathons ou organisations externes 
s'invitent pour collaborer à de telles tâches avec les milliers et milliers de 
personnes qui viennent jardiner quelques heures sans organisation / formation 
réelle et laissent ensuite le tout sans dessus, dessous. 
Pierre 
 

Le vendredi 2 novembre 2018 16 h 07 min 40 s HAE, James 
 a écrit :  
 
 From my initial glance at the data...seems pretty good and accurate(again I 
didn't check all the cities nor do I expect them all to be having same level of 
accuracy)
The two I've been eye balling are Kingston and Rimouski which seem to be very 
accurate at first assessment. If we do want to import them, a formal draft up 
will have to be done though
On Fri., Nov. 2, 2018, 3:53 p.m. john whelan https://lists.openstreetmap.org/listinfo/talk-ca

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

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

[Pierre Béland]

Merci Javi
Comme mon hébergeur est au Canada, cela serait surprenant.
 
Pierre 
 

Le vendredi 2 novembre 2018 17 h 15 min 56 s HAE, Javi Rodriguez 
 a écrit :  
 
 Hi Pierre, 

Maybe your internet provider has bad connections with Canadian/US carriers.

I mirrored all the data for you. Download it here:
https://www.illot.cat/ODB/

Salutations,
Javi

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

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

[Pierre Béland]

merci,
ip... téléchargement ok, moins de 2min pour chaque fichier.

 
Pierre 
 

Le vendredi 2 novembre 2018 16 h 39 min 55 s HAE, Javi Rodriguez 
 a écrit :  
 
 Hi Pierre,

I did not found any problem with the StatCan website.
I mirrored those files only to test your connection. Test it:

https://www.illot.cat/ODB/BDOI_Quebec.zip
https://www.illot.cat/ODB/ODB_Quebec.zip

Salutations,
Javi

‐‐‐ Original Message ‐‐‐
 On Friday, November 2, 2018 3:38 PM, Pierre Béland  wrote:
 

Bonjour Alessandro

Je rencontre depuis hier des problèmes à télécharger les fichiers pour le 
Québec (fr ou en). Je ne suis sans doute pas le seul et les navigateurs ne nous 
offrent pas d'outils pour reprendre les transferts interrompus ou bien 
diagnostiquer les problèmes, sinon message Échec de transfert.  Le transfert 
est lent et interrompu après plusieurs minutes. Il est possible que votre 
serveur soit surchargé. Dans un tel contexte, il serait sans doute mieux de 
subdiviser les fichiers pour chaque ville ou zone à l'intérieur d'une province.

J'ai testé depuis hier avec les navigateurs Firefox et Chrome et rencontre des 
problèmes d'interruption de transfert avec chacun.  Je n'ai généralement pas de 
problème et ai une bonne connexion internet. 

liens url testés
https://www.statcan.gc.ca/sites/default/files/upload/media/BDOI_Quebec.zip
https://www.statcan.gc.ca/sites/default/files/upload/media/ODB_Quebec.zip 
Pierre 

Le jeudi 1 novembre 2018 14 h 07 min 17 s HAE, Alasia, Alessandro (STATCAN) 
 a écrit :


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


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

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

[Pierre Béland]

Bonjour Alessandro
Je rencontre depuis hier des problèmes à télécharger les fichiers pour le 
Québec (fr ou en). Je ne suis sans doute pas le seul et les navigateurs ne nous 
offrent pas d'outils pour reprendre les transferts interrompus ou bien 
diagnostiquer les problèmes, sinon message Échec de transfert.  Le transfert 
est lent et interrompu après plusieurs minutes. Il est possible que votre 
serveur soit surchargé. Dans un tel contexte, il serait sans doute mieux de 
subdiviser les fichiers pour chaque ville ou zone à l'intérieur d'une province.
J'ai testé depuis hier avec les navigateurs Firefox et Chrome et rencontre des 
problèmes d'interruption de transfert avec chacun.  Je n'ai généralement pas de 
problème et ai une bonne connexion internet. 

liens url testés
https://www.statcan.gc.ca/sites/default/files/upload/media/BDOI_Quebec.zip
https://www.statcan.gc.ca/sites/default/files/upload/media/ODB_Quebec.zip 
Pierre 
 

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

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude, 

Je connais peu les relations pour itinéraires de services de transport.
Le groupe de discussion Import de OSM suit de très près tout import. Et la 
question de licence c'est toujours très litigieux. Si pas indiqué OdBL, il faut 
habituellement une autorisation écrite permettant spécifiquement à OSM 
d'utiliser les données.
Licences ; À première vue RTL Longueuil et STL Laval ont la même licence avec 
un libellé indiquant que pas pour fin commerciales 
-> Automatiquement, cela est non conforme à OdBL et donc il faudrait une 
autorisation écrite
 
Pierre 
 

Le vendredi 19 octobre 2018 13 h 55 min 35 s HAE, Alouette955 
 a écrit :  
 
 Bonjour, Il y a quelques temps je lançais une consultation sur ma proposition 
d’import pour les arrêts d’autobus du Réseau de transport Métropolitain, 
maintenant EXO. J’attends incessamment leur autorisation pour l’import avec 
mention sur la page des contributeurs.    
https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
 Tout commentaire sur ma méthodologie est bienvenue. Depuis j’ai compris que 
EXO, tout comme la STM (Montréal), la STL (Laval) et le RTL (Longueuil) sont 
des opérateurs distincts mais qui collaborent sous l’égide de l’ARTM. Un peu 
compliqué mais maintenant clarifié. J’en ai profité pour créer une page pour 
l’ARTM dans le wiki:   
https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 La STL et le RTM ont une licence qui me semble beaucoup plus permissive:   
http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/  
https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à l’encadré 
Conditions d’utilisation) Je songe donc les inclure à mon projet d’import sans 
autre formalité autre de les indiquer dans la page des contributeurs. La 
question est: Aie-je bien compris ces licences?  Il ne me semble pas que 
l’import dans la base de données OSM est une utilisation commerciale ou quasi 
commerciale mais peut-être y a-t-il un précédent qui m’obligerait à obtenir une 
autorisation spécifique. 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] Question

[Pierre Béland]

Pier Luc,

Nous ne pouvons importer systématiquement dans OSM les Codes postaux, Poste 
Canada prétendant avoir un copyright la-dessus. Mais il est possible pour une 
adresse particulière (un node avec clé addr:housenumber) d'y ajouter aussi un 
code postal.  On retrouve aussi des lignes d'interpolation d'adresse. C'est de 
cette façon que OSM repère le 2985 rue de la Broussaille
voir https://www.openstreetmap.org/way/104093690Cette ligne débute au 2945
https://www.openstreetmap.org/node/1201135774et se termine au 
https://www.openstreetmap.org/node/1201130753
Si tu mettais à jour ces deux nodes en y ajoutant addr:postcode=G2C 1S1
Le bon code postal serait disponible rapidement sur le site. Par contre les 
délais de mise à jour des fichiers obf varie selon chaque éditeur de logiciel.

Une bonne façon pour toi comme collaborateur de Québec de mettre la main à la 
sauce!
Pour ce qui est des résultats lors de la recherche d'adresses, chaque logiciel 
a sa propre méthode. Et les logiciels sur téléphone ou tablette doivent 
économiser l'espace disque.  Méthode sans doute simplifiée.

Tu peux essayer le logiciel Maps.Me disponible pour Android et Apple. Et 
comparer si différent de OsmAND.
 
Pierre 
 

Le vendredi 27 avril 2018 17 h 26 min 56 s HAE, john whelan 
 a écrit :  
 
 Post codes are put in one at a time.  They aren't all there.
If you could help clean them up that would be useful.
Zip codes are different and belong in Donald's land.
Cheerio John



On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:

Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my City 
using offline mode and the OBF file of the Province of Quebec. Every time I 
search an address it can not find it! Sometime it offer me other address, 
sometime not. It's like if only a tiny part of Quebec's address had been insert 
in Open Street Map. But, it's not exactly the case because is has more address 
in Open street Map website.

Look at that example, searching: 2985 rue de la Broussaille.
Osmand can't find it by OSM web site gives:
Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres, Québec, 
Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada

I think it has a problem there. A lot of information should not be there and 
the zip code is bad. It should be G2C 1S1. If that address is in the OBF, I 
supposed the app have difficulties to find it.

The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1, Canada




An other test: 920, rue Noël-Carter


Osmand can't find it but OSM web site can:



École Centre de formation professionnelle Maurice-Barbeau, 920, Rue 
Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération), Capitale-Nationale, 
Québec, G1V 1X3, Canada

The good address is


CFP Maurice-Barbeau
920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada

An other zip code error and an other address full of "dust".

Every-time I tried to find something it's the same thing. It's impossible to 
use Osmand as a GPS in Quebec City. I think it's because the data in the OBF of 
the Province of Quebec is bad.

Is your work have been put in the OBF? Does is exist and other OBF for the 
Province of Quebec than the OF we can find there?
https://download.osmand.net/list.php

Tank-you




   

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

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

[Talk-ca] Réserves, gestion de la faune

[Pierre Béland]

Le contributeur webfil a fait un excellent travail au Québec de cartographier 
les différentes réserves naturelles et territoires de la gestion de la faune. 
Si vous regardez la carte du Québec, vous verrez que ceci comprend de larges 
portions du territoire dans les zones forestières.

Je ne sais ailleurs au Canada, mais au Québec en plus des parcs nationaux et 
réserves strictes de protection de la faune, écologie ou autre, il y a deux 
catégories supplémentaires des territoires publics de gestion de la faune 
(activités de chasse et pêche). Ces territoires sont souvent aussi grands que 
les parcs nationaux.- Zec - gestion par une association
- Pourvoiries - concession de l'exploitation d'un territoire à une entreprise 
privée

Suite à la discussion sur le changeset 
https://www.openstreetmap.org/changeset/53933324#map=8/49.465/-62.898, je 
poursuis ici.

Webfil a classifié 
parc national : boundary=national_parc, leisure=nature_reserve
ZEC: boundary=protected_area, protected_class=7, leisure=national_reserve
Réserve faunique: boundary=protected_area, protected_class=4, 
leisure=national_reserve
Réserve écologique: boundary=protected_area, protected_class=1, 
leisure=national_reserve
Pourvoiries : landuse=commercial

La classification pour les pourvoiries m'apparait inadéquate. On pourrait soit 
classifier de façon similaires aux ZEC, soit indiquer uniquement 
leisure=nature_reserve.

En comparaison, je vois en Colombie-Britannique, un territoire classifié 
leisure=nature_reserve
Relation : Dewdrop-Rosseau Wildlife Management Area (2238697)
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Limites de territoires - Suivi et mise à jour via JOSM

[Pierre Béland]

L'ajout de limites de territoires par les contributeurs canadiens a beaucoup 
progressé au cours de derniers mois.  La carte Osmose permet de visualiser le 
différents niveaux hiérarchiques de territoires complétés pour un pays ou 
région (voir 
http://osmose.openstreetmap.fr/fr/map/#zoom=7=7.28=-4.845==1%2C2===FFTTTFFFT).
À noter que ce travail d'édition doit être fait par des contributeurs 
expérimentés. Et il faut les bons outils. Voici un petit tutoriel où je partage 
mon expérience. J'y décrit également le Style «Admin Boundaries» que j'ai 
ajouté aux Styles JOSM.
Le lien Osmose ci-dessous permet de lister les erreurs pour un pays / région 
donné. Pour chaque erreur, il est possible d'importer les données de cet objet 
directement dans JOSM pour correction en cliquant sur chaque hyperlien.
Exemple 
https://osmose.openstreetmap.fr/fr/errors/?country=ivory_coast=100=1060%2C6010%2C6060
Le style JOSM  Admin_Boundaries que je viens d'ajouter facilite lui l'édition 
dans JOSM.  Il y affiche une carte similaire à Osmose lorsque l'on fait un 
zoom-out, ce qui perment de voir rapidement les zones complétées ou non.  

Pour l'édition dans JOSM, il est possible de travailler avec un ou plusieurs 
niveaux hiérarchiques simultanément. Tout comme dans Osmose, chaque niveau 
hiérarchique est coloré différemment. Aussi, lorsque l'on zoom en détail, 
différent éléments sont mis en évidence pour faciliter l'édition (ie. noeuds de 
connection, chemins non fermés, etc.).
On ajoute ce style dans JOSM à partir du panneau Coloriage1. Sélectionner les 
Préférences (F12)2. Cliquer dans la colonne de gauche sur le 3ième bouton, puis 
sur Coloriage.3. Rafraichir la liste des Styles disponibles en cliquant sur le 
bouton au bas du panneau de Styles disponibles4. Sélectionnez le style 
Admin_Boundaries.Ce style est aussi décrit à l'adresse 
https://josm.openstreetmap.de/wiki/Styles/Admin_Boundaries
Voici un exemple dans JOSM à l'aide d'une requête Overpass pour les limites 
territoriales de Chaudière-Appalaches au Québec. La requête ci-dessous est 
simplement copiée dans la fenêtre de droite (Overpass) du panneau de 
téléchargement JOSM.  Il faut cependant être conscient que l'on ne télécharge 
qu'une partie des données. Cela peut créer des conflits d'édition. Il faudra 
donc s'assurer de ne pas détruire des données telles rivières, routes, etc 
faisant partie des relations de territoire.  On doit aussi recharger les 
données avant le téléchargement vers le serveur pour s'assurer que de nouvelles 
données n'ont pas été ajoutées très récemment et valider s'il y a des conflits 
d'édition.

[out:xml][timeout:40];
 {{geocodeArea:"Chaudiere-Appalaches"}}->.territoire;
  (
  relation["boundary"](area.territoire);
 );
out meta;
>;
out meta;

Après le téléchargement,  les paramètres d'option du style Admin Boundaries 
nous permettent de sélectionner le ou les niveaux administratifs à afficher. 
Voir sur twitter exemple pour la Côte d'Ivoire 
https://twitter.com/pierzen/status/983089154115465217
Pour ce pays, nous pouvons par exemple sélectionner les niveaux 4, 5 et 6. On 
clique sur le style Admin Boundaries dans le panneau coloriage à droite avec le 
bouton droit de la souris, puis sur «Paramètres de style». On sélectionne un 
niveau hiérarchique. Pour en afficher plusieurs simultanément, on répète la 
sélection pour pour chacun.

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

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Martijn
Si je comprends bien ton message, tu proposes que la communauté canadienne 
accepte de réaliser les projets de Telenav, sinon, votre équipe prendra le 
contrôle ?  À mon avis, cette proposition ignore le rôle des communautés 
locales dans le projet OSM, et le réduit à celui d'exécutants.

Les commentaires des contributeurs canadiens allaient tous dans le même sens. 
Nous ne comprenons pas ce que vous visez exactement. Si une simple relation 
Transcanadienne répond à vos besoins, je penses que vous pouvez le réaliser 
facilement. 
Par contre, les contributeurs canadiens ont exprimé leur désaccord à ce que 
vous modifiez systématiquement les routes pour normaliser les noms selon les 
besoins de votre équipe. 
Pierre 
 

Le mercredi 28 mars 2018 15 h 43 min 31 s HAE, Martijn van Exel 
 a écrit :  
 
 Pierre, 

Consistency in the data is the main goal. This benefits all the things you 
mention, including map rendering and parsing by navigation software such as 
ours but also OSMAnd, maps.me and others.
There is a master relation for the Trans-Canada Highway / Route 
Transcanadienne[0] but it is incomplete and broken. One idea would be to repair 
it, and the province-level relations that would be the members of it. Would you 
be interested in coordinating that?

[0] https://www.openstreetmap.org/relation/1307243
--
  Martijn van Exel
  m...@rtijn.org
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Bonjour Martin,
Il me semble que les divers commentaires ont été assez clair. La communauté OSM 
du Canada est assez mature pour gérer cela et n'avons pas besoin que Navteq 
démarre un projet pour modifier ces données.
L'équipe Navteq a déja créé beaucoup de problèmes en ajoutant partout des 
relations complexes pour un simple interdit de faire un virage en U.  Quels 
sont maintenant les objectifs de la tâche
 More Overlapping Ways in CanadaTelenav OSM Integrity Checks's Project
A mon  avis, vous devez discuter avec la communauté canadienne avant de 
démarrer de tels projets. Svp interrompre cette tâche et venez en discuter.

Et quels sont vos objectifs pour les modifications vs la route Trancanadienne? 
Un meilleur rendu sur la carte, des itinéraires dans les outils de navigation ? 
Pourquoi ne pas simplement créer une relation de type route pour la route 
Transcanadienne?

 
Pierre 
 

Le mercredi 28 mars 2018 13 h 23 min 37 s HAE, Martijn van Exel 
 a écrit :  
 
 Hi all, 

My colleague Olivia will respond more in depth with some suggestions based on 
your feedback. Thanks for giving our team's ideas some thought.

In the meantime, as I was writing a post about the new version of MapRoulette, 
I thought I'd make a Challenge for misspelled Trans-Canada Highway names. 
Please find it here: http://maproulette.org/mr3/browse/challenges/2955 . 
There's only a little over 200 tasks, so that should be an easy thing to fix 
together. 

The Challenge is based on this Overpass query: http://overpass-turbo.eu/s/xoW 
-- it's pretty easy to make your own Challenges based on your own Overpass 
queries or GeoJSON files.

The diary post explaining MapRoulette is here: 
https://www.openstreetmap.org/user/mvexel/diary/43596

Thanks,--
  Martijn van Exel
  m...@rtijn.org



On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:


Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient Roumains, 
Javanais ou Américains soit à considérer. Ils nous ont consultés avant de faire 
la modification et c’est parfait. Cependant, je suis entièrement en accord avec 
ta réponse - laissez ça à la communauté canadienne!


 


(I do not believe that the fact these ‘contributors’ are Romanians, Javanese or 
Americans is to be considered. They consulted us before making the change and 
it's perfect. However, I fully agree with your answer - leave that to the 
Canadian community!-)


 


Sent from  Mail for Windows 10


 


From: Andrew Lester 
 Sent: Monday, March 26, 2018 1:35:56 PM
 To: Olivia Robu - (p)
 Cc: talk-ca
 Subject: Re: [Talk-ca] Trans-Canada Highway research  
While standardization may be nice, it often won't be possible even within a 
single country. As has already been discussed, there are differing conventions 
in different provinces, so please don't try to apply a single plan to all 
provinces. How the TCH is handled in OSM will vary depending on the province.

For example, in BC (and some other western provinces), the TCH carries the 1 
ref. In some places where other ref'ed highways coincide with the TCH, the ref 
is recorded as "ref=1;19", for example. There are places within cities where 
the TCH runs on city roads with different names (e.g. Douglas Street in 
Victoria), so those ways are named with the local name and the TCH name is 
recorded in the alt_name or nat_name tag (a separate argument is which one of 
these to use). An alternate name should never be added to the primary name in 
brackets like proposed. That's exactly what the alt_name (and similar) tags are 
for. There are also many places where Trans-Canada Highway is the official 
local name of the road, like most of the highway in BC.

As for the correct spelling of the TCH, I think it would be fairly 
uncontroversial to standardize the name to "Trans-Canada Highway" or "Route 
Transcanadienne" where it's appropriate to use the TCH name, because those are 
the official spellings. Any variants can be considered errors.

As for varying highway classifications, this is correct and to be expected. 
Unlike the US interstate system, the Trans-Canada Highway network varies in 
construction and importance all across the country, so the classification can't 
be standardized to just motorway or trunk. There are sections where primary is 
the most appropriate, and possibly even secondary in some places. Just on 
Vancouver Island alone, the roads designated as the TCH vary from a six-lane 
motorway all the way down to a two-lane effectively-tertiary road.

Since there will need to be a lot of local knowledge required for such a 
project, I strongly recommend that this project not be undertaken by Telenav. 
This is the kind of work that Canadians should be doing, being the most 
familiar with the on-the-ground situation which will dictate how the highway is 
handled in each province. The numerous past issues with Telenav's contributions 
is also a factor that can't be ignored. Does it really make sense for a team of 

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Sur la page wiki https://en.wikipedia.org/wiki/Trans-Canada_Highway, on voit 
que des panneaux Transcanada sont ajoutés sur le côté de la route. Cependant, 
au Québec comme en Ontario, les panneaux de navigation au-dessus de la route ne 
font pas de façon générale référence à la Transcanadienne. 
Comme le dit James, la Transcanadienne, c'est une méta-donnée. Une relation de 
type route permettrait de décrire ce réseau.  
Il serait aussi possible d'ajouter une référence à la Transcanadienne dans la 
clé ref. 
Exemple ref=417; TC(TC pour Transcanadienne).
Exemple où trois routes partagent un segment, ref=35; 104; 133.
voir https://www.openstreetmap.org/way/128245108#map=16/45.3227/-73.2309
Au dela du rendu sur la carte, ces références sont-elles utiles aux outils de 
navigation routière? En ajoutant TC, est-ce que l'on indiquerait à chaque fois, 
Continuez sur la route 417, Transcanadienne ?  Le risque est d'ajouter de la 
confusion dans les instructions de navigation.
Quel est l'objectif de l'équipe de Telenav pour harmoniser les références à la 
Transcanadienne et  ajouter les infos proposées ?

 
Pierre 
 

Le lundi 26 mars 2018 12 h 21 min 52 s HAE, James  a 
écrit :  
 
 http://openstreetview.org/details/23187/73
No trans-canada naming in sight because the trans-canada is a meta road 
composed of multiple highways. See road sign in OSV.
On Mon, Mar 26, 2018, 12:07 PM Kevin Farrugia,  wrote:

The proper name for the highways that are under the Kings Highway system 
(400-Series included) is "Highway xxx" or Highway xx, with the exception of the 
QEW.  Highways signs and government data follow the same rules.
The Trans-Canada as a name/deaignation is almost inconsequential in Ontario and 
to Ontarians.

---
Kevin Farrugia

On Mon, Mar 26, 2018, 11:46 AM Viajero Perdido, 
 wrote:

On 18-03-26 05:33 AM, talk-ca-requ...@openstreetmap.org wrote:
> Message: 3
> Date: Mon, 26 Mar 2018 11:33:14 +
> From: James 
> To: "Olivia Robu - (p)" 
> Cc: Talk-CA OpenStreetMap 
> Subject: Re: [Talk-ca] Trans-Canada Highway research
> Message-ID:
>       
> Content-Type: text/plain; charset="utf-8"
>
> highway 417 should be tagged as highway 417 and not principally transcanada
> way as this is how it's known locally. It can be tagged in transcanada
> relation, but it's mainly known as the 417

I disagree.  "Highway 417" is a low-value name, because the "ref" tag
should already contain the number, causing numbered shields to be
shown.  "Highway 417" is just a verbosification of the number.
"Trans-Canada Highway", however, is a real name; it belongs in the name
field.

This way, most maps would show both name and number.

To me, the (completely separate) issue is whether ordinary numbered
highways should have a name tag at all, "Highway nnn", or simply nothing
because "ref" takes care of it.  I've been able to find no guidance on
this, and I've looked.  I've been leaving "Highway nnn" in place when I
see it, which is most of the time.  But that's another discussion for
another day.

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

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

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

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

[Pierre Béland]

J'ai ajouté short_name pour le Québec, mais je pense effectivement que c'est 
inutile à comparer avec Ontario. Dans ce cas, le ON fonctionne sans doute à 
cause de state_code=ON.
Et effectivement, lorsque les relations de territoires sont ajoutées et 
fonctionnelles, les is_in et addr:province sont inutiles et Nominatim fourni 
correctement l'info.  


 
Pierre 
 

Le lundi 19 mars 2018 11 h 18 min 23 s HAE, Matthew Darwin 
<matt...@mdarwin.ca> a écrit :  
 
  Searching on "110 Laurier Avenue West, on" in Nominatim already works (it 
finds Ottawa City hall) even though the address has no addr:province tag for 
City Halle.  So I don't think this is a good reason to be adding 
addr:province/addr:province:short_name tags. IMO.  Unless there is another use 
case I am missing.  Similarly your example of searching for "Toronto, ON" works 
fine.
 
 I'm guessing this works because the Ontario admin relation has ISO3166-2 tag 
of CA-ON
 
 
 


  On 2018-03-10 04:51 PM, Pierre Béland wrote:
 
   Non, inutile si relations. Dans relation province d'Ontario - ajouter 
short_name='ON'. 
  De cette façon, Recherche Toronto, ON
  devrait fonctionner. A essayer :)
  
   
 Pierre 
   
  
 Le samedi 10 mars 2018 15:39:53 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
  
  So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario
 
  How would that work?
 
 addr:province=Ontario 
  addr:province:short_name=ON ?
 
  Merci John
   
   
 
   ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca