ich bräuchte für JOSM eine Liste von Tags, die eine Flächeneigentschaft beschreiben.
Anwendung: Wenn ein type=multipolygon keines dieser Tags hat, dann soll eine Warnung ausgegeben werden. im Moment klappt das nur bedingt. Detals dazu siehe auch https://josm.openstreetmap.de/ticket/19136
Meine Idee: Man gibt einfach alle Tags aus, die bei Relationen mit type=multipolygon mehr als 100 mal verwendet werden, gruppiert nach Häufigkeit und filtert die dann weiter wegen Tippfehlern.
name=, ref=, operator=, network= einschließlich aller mit ihnen verwandten Tags müsstest du aber wieder ausschließen. Dafür dürfte es aber sicherlich schon eine Funktion im JOSM-Quellcode geben, um alt_name=* als name-ähnlichen Key zu erkennen. Sonst landet da u.U. operator=“DB Station&Service AG” in der Liste, weil diese Firma die Bahnsteige “betreibt”.
Meine erste Antwort wäre: Schau doch, welche JOSM-Presets für Flächen zugelassen sind.
Ich pflege für den Tagging-View des OSM Inspectors eine Liste mit Keys (vereinzelt mit zusätzlichem Filter für die Values), was ein Feature-Tag ist, also ein Tag, das beschreibt, um was es sich bei etwas handelt. Die Liste enthält auch Objekte, die keine Flächen sind. Bei den folgenden Keys sind nicht alle Werte flächentauglich:
So als Alternative: Warum nicht einfach nur bei komplett ungetaggten Multipolygonen warnen, bzw. halt ungetaggt bis auf Metadaten-Schlüssel wie source, note oder description? Fallen da wirklich so viele sinnvolle Warnungen weg?
(JOSM ist m.E. generell zu voreilig mit Warnungen. Die sollte es nur geben, wenn sich der Validator ziemlich sicher ist, dass ein Fehler vorliegt, nicht bei bloß unbekannten Tags.)
Habe ich auch dran gedacht, aber es gibt speziell bei Importen oft sehr viele Tags, die eigentlich irrelevant sind, aber nicht in den internen Listen von JOSM auftauchen, z.B. diverse Tags mit dem Prefix ref:bgt:
Es geht ja darum, möglichst wenige falsch-positive zu erzeugen für die Frage: Beschreibt das MP eine Fläche oder nicht? Läuft anscheinend immer darauf hinaus, irgendwelche langen Listen zu pflegen. Der map paint style rendert diverse Sachen nicht als Flache, z.B. viele place=*. Die sind aber durchaus sinnvoll für ein MP.
Wenn die Importeure sich einigermaßen an Tag-Benennungs-Konventionen halten, könntest du so typische Import-Artefakt-Keys mit einer C++Funktion wie dieser (Dokumentation) finden. Du brauchst dann nur eine Liste an Tag-Basen. Das wären z.B. ref, id, name, website, url, comment, note, description, latitude, lat, longitude, lon, x, y, height, ele, length, width [1].
Sicherheitshalber empfehle ich dir auch noch alle Keys auszuschließen, die Großbuchstaben enthalten (sind ref:<KÜRZEL>=* oder Shapefile-Überbleibsel). Keys mit weniger als 11 Zeichen wären auch eine Überprüfung wert (In Shapefiles sind Spaltennamen auf diese Länge begrenzt und manche Leute machen schlechte Importe).
Viele Grüße
Michael
[1] Die Koordinaten noch einmal in Tags abzulegen entspricht keiner Konvention, der ich zustimmen würde. Leute tun es aber trotzdem.
Das wäre schön, aber auch diese Liste ist nicht vollständig. Es fehlen z.B. area:highway=* , healthcare=*. Ein Preset braucht halt deutlich mehr Arbeit als einen Eintrag in einer Liste.
Die auf den Presets basierende Liste wird aber schon erstellt, wenn man bei der Prüfung die “Unwichtigen Warnungen” anzeigen lässt. Dann bekommt man z.B. unter Andere:
Objekttyp nicht in Vorlage - Objekttyp Multipolygon wird von Vorlage nicht unterstützt: Feld- oder Waldweg (1)
für ein type=multipolygon,highway=track
Edit: typo
bei barrier gibt es Werte, z.B. hedge
eigentlich dachte ich auch block wäre möglich, aber obwohl es da 5,7% ways mit dem tag gibt behauptet das Wiki das würde nur auf Nodes genutzt.
Eine solche Liste ist per Definition nie vollständig in OSM egal wie sie generiert wird, aber ihr könntet trivial deutlich vollständigere Presets haben als aktuell. Aber mir war schon klar, dass auf eine separate Liste zu verzichten nicht zur Entwicklungsphilosophie “einmal ist keinmal, und zweimal ist auch nichts” passt.
Kann mit diesem Post nichts anfangen. Bezieht sich wahrscheinlich auf irgendeine Diskussion mit anderen JOSM Entwicklern.
Geht es um den Ansatz, Presets aus Taginfo-Daten zu generieren?