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

Thu Mar 10 00:42:40 UTC 2022

An excellent point and I agree that before changing or cleaning up these
areas we should have come to a consensus about how areas which are part of
larger areas should be mapped.

In the meantime mapping as nodes at least means there are no errors.

My vote would be for nodes as being the least complex solution.

Cheerio John

On Wed, Mar 9, 2022, 19:34 Andrew Lester <a-lester at shaw.ca> wrote:

> 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). 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
> NateWessel.com <https://www.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
>
> On Mar 6, 2022, at 12:42, Pierre Béland via Talk-ca <
> 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
>
> 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) 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(%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
> <http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Btimeout%3A100%5D%3B%0A%28%0A%20%20relation%5Bnatural~'bay%7Cstrait'%5D%28%7B%7Bbbox%7D%7D%29%3B%0Away%5Bnatural~'bay%7Cstrait'%5D%28%7B%7Bbbox%7D%7D%29%3B%0Anode%5Bnatural~'bay%7Cstrait'%5D%28%7B%7Bbbox%7D%7D%29%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'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
> <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>
> Après - 1335 chemins, 50 relations
>
> 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
> <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>
>
> 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/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 <
> 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
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> _______________________________________________
> Talk-ca mailing listTalk-ca at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> _______________________________________________
> 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/dad41e09/attachment-0001.htm>