In total there are about 6,500 islands (and islets) that are mapped as nodes, and are within an island (or islet) mapped as an area. Some of them are islands in lakes on islands so they actually represent two different islands. But in around 2,000 cases the island node and island area have exactly the same name.
Another 20 random examples, in case you're curious
At a glance, it seems to be forgotten (including large island size, or from GNIS import), bad (MapRoulette) task, bad fix, etc. Among them, I dislike the =coastline + place= mixing 2 linear and area features more, not worth an exception for it.
This won’t apply to most islands, but it’s pretty common for a place that is an admin area to have a relation for the area and a node for the logical centre. Those examples are for Sheffield, and obviously it makes sense to have the “centre” of Sheffield in the urban centre just behind the town hall, not in the geographical centre of the admin area, well to the west,
I have more than once seen new mappers trying to name islands by giving the coastline a name tag, then being disappointed when no name shows up on Carto, and “solving” this by adding a node with place and name, not realizing that adding place to the coastline would solve their problem. Which isn’t obvious. (And the simpler case: going for a node straight away, and future mappers not seeing the node)
Seems like a frequent enough confusion that it has produced quite a few of the duplications.
I would make a boundary relation of the coastlines and make that the place=*. Having place and coastline on the same objects is of course possible, but could be considered out of line with the “One feature, one OSM element” principle.
I’ve made a MapRoulette challenge asking people to check if the node and area refer to the same island, and if so, delete the node after moving any tags over to the area (ignoring cases where this would lead to a conflict of tags). The challenge excludes any islands or islet nodes that are members of relations.
Your task is to find out if the island node and the island area refer to the same real-world island; in that case, move any tags that are not present on the area to the node, then delete the node.
Which sounds backwards, and I think is asking me to move tags to a node and then immediately delete it?
Also I’m not sure I should be really be moving all tags to the island; for the first one I clicked on Martha’s Vineyard; there’s an ele tag which I’m not sure makes sense to apply to the entire island as a whole?
The elevation data available in the GNIS Feature Detail Report are not official and do not represent precisely measured or surveyed values. Elevations are approximate because they are interpolated from terrain elevations sampled on a grid.
The elevation data in GNIS is interpolated so it is generally not precise. … Note that for features mapped as ways and areas in OSM, the elevation data in GNIS corresponds only to the Primary coordinate and is not relevant to a broader area. For these features, the imported ele=* tag should not be retained.
I’ve looked at a few examples in the data with high ele values. It turns out the nodes are not placed at the highest point of the island (which might be a peak) but somewhere near the geographical centre. The ele values are the elevations of these points.
We don’t record the elevations of arbitrary points in OSM, especially when they aren’t accurate measurements, so I think these can safely be discarded.
I’m also not sure of the value of keeping the import-centric gnis: values (gnis:county_id, gnis:created, gnis:state_id, and maybe others?). I can see keeping gnis:feature_id, but I think people should be instructed to double-check that it’s correct for the island that they’re being asked to merge it with. The one that I linked earlier that I thought was for Martha’s Vineyard seems to actually have been for the GNIS data for “Edys Island” (which I’m not familiar with, though it wouldn’t surprise me if it were a name for a portion of the Martha’s Vineyard island somehow). It may just be that I got unlucky with the first place I thought of to look at in the MapRoulette challenge.
I think the grid had a post spacing of about 30 meters if I recall, so fairly coarse. Couple that with the fact that the horizontal accuracy of the GNIS is not good, and you get a situation where the ele value cannot be trusted, even for features, such as natural=peak, where it makes sense.
On second thought you’re probably right to say that the boundary relation is probably not the most fitting in this case, unless the island is an administrative boundary. Dual-tagging is also not a good idea, so you can either make a multipolygon with the place=* tag or, as I prefer it, use overlapping closed ways.
On removing most of the gnis tags, the import’s Wiki page agrees:
The only GNIS field that is useful in OSM is the Feature ID in the gnis:feature_id=* tag.
I’ve added this to the instructions.
And yes, I think you saw a bad example. For this island, the GNIS data seems to be wrong, the island isn’t there. Someone realised that a few years ago and removed the name but didn’t delete the object.
For now I’ve removed any cases from the data where the island node has a different name from the island area, that should make the task easier.
one to review water nodes within water areas. This was suggested by one of the people who worked on the GNIS challenge. Also limited to the case of one natural=water node inside one natural=water area where there isn’t a name conflict between the two. It looks like most of these nodes were created by imports in the US and Canada and often it’s straightforward to move the tags onto the area, but sometimes it needs more attention, for example, the node may be for rapids and the area the entire river, so the water area needs splitting. The challenge only covers inland water bodies because there are some weird cases off the coast that should probably be reviewed separately.
They’re not set to discoverable yet in case anyone has any comments.