Many islands mapped twice

Sometimes the same island is mapped both as a node and an area. Is there any reason for tagging like this?

When both objects have a name this results in the label rendering twice. Random example: Node: ‪Boucaut Island‬ (‪3587872970‬) | OpenStreetMap

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

Is it just poorly conflated imports or is there something I am missing?

4 Likes

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.

Thanks, so it should be fine to just delete the node after moving any tags to the area?

I suppose I was just surprised to find so many examples in the data.

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,

1 Like

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.

Certainly. But the users in question aren’t exactly fluent in relations yet anyway.

1 Like

Thanks, I didn’t know about that. These nodes would always be in a relation with a role like label or admin_centre, correct? Only a handful of the nodes I’m looking at are in relations at all.

Why not just a multipolygon? That’s what I usually use for place=islet and place=island, particularly when I don’t want to dual-tag a coastline.

Any advantage to a boundary relation that I’m not aware of?

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.

https://maproulette.org/challenge/42539/

It’s limited for now to one particular import that created a lot of these nodes (USGS GNIS).

It’s set to non-discoverable for now, and I would welcome feedback - if there are any objections I’ll delete it.

Okay; and then the instructions say

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?

2 Likes

A typo! I meant, move tags over from the node to the area, then delete the node. Thanks for catching that.

OK so it looks like most of the GNIS island nodes have elevations. Looking at the documentation of the dataset, it says

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 Wiki page for the import says about elevation:

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.

2 Likes

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.

1 Like

The MapRoulette challege to review island nodes inside island areas from the GNIS import has now been completed. :tada:

I’ve added two more.

  • one to review island nodes within island areas but this time globally. It’s limited to the simpler case where there is exactly one place=island/islet node inside a place=island/islet area
  • 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.

3 Likes