Re: [OSM-talk] Help with reverting a changeset (somebody deleted weeks and weeks of work)

[Pierre Béland via talk]

I reverted the nodes and ways. I think that the relations should be edited 
carefully by someone who knows the content. 
See https://www.openstreetmap.org/changeset/134706111

Pierre


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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

My workflow in the last few days was to select/process series of way id's from 
Frederik list with closed iterations that look to come from the same changeset. 

Using the JOSM Overpass query function with instructions I provided earlier, it 
is easy to download such a block of data, validate and correct with the help of 
the validation functionality. 

But when there is both quadri-duplicates combined with Bad quality problem 
illustrated from the overpass query below, I leave it to Quality teams involved 
in the project (here #hotosm-project-11827) to document and correct. 

See http://overpass-turbo.eu/s/1sQQ

Pierre



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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

From the OSM-id list of Frederik, it is possible to query with Overpass. For 
the following list:

id1,id2,id3,id4
-15538065,-15538064,-15538063,1137657546

I isolate negative values and query as relation, others as way.

[out:xml][date:'2023-03-05T00:00:00Z'];
(
  way(id: 1137657546  
 );
  relation(id: 
15538065, 15538064, 15538063
 );
);
out meta;
>; out meta;

Pierre

Envoyé avec la messagerie sécurisée Proton Mail.

--- Original Message ---
Le mercredi 15 mars 2023 à 07:11, Marc_marc  a écrit :

 
> 
> in fact I was thinking about the overpass turbo query :)
> to test it in my area
> 
> > the 4 dates of edit.
> 
> 

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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Hi Marc,

I created a csv file available on wetranser for 7 days. It contains 
901 quadruplets. For each line, the 4 OSM id's (similar to Frederik list)  + 
the 4 dates of edit.

See https://we.tl/t-rt9KSsZXBD

The osm-id list below refers to 77 buildings (ways) with level, layer or 
building:part attributes:

310361827, 310362676, 310362677, 310362678, 618340953, 618340954, 618340955, 
618340956, 618489859, 618489861, 618489863, 618489865, 618763855, 618763856, 
618763857, 618763858, 626660536, 626660537, 626660538, 626660539, 626660540, 
626660541, 921548773, 921548775, 921550589, 921550590, 921550591, 921550592, 
921550593, 921550594, 921550595, 921550596, 921550597, 921550598, 951883751, 
951883903, 951884118, 951884269, 951884402, 951884775, 951885143, 951885226, 
951885296, 951885425, 951885509, 951885788, 969467331, 1011631197, 1011631208, 
1011631209, 1078444684, 1078444685, 1078444686, 1078444687, 1078444688, 
1078444706, 1078444707, 1078444708, 1078444709, 1078444710, 1078444711, 
1078444712, 1078444713, 1078444714, 1078444715, 1078941994, 1078941995, 
1078941996, 1078941997, 1078941999, 1078942000, 1078942001, 1078942002, 
1078942003, 1078942004, 1078942005, 1078942006


Pierre


--- Original Message ---
Le mardi 14 mars 2023 à 11:51, Marc_marc  a écrit :


> Le 14.03.23 à 13:45, Pierre Béland via talk a écrit :
> 
> > I imported the osm metadata using overpass
> 
> 
> can youu share it to avoid having to make it again :)
> 


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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Marc, I will revise and share data. 

First, below are the instructions to extract relations metadata with 

[out:csv(::changeset, ::timestamp,::user, ::type, ::id, building, highway, 
level, layer, 'building:part', 'building:roof')];
relation(id: 
3240506, 3240507, 3240508, 3240509, 3240510, 3240511, 3240512, 3240513, 
3240514, 3240515, 3240516, 3240517, 8325855, 8325856, 8325857, 8325858, 
8853592, 8898812, 8898813, 8898814, 9168214, 9168215, 9168216, 9168217, 
9168218, 9168219, 9173897, 9173898, 9173899, 9173900, 9173901, 9173902, 
9173903, 9173904, 9173905, 9175052, 9175053, 9175054, 9175055, 9796369, 
9796370, 9796371, 9796372, 10326411, 10326412, 10326413, 10326414, 10784846, 
10784847, 10784848, 10784849, 11305092, 11305093, 11305094, 11305095, 13965409, 
13965410, 13965411, 13965412, 14627860, 14627861, 14627862, 14627863, 15538063, 
15538064, 15538065 
   ); out meta;
Overpass. We can spot other relations with the level attribute.


Pierre

--- Original Message ---
Le mardi 14 mars 2023 à 11:51, Marc_marc  a écrit :


> Le 14.03.23 à 13:45, Pierre Béland via talk a écrit :
> 
> > I imported the osm metadata using overpass
> 
> 
> can youu share it to avoid having to make it again :)
> 
> > Simple Building duplicates from the same contributor are the easy ones to 
> > correct.
> 
> 
> yes, on the condition that you can easily detect when the contributor
> wanted to represent a simple building ?
> I imagine that a first criterion could be the absence of the level layer
> tag (which we see badly used in one of your examples) and perhaps
> building:level
> 
> > osm type nb of quaddup objects
> > way 1 838 3352
> 
> 
> maybe best to focus on that first
> 
> > See https://www.openstreetmap.org/relation/13965412 that contains 
> > way/677238859 with inner role to 6 relations that represent each level of 
> > the building.
> 
> 
> commented https://www.openstreetmap.org/changeset/118924402
> 
> > one building is represented with one way (6 nodes) and 3 relations in which 
> > this way has role=outer.
> > way 1137657546 building=cabin
> > Relation : 15538065 building=yes
> > Relation : 15538064 building=yes
> > Relation : Horsnæs Fangststation (15538063) place=locality
> 
> 
> ccommented https://www.openstreetmap.org/changeset/133075628
> 
> > These are four different relations.
> > -10326414 -10326413 -10326412 -10326411
> > They all share these 2 buildings as outer members.
> > 48002128 505561207
> 
> 
> what's strange is to have managed to do this with iD
> but that's three mistakes :
> - duplicate
> - the garage is not a house
> - the address in Switzerland represents an entrance door and by
> extention the building if this one has only one address. if the no. 7
> represents the house, the garage does have the no. 7 (but probably the
> number 7.1 which is rarely tagged in osm)
> 
> Regards,
> Marc
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Using id's from the Frederick quadruplicate list, I imported the osm metadata 
using overpass. Note thate the negative values in the list represent relations.

The table below shows that the majority of quadruplicate cases implicate only 
one contributor. Simple Building duplicates from the same contributor are the 
easy ones to correct.  It is different for the relations or combination of 
relations/ways where it is sometime necessary to revise the tagging as a 
contributor misused duplicates to represent various levels of a building.

osm typenb ofquaddupobjects
contributors  cases
relation168   272
relation2 936
way 1   838  3352
way 2   134   536
way 3 520

See https://www.openstreetmap.org/relation/13965412 that contains way/677238859 
with inner role to 6 relations that represent each level of the building.

There are also strange schemas. For this block, one building is represented 
with one way (6 nodes) and 3 relations in which this way has role=outer.
  way 1137657546building=cabin
  Relation : 15538065   building=yes
Relation : 15538064 building=yes
Relation : Horsnæs Fangststation (15538063) place=locality

These are four different relations.
-10326414   -10326413   -10326412   -10326411
They all share these  2 buildings  as outer members.
48002128505561207


Pierre


--- Original Message ---
Le samedi 11 mars 2023 à 07:35, Frederik Ramm  a écrit :


> Hi,
> 
> I think an automatic fix of the problem is possible, however it would be
> a good idea to try and find out what the root cause of the problem is -
> bad software, bad imports, bad instructions?
> 
> To get an idea of how big the issue is, I did this on a standard
> rendering database:
> 
> create table buildings as (select way,osm_id from planet_osm_polygon
> where building is not null)
> 
> select a.osm_id, b.osm_id into duplicates from buildings a, buildings b
> where a.osm_id < b.osm_id and a.way ~= b.way and st_equals(a.way,b.way);
> 
> This took a few days - probably it could have been done more efficiently
> - and resulted in a list of about 70k buldings world-wide that are exact
> duplicates (geoetry-wise) of other buildings. The list is here:
> 
> http://www.remote.org/frederik/tmp/duplicatebuildings.csv
> 
> Some buildings are in OSM three or four times (contained i nthe above in
> the form of "a is duplicate of b, b is duplicate of c") but I've
> extracted them in extra files:
> http://www.remote.org/frederik/tmp/triplcatebuildings.csv and
> http://www.remote.org/frederik/tmp/quadruplicatebuildings.csv)
> 
> I don't have the time to analyse the situation in more detail at present
> so if anyone wants to take the above lists as a basis for deeper analysis...
> 
> Cheers
> Frederik


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

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[Pierre Béland via talk]

Why are we mapping these infrastructures. Well these are major infrastructures 
and quite an asset in OSM to let compare from country to country. Dont you know 
https://openinframap.org/ ?

I do map major infrastructures such as dams, hydro-electric power plants and 
substation and high voltage power lines. I dont think that we should neglect 
these infrastructures. Like for highway networks, we should have a 
classification of major high voltage power lines and render them to lower zooms 
then 14. Power Plants and Substations should be searchable in Nominatim. To 
hide these wont protect them as they can be observed easily from the ground.

Pierre​

--- Original Message ---
Le mercredi 18 janvier 2023 à 22:35, Clifford Snow  a 
écrit :

> On Wed, Jan 18, 2023 at 7:05 PM john whelan  wrote:
>
>> Apparently you can do a lot of expensive damage by firing a rifle bullet 
>> through them as happened more than once in the US and given the situation in 
>> Europe at the moment is there a risk that something similar could happen 
>> there?
>>
>> Should we have a process that says some things should not be mapped?
>>
>> I seem to recall that the location of the pipeline that supplies aviation 
>> fuel to airports is considered an official secret in the UK.
>>
>> Thoughts?
>
> I live in one of the states where people fired at and damaged a power 
> substation so I'm concerned about the safety of our infrastructure. 
> Unfortunately there are many infrastructures that are vulnerable to attacks. 
> Such facilities as water plants, dams, bridges, transportation, pipelines, 
> hospitals, and a host of others. But I believe that mapping them can also 
> help. If you go back to the idea that "security through obscurity" I think 
> you'll find that it is just an illusion.
>
> BTW - those caught and charged with damaging a power substation here were 
> looking to rob some stores. We all assumed it was right wing radicals.
>
> Best,
> Clifford
>
> --
>
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Ile des Faisans - îlot historique entre Hendaye - Irun

[Pierre Béland via Talk-fr]

Le jeudi 7 juillet 2022 à 15 h 06 min 9 s UTC−4, Ludovic Hirlimann  a écrit :> 
un cron qui tourne tous les 6 mois, mais je trouve l'interêt limité. On 
> pourrait mettre une note sur l'ile histoire de montrer que ça change 
> tous les 6 mois
  Une solution simple serait de faire passer la frontière au centre de l'île et 
utiliser la description pour expliquer le statut de souveraineté partagée.
 
Pierre 
 

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

[OSM-talk-fr] Ile des Faisans - îlot historique entre Hendaye - Irun

[Pierre Béland via Talk-fr]

L'Île des Faisans https://www.openstreetmap.org/way/177945817 
(https://fr.wikipedia.org/wiki/%C3%8Ele_des_Faisans , 
https://www.bbc.com/travel/article/20220706-europes-island-that-swaps-nationalities),
 cet îlot historique où il y a eu des rencontres diplomatiques des le XVième 
siècle et où se négocia entre autres le mariage de Louis XIV avec l'infante 
d'Espagne a le statut particulier de condominium partagé entre la France et 
l'Espagne avec souveraineté alternée à chaque six mois.  

Ne faudrait-il pas réviser le tracé de la frontière entre les deux pays pour 
refléter ce statut de copropriété, et si oui, comment ?

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

Re: [OSM-talk] Updating of land/water polygons (based on natural=coastline) is too slow and unreliable

[Pierre Béland via talk]

The Saguenay River, a tributary of the Saint-Lawrence Estuary and a major river 
with salty water and tidal is an example where some contributors might have 
difficulty to understand that such rivers correspond to the definition of "sea" 
and should be tagged with natural=coastline. This Fjord more then 100 km long 
is the  southernmost on the planet and connects to a large Estuary. The 
Saint-Lawrence is 25 km wide at the junction of the Saguenay. This thread made 
be go back and notice that a contributor silently removed the coastline a year 
ago.
https://www.openstreetmap.org/changeset/71656040

The monitoring problem is not only technical with broken multipolygons and 
floating continents but also when people decide to remove parts already defined 
as coastlines not understanding this definition and without consensus with the 
community.
 
Pierre 
 

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

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

Hannes,
Ton exemple de doublons, on le retrouve beaucoup.  Et effectivement, le 
validateur JOSM permet de repérer ces doublons.  Et comme Daniel l'a clairement 
expliqué, il faut bien connaitre les données et effectuer les correction 
nécessaires.
Voici un script Overpass pour identifier les doublons  de polygones 
[natural=water] vs [roles inner - natural=wood]. Cette requête Overpass peut 
être lancée à partir de JOSM. 
http://overpass-turbo.eu/s/VW1
Il faut éviter de sélectionner une zone trop grande. Le script va extraire la 
relation natural=wood pour la zone et les chemins en doublon./ relations où 
doublons avec les éléments de cette relation natural=water. 

Le panneau Validation permet ensuite de repérer les doublons. Pour chacun il 
faut ensuite corriger tout en assurant l'intégrité de la relation natural=wood. 
Pierre 
 

Le mercredi 8 juillet 2020 17 h 23 min 04 s UTC−4, Hannes Röst 
 a écrit :  
 
 Dear Daniel Thanks for your answers, I have tried to piece together this 
(apparently 10 year old) history of the import from the mailing list threads 
and the wiki and it has been somewhat difficult, especially as discussions seem 
to have been at multiple places. So, so many discussion about 
forests!...Overall there seem to be some questions about the quality and 
desirability of parts of the import of CanVec with the (Canadian) consus being 
that it is desireable to do the imports. The wiki still indicates to use the 
canvec.osm product even though the timestamps on the files are from 2013 [1] 
and it is not clear whether there is a newer / updated version of the data. 
When I compare the OSM files of tiles from the FTP site to the Toporama product 
doing some spot-checks I find them to be identical for hydrological data 
(wetlands, rivers etc) and almost identical for forests (with Toporama having 
some additional "inner" ways where no forest is, but not always more accurate). 
If my understanding is correct that the WMS endpoints of CanVec and Toporama 
are up-to-date, then this allows us to compare changes in the products since 
2013 when the OSM FTP dump was made. On the other hand in the release notes 
from 2019 [2] they point to an FTP site but that one does not contain OSM files 
and the release notes seem to indicate 2016-01-14 as "original release" of the 
current CanVec data [3]. So it seems our version from 2013 is a bit behind but 
probably the best we have unless somebody is willing to create another export. 
However, it may make sense to load the *current* Toporama WSM layer into JOSM 
during an import and check for any updates since the 2013 dump. On the other 
hand, the data is not very up to date in cities, I found a large industrial 
complex in the Toporama map in downtown Toronto where "Marian Engel Park" is 
since at least 12 years [4], so we have to keep that in mind.  The wiki also 
suggest to use a Google Sheet to track imports, but it does not seem to be used 
a lot - I assume from the wikipage that you have written most of it and 
initiated the import, correct? Best regards Hannes 1. 
https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets2. 
https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/225433.
 
https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf4.
 https://www.openstreetmap.org/way/15804193 Gesendet: Mittwoch, 08. Juli 2020 
um 13:09 Uhr
Von: "Daniel @jfd553" 
An: "pierz...@yahoo.fr" , "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
Betreff: Re: [Talk-ca] NRCan lakesOMG, a lot of pertinent questions!You are 
summarizing questions than were discussed on this list over the last decade. 
Discussions about canvec/osm data modeling, internal canvec data sources, 
import problems, edits problems, and artifacts from osm validation tools' 
history!Because of that, you cannot assume any coast-to-coast consistency with 
the problems you have identified, although you can find them almost 
everywhere.Here are some clues. Canvec model did not change much over years but 
the sources used to build the product changed (from federal to 
provincial/municipal). As far as I know,  canvec.osm product is not maintained 
anymore, even if its last version is still available. When you find 
inconsistencies, look at data history. It may help to identify if a problem 
comes from an initial import, from an adjustment with existing data, from a 
duplicated erroneous import, or from subsequent edits.Good mapping!Daniel
 Sent from Galaxy S7From: Hannes Röst 
Sent: Wednesday, July 8, 2020 11:41:50 AM
To: pierz...@yahoo.fr 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] NRCan lakes 
Dear Pierre
 
Thanks a lot, your explanation of the history is very helpful.  I can also see 
on the wiki and the mailing list some threads and pages that explain the import 
but some of the wiki pages are quite old (10 years or so) and its not clear 
whether they 

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: [OSM-talk] mspray stealth organized mapping

[Pierre Béland via talk]

 Le vendredi 22 mai 2020 10 h 40 min 51 s UTC−4, Mateusz Konieczny via talk 
 a écrit :  
 
> Are you sure that in 72427535 buildings were just moved?
If I place the mouse over a red oultine (old building), Achavi reports «Modify 
geometry»
Loading the changeset in an editor for validation, I confirm that I only see 
create and modify actions.
https://www.openstreetmap.org/api/0.6/changeset/85329885/download
 > buildings and college that used to be mapped at
> https://www.openstreetmap.org/#map=18/-12.94547/28.64318
> It is gone thanks to https://overpass-api.de/achavi/?changeset=72427535
Achavi reports for old building «delete way» and «delete node»
Pierre 

 

Le vendredi 22 mai 2020 10 h 40 min 51 s UTC−4, Mateusz Konieczny via talk 
 a écrit :  
 
 Are you sure that in 72427535 buildings were just moved?
