Other suspicious MP cases

[nebulon42]

I'm not sure if you have this in your pipeline anyway, but found those cases worth mentioning here.

Multipolygon relations with only one member

relation({{bbox}})
  [type=multipolygon]
  (if:count_members()==1);
(._;>;);
out meta;

Closed ways that are member of more than one multipolygon relation with role outer

(clarified, that only closed ways that are member in more than one multipolygon with role outer may be suspicious)

[ImreSamu]

... don't know if it is possible to do with Overpass API.

imho: we can use the osmium-tool for detecting suspicious MP cases.

I have created a minimal prototype script analyze_osm_relations.sh: https://github.com/ImreSamu/osm_simple_relation_analyzer201703
And I am sure it is easy to create a similar report for detecting multiple outer role.

Check the reports about

austria-latest.osm.pbf (2017-03-11T21:43:02Z)

• FREQ_RELATION_OUTER
• LIST_RELATION_OUTER
• FREQ_RELATION_NO_TYPE
• LIST_RELATION_NO_TYPE
• FREQ_RELATION_OUTER_YEAR_VERSION

berlin-latest.osm.pbf (2017-03-11T21:43:02Z)

• FREQ_RELATION_OUTER
• LIST_RELATION_OUTER
• FREQ_RELATION_NO_TYPE
• LIST_RELATION_NO_TYPE
• FREQ_RELATION_OUTER_YEAR_VERSION

asia-latest.osm.pbf (2017-03-09T21:43:02Z)

• FREQ_RELATION_OUTER
• LIST_RELATION_OUTER
• FREQ_RELATION_NO_TYPE
• LIST_RELATION_NO_TYPE
• FREQ_RELATION_OUTER_YEAR_VERSION

germany-latest.osm.pbf (2017-03-08T21:43:02Z)

• FREQ_RELATION_OUTER
• LIST_RELATION_OUTER
• FREQ_RELATION_NO_TYPE
• LIST_RELATION_NO_TYPE
• FREQ_RELATION_OUTER_YEAR_VERSION

see more ... : https://github.com/ImreSamu/osm_simple_relation_analyzer201703/blob/master/docs/index.md

Example :

FREQ: Analyze OSM Relations with role=outer without primary OSM keys

austria-latest.osm.pbf ( 2017-03-11T21:43:02Z ) http://download.geofabrik.de/europe/austria-updates [Rv:0.1b]

count	osm tag combinations
6261	type=multipolygon,
132	name=, type=multipolygon,
68	name=, type=multipolygon, source=,
27	type=multipolygon, source=,
27	note=, type=multipolygon,
17	golf=, type=multipolygon,
11	ref=, type=multipolygon,
9	type=multipolygon, created_by=,
8	name=, type=multipolygon, source=, wikipedia=,
7	type=multipolygon, surface=,
5	area=, name=, type=multipolygon,
4	type=multipolygon, description=,
4	type=multipolygon, addr:city=, addr:hamlet=, addr:postcode=, addr:housenumber=,
4	area=, type=multipolygon,
3	type=multipolygon, addr:city=, addr:place=, addr:country=, addr:postcode=, addr:housenumber=,
3	type=building,
3	,
2	type=multipolygon, layer=,
2	type=multipolygon, addr:place=, addr:housenumber=,
2	type=multipolygon, addr:city=, addr:hamlet=, addr:housenumber=,
2	name=, type=multipolygon, name:de=,
2	name=, type=multipolygon, access=,
2	name=, type=junction, junction=,
2	lit=, ref=, name=, type=multipolygon, oneway=, piste:name=, piste:type=, piste:grooming=, piste:difficulty=,
2	golf=, surface=, type=multipolygon,
1	type=multipolygon, wood=, surface=, landcover=,
1	type=multipolygon, wikipedia=,
1	type=multipolygon, website=,
1	type=multipolygon, source=, service=,
1	type=multipolygon, fixme=,
1	type=multipolygon, designation=,
1	type=multipolygon, animal=,
1	type=multipolygon, addr:city=,
1	type=multipolygon, access=,
1	ref=, area=, name=, type=multipolygon,
1	note=, type=multipolygon, source=,
1	name=, type=multipolygon, wikipedia=,
1	name=, type=multipolygon, wikimedia_commons=,
1	name=, type=multipolygon, wikidata=, wikipedia=,
1	name=, type=multipolygon, website=,
1	name=, type=multipolygon, water_park=, opening_hours=,
1	name=, type=multipolygon, source:name=, source:position=,
1	name=, type=multipolygon, source=, heritage=, wikipedia=, heritage:ref=, heritage:since=, heritage:operator=,
1	name=, type=multipolygon, is_in=,
1	name=, type=multipolygon, heritage=, ref:at:bda=, heritage:operator=,
1	name=, type=multipolygon, admin_level=,
1	name=, type=multipolygon, access=, bicycle=,
1	name=, type=building,
1	name=, note=, TMC:cid_58:tabcd_1:Class=, TMC:cid_58:tabcd_1:LCLversion=, TMC:cid_58:tabcd_1:LocationCode=, type=TMC,
1	lit=, ref=, name=, type=multipolygon, oneway=, piste:type=, piste:grooming=, piste:difficulty=,
1	ele=, name=, note=, sqkm=, type=multipolygon, name:hu=, alt_name=, wikidata=, wikipedia=,
1	area=, type=multipolygon, surface=,
1	area=, type=multipolygon, source=, service=, surface=,
1	area=, name=, type=multipolygon, piste:type=, piste:grooming=, piste:difficulty=,
1	area=, lit=, name=, oneway=, piste:difficulty=, piste:grooming=, piste:name=, piste:type=, ref=, type=multipolygon,
1	admin_level=, land_area=, name=, name:de=, name:hu=, name:sl=, type=land_area,
1	addr:city=, addr:country=, addr:housenumber=, addr:place=, addr:postcode=, type=multipolygon,

