[Talk-ca] Définition de zones fluviale / cotières vs chenaux de navigation ou baies

Thu Mar 10 00:27:56 UTC 2022

Personally, I don't have a strong opinion one way or the other on whether these bodies of water should be mapped as relations or not. The relations do make the data more complicated to manage and there's a higher chance of a newer contributor accidentally breaking things, and it does require some arbitrary boundaries. On the flip-side, the relations do provide more useful information to data consumers and renderers by better-representing the area of each body. I'd probably lean more towards keeping things as nodes if forced to choose, but my opinion wouldn't be strong enough to revert relations to nodes based solely on this factor. 

However, I don't agree with the way in which the relations were implemented. David chose to use a personal "one point, one name" guideline, where no bodies of water overlap each other. In my opinion, this is objectively wrong and has led to flawed data. 

Let's look at an example local to me: Thetis Cove ( [ https://www.openstreetmap.org/relation/8350231 | https://www.openstreetmap.org/relation/8350231 ] ). With the way David has mapped things, the interior of this bay is its own body of water and the ways are not included in the larger Esquimalt Harbour relation (https://www.openstreetmap.org/relation/6599864). Semantically, if someone were to sail a boat into this bay with the data in its current form, they would be "leaving Esquimalt Harbour and entering Thetis Cove". I think most would agree that this is demonstrably wrong. This bay is just as much a part of Esquimalt Harbour as the rest of the water. When looking at the Esquimalt Harbour relation above, we can see similar issues with Price Bay, Plumper Bay, the large Constance Cove to the southeast, and several other smallers bodies of water. In reality, all the water inside the Fisgard Lighthouse/Duntze Head line is part of Esquimalt Harbour and should be included in that relation, but these areas have been arbitrarily excluded due to David's personal guideline. 

There are now many examples like this all around Canada's coastline, where "child" bodies of water have not been included in the logical "parent" relation. At this point, the community needs to come to a consensus on whether the current state of the data is acceptable or not. 

If it's determined that the data isn't okay, I think we have two options: 
1. Someone fixes the data, which would be a massive undertaking, since each of the "parent" and "child" relations would need to be inspected to see what needs to be included where. It would have been easier to manage this task while the edits were being made initially, but the community wasn't aware of the guideline that was going to be used. 
2. The changes get reverted, so the bodies of water return to nodes. 

As you can probably tell from everything above, I do not believe that the current state of the data is acceptable. Now we need others to weigh in and for the community to come to a consensus (something that should have occurred before such a massive project was undertaken). 

Andrew 
Victoria, BC 

From: "Nate Wessel" <bike756 at gmail.com> 
To: "talk-ca" <talk-ca at openstreetmap.org> 
Sent: Sunday, March 6, 2022 11:05:11 AM 
Subject: Re: [Talk-ca] Définition de zones fluviale / cotières vs chenaux de navigation ou baies 

This last month, for my own reasons, I happened to be doing some extensive edits along the coastline boundary between Quebec and Nunavut. I've noticed that the places where David has been editing are now much better mapped, and more manageable in terms of way-size and relation alignment than the areas where he hasn't (yet?) been active. 

I won't purport to defend all his edits since they are so numerous, but I will say that in all it's clear to me that he has been having a net-positive influence on Canada's coastline data. If he is the last editor on so many coastal relations, I would argue it is because the data has been quite stagnant, not because he is exerting some inappropriate influence. 

Cheers, 