buildings and college that used to be mapped at
OpenStreetMap


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OpenStreetMap

OpenStreetMap is a map of the world, created by people like you and free to use 
under an open license.
 |

 |

 |




It is gone thanks to https://overpass-api.de/achavi/?changeset=72427535

BTW how one may undelete delete buildings? Straight revert will delete new ones,
what may be not needed.

Use reverter plugin in JOSM, copy buildings to a new layer, delete reverter 
layer, save?

Is there some script that I can run with "revert deletions only in changeset 
XYZ"?

May 22, 2020, 15:47 by talk@openstreetmap.org:

Le vendredi 22 mai 2020 07 h 29 min 19 s UTC−4, Frederik Ramm 
 a écrit :
> Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason

Looking at Achavi, red outlines make us think objects were deleted. But in 
fact, the buildings were simply slightly moved to realign to DigitalGlobe 
imagery (not Bing).  And no correction of geometry was made, even where too 
many and unsquared angles to represent a rectangular building. Also Tags are 
systematically added:  
    "mapper"="mspray4"
    "source"="Akros"
 



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

Re: [OSM-talk] mspray stealth organized mapping

[Pierre Béland via talk]

 Le vendredi 22 mai 2020 07 h 29 min 19 s UTC−4, Frederik Ramm 
 a écrit :  > Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason
Looking at Achavi, red outlines make us think objects were deleted. But in 
fact, the buildings were simply slightly moved to realign to DigitalGlobe 
imagery (not Bing).  And no correction of geometry was made, even where too 
many and unsquared angles to represent a rectangular building. Also Tags are 
systematically added:  
    "mapper"="mspray4"
    "source"="Akros"

 
Pierre 
 

  

 Hi,

the "mspray" accounts were blocked in July 2019 for problematic edits
and failing to document properly. The project leader has contacted DWG
on 15 May 2020 asking what needs to be done to unblock the accounts, and
was informed by us that:

> the "mspray" users have only been blocked until they read the block
> message; the accounts can be used again now. But they will be blocked
> again, and their edits potentially reverted, if they continue to
> disregard OSM rules.
> 
> To re-iterate, the issues were:
> 
> * accidentally "squaring" water areas
> * no proper changeset comments
> * no documentation of the project
> 
> As a general rule, someone encountering an edit by an "mspray" user
> should be able to see (through a link from the user profile for example)
> what kind of project this is, who is running it, and what the goals of
> the project are. Ideally, such project should be discussed with the
> community before they commence. And changeset comments should explain
> the concrete action, for example "tracing buildings in XY region". Also
> the frequent mention of "evwhsdigitalglobe" is puzzling; this is not a
> well-known source in OSM. Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason (the changeset comment "reveal enumeration
> # malaria elimination" is not enough to explain why you deleted dozens
> of buildings).

If you feel they are disregarding that message, we are happy to block
them again.

Bye
Frederik


-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Référencement, cartes uMap

[Pierre Béland via Talk-fr]

Vincent Bergeot a écrit:> sans doute à ajouter sur 
https://github.com/umap-project/umap/ ? 

C'est fait, mercihttps://github.com/umap-project/umap/issues/798 
Pierre 

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

[OSM-talk-fr] Référencement, cartes uMap

[Pierre Béland via Talk-fr]

Il existe plusieurs cartes uMap portant sur la thématique Covid-19.  Mais 
j'observe qu'elles sont mal référencées. En recherchant pour mots clés [umap  
Covid-19], j'observe effectivement peu ou pas de référencement des cartes uMap.
Recherche umap  Covid-19
Qwant.com et Bing : aucun résultat
Google : Quelques pages, et description peu pertinente

Ces problèmes pourraient facilement être corrigés à mon avis en ajoutant des 
balises dans les pages uMap.
Il serait facile d'ajouter à la page HTML la balise  
en y insérant la description contenue dans chacune des cartes.  L'utilisation 
de moteurs de recherche fournirait une description plus claire de la carte et 
retournerait plus de résultats pertinents.
 
Pierre 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Bridge area construction

[Pierre Béland via talk]

On 5. May 2020,   Martin Koppenhoefer wrote:


I think the common tag would be landuse=construction



I dont think that it is appropriate to superpose a landuse over a waterway.

Since the tag man_made=bridge is used, it seems better to  refer to the 
construction project with the tags as proposed by Jack Armstrong

- man_made=construction- construction=bridge- layer=1

 
Pierre 
 

Le mardi 5 mai 2020 17 h 53 min 59 s UTC−4, Martin Koppenhoefer 
 a écrit :  
 
 

sent from a phone

On 5. May 2020, at 22:27, Jack Armstrong  wrote:



I assume the best way to map a large bridge area that's under construction 
would be with the minimum following tags? I'm not asking about the ways 
associated with/on the bridge.
man_made=constructionconstruction=bridgelayer=1


I think the common tag would be landuse=construction
Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] healthsites.io breaks OSM data, do not use

[Pierre Béland via talk]

Thanks to the Healthsites.io Team.  

See my comments below about the keys added.

First point is about the addr:full  The addr wiki page suggests to avoid this 
key if possible. See https://wiki.openstreetmap.org/wiki/Key:addr
Second point,, the rule in OSM is to not abbreviate addresses.See  changeset 
82308472,  way=28712045addr:full=1825 E Warner Rd, Tempe, AZ 85284

The street name is different from the highway way 597611061 : East Warner Road. 
To my understanding, this might create problem with navigation tools. Third 
point : source = should be put on the changeset especially if you only added 
tags to an existant OSM object.  

Fourth point : One object per changeset adds burden to OSM contributors 
validating edits. This should be avoided as much as possible.
regard
Pierre 
 

Le dimanche 22 mars 2020 09 h 38 min 18 s UTC−4, sharehealthdata share 
 a écrit :  
 
 Dear OSM Moderators

Thank you for raising the issue with data loss caused by edits through 
Healthsites.io. Our project is an important focal point for people looking to 
create, edit, visualise and extract data health facility data from OSM - 
especially in this trying time with COVID-19. We have fixed the underlying 
issues and also corrected any data issues that arose because of this issue.  
Our team is on standby and will move to rapidly resolve any problems surfaced 
by the OSM community
.
A detailed list of data fixes we have done is available here:  
https://github.com/healthsites/healthsites/issues/1357#issuecomment-602165455 

Thank you everyone,
Keep Safe
Regards

The Healthsites.io Team
ᐧ
On Sun, Mar 22, 2020 at 1:05 PM  wrote:

Send talk mailing list submissions to
        talk@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.openstreetmap.org/listinfo/talk
or, via email, send a message with subject or body 'help' to
        talk-requ...@openstreetmap.org

You can reach the person managing the list at
        talk-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk digest..."


Today's Topics:

   1. Re: healthsites.io breaks OSM data, do not use (Mikel Maron)


--

Message: 1
Date: Sun, 22 Mar 2020 11:03:15 + (UTC)
From: Mikel Maron 
To: Frederik Ramm ,  Talk Openstreetmap
        ,  Oleksiy Muzalyev
        
Subject: Re: [OSM-talk] healthsites.io breaks OSM data, do not use
Message-ID: <1795611632.59384.1584874995...@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

Update:

https://github.com/healthsites/healthsites/issues/1357#issuecomment-602164476

The editor is disabled for now. 
They're working on fixing bad edits.

-Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Sunday, March 22, 2020, 03:37:43 AM EDT, Oleksiy Muzalyev 
 wrote: 





On 3/21/20 17:39, Frederik Ramm wrote:
> Hi,
>
> the "healthsites.io" web app allows you to contribute data to OSM,
> however if you modify existing OSM objects, it throws away all tags it
> does not know of. Until this bug is fixed, please refrain from using
> healthsites.io!
>
> You can track progress here
> https://github.com/healthsites/healthsites/issues/1357#issuecomment-602068556
>
> Bye
> Frederik
>
It is one more lesson of this outbreak that the emergency response tools 
are to be prepared and tested well beforehand.

By the way, a viral respiratory infection can be stopped, or at least 
slowed down, by mere physical separation of hosts, i.e. people, because 
it stops the exponential chain reaction.

That is why mapping with the reliable editor say an archeological site 
in a forest could be also very beneficial. As some people could hike to 
it on weekend, instead of going to an overcrowded city park.

And we shall also remember of ambulances. Sometimes it is very hard for 
a driver to find a location of an address. In some cases it may take 
hours. So the general overall improvement of the map should continue.

Best regards,

Oleksiy



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



--

Subject: Digest Footer

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


--

End of talk Digest, Vol 187, Issue 56
*

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

[OSM-talk] Covid19 OSM Community Buzz Challenge 1. Building overlaps

[Pierre Béland via talk]

For many, we are doing social distanciation staying at home. This is a great 
time to do some social proximity actions from internet. 

We can easily do some Quality actions easy enough to show to childs or 
relatives nervous to do something positive. Various tools can be used. The 
easiest one I propose is Osmose. For more aventurous, there is an Overpass 
query.
- http://osmose.openstreetmap.fr select building theme- 
https://overpass-turbo.eu/s/M4m Overpass query - you simply select the zone to 
cover

