"uninteresting"/"unimportant" tag list for detecting old-style polygons

[ImreSamu]

I didn't find any information, so maybe somebody can help me.

What is the full "uninteresting"/"unimportant" tag list for detecting Old-style polygons ?

My first guess : the keys from osm2pgsql default syle , marked with 'delete'

note
note:*
source
source_ref
source:*
attribution
comment
fixme
created_by
odbl
odbl:note
SK53_bulk:load
tiger:*
NHD:*
nhd:*
gnis:*
geobase:*
accuracy:meters
sub_sea:type
waterway:type
KSJ2:*
yh:*
osak:*
kms:*
ngbe:*
naptan:*
CLC:*
3dshapes:ggmodelk
AND_nosr_r
import
it:fvg:*

We have a better definitions ?

[grischard]

JOSM also has converted_by and import in the keys it considers discardable.

I'd add history and FIXME.

[tyrasd]

Maybe also add name and name:* (and similar tags like ref, etc.)?

A completely different approach would be to flag every multipolygon that has no area tag set. One could use an inverse version of osm-polygon-features or id-area-keys for that (maybe with added variants of the respective tags, e.g. disused:<area-key>, abandoned:<area-key>, etc.). This approach could maybe result in a few false-positives, but wouldn't overlook any otherwise possibly false negatives.

[grischard]

@tyrasd it would be very interesting to compare the two. The relevant and slightly complex piece of code, in JOSM, is hasAreaTags.

It's interesting how these three sources have slightly different ideas of what's an area and what isn't.

[ImreSamu]

@tyrasd

Maybe also add name and name:* (and similar tags like ref, etc.)?

In my mind we have a 4 category of osm keys

• Primary OSM keys / name spaces
  • aeroway|amenity|attraction|barrier|boundary|building|craft|...
  • abandoned:|proposed:|planned:|removed:|razed:|disused:|demolished:|seamark:|was: ....
• Secondary OSM keys ( without the primary OSM keys - it is a probably a tagging problems )
  • wheelchair|wikipedia|wikidata|layer|ref|url|phone|website|....
  • area
  • name ; name:* ; alt_name ....
  • ....
• "uninteresting"/"unimportant" OSM keys ( for detecting Old-style polygons )
• Other keys ( none of the above )

I would like to separate the tagging errors and the old-style polygons.

So they are maybe a tagging problems ( no primary osm keys )

• name=, type=multipolygon,
• area=, type=multipolygon,
• area=, type=multipolygon, smoking=, wheelchair=, description=,
• type=multipolygon, wheelchair=,
• type=multipolygon, wikipedia=,

And they are maybe an old-style multipolygons candidates ( only "uninteresting"/"unimportant" OSM keys )

• note=, type=multipolygon,
• type=multipolygon, created_by=,
• type=multipolygon, fixme=,

A completely different approach would be to flag every multipolygon that has no area tag set. One could use an inverse version of osm-polygon-features or id-area-keys ...

my approach is similar ;

• find every relations/multipolygons (tag combinations) without a "Primary OSM keys" see: https://github.com/ImreSamu/osm_simple_relation_analyzer201703/blob/master/docs/germany-latest.osm.pbf_FREQ_RELATION_OUTER.md And thank you for the links, I will try to merge with my primary key list.

[joto]

I don't think we have to make it all so complicated. Just fixing everything that has no tag except type=multipolygon and we are a good way there. Ignoring source and created_by and we get almost 100%. After that we can look at other tags and the obvious place is osm2pgsql. Whatever osm2pgsql thinks is old-style will have to be dealt with eventually. If you start looking more closely into the tag combinations, you'll get to many things that aren't really about fixing old-style multipolygons but general "fixing of suspect" data, and that's not are focus here.

[ImreSamu]

side note: As I see the NEW Lua based openstreetmap-carto version will have more "unwanted" keys, than the current version. See delete_tags, delete_prefixes in openstreetmap-carto.lua