|
An editor renamed some named areas of the sea close to where I live, saying that bodies of water should only have one name for each point. I believe many places, both on land and at sea, are subunits of larger areas, both named. As such I think it is a mistake to avoid overlapping named areas. It is clear on land that, for example, neighbourhoods are subunits of cities, so there is no issues of having one within another. At sea, there is a less clear hierarchy, with inlets, harbours, bays, coves, sometimes existing as subunits, and sometimes existing independently. I think that a Cove may exist independently of a inlet, or as part of an inlet, and should be mapped in whichever way is correct. Maybe it's less clear because we have fewer tags for parts of the sea, than we do for human settlements, and the Here is the changeset where the editor explains their opinion on the matter. The Wikipedia entry for Burrard Inlet (link) describes an area many times larger than what we have mapped on OSM ( Am I missing something? Edit: here's an additional bit of info, there seems to have been a bit of a controversy on the mailing list related to the edits that brought this to my attention. Although that was focused on whether relations were an appropriate choice, not on my question of whether or not named areas should not overlap, even if one is within another. |
|
I would not recommend the naming of water areas by creating large polygons, instead I would just place a node somewhere in the middle of that water area. Most of these areas are somewhat fuzzy at least on the sea side, and creating polygons always forces you to specify an exact (and thereby wrong) boundary. Plus, they make coastline editing more complex as many edits to the coastline will require creating and uploading new versions of the water relations. So just get rid of these polygons and that will neatly solve your overlap problem as well. 2
Although your general point is correct, in this case it's a bit different. This is a fjord, and its area is actually pretty well defined by land on all sides. It's not a vague sea area where the boundary to other vague sea areas is not well defined, and https://www.openstreetmap.org/way/978872326 pretty clearly delineates the western end (although as keithonearth says, what is in OSM right now does not really reflect reality).
(19 Feb '22, 13:42)
SomeoneElse ♦
A agree that for many areas of the sea a node is a good choice, as the boundaries are so ambiguous. For other features the boundaries are pretty well defined, and using a multipolygon is appropriate. The advantage of a multipolygon over a node is it allows software to prioritise based on size, for example the renderer showing large features' names, and not small features' names, when there is not room for both. In the case that initially brought this to my attention many bays, and inlets are clearly defined on 3 sides, and often have a small opening to other areas of the sea.
(22 Feb '22, 23:18)
keithonearth
|
|
Here is an idea I have for how to solve this. I have created Burrard Inlet https://www.openstreetmap.org/relation/13828328 and Howe Sound https://www.openstreetmap.org/relation/13828327 as parent relations for the named bodies of seawater that comprise those larger bodies. I know that Nominatim will not recognize them in this form at this point, and they will not be painted in on a search, but at least it is a start, and better than nothing, and I hope it goes part of the way to satisfying everyone involved in this, including myself. I think when you say "solve this", you mean how best to structure the overlaping areas within Burrard Inlet. The question I posted was only asking the validity of your "one point, one name rule for bodies of seawater". I do not think your original rule is valid. The specifics of how to structure the areas of Burrard Inlet are better discussed on that changeset I initially asked about your rule, but I do not see your new approach as an improvement. Now we have two relations for Burrard Inlet, one that you've renamed "Burrard Inlet (Central)", a term I've never heard used before. I think it would be wise to avoid making further edits until we've come to a consensus.
(21 Feb '22, 03:15)
keithonearth
I said that is the rule that I use when making these edits, and it is my preference. For a lot of these bodies of seawater, they did not even have a presence in the OSM database until I put them in. Besides, the relationship between larger and smaller bodies of seawater can still be understood by context. If you can only reach a small body of seawater by boat from a larger body by going through a single medium-sized body, then the small body of seawater is a child of the medium-sized body. In the cases of Howe Sound and Burrard Inlet, those are instead "composite" areas, with several small named bodies of seawater, none of which overlap, added up to make a single bigger body, like a jigsaw puzzle.
(22 Feb '22, 08:46)
DENelson83
I'm not sure what your point is DENelson83. Yes, Howe Sound does consist of many smaller named bodies which add up to form a larger body of water, sort of like a jigsaw puzzle. This supports my point that bodies of sea water have areas that do have more than one name. If I'm Snug Cove, I'm also in Howe Sound. One point, two names. It should be mapped as such, just because your preference is to obscure the fact that Snug Cove is in Howe Sound doesn't make it a good idea, or the right way to do things. No one has supported your approach.
(03 Mar '22, 21:21)
keithonearth
|
|
You can certainly create an overarching "parent" relation that describes a larger body of water and put in the bodies of water that comprise it as "child" relations. I use this "one point, one name" rule to minimize interference with coastline edits—if someone wishes to edit a length of coastline, they can do so while breaking as few body-of-water relations as possible, and it makes it a bit easier for me to maintain this kind of data. 4
You shouldn't change other people's work based on your own devised rules and habits. When you add new data that is usually acceptable, but here you are destroying data, not nice. I'm not familiar with sea mapping, I've read a few debates, but I guess there are some conventions worldwide that you should follow. If not, you could start a discussion around your "rules", usually on a mailing list, and try to find a consensus and then document it on the wiki. Regards.
(19 Feb '22, 13:24)
H_mlet
|
|
I say just let people edit the coastline as they see fit. In Canada, I apply a tag of "ocean=yes" to all such relations so that they can easily be filtered out. I am fine with just maintaining these relations myself. I will say this, area definitions for bodies of water make their identification much easier on Garmin GPS units. If you move the pointer on a Garmin GPS map to any point on a body of water defined as an area, its name will pop up on the screen. You do not have to point the map to a specific point in that case. 3
You can't map in OSM just for Garmin compliance. Also, it seems you answering to Frederick's answer, please say so to make it clear. You could also have added a comment to his answer. Regards.
(19 Feb '22, 13:20)
H_mlet
(somewhat offtopic for this question but) when I create Garmin maps I specifically exclude certain large areas to avoid this "feature" - in my case the "Island of Great Britain", which it's not useful to be told I'm still on :)
(19 Feb '22, 13:37)
SomeoneElse ♦
These relations had been edited as others had seen fit, but you made significant changes, that are inconsistent with the previous consensus, and common definitions.
(19 Feb '22, 14:35)
keithonearth
|
|
Well, again, I personally will not support any approach for mapping bodies of seawater other than "one point, one name", and that position is reflected in my changesets. You can disagree with me, but you cannot change my mind on this. 2
Indeed - it's perfectly normal that some people in OSM have "views that are shared with few other people". What's important is that most people agree, the project continues and echoes their consensus. For example, I tend to think that "highway=path" isn't a great way to map "where someone can walk", because it uses the same tag value for "who the thing is designed for" and "what the access rights are". It's pretty clear that my view is not the majority one on that.
(03 Mar '22, 22:51)
SomeoneElse ♦
1
@DENelson83 As we all work on the same database, this will be hard for all. Note that I don't have opinion about this particular problem, I just think that you need to be able to discuss and find a common way of doing things. Best regards.
(04 Mar '22, 17:38)
H_mlet
1
I am willing to consider your "one point, one name" suggestion. I can personally support any good idea that has been put forward and justified. In this case, I don't see an advantage, and it seems like a distortion of reality. If presented with sufficient advantages to the approach I will change my mind. But so far all that has been put forth is that one editor likes it, and will not accept any other approach. Also it renders better on Garmin units. This is far from convincing, and as some bodies bodies of sea have been edited (mostly nodes deleted) to fit this unexplained "rule", I personally view it as vandalism.
(05 Mar '22, 04:21)
keithonearth
|
I believe that the relevant wiki page is https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element and I don't think that it supports @DENelson83's approach here (as I've said on the changeset).