Pierre Béland on Twitter

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Pierre Béland on Twitter

“my #buzzOSM today: #OpenStreetMap community Quality challenge 1. Osmose 
theme:building or other Quality tools ...
 |

 |

 |




takes care, have fun :)
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] fixme=name

[Pierre Béland via talk]

 Mar.12 2020 12 h 16 UTC−4, Volker Schmidt wrote :  
> It may have been a user who wanted to draw attention to the fact that she has 
> inserted a place>  without knowing the name.
 For the Mali example given by John, an Overpass query reports some 1,200 such 
points north of Mali, the majority added in 2013. Note that I did coordinate 
the humanitarian response at the time with Andrew Buck. See his message at the 
time https://lists.openstreetmap.org/pipermail/hot/2013-February/002802.html 

These names were added for the Mali humanitarian response in 2013 at the 
request of UN agencies and NGO's answering in the area.  If we remember, we did 
innovate at the time using Imagery tiles to spot villages in often flooded 
areas, then traced roads from these villages. Then NGIS data was imported. 
Since geolocation is often very imprecise, we did manually add these infos 
placing them at the best of our knowledge.
The local ressources are still quite limited in Mali even at the government 
level.  The OSM volunteer community has organized a few missions in the south 
to revise names but it is more difficult to deal with the northern area.  And 
badly, the volunteers do not manage the subsidies that were received from such 
humanitarian actions.


Pierre 

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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

Mar. 12 2020 10 h 43 min  UTC−4, Simon Poole wrote :
> To use a completely different example: assume that you purchase a TV set 
> paid by monthly instalments and you default on them. In civilised 
> countries that doesn't give the seller the right to break in to your 
> apartment and repossess the TV, they don't get to cut off electricity to 
> the flat and they don't get the right to stick big notices on your doors. 
> The seller needs to utilize the  whatever tools are provided by the legal 
> system, totally regardless off how upset they are and how righteous they 
> might feel about their actions. Simon
An other example 
Let say we produce bricks standing outside of the shop.  Since too many are 
stolen, we use a trick to make the bricks flashing with a message when they get 
in inappropriate hands. Can somebody sue us because their house is flashing 
with message about where the bricks come from ?

 
Pierre 
 

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

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: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

 
Pierre 
 

   Mar.8, 2020 1byMateusz Konieczny 

> To be more clear: I fully support action like OSM France to actually enforce
> license requirements using methods like described here or by a legal action 
> like
> DMCA takedown notices against entities refusing to show a proper attribution.
  I also support such actions. To be less intrusive and more diplomatic, the 
box could be smaller and semi transparent, and the text rewrittten to be more 
specific What's about something like ? 

- WARNING : OSM Attribution is required for these tile products
- These OSM tiles are downloaded from openstreetmap-France tile server 
   without this website providing any visible attribution
- See https://www.openstreetmap.org/copyright
- Contact us at ti...@openstreetmap.fr

Mar 8, 2020, 20:26 by talk@openstreetmap.org:


Mar 8, 2020, 12:12 by si...@poole.ch:


I would be very very wary of doing anything that deliberately defaces a web 
site without consulting with a local (to the country the web site is in) 
lawyer, particularly if the message implies wrong doing.


Illegal use of OSM data and violating terms of use of service is a clear wrong 
doing.

I am not a lawyer, but showing message informing about violating license and 
terms of use of service seems 100% OK in case of website actually violating
OSM license.
And I fully support websites doing this.

To be more clear: I fully support action like OSM France to actually enforce
license requirements using methods like described here or by a legal action like
DMCA takedown notices against entities refusing to show a proper attribution.
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

You could use the navigator user language preference for the language to use 
for the message.

 
Pierre 
 

Le dimanche 8 mars 2020 11 h 40 min 47 s UTC−4, Christian Quest 
 a écrit :  
 
 Le 08/03/2020 à 16:00, Mario Frasca a écrit :
> well, it does look slightly invasive …


That's the goal... slightly invasive... and not time consuming for the 
tile server and myself.

Please, don't forget who's wrong here.


-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] [OSM-dev-fr] Hack Weekend, Toulouse, 4-5 avril 2020, soutien aux déplacements

[Pierre Béland via Talk-fr]

Pour un tel événement, il serait intéressant de prévoir une/des périodes avec 
vidéo-conférence pour permettre les échanges avec les contributeurs à distance.

 
Pierre 
 

Le mardi 3 mars 2020 17 h 22 min 05 s UTC−5, Vincent Bergeot 
 a écrit :  
 
   
Bonjour à toutes et tous, (copie sur talk-fr, tech, dev-fr et association@)
 
 
un hack weekend OSM se déroule à Toulouse les 4 et 5 avril 2020. Toutes les 
infos ici : 
https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020.
 
OpenStreetMap France souhaite faciliter la venue à ce hack weekend et prend 
donc en charge les frais de déplacements des participants en faisant la demande 
!
 
Alors n'hésitez pas et contacter tresore...@openstreetmap.fr (prévoyez un RIB 
et un petit formulaire à compléter 
https://nextcloud.openstreetmap.fr/index.php/s/ZmTWX6pdibPJY5L)
 
 
Pour l'hébergement il y a quelques places de disponible chez des contributeurs 
locaux. Demandez si besoin !
 
--
 
 Vincent Bergeot
pour l'association OSM-FR 
 
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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: [OSM-talk] MapRoulette - cryptic tasks

[Pierre Béland via talk]

Hi Martin, 

If we want to monitor revisions for a specific territory we take care of, I see 
that Maproulette Challenge offers a map where we can see I suppose individual 
objects/tasks for the area. Zooming in and out of the area, the numbers 
constantly change.  If I zoom-in, I cannot see the individual tasks neither see 
simply what is the object of the challenge for these tasks.

 
https://maproulette.org/browse/challenges?challengeSearch=-71.55601501464845%2C46.70691089512589%2C-70.99777221679689%2C46.908998382774506=intersectingMapBounds=created%2C

Could MapRoulette API help to monitor an area by rapidly providing  a list of 
individual tasks + OSM object Id (ie. Challenge -OSM object id, problem / tag 
to correct, solution / tag proposed )  ?

Could you give example of API call for this ?
 


Pierre 
 

Feb.26 2020 10 h 05 min 52 s UTC−5, Martijn van Exel wrote :  
there is also an API call you can use. 

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

Re: [OSM-talk] Deletion of wiki page contributions Was Creation of "Data Items" by bot for undocumented tags

[Pierre Béland via talk]

Joseph,
If you were talking of fast food restaurants, I would understand that we expect 
to see these in hundred of countries.  But there are features that yes are not 
seen as intensively.

One fast food POI counts for one. One 500km route counts also for one.
This Overpass query shows that the tag is used in five provinces / territories 
in Canada, plus Norway and Sweden.
 
Please revert your undelete and if you are not happy with this, you should go 
to the Tagging list for discussion.

regard

Pierre 
 

Le mercredi 19 février 2020 09 h 38 min 44 s UTC−5, Joseph Eisenberg 
 a écrit :  
 
 The tag is documented at
https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile - it has
been used 141 times only. I did not delete the documentation, but I
did remove the tag from
https://wiki.openstreetmap.org/wiki/Template:Map_Features:route, and
added a comment to
https://wiki.openstreetmap.org/wiki/Template_talk:Map_Features:route

This does not need to be on the main "Map features" page, which is a
curated list of the most commonly used tags, for new users, since it
is a new tag with few uses. This has nothing to do with my opinion of
the tag. It looks fine to me.

If you wish to add this tag to Map Features, there are 2 options:

1) Create a Proposal page and follow the process to get the tag
Approved (see https://wiki.openstreetmap.org/wiki/Proposed_features)

2) Map lots of these features and then wait for other mappers to adopt
the tag. If it has been used thousands of times in many different
countries over a period of several years, then it can be added to Map
Features as a "De facto" tag, even without a vote.

Joseph Eisenberg