LIST of Problematic/OldStyle OSM Relations with role=outer

austria-latest.osm.pbf ( 2017-03-11T21:43:02Z ) http://download.geofabrik.de/europe/austria-updates [Rv:0.1b]
Not included: type=multipolygon

url	osm tags
http://www.openstreetmap.org/relation/11935	type=multipolygon,created_by=JOSM,
http://www.openstreetmap.org/relation/11936	type=multipolygon,created_by=JOSM,
http://www.openstreetmap.org/relation/14605	name=HS%20%1,type=multipolygon,
http://www.openstreetmap.org/relation/27564	type=multipolygon,created_by=Potlatch%20%0.10b,
http://www.openstreetmap.org/relation/28905	type=multipolygon,created_by=Potlatch%20%0.10f,
http://www.openstreetmap.org/relation/29311	type=multipolygon,created_by=Potlatch%20%0.10b,
http://www.openstreetmap.org/relation/32543	type=multipolygon,created_by=Potlatch%20%0.10b,
http://www.openstreetmap.org/relation/49949	type=multipolygon,created_by=Potlatch%20%0.10f,
http://www.openstreetmap.org/relation/65236	type=multipolygon,created_by=xybot,
http://www.openstreetmap.org/relation/68842	name=Finanzamt%20%Wien%20%21%2c%%20%22,type=multipolygon,
http://www.openstreetmap.org/relation/68845	type=multipolygon,created_by=Potlatch%20%0.10f,
http://www.openstreetmap.org/relation/102552	name=Weidenbach%20%Biotop%20%1,type=multipolygon,
.... cutted ...

[joto]

@nebulon42 Yes, I have thought about this and am tracking those, too, but haven't exposed the numbers on the stats page. There are currently about 140,000 multipolygon relations with a single member. I am not sure what to do about them, though. Many of them could probably be replaced by a simple closed way, but some of them will be too long for that, or it makes sense to keep the way as it is, because it is used in a neighboring multipolygon or so. Anyway, 140,000 multipolygons are not really that many so that the extra effort needed compared to a closed way would amount to a big problem.

[stoecker]

During the fixing of some intersections I left single object multipolygons. When it is a small building or something alike I converted it to a single way. In cases of larger landuses I kept the multipolygons, as the chance that additional inners will come up later is high and when everything else of similar style is a multipolygon it looks better.

So in case you want to treat these as "to fix" I'd suggest to restrict it to small objects less than a hectare.

[wolfbert]

@ImreSamu Just for information, I've fixed most of the issues in LIST_RELATION_NO_TYPE for Austria with exception of public transport, hiking routes and some weird stuff.

[wolfbert]

Another case for cleanup are ways tagged with "type=multipolygon". There were about 100 cases in Austria, which I'm working on. Most are left overs and the tag can be deleted, but in some cases the mapper wanted to create an mp (and failed), so individual checking is necessary.

[wolfbert]

A database query for relations with "type=multipolygon" and excluding tags ['landuse', 'natural', 'building', 'waterway', 'highway', 'leisure', 'amenity', 'boundary', 'railway', 'tourism', 'place', 'man_made', 'public_transport'] will yield 639 old-style or suspicious multipolygons in Austria (and all mps detected on the mp-map have already been fixed). Most of those are old-style buildings, landuses and boundarys.

Update: turns out that with exception of buildings, these are really hard to fix. It's amazing what people have done with mps (and not all of it correctly, but often a better solution is not obvious or would require extensive changes).

[gscholz]

What about the current state of the comparison map:

http://area.jochentopf.com/map/index.html#3/30.00/0.00

This morning it does not show any red dot. Are all relations fixed?
Guido

[joto]

@gscholz No, software error. Fixed now.

[gscholz]

Thanks,