Nate Wessel 
Cartographer, Planner, Transport Nerd 
[ https://www.natewessel.com/ |  NateWessel.com  ] 
On 2022-03-06 13:38, Martin Chalifoux via Talk-ca wrote: 

Je suis d’accord avec Pierre. Briser les plans d’eau en morceaux pour cartographier des baies c'est inutile et ça ajoute une complexité sans ajouter de fonctionnalité. Le POI est bien adéquat pour une baie. De plus les voies (ways) qui sont intégrées a de multiples relations pour former plusieurs polygones adjacents (wood, bay, lake, etc) c’est vraiment plus complexe et difficile à maintenait. Si il y avait un avantage je ne dit pas mais j’en voit aucun. La réalité est que la limite réelle d’une baie est rien d’officiel, c’est un peu arbitraire. Alors le POI au centre approximatif de la baie c est suffisant. Toute ceci est un bel exemple de temps inutilement passé a faire des modifications complexes qui ajoute aucune nouvelle information ni précision à OSM. “If not broken, don’t fix it" 
Cheers 

BQ_BEGIN

On Mar 6, 2022, at 12:42, Pierre Béland via Talk-ca < [ mailto:talk-ca at openstreetmap.org | talk-ca at openstreetmap.org ] > wrote: 

David continue de façon unilatérale à imposer son modèle de définition des baies et chenaux/estuaires sous forme de relations et contrairement à ce qu'il exprime, la communauté n'a pas approuvé sa proposition lors des discussions sur talk-ca en octobre. 
[ https://lists.openstreetmap.org/pipermail/talk-ca/2021-October/010127.html | https://lists.openstreetmap.org/pipermail/talk-ca/2021-October/010127.html ] 

Vous trouverez ci-dessous un résumé des actions et discussions à date via changesets et un tableau démontrant à quel point la démarche de David est unilatérale. Vous trouverez également des requêtes Overpass qui permette d'analyser les actions de David et autre solution ailleurs. Et à la fin, je fais des propositions pour progresser dans ce désaccord avec David. 

A date, David a couvert les côtes ouest, est et nord du Canada et en partie semble-t-il les États-Unis. Le tableau ci-dessous à partir de Taginfo, Taginfo-CA et Overpass montre comment David agit de façon unilatérale avec 12150 des 18937 relations (64%) où il est le dernier éditeur. David pourrait confirmer, mais il semble que pour la majorité des baies, celles-ci existaient déja sous forme de points et David a pris la liberté de transformer ces points sous forme de relations alourdissant grandement la base de données. 

Nombre d'objets OpenStreetMap, 2022-03-03 

natural=bay 	Monde 	Canada 	David 
Nœud 	49 440 	4 692 	0 
Chemin 	2 988 	40 	5 
Relation 	18 937 	12 150 	13 050 

natural=strait 	Monde 	Canada 	David 
Nœud 	1 449 	49 	0 
Chemin 	1 615 	12 	5 
Relation 	2 463 	1 636 	1 728 

Il transforme les points en relations et coupe des polygones existants (example [ https://www.openstreetmap.org/relation/2427871 | https://www.openstreetmap.org/relation/2427871 ] ) qui ne correspondent pas à sa vision de décrire les baies, estuaires, chenaux. David n'assure pas la cohexistance d'éléments qu'il ajoute tel chenal local ou baie avec des objets existants tels pour le Fleuve ou Golf du Saint-Laurent. 

Il y a pourtant des solutions simples telles que baies sous forme de points et détroits/chenaux sous forme de points ou lignes. La requête Overpass ci-dessous permet de voir au sud de l'Angleterre la représentation de baies en points et de chenaux en lignes et non en polygones / relations. 
[ http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%3B%0A%28%0A%20%20relation%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Away%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Anode%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0A | http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%3B%0A(%0A%20%20relation%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Away%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Anode%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0A ] )%3B%0Aout%20meta%3B%3E%3B%20out%20meta%3B%0A&C=51.38898;0.61764;14 

Cela permet la cohexistance avec d'autres objets OSM et évite de complexifier les données. 

Voici ici un exemple avant / après des modifications de David pour l'Archipel des Îles de Mingan (distance sur la côte d'environ 30km). 
Avant - 34 noeuds natural=bay 
[ http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%0A%5Bdate%3A%272021-09-01T00%3A00%3A00Z%27%5D%3B%0A%28%0A%20%20relation%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Away%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Anode%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0A%29%3B%0Aout%20meta%3B%3E%3B%20out%20meta%3B%0A&C=50.25203;-63.73512;11 | http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%0A%5Bdate%3A'2021-09-01T00%3A00%3A00Z'%5D%3B%0A(%0A%20%20relation%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Away%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Anode%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0A)%3B%0Aout%20meta%3B%3E%3B%20out%20meta%3B%0A&C=50.25203;-63.73512;11 ] 
Après - 1335 chemins, 50 relations 
[ http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%0A%3B%0A%28%20%20relation%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Away%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0Anode%5Bnatural~%27bay%7Cstrait%27%5D%28%7B%7Bbbox%7D%7D%29%3B%0A%29%3B%0Aout%20meta%3B%3E%3B%20out%20meta%3B%0A&C=50.25203;-63.73512;11 | http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%0A%3B%0A(%20%20relation%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Away%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0Anode%5Bnatural~'bay%7Cstrait'%5D(%7B%7Bbbox%7D%7D)%3B%0A)%3B%0Aout%20meta%3B%3E%3B%20out%20meta%3B%0A&C=50.25203;-63.73512;11 ] 

Voici à nouveau les deux Changesets où j'ai discuté des modifications avec David. Après avoir révisé partiellement les données, celui-ci s'est opposé à aller plus loin. 
[ https://www.openstreetmap.org/changeset/114545684 | https://www.openstreetmap.org/changeset/114545684 ] 
[ https://www.openstreetmap.org/changeset/117963247 | https://www.openstreetmap.org/changeset/117963247 ] 

Je répète à David à nouveau que sa façon unilatérale d'agir est inacceptable. 

A ce point il faut trouver une solution pour poursuivre. David a toujours le choix de communiquer avec le Comité des données (DWG) de l'OSMF pour valider sa démarche. 

Sinon je demande à David de revenir en arrière pour les relations liées au Fleuve et au Golf du Saint-Laurent. Après examen des données, on pourrait aussi voir utile de réviser ailleurs. 

Nous referons le point au cours de la semaine. Si aucun progrès, je renverserai les 
modifications effectuées par David. 

cordialement 

Pierre 

Le lundi 28 février 2022, 20 h 37 min 03 s UTC−5, David E. Nelson < [ mailto:denelson83 at yahoo.ca | denelson83 at yahoo.ca ] > a écrit : 

I came up with this "one point, one name" guideline for the simple reason that it is meant to minimize interference with coastline edits. If an editor subsequently goes in and updates a stretch of coastline, as few seawater relations as possible are broken, and it makes my maintenance of this dataset, aided by the OSM Inspector utility, easier. 

- David E. Nelson 

_______________________________________________ 
Talk-ca mailing list 
[ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] 
[ https://lists.openstreetmap.org/listinfo/talk-ca | https://lists.openstreetmap.org/listinfo/talk-ca ] 

_______________________________________________
Talk-ca mailing list [ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] [ https://lists.openstreetmap.org/listinfo/talk-ca | https://lists.openstreetmap.org/listinfo/talk-ca ] 

BQ_END

_______________________________________________ 
Talk-ca mailing list 
Talk-ca at openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-ca 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20220309/297e74bf/attachment-0001.htm>