(In the future, a better place to discuss changes to
Template:Map_Features:route is
https://wiki.openstreetmap.org/wiki/Template_talk:Map_Features:route)

On 2/19/20, Pierre Béland  wrote:
> Joseph, you deleted recently the link I added to the Map_features wiki page
> for snowmobile routes.  It seems you dont like such schema and want to
> impose your views here.
>
> Snowmobiles routes are as common as bike or hiking trails in nordic
> countries. And the snowmobile wiki page describes it.
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile
> Would you please revert your delete ?
>
>
>
> Pierre
>
>
>    Le mercredi 19 février 2020 04 h 00 min 04 s UTC−5, Joseph Eisenberg
>  a écrit :
>
>  > I have occasionally moved such pages into the user's name space when I
> found them to (by content, if not by name) to be proposals for
> something, rather than a documentation of something already established.
>
> That is fine if the tag has not been used, and the page is written
> like a proposal suggestion. But if the user just wants to tag a dozen
> widgets as Tag:amenity=widget, it is fine to leave the Tag page in
> place, and then add information as needed like "See Also the more
> common tag landuse=widget which has a similar meaning", or "Some other
> mappers have used this tag in a different way, with this differnet
> meaning..." when necessary.
>
> I personally check every new Tag: and Key: page (in English,
> Indonesian or Spanish) every couple of weeks, and I suspect  Mateusz
> Konieczny  and some other experienced wiki users also check the
> Special:NewPages list frequently for the same reason. You can see that
> many of the Tag: and Talk pages on
> https://wiki.openstreetmap.org/wiki/Special:NewPages have been edited
> by more than one user, even the ones that were made in the past month
> or two.
>
> This review effort is not yet happening for the Data Items, and since
> there were >500 created by bot over Christmas (Dec 25-26th), I think
> it's unlikely anyone has reviewed the recently created data items over
> the past few months. Most are content-free (key=value is the only
> property), but some probably need to be checked.
>
> - Joseph Eisenberg
>
>  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Deletion of wiki page contributions Was Creation of "Data Items" by bot for undocumented tags

[Pierre Béland via talk]

Joseph, you deleted recently the link I added to the Map_features wiki page for 
snowmobile routes.  It seems you dont like such schema and want to impose your 
views here. 

Snowmobiles routes are as common as bike or hiking trails in nordic countries. 
And the snowmobile wiki page describes it. 
https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile
Would you please revert your delete ?


 
Pierre 
 

Le mercredi 19 février 2020 04 h 00 min 04 s UTC−5, Joseph Eisenberg 
 a écrit :  
 
 > I have occasionally moved such pages into the user's name space when I
found them to (by content, if not by name) to be proposals for
something, rather than a documentation of something already established.

That is fine if the tag has not been used, and the page is written
like a proposal suggestion. But if the user just wants to tag a dozen
widgets as Tag:amenity=widget, it is fine to leave the Tag page in
place, and then add information as needed like "See Also the more
common tag landuse=widget which has a similar meaning", or "Some other
mappers have used this tag in a different way, with this differnet
meaning..." when necessary.

I personally check every new Tag: and Key: page (in English,
Indonesian or Spanish) every couple of weeks, and I suspect  Mateusz
Konieczny  and some other experienced wiki users also check the
Special:NewPages list frequently for the same reason. You can see that
many of the Tag: and Talk pages on
https://wiki.openstreetmap.org/wiki/Special:NewPages have been edited
by more than one user, even the ones that were made in the past month
or two.

This review effort is not yet happening for the Data Items, and since
there were >500 created by bot over Christmas (Dec 25-26th), I think
it's unlikely anyone has reviewed the recently created data items over
the past few months. Most are content-free (key=value is the only
property), but some probably need to be checked.

- Joseph Eisenberg

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

Re: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

Hi Mateusz
The link below shows north of Canada areas, where the wood landcover correspond 
in general to Canvec imports. The blank areas are mostly not mapped yet except 
some lakes and 
infrastructures.https://www.openstreetmap.org/#map=5/55.740/-79.804
But for Labrador, the contributors have made the choice to import Canvec 
excluding the wood landcover. If someone wants to test how easy it is to add 
the wood landcover, there is quite some work to do there creating multipolygons 
with inner roles for lakes, cuts for Power lines, etc. 
https://www.openstreetmap.org/#map=9/53.4595/-63.9679 
Pierre 
 

Feb 12 r 2020 13 h 30 min 57 s UTC−5, Mateusz Konieczny wrote :

Hard to say more or verify without getting specific location but I cleaned up 
some places
mangled by badly done forest imports - for example border area that was hit 
with multiple
low quality imports.

But it sounds exactly like https://www.openstreetmap.org/user/Abbe98/diary/28368
that was solved by splitting unreasonably large relation in parts (by deleting 
it
and remapping)

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

On Feb 11  18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk wrote: 

>  ??? just do not create unreasonably large multipolygons (or split existing, 
> possibly undo import if it makes area uneditable and do it right).
Your answer seems to be that it is possible to map appropriately with the 
current rules. Or maybe not, but anyway, let simply ignore these areas, not 
find appropriate solution to add these areas  to OSM. For north of Canada 
alone, the superficy is closed to the size of Europe.

Your answer about polygons is simply a spin rethoric form (une pirouette) to 
ignore the problem. Should we rename this project OpenEurope ?
Pierre 
 

Le mardi 11 février 2020 18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk 
 a écrit :  
 
 


Feb 12, 2020, 00:07 by talk@openstreetmap.org:

Feb 11, 15:59, stevea wrote :

> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.

I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

Note that it is not violating OTG. OTG is not "everything must be mapped on 
survey", it means
that direct survey (what is actually existing) overrides official data, 
opinions and desires.

If we could keep the wood landcover outside of OSM, it would greatly simplify 
mapping of such areas and dramatically reduce the Mulipolygons problems where 
huge multipolygons are created with inner for lakes and all the problems 
related to this.

??? just do not create unreasonably large multipolygons (or split existing, 
possibly undo import
if it makes area uneditable and do it right).
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

Feb 11, 15:59, stevea wrote :
> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.
 
I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

In Africa, I have often used ne highres imagery to retrace official imported 
border limits that had been traced prior to the availability of detailed aerial 
imageries.
Also there are remote areas like lake North of Quebec, where we cannot 
realistically go and walk to trace every lake contour or follow thousand of km 
of Power lines (+ bears, mosquitos), and we need some assistance for example to 
trace hundred of thousand lakes like this one (imagery, assisted mapping, 
imports ??).https://www.openstreetmap.org/way/75891758#map=11/61.3877/-73.4622
Mappers dont add wood cuts for roads and map styles take care of this. Could we 
have a similar rule applied for Power lines, rivers and lakes ? And any 
possibility to approach the landcover differently ? Mappers, Schema or 
Developpers problem ?

What can we do to approach more realistically the problems, to establish good 
basis for more mapping to come ?
Yes, let's avoid the problem saying this is the bad Canada imports. Or maybe, 
we should think to revise the OSM schema which is not well adapted for such 
areas.
There exist distinct Landcover layers like on this Maptiler OSM Vectorial Map  
with a distinct Landcover layer
https://openlayers.org/en/latest/examples/mapbox-style.html
If we could keep the wood landcover outside of OSM, it would greatly simplify 
mapping of such areas and dramatically reduce the Mulipolygons problems where 
huge multipolygons are created with inner for lakes and all the problems 
related to this.
Yes the problems must be realistically adressed if we want to progress.
 
Pierre 
 

Le mardi 11 février 2020 15 h 59 min 12 s UTC−5, stevea 
 a écrit :  
 
 On Feb 11, 2020, at 12:05 PM, Mark Wagner  wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will 
always be counter-examples to a claim of "boundaries are not always obvious or 
indicated on-the-ground," (as you did, here, with a cutline in the real world 
some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies 
of water, etc. that have no signage or evidence of them (named as they are) 
being OTG.  Simply stated, there ARE (and always will be) things we map which 
are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM 
shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think 
all of us (even its original proponent in 2007, as Mikel stated earlier) agree 
that OTG is "an excellent guideline to be followed where it can be," others 
(Colin, Yuri) here have chimed in or infer that it can't realistically be 
absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus 
that "Independent verifiability" is a crucial component of Good Practice in 
those cases where OTG cannot STRICTLY be followed, as in cases of invisible 
boundaries, oceans without signage, and mountain ranges where we are forced to 
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky 
Mountains.'"  The solution here is "this (and its correct name) can be 
independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
 has input from Yuri and jeisenberg and I discussing whether unsigned routes 
qualify for this treatment (we can't see them OTG, but we map them anyway, as a 
public agency asserts their existence, though it hasn't signed them well).  
While routes like this are a relatively minor (lesser) concern about OTG, 
broader 

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: [OSM-talk] Tag:man_made=embankment

[Pierre Béland via talk]

I think that there is a miss-conception here. If you want to talk about the 
wall the retains the earth, this is the dyke. The embankment is more then a 
wall and is at least as large as the road and made of resistant material.  The 
wiki pages https://wiki.openstreetmap.org/wiki/Key:embankment and 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment do not accept 
usage of polygones with these tags.
see description of embankments in 
https://www.sciencedirect.com/topics/engineering/highway-embankment
 
Pierre 
 

Le mercredi 15 janvier 2020 13 h 56 min 45 s UTC−5, Yves 
 a écrit :  
 
 You should have read "right side of way" : it's the side on your right when 
you follow the way in its direction.
Yves 

Le 15 janvier 2020 17:59:42 GMT+01:00, Paul Johnson  a 
écrit :


On Wed, Jan 15, 2020 at 10:28 AM 80hnhtv4agou--- via talk 
 wrote:

What does this mean ? “should be tagged on a way drawn with the lower side on 
right side of way direction”

The downhill side of the embankment is to the right of the way. 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Eh, I am quite please to realise that the page is now available in 6 languages.

The  first version of the page early 2013 was for the OpenStreetMap response 
North of Mali. But in later discussions, contributors did say that it did also 
represent reality of other African countries. We then collectively decided to 
rename it to highway_tag_africa. 

There are regular mentions on discussion lists about this classification but no 
success using search tools to find references. I will let local contributors 
from various countries respond to your questions about classification and name 
to use.
In one country, the situation can vary a lot from more urban and industrialized 
regions to other regions.  I can tell you that north of Quebec / Canada there 
are vast forestry areas with very low population. Road infrastructures in such 
forestry areas are quite different from the urban areas and I would not 
classify a few hundred km long unpaved and rough road interconnecting various 
other roads as track.See for example the transtaiga highway 
https://www.openstreetmap.org/relation/6625883#map=7/54.104/-73.644
 Pierre 
 

Le mardi 7 janvier 2020 16 h 38 min 39 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 15:46, Pierre Béland wrote:
> I am the original author of the Highway Africa Tag wiki page.  This 
> page is now widely used outside of Africa (Asia and Latin-America) in 
> areas where it better correspond to the reality of the roads 
> infrastructure.

I see, and I like it.  good job!

but it still only mentions 'Africa'.  How would you describe the 
application range, other than "outside high wages / developed countries"?

my guess for the first sentence would be "Most regions in the world do 
not show the same road network quality as, say, Germany or Canada.  Road 
conditions in such regions do not match the economic and social role of 
the road." then go on with the rest.

which Latin American countries are using this page as a reference? as 
far as you and others here know?
> And pictures have been used to better correspond to the ligther road 
> structures in these areas, which are often unpaved. 

nice pictures indeed.  curious enough, they aren't (yet) linked in the 
Spanish version of the page.  I might find time to do so.

ciao,

MF

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

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Hi Mario
I am the original author of the Highway Africa Tag wiki page.  This page is now 
widely used outside of Africa (Asia and Latin-America) in areas where it better 
correspond to the reality of the roads infrastructure.  And pictures have been 
used to better correspond to the ligther road structures in these areas, which 
are often unpaved.  

This image near Butembo, North of Democratic Republic of Congo, cleary shows 
damages to road structures at rainy season. I have experienced the same in 
south-east of Haiti, and observed it often in other countries.

https://twitter.com/pierzen/status/1163096946300653570
There is quite a difference between crowdmapping and community mapping. It is 
easy to bring in thousand of inexperienced contributors. But, if  they are not 
trained and monitored, there will be significant damages to the map.
 regard

Pierre 
 

Le mardi 7 janvier 2020 15 h 05 min 38 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 14:53, Mario Frasca wrote:
> so you say: just revolutionize the overview for the highway tag, 
> without first reaching a consensus?  or I understood you wrong? or 
> replace the Eurocentric pictures with Panama and Morocco pics? an edit 
> like this will be reverted after 15 minutes! 

ah, no, I see, you suggest to take inspiration from the 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa, or the German 
(very complete) overview How-to-map-a.  both pages which I did not know.

quite a bit of work, but who knows we manage to motivate the Latam group 
for this.

will put it on my personal to-do list, but if others from Latam are 
reading here, they can add their comments and ideas.

MF
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Pierre Béland via talk]

Hi Nuno, 

How can we react positively suggesting to take care obout OSM attribution ? 
This is an international media and we can benefit by having a bit of fun.

Plus this is Christmas coming soon and we need to think positive !
 You could make tweet to https://twitter.com/BBCTwo   + using OpenStreetMap 
logo image (add @OpenStreetMap as who is on the image) + url link to facebook 
article
 saying
Merry Christmas from the OpenStreetMap community Happy to provide accurate and 
detailed maps to news medias, governnments, research, business, consumers, to 
respond to disasters, etc.  Dont forget - Our New Year Best Wishes to have more 
impact - OpenStreetMap Contributors attribution :)
Then you could invite OSM contributors on the discussion lists to make it Viral 
by responding !
To show OSM diversity, I would be pleased to respond to the tweet.

