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

[john whelan]

Let's recap.  There wasn't a consensus before you started that your method
was acceptable.

That means you took a risk.

An issue has been identified with your method perhaps you can suggest a way
to deal with the identified issue?

Many Thanks

John

On Thu, Mar 10, 2022, 17:26 David E. Nelson via Talk-ca <
talk-ca at openstreetmap.org> wrote:

> Then are you advocating for total status quo ante and completely
> destroying what took me five months to put together?  That would crush me.
>
> I do not support mapping bays or straits as points at all.  Apart from my
> personal preferences, a lot of information, such as the shape and relative
> sizes of these bodies of seawater, and how one connects to another, would
> be lost.
>
> - David E. Nelson
>
>
> On Mar. 10, 2022 14:07, Pierre Béland via Talk-ca <
> talk-ca at openstreetmap.org> wrote:
>
> 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/search
> en 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.8834
> C'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
> <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.
>
> 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.
> <https://www.openstreetmap.org/relation/8350231>
>
>
>
>
> 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
>
>
> _______________________________________________
> 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/20220310/c20c8c2a/attachment.htm>