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

Pierre Béland pierzenh at yahoo.fr
Thu Mar 10 22:07:59 UTC 2022


Il est possible d'interroger la base toponymique du Canada. Elle contient les données des provinces/territoires et les représentent sous forme géographique.
fr  http://www4.rncan.gc.ca/recherche-de-noms-de-lieux/searchen http://www4.rncan.gc.ca/search-place-names/search
Esquimalt Harbour est représenté sous forme d'un polygone tracé grossièrement tandis que le Thetis Cove est représenté par un point. De même, le long du fleuve Saint-Laurent les petites baies et chenaux (way=[bay|strait]) sont représentés par des points ou par des polygones intégrant ou non les Baies. Nous devons de notre côté adopter une approche cohérente et simple et ces outils quoique très utiles ne nous apportent pas toutes les réponses. 

Voici ci-dessous un exemple avec hiérachies multiples où les éditions récentes ont causé beaucoup de problèmes.
Le détroit de Jacques Cartier et l'Archipel de Mingan juste au nord font normalement partie du Golfe du Saint-Laurent mais les révisions avec polygones (relation=[bay|strait]) excluent des zones alourdissent inutilement les données de la zone.
Détroit de Jacques-Cartier
https://www.openstreetmap.org/relation/13515290#map=11/50.2485/-63.8834 J'ai actuellement un fichier de travail qui vise à renverser les éditions pour l'Estuaire maritime du Saint-Laurent qui excluaient baies et chenaux. 
https://www.openstreetmap.org/relation/13515290#map=11/50.2485/-63.8834C'est oui un travail colossal (une journée à date pour moins de 40% de la zone à couvrir pour la relation). 

Je planifie de renverser les données actuelles et revenir à la situation avant les conversions des points (natural=bay) en relations (en général de très petites baies) et remettre les contours le long de la rive comme c'était au départ.

Je suis favorable à l'option de représenter les baies et les chenaux sous forme de points (node [natural=bay|strait]).   Doit-on prévoir des exceptions lorsque le littoral côtier est très échancré ? Si oui,  il faut éviter d'inclure partiellement des îles comme dans l'exemple ci-dessous.https://www.openstreetmap.org/relation/13515290#map=11/50.2485/-63.8834
Pierre 
 

    Le mercredi 9 mars 2022, 19 h 45 min 41 s UTC−5, john whelan <jwhelan0112 at gmail.com> a écrit :  
 
 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 (Relation: ‪Thetis Cove‬ (‪8350231‬) | OpenStreetMap). 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.


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Relation: ‪Thetis Cove‬ (‪8350231‬) | OpenStreetMap

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

 |

 |





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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20220310/73b60464/attachment.htm>


More information about the Talk-ca mailing list