Bonne année, Pierre Béland, du Québec, Canada, fier de supporter OpenStreetMap.

;)
 
Pierre 
 

Le jeudi 19 décembre 2019 18 h 16 min 44 s UTC−5, Nuno Caldeira 
 a écrit :  
 
 here's another lovely example from BBC TWO using Strava (i can spot the Mapbox 
logo, not the reasonable calculated ©OpenStreetMap contributors). glad BBC 
attributed Google properly. they probably aren't aware it's OpenStreetMap, if 
they can't read the attribution on 
Stravahttps://www.facebook.com/413132078795966/posts/2468472903261863/

On Fri, 1 Nov 2019, 18:59 Nuno Caldeira,  wrote:



On Fri, 1 Nov 2019, 18:05 Simon Poole,  wrote:
 
The fair use point just turned up to illustrate that there are limits on what 
we can expect copyright to do for us (aka the tweets from private individuals 
showing a map excerpt that Nuno pointed to) and there is no point in getting 
upset over that there are such limitations. 

actually Simon those prints indivuals share on social media is sent to their 
emails by the company (as someone pointed after you writing). Strava sends 
emails of OSM basemap to their users without attribution. I been testing Strava 
app today and had a couple of laughts TB. tYhere's even more interesting stuff 
we should take notice when doing the attribution guidance. they use Google maps 
on their android app, the routes they display clearly isn't from their users 
(it's not GPS traces as it is impossible to have no overlaping traces on 
mountain regions). I'm sure these routes are from OSM and I'm gathering 
evidence from my contributions that this is OSM data. I will get back to it 
when I get home and record a video with clear evidence that it is impossible to 
be their users GPS trace or Google Maps (as they do not have data in that 
regions). That could only come from OSM and I'm sure as I added that data and 
weekly monitor the editing and their suggested routes sometimes overlap the 
same route as it displayed different versions of OSM data during the years. 


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

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: [OSM-talk-fr] tuiles cycleosm.org inaccessibles

[Pierre Béland via Talk-fr]

marc marc a écrit> oui, on y bosse, plus d'info suivrontMerci, la carte 
s'affiche à nouveau correctement.
 
Pierre 

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

[OSM-talk-fr] tuiles cycleosm.org inaccessibles

[Pierre Béland via Talk-fr]

Sur la liste talk-ca, les contributeurs rapportent ne pouvoir afficher la 
couche cycleosm dans cycleosm.org. Voici ci-dessous un lien vers une des tuiles 
sur tile.openstreetmap.org.
https://dev.c.tile.openstreetmap.fr/cyclosm/12/2076/1412.png
Problème temporaire ?
 
Pierre 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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: [OSM-talk] Status / Documentation of JOSM Check for Almost for almost right angle buildings

[Pierre Béland via talk]

I have obtained infos about how to run this, filing JOSM ticket 
https://josm.openstreetmap.de/ticket/18171
We first need to select in the Preferences Data Validator Panel the option 
«Show Informational level»Then only data downloaded with selecting a BBOX is 
considered (does not work with Overpass query downloads).

When we click for Validation, reports are classified under-Other
  -> Building with an almost square angle
 
Pierre 
 

Le mercredi 25 septembre 2019 14 h 37 min 59 s UTC−4, Pierre Béland 
 a écrit :  
 
 I can find some references to this subject in JOSM tickets and the definitiion 
of minimum  / maximum in JOSM Advanced paramenters. But I have no success to 
run the tests.

The JOSM ticket https://josm.openstreetmap.de/ticket/16189  discusses about the 
implementation of the Check for Almost right angle with reference to the two 
parameters to control minimum and maximum angles for building polygons to 
detect.
>From JO§M advanced preferences, I see that the two variables have default 
>values.
validator.RightAngleBuilding.maximumDelta=1
validator.RightAngleBuilding.maximumDelta=10
To test this function, I did assure that I have Expert Mode selected and that I 
have angles in building polygons closed to right angle. But Running the 
Validator Check function from the Validation Pannel, I do not see any warnings 
added to the Validation Results.

Could somebody tells me the status of this function and help me to understand 
how to run this function ?
 
Pierre 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk] Status / Documentation of JOSM Check for Almost for almost right angle buildings

[Pierre Béland via talk]

I can find some references to this subject in JOSM tickets and the definitiion 
of minimum  / maximum in JOSM Advanced paramenters. But I have no success to 
run the tests.

The JOSM ticket https://josm.openstreetmap.de/ticket/16189  discusses about the 
implementation of the Check for Almost right angle with reference to the two 
parameters to control minimum and maximum angles for building polygons to 
detect.
>From JO§M advanced preferences, I see that the two variables have default 
>values.
validator.RightAngleBuilding.maximumDelta=1
validator.RightAngleBuilding.maximumDelta=10
To test this function, I did assure that I have Expert Mode selected and that I 
have angles in building polygons closed to right angle. But Running the 
Validator Check function from the Validation Pannel, I do not see any warnings 
added to the Validation Results.

