Changeset: 132263642
split a huge multipolygon in 2 parts (more to come)
Closed by deleted
Tags
changesets_count | 828 |
---|---|
created_by | iD 2.24.1 |
host | https://www.openstreetmap.org/edit |
imagery_used | Bing Maps Aerial |
locale | fr-FR |
Discussion
-
Comment from cryptickryptos
But now there is more than one Rainy Lake. Wouldn't it be more accurate to split the ways and include them in a single relation as outer members?
-
Comment from user_18305684
The rainy lake was a huge multipolygon (when i say huge, I mean with many members (ways) which means many nodes which means impossible to open in ID (and to work on it with iD).
Someone had created the relation 12311888 2 years ago to split this huge multipolygon in smaller parts : I think it was a good idea.
One of this part was still huge and no more working (map was empty, the lake no more visible).
I tried to fix this by splitting this last multipolygon in smaller parts : now all is working and the relation 12311888 is complete (I controlled with taginfo all nodes/ways/relations with the name Rainy lake and fixed this particular relation).
Now there is one last step : to control each area and improve geometry + add missing islands.
I have done some but there is still much to do.
Best regards -
Comment from cryptickryptos
I understand the purpose of it, but the way it is done seems to be the equivalent of splitting the United States up into a bunch of areas as if it is multiple separate countries, when in reality it is only one contiguous area. If it cannot be worked on in iD, wouldn't it be better to use JOSM instead?
-
Comment from cryptickryptos
If anything, I think it makes it a lot harder to edit (things such as multilingual names) when there are now dozens of relations that have to be located and selected any time another user wants to make a change consistently.
-
Comment from user_18305684
A boundary (United States) is not a multipolygon.
For a big/long/wide river, you split the water areas into smaller parts because it is impossible to have only one river area (for the Nile or the Amazon or Mississipi).
For the river areas, you don't need a relation because the names are on the waterway ways (you just add a waterway relation to have all the waterways ways in one relation). River areas is only for the map.The good thing when you split the big multipolygon in several part is the name : with one relation, you will have one name on the map, in the middle of all of the area and probably not on the lake. By splitting the multipolygon, you will have several times the name, inside the lake, like you have the name of the river all along the ways inside the water areas.
Another point : if someone makes a change in the north part of the lake and at the same time someone else makes a change in the south, with one big multipolygon you will have a conflict (probability is high). With small multipolygons, no more conflicts.
There is no equivalent of a waterway relation for big multipolygons. Here someone thought that a site relation would be similar. I agree with him. Sometimes some mappers are using "collection" but it seems deprecated now. If you think we should create a new type of relations, you can propose one.
Best regards
-
Comment from Minh Nguyen
The lake is very complex in reality; I would think OSM should reflect that fact to the extent possible. It seems like you’ve identified a gap in the tagging model. Splitting up this lake is at best a workaround. After all, not every editor or data consumer would be impacted by the issue you mentioned.
-
Comment from user_18305684
Please stop to comment this changeset.
If you want to talk about huge multipolygons, open a new talk on https://lists.openstreetmap.org/listinfo/talk
Or ask the mapper who created the relation 12311888 (see version 1).
Or if you have the solution, make a proposal on the wiki.
Just to remember :
in the relation 12311888 (=the lake), you have (today):
853 ways
147596 nodes
And the lake is not complete, a lot of islands are missing.
Thanks. -
Comment from Minh Nguyen
FYI, the local community has been discussing this issue on OSMUS Slack: https://osmus.slack.com/archives/CCV2P9QET/p1679802276162459 https://osmus.slack.com/archives/C2VJAJCS0/p1679826643887899 (You’re welcome to join the workspace by visiting: https://slack.openstreetmap.us/ )
-
Comment from mikeocool
Hey there, I think folks are commenting on this changeset, because this is not how lakes are typically represented. Personally, I haven't been able to find any other examples of lakes that are represented by several multipolygons that have a super relation as you have done here.
Looking at other larger and more complicated lakes in the area -- such as Lake of the Woods and Lake Superior, they are both represented as a single multipolygon relation with many smaller ways forming the outer ring of the multipolygon. Both these appear to be editable in iD.
Additionally, if you look at the rendering of this lake on openstreetmap.org -- the labeling of Rainy Lake is now very inconsistent with the other lakes in the area -- each multipolygon is labelled instead of having a single label for the whole lake, like all other lakes in the area.
I came upon this changeset when I was working on a map style that only labeled large lakes at low zoom levels. The Rainy Lake label wasn't showing up, because it is appearing in the data as many small lakes instead of a single large lake.
In my opinion, you've made a good step by breaking up large ways -- but rather than having many multipolygons represent a single lake, we should use the ways that represent the lake's actual shoreline to form the outer ring of a single multipolygon, and eliminate the pieces of the ways that are just breaking up the lake into multiple pieces.
-
Comment from user_18305684
"that are represented by several multipolygons that have a super relation as you have done here." :
wrong, I did nothing, the super relation was created by Glassman, see https://www.openstreetmap.org/changeset/99222957PLEASE STOP COMMENT HERE
-
Comment from Minh Nguyen
Sorry for implicating you in this multipolygon mess. Indeed, the split multipolygons originated even earlier, in changeset 56736435 by a different mapper. We’ll continue to discuss this as a community, but you’re welcome to participate in the discussion if you prefer the current approach.
-
Comment from mikeocool
Agreed, apologies Krako73, I should looked for closely at the history.
- Comment from Minh Nguyen
Ways (12)
- 1139709292, v1
- 1139709293, v1
- 1139709294, v1
- County Road 134 (1139709295), v1
- County Road 134 (1139709296), v1
- County Road 134 (18129806), v6
- 49786847, v40
- 49787073, v7
- 564826564, v3
- 564826687, v2
- 1139619838, v2
803449639, v2
Relations (4)
Nodes (1-20 of 27)
- 1
- 2
- 10621319838, v1
- 10621319839, v1
- 10621319840, v1
- 10621319841, v1
- 10621319842, v1
- 10621319843, v1
- 10621319844, v1
- 10621319845, v1
- 10621319846, v1
- 10621319847, v1
- 10621319848, v1
- 853620049, v6
- 853620050, v3
- 853620055, v3
- 3402645438, v2
- 3402645441, v2
- 3402645443, v2
- 3402645464, v2
- 5441165423, v2
- 5441179915, v2
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |