Overpass returns node's data with area's information that should not exist

[TitanFighter]

There is a village: http://www.openstreetmap.org/node/337512354

I want to get all relationships of this village.
In order to get it, I do request: http://overpass-api.de/api/interpreter?data=node(337512354);is_in;out;

Also reproducible via https://overpass-turbo.eu with request node(337512354);is_in;out;

In this file\response, the top one area record shows:

<area id="2430719979">
<tag k="name" v="Пересіка"/>
<tag k="place" v="village"/>
</area>

The page of this area (actually way): http://www.openstreetmap.org/way/30719979
This is simply a line, which does not have any tags, but have relationship with node's relation http://www.openstreetmap.org/relation/6258680 as part of it.

The 1st issue - area gets tags somehow from somewhere.
The 2nd one - as this area is simply a line, it seems that this area should be excluded from the response.

Exact same problems happens for this village: http://www.openstreetmap.org/node/2430719324

Seems to be this is a bug. I have seen before ways that actually are areas (looks like boundaries), but in this case the area\way is simply a line.

[mmd-osm]

See https://help.openstreetmap.org/questions/50056/overpass-returns-nodes-data-with-areas-information-that-should-not-exist

The issue is that way 30719979 used to be a valid area, but in the meantime, the way is just a line (rather than an area). The tags are retained from the last time, the way was still an area. This causes inconsistent results.

[date:"2016-05-06T05:51:02Z"];way(30719979);out geom meta;

[TitanFighter]

There is such query: http://overpass-turbo.eu/s/gHt
Timestamps are quite fresh (1 day old):
<meta osm_base="2016-06-08T13:00:02Z" areas="2016-06-07T04:53:03Z"/>

The 1st area shows:

 <area id="2430717714">
    <tag k="addr:postcode" v="93704"/>
    <tag k="boundary" v="administrative"/>
    <tag k="is_in" v="Луганська обл., Україна"/>
    <tag k="koatuu" v="4424555102"/>
    <tag k="name" v="Знам’янка"/>
    <tag k="name:en" v="Znamianka"/>
    <tag k="name:ru" v="Знаменка"/>
    <tag k="name:uk" v="Знам’янка"/>
    <tag k="place" v="village"/>
  </area>

Area id shows that this is way 30717714
Check this way on OSM: http://www.openstreetmap.org/way/30717714 and see that this line was removed 10 days ago and if we check history of chages, we can find that information from area's tags relates to the old\removed record.

Edited:
The same situation with the:

1. node 337587463 and its way 30718706
2. node 337588045 and its way 30719499

[drolbr]

I won't fix this bug.

The problem is: a way or relation that used to represent an area no longer represents an area.
Most cases of these are accidentally damaged ways or relations, and user are happy that the areas are there despite the underlying object being broken.

On the other hand, you should anyway be prepared that multiple areas represent the same administrative structure. For example, for Germany exists a border for the land mass only and a border including the parts of the sea that belongs to Germany. Thus, you should be drop duplicate entries.

[mmd-osm]

I think, the underlying question really is: how can a user have some influence on Overpass API, so that way 30717714 no longer shows up as area 2430717714.

Should the original polygon be restored, then wait for the next Overpass area creation run, delete the object again?

Some practical guidance for a mapper would be really helpful on how to get rid of such phantom areas.

Another option might be to drop all areas once e.g. per month and recreate them from scratch. This way, area 2430717714 would disappear.

[mmd-osm]

With 2 servers now serving queries under the same host name things are getting confusing. On “z“ some old areas still linger around while „lz4“ doesn’t know them.

There’s something missing to recreate areas from scratch once in a while, I.e. delete all area files and start over new. Leaving old areas around forever doesn’t really work.

Ref: https://help.openstreetmap.org/questions/61078/overpass-how-can-i-create-my-own-area