Could somebody tells me the status of this function and help me to understand 
how to run this function ?
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[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

[OSM-talk] Re : Tagging Governance

[Pierre Béland via talk]

Hi Roland
It would help To better see the structure of
1.main tags2.attributes adding detailed infos To these tags
Also cases like polygons that should not be overlapped when related   To 
landcoverie. Amenity=university vs landuse=retail
Pierre

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le mar., sept. 10 2019 à 6:54 AM, Roland Olbricht a 
écrit :   Hi all,

I have got into the duty to talk about tagging governance on the SotM
and I would like to develop that opportunity towards something that is
rather helpful in the long term.
To ensure that I am on the right track and not unintentionally after a
personal agenda I would like to ask you to comment on the findings so
far listed below.

To encourage a widespread discussion, I have spread this message on
German and French lists as well (these two because I understand the
languages) and will do so in addition on the tagging list. Feel free to
spread this message further as long as you remember to channel back all
feedback.


Imperfect Flow of Information

Although many parts of the OpenStreetMap project are well translated,
the tagging documentation has substantial deficiencies. Over a random
sample of 10 tags the number of declared languages varies between 2 and
18, but only few are complete and up to date (sample: 2 of 10 for
German, 3 of 10 for French).

Another kind of imperfect information flow is that tag definitions can
be changed on the wiki page long after the tag is in widespread use.

The converse case that a tag is introduced without any documentation is
also happening. While this happens by ordinary users usually slow enough
to make sense of the added data, an import or organized edit might be
able to substantially skew the de facto meaning of a tag, regardless
whether it is in widespread use, documented, both, or none.


More Structure needed

The translation issues have been conflated with a different problem:
Different features may look very different between regions. E.g.
highway=primary and highway=unclassfied versus highway=track
need different sets of examples in Germany and the urban US on the one
hand and Iceland or rural Africa on the other. It is easy to mix this
with the translation into the predominant language in the area,
but the tagging challenges in Belgium, Canada, and Niger are
substantially different, although all three countries happen to have
French as official language. Conversely, there is no sane reason to
change tagging rules every block of houses in Brussels.

Additionally, people often have different search terms than the British
English tag names or their translations, and the wiki search engine is
infamous for its bad performance. Having explicit keywords to direct the
attention of a mapper to the list of possibly fitting tags might help.

A substantial problem source of the concept of proposals is
that it interacts with lots of tags in a nontrivial way and is
practically never properly applied to all affected tag definitions.
A proposal currently is an extra page although it should have much more
an impact like a Git commit, grouping changes across various tag
definition pages in a single changeset.


Legitimacy and Governance

What legitimation has a process if only a handful of people have that
have the time to write mails on a mailing list and to write wiki pages
are involved? In particular, if the proposals end up as being full of
contradictions or vague terms and leave necessary answers undefined.
Yet these still are the people that have shown the necessary long-term
endurance to assure maintenance and that do the work. Thus every change
to replace processes with better processes must be geared towards
broadening not narrowing the base of long-term maintainers.

Conversely, I fully understand mappers that are wary of sudden changes
in the rendering or the access to tags in edting software. A lot of
people whould probably appreciate to better understand what happens on
the way from a tag discussion to a final change in the renderer or
editing software. These processes are not secret, but often
under-documented.

Again, the various discussion channels and the lacking information flow
between them contribute to the bad mood. Even worse, the ratio between
people and channels means that evil or just plainly incompetent people
could easily take over some channels and contribute substantially to the
confusion. Good ideas how to redirect people and close down some of the
channels (e.g. wiki discussion pages) might be worth pursuing. On top of
that the wiki history is so much less helpful than what developers are
nowadays used to from version control systems that borrowing methaphors
and paradigms from there to the tag documentation is worth consideration.

This hopefully helps to foster that the authors of the documentation and
the mappers using a tag actually agree on its meaning.


Best regards,

Roland

___
talk mailing list
talk@openstreetmap.org

[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: [OSM-talk] Attribution guideline status update

[Pierre Béland via talk]

I agree, this would be more snappy and more international. It woulrd not be 
necessary to translate the attribution for various languages.   By shortening 
the attribution, their would be less excuses to not attribute on the map.

 
Pierre 
 

Le vendredi 9 août 2019 10 h 40 min 27 s UTC−4, Frederik Ramm 
 a écrit :  
 
 Hi,

I wonder if we could perhaps get rid of the "Contributors" mention
altogether.

The term "OpenStreetMap Contributors" is the unwieldy; it just sounds
strange to say "this is a map made by OpenStreetMap contributors" when
what we really want to say is "this is OpenStreetMap". When translated
into German, you would have to say "OpenStreetMap-Beitragende" or, more
correctly, "Beitragende zu OpenStreetMap", which to the un-initiated
sounds a bit strange and kind of dilutes the OpenStreetMap brand by
adding things before or after. I am pretty sure that there are languages
where grammar in fact requires that the "contributors" be placed before
OSM (as in my "Beitragende zu OpenStreetMap" example) and where no
grammatically correct way exists to place OSM first.

I know, OpenStreetMap is not a legal entity and therefore cannot be said
to own the copyright. Then again, "(c) OpenStreetMap contributors" is
not technically correct either, as there are many ways in which you can
contribute to OSM, but only some of them will earn you a share of the
copyright in the map. Someone who contributes to OSM by giving us money,
or writing code, or organising meetups, is not part of the group that
holds the rights in the map.

I would find a simple "(c) OpenStreetMap" better, more snappy, more
recognizable than if we demand that the "contributors" are mentioned.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Microsoft Buildings vs. OpenStreetMap visualization

[Pierre Béland via talk]

While you observe quality problems with imports,  you can contribute to better 
document these problems  with samples of buildings ( list of osm_id  and brief 
description of observations ).
 
Pierre 
 

Le vendredi 2 août 2019 23 h 34 min 17 s UTC−4, AntiCompositeNumber 
 a écrit :  
 
 In my area, it also appears that the detection rate is fairly good. In
my brief look through I found one building where there is no building
and a few buildings that the AI did not find. The rotation issue was
fairly common as well as a general offset from the imagery (This may
be on the Mapbox side, I don't know). The footprints get the general
shape of the building mostly there, but struggle with smaller
sections. Overall, the tool seems to be good at saying "There is a
building here and it's about this big" but is less successful at
identifying the details of the buildings.

On Fri, Aug 2, 2019 at 8:17 PM Jmapb  wrote:
>
> On 8/2/2019 7:24 AM, Darafei "Komяpa" Praliaskouski wrote:
> > Here's a demo by azavea showing how 125 Million AI-mapped buildings
> > relate to 33 Million buildings currently in OpenStreetMap in the same
> > region.
> >
> > https://demos.azavea.com/building-footprint-comparison/#4.4/38.67/-93.93
>
> Thanks, this is interesting.
>
> Browsing the areas I'm most familiar with in NYC (where we had a
> building footprint import from city data in 2013), I find that the
> buildings that are detected by Microsoft but missing from OSM are mostly
> either already demolished buildings (currently mapped as
> landuse=construction), small outbuildings, or simply nonexistent. In the
> cemetery, Microsoft has picked out a few of the more impressive tombs
> and mausoleums. And in one case Azavea seems to have failed to notice a
> building that's been mapped in OSM for years (since the import.)
>
> Browsing more rural areas in upstate NY, I see thousands of unmapped
> buildings, mostly houses, that Microsoft successfully detected -- in
> some cases despite tree cover. The sizes are pretty good and the
> footprints are okayish. Oddly some of them seem slightly rotated, maybe
> a trick of the shadows.
>
> J
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Way to delete buildings added by specific user, or help reverting?

[Pierre Béland via talk]

This link let extract object edited by this user in the area the day of this 
changeset.http://overpass-turbo.eu/s/KzM 

This shows that builidngs position correspond to presence of buildings but that 
geometry do not correspond to what we observe on the imagery,.  We see that 
buildings are aligned in parallel with no correspondance to the geometry 
observed.

 
Pierre 
 

Le lundi 8 juillet 2019 15 h 57 min 47 s UTC−4, hbogner 
 a écrit :  
 
 My comment was not nice because I snapped after seeing what he/she did.

As a schooled surveyor that kind of neglect and false data is hurting me 
and I have the right to be angry. Maybe to harsh language but that data 
is false data.

Only one building on this map is not the same as the others:
https://www.dropbox.com/s/r3u6tow5qbc7jna/osm-Venko.png
They are copy/pasted all over the map.

This is not the first complaint I got about him/her from Croatian community.

Croatian community does not like false data being entered just to fill 
the map.


On 08. 07. 2019. 21:36, Bryan Housel wrote:
> hbonger, your comment here is not very nice.
> https://www.openstreetmap.org/changeset/56552674
> 
> Reviewing their edits on OSMCha, most of their edits don’t look too bad
> https://osmcha.mapbox.com/changesets/69561377?filters=%7B%22users%22%3A%5B%7B%22label%22%3A%22Venko%22%2C%22value%22%3A%22Venko%22%7D%5D%2C%22date__gte%22%3A%5B%7B%22label%22%3A%22%22%2C%22value%22%3A%22%22%7D%5D%7D
>  
> 
> 
> Maybe you should try being nicer to them and they might care about the 
> map more.  Comments like yours ripple outwards and affect the rest of 
> the OSM project negatively.. Calling some’s edit “bullshit” is not going 
> to get them to draw better buildings.
> 
> Just saying - be nicer, thanks.
> Bryan
> 
> 
> 
> 
>> On Jul 8, 2019, at 2:57 PM, hbogner > > wrote:
>>
>> Hi all
>>
>> Is there a way to delete buildings created by specific user?
>>
>> Some users already complained about 
>> https://www.openstreetmap.org/user/Venko to me for inaccurate mapping 
>> and imaginary mapping. They wrote to him, but he didn't reply or stop.
>>
>> Here is an example on which I just stumbled:
>> https://www.openstreetmap.org/#map=17/45.52874/15.48285=N
>>
>> He copy/pasted one building all over the place.
>>
>> I tried to revert the changeset, but there are too many conflicts.
>>
>> Any suggestions how to fix this mess?
>>
>> regards, Hrvoje
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



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

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Pierre Béland via talk]

Speaking more generally, 
Populatation is growing fast in Africa and many african countries dont have the 
resources to organize regular census. See the UN Statistics Division record of 
last census by country 
https://unstats.un.org/unsd/demographic/sources/census/censusdates.htm
This means that quality vary from one country to the other and that often we 
lack good info about distribution of population in the various countries.  The 
OSM building mapping projects are often used for population estimates.
 
Pierre 
 

Le samedi 6 juillet 2019 20 h 08 min 09 s UTC−4, Darafei "Komяpa" 
Praliaskouski  a écrit :  
 
 Hi,
On Fri, Jul 5, 2019 at 4:09 PM Jean-Marc Liotier  wrote:

On Fri, July 5, 2019 2:40 pm, Christoph Hormann wrote:
>
> One warning:  All global population data sets that exist are rough
> estimates with usually significant systematic biases and errors.  For
> example in Switzerland the data set you used sees high population
> density in mountain areas with no basis in reality.

Same in rural Senegal. Low-resolution population data I guess.


Can you point to a specific place please?

What would be the population dataset that you would recommend for 
Senegal?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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: [OSM-talk] Mali

[Pierre Béland via talk]

John some answers about your concerns
We have our own difficulties in countries like Canada to recruit contributors. 
Not surpsingly, for  African communities with more difficult economic 
conditions, they have poor, unstable internet access and less time to 
contribute.  
Problems are multiple in countries like Mali. It is hard to train and maintain 
local communities. Following the school and health faicilities imports in 2014, 
the Mali community has tried to fix bad imports. But has you see there are 
still problems. The government cannot provide detailed data and the community 
organize various trips to collect more precise data. 


If the international community could work with the local community and not only 
organize mapathons discionnected from these communities with too often newbies 
and problems never corrected. Projects disconnected from the african 
communities add burden, inconsistent map, Spaghetti has one contributor 
reported.  

How collectively can we corret that ? We need our partners that organize 
mapathons to revise their policies to bring in Quality.  Also, it would be 
interesting that software editors could catch more rapidly duplicates to 
correct them quickly.

- About Overlapping and duplicate buildings - Tools like Osmose report these. 
Looking for Mali, it seems that it has been cleaned.

- Large Areas tagged as buildingYou can use this query in JOSM (Overpass Query 
Panel). If you cover a large zone in one query, your query might be rejected.  
In this example, it will query building polygons that have a perimeter longer 
then 1,000 meters. Only a few were reported in Mali.

[out:xml][timeout:60];way[building](if: length()>1000.0)({{bbox}}); out meta;>; 
out meta;

regard
 
Pierre 
 

Le dimanche 30 juin 2019 13 h 18 min 55 s UTC−4, john whelan 
 a écrit :  
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  I think the concerns are more to do with how do we clean it up.

The first major concern is  "Working for a mapping project with Apple."  the 
concern here is paid mappers and the quality of their work.
The second is there are a fair number of imports of varying quality.  Most 
schools I suspect are fairly accurate but it would be nice to tie the node to a 
building or an area.  Some hospitals are very definitely wrong the node is in 
the middle of nowhere and yes I have checked different imagery.  This really 
needs local knowledge to sort out.

Much of it is HOT, highways that are mapped to the edge of the task manager 
tile.  So one highway section gets mapped as track, another as unclassified, 
another as path, another as tertiary as different mappers put heir own 
interpretation of what the tag should be.
If some nice person could come up with an overpass that picked out large 
buildings in Africa that should pick out the villages tagged as buildings.
For paid mappers I think we need a code of conduct.
I think there is sufficient infrastructure in Africa three days for local 
mappers.  Smartphones are becoming more common and so is an Internet connection 
albeit driven by social media.
Can we build on this?  Schools need to communicate with parents and other 
schools.  This sort of implies a postal service which in turn implies names on 
streets and house numbers.
My impression is there would be an economic advantage, larger cities already 
have street names.  Could someone do a PhD in the subject which might well mean 
a bit more government.  My personal view is some things are best done by 
governments.  Highways for example.
By the way some mappers seem to be non HOT so if we can pick them out and 
support them a percentage may well be local.
Cheerio John
On Sun, 30 Jun 2019 at 11:24, Andrew Hain  wrote:

Is there any sign of mappers being part of an organised activity or of someone 
having encouraged them to contribute?
--Andrew
From: John Whelan 
Sent: 29 June 2019 23:49
To: talk@openstreetmap.org
Cc: Pierre Béland via HOT
Subject: [OSM-talk] Mali I've been going over Mali adding in missing villages 
and hamlets working in the southern and eastern part of Mali and cleaning up as 
I go.  Adding nodes to highways that cross but have no nodes, adding tags to 
untagged ways etc.  I even try to make sure each village has one highway at 
least leading to it. 

However as I work west I'm coming across areas that have lots of buildings and 
lots of errors.  I've zapped more than a few hundred duplicate buildings.  I 
confess I have not put a comment on every changeset especially when the mapper 
has less than 30 edits.  I'm seeing three buildings mapped on top of each other 
by the same mapper.  One is untagged and its not just once.  Interestingly some 
of the changesets are tagged "untangling the spaghetti" and I have sympathy 
with that mapper.

In particular I'm seeing whole villages marked as a single building=yes, 
villages with highways that don't meet in the middle.  

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: [OSM-talk] Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

[Pierre Béland via talk]

Am 11/05/2019 um 21.09 schrieb Simon Poole:
> Just a general remark on the technical issue that sparked of this
> discussion:  squaring buildings is not primarily about improving data
> quality. Non-square buildings are simply visually annoying when
> rendered, so much that I support squaring them "as a rule" too when it
> can reasonably be assumed that there are 90° angles in the actual
> building outline. But I'm not kidding myself that it improves "quality".
> If we wanted to define quality of building outlines in OSM we would
> probably be talking about deviations from the buildings footprint area,
> average deviations from the outline and so on, any of these could be
> very small even without squaring. Actually, squaring might impact them
> negatively, particularly when the outline is rough, but as said: square
> buildings are just so much easier on the eyes :-).

See some annoying deviations from the building footprints we would prefer to no 
observe on the map
https://opendatalabrdc.github.io/Blog/img/JOSM-TM-4975-Ndorwa-County-Uganda.pnghttps://opendatalabrdc.github.io/Blog/img/Overpass-Kochi-India-Irregular-Forms-Validation.png
 
High ratios of Unsquarred buildings is often an indication of imprecise mapping 
with often significative deviations from the outlines. But, yes this is more 
then worry about squarred buidlings. We should also worry about the general 
problem of deviations from the footprint.  Dark and unaligned Imagery, various 
images with different offsets and inexperience in correcting the offsets also 
contribute to bad mapping. 

An angle deviation of 1-2 degree is surely acceptable. But analysis of mapping 
shows in some areas very high ratio of unsquarred buildings or irrregular Round 
buildings with important deviations. We see the same with Building Imports 
projects. We cannot apply a strict Yes or No rule like for Topology errors. But 
how much shoud we deviate ?  Geography or Pop Arts ? 
Pierre 

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

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Pierre Béland via talk]

May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller  wrote 
: 
> Trying to get focus back on the thread topic.

> Storing hints like nosquare=yes (or square=no) is not best practice of
> data curation on w worldwide level.
I dont think either that this is the solution.  We have to look where these 
problems come and try to correct from the source.  Adding  such tag will not 
help software tools to identify where we have problems and can create some 
missunderstanding about its meaning. And experienced mappers are more and more 
reluctant to correct inprecise building mapping.

For Newbies, Building Quality Analysis last year this show some Tasking Manager 
projects with some 60% of unsquarred buldings (see 
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md).
 
The same problem for the DR Congo Ebola response in november where we had to 
restart mapping Butembo in an emergency response and restrict mapping to 
experienced mappers.

For an editor like iD, it can participate with other solutions like better 
training to assure that Newbies understand what Building tracing really mean 
and give then some feedback, like for example saying before save "You have 10 
over 12 buildings that are unsquarred.  If you dont know how to make 
rectangular buildings, you should ask for help before you continue.  Do you 
want to send data anyway ?"

We have the same problem with some Building import projects and I think that 
this needs to be fixed where it originates, before it goes in the database.  
For newbies, this mean more training and monitoring in particular in the 
context of Mapathons.
For Imports, this mean to analyze carefully and correct the data before the 
Import.
 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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