Bisher haben wir die Situation, dass die Renderer und deren Importprogramme raten müssen, ob der Mapper eine Fläche meint oder einen Weg, wenn der Weg geschlossen ist. Das tun sie anhand des Schlüssels “area=yes/no” (das relativ zuverlässig) oder (unzuverlässig) anhand weiterer Schlüssel (“natural” ist bestimmt eine Fläche, “landuse” und “leisure” auch, “highway” ist ein Strich …)
Diese Raterei führt dazu dass “leisure” als Fläche gerendert wird (hier z.B.), wo vielleicht eher ein Strich gemeint sein könnte (hier das gleiche Gebilde).
Man könnte das Spiel natürlich verfeinern (“leisure ist eine Fläche, ausser leisure=track”), aber das wäre auch nur rumbasteln an den Symptomen…
Ich lese immer nur das Schlagwort von Flächendatentyp. Anscheinend weiß ab er keiner, wie der aussehen soll. Woran soll denn ein Renderer oder Importprogramm mit erkennen, dass ein Kreis der Umriss einer Fläche und nicht eine ringförmige Straße ist?
Der Mapper erkennt es daran, dass er ein Polygon aufzieht, statt eine Spur zu zeichnen. Was er zeichen will, wählt er vorher aus. So wie z.B. in Qgis oder sonst in einem Malprogramm.
Der Importeur und der Renderer erkennen es so wie der Renderer es jetzt auch erkennen muss: Am Datentyp des Weges (Postgis nennt das z.B. Linestring, Multilinestring, Polygon, Multipolygon…)
Aber das ist doch nur das Werkzeug und damit eine Frage des Editors, deswegen ist das Ergebnis aber kein besonderer Flächendatentyp, wie Du ja auch selber schreibst:
Der Unterschied ist der Datentyp “area” in der ersten Zeile. Das Tag ist in diesem Fall egal.
Grüße, Max
PS: Und natürlich müssen wir uns einigen, wie man da Löcher reinmacht, ob Tags sich auf den Umriss mit/ohne Löcher beziehen, ob Löcher sich berühren dürfen, oder den Rand und …
Wir haben für alle Objekte einen Basis-Tag: highway=tertiary, landuse=farmland, amenity=toilets. In der Folge benötigen wir eine Liste mit allen Basis-Tags und deren Zulässigkeit im Datentyp: Landsuse=farmland kann niemals ein Punktoder eine Linie sein. amenity=toilets kann keine Linie sein. highway=tertiary kann nur eine Linie sein. Nur bei Linien muß zusätzlich geprüft werden, ob ein seperater oder vorangestellter area-Tag (area=yes; area:*) vorhanden ist, dann wird das zur Fläche.
Man kommt aber nicht umhin, auf kompaktibilitätsgründen bisberiges zu übernehmen: MP-Konstukrukte, deren Inner und/ oder Outer aus mehr als einem Liniensegment gebildet werden.
MP-Relationen, die aus einzelnen geschlossen LineStrings bestehen, können in normale Polygone umbewandelt werden.
und genau dieses “Konstrukt” stellt das große OSM-Alleinstellungsmerkmal dar - so (bescheuert) macht das kein anderes GIS-System.
Nicht einigen sondern den OGC-Standard knallhart übernehmen. Wird wohl ein ähnlicher Akt werden wie die Lizenzgeschichte aber da müssen wird endlich durch.
Im Wiki haben wir ja auch allerhand Definitionen, aber entweder kennt man die nicht, oder ignoriert sie oder interpretiert sie völlig anders als der Nachbarmapper. Wenn das genügend Leute tun, passen sich sogar irgendwann die Auswerter an, vielleicht auch später das Wiki.
Mit Definitionen und deren Durchsetzung tun wir uns schwer, dafür können wir fröhlicher experimentieren. Auch das ist ein OSM-Alleinstellungsmerkmal
Es stimmt, dass ich das erst jetzt gelesen habe. Wie kann jemand nur auf den hirnrissigen Gedanken kommen, einen seit Jahrhunderten feststehenden Fachausdruck so zu verdrehen?
Wenn ich in irgendwelchen Beiträgen das Wort “Polygon” benutzt habe, dann meinte ich damit nicht “OGC-Polygone”. Ich habe das Wort so benutzt, wie es beispielsweise in Wikipedia steht.
Ich sehe keinerlei Vorteil darin, dass es vom verwendeten Werkzeug abhängen soll, ob dort nun für den mapper unsichtbar “area” oder “way” steht, eher das Gegenteil. Die Festlegung, ob ein geschlossener Linienzug nun als Fläche oder Linie zu interpretieren ist, ist ja jetzt schon möglich, indem man aerea=yes/no angibt. Oder, damit man es bei bei jedem in Frage kommenden Objekt explizit angeben muss, für bestimmte Objekttypen einen dieser Werte als default festlegt, z.B. landuse als “area” und highways als “way”. Als Raterei würde ich das Vorgehen nach diesen Reglen nicht bezeichnen. Ein Werkzeug, wie Du es ins Spiel gebracht hast, kann dabei durchaus auch eine Erleichterung für die Vorbelegung sein, die der Mapper bei Bedarf aber überschreiben können muss.
Dass die Festlegung, was eine Fläche ist, vor dem speichern in die Datenbank erfolgt und diese dann als “area” abgelegt wird, hat sicher Vorteile gegenüber der wiederholten Auswertung bei jedem Rendervorgang. Aber zu eigentlichen Frage dieses Fadens, welches nun gültige Geometrien für Flächen sind, trägt ein Flächendatentyp nichts bei.
Wir haben im Moment die drei Datentypen “Node”, “Way” und “Relation”. Sie werden daran erkannt, dass diese Eigenschaft am Datensatz unveränderlich dransteht. Genauso wäre es, wenn wir “Node”, “Way”, “Area” und “Relation” hätten. Die bisher als “Way” und “Relation” dargestellten Flächen müssten konvertiert werden. “Area” würde immer eine Fläche bezeichnen und alle Flächen wären "Area"s.
Ich würde anstatt von area lieber gleich saubere Begriffe verwenden: Polygon. Der Begriff “area” sollte als Feldangabe für die Flächengröße reserviert werden.
Ich dachte, ich hätte das schon deutlich gemacht. Aber OK:
Nein. Die Polygondefinition in OGC hat mich völlig überrascht. Ich hätte nie gedacht, das Leute vom Fach einen etablierten Fachausdruck einfach umdefinieren. Das “Auch woanders” war in dieser Allgemeinheit falsch.
Ich bleibe allerdings dabei, dass der Rand von OSM-darstellbaren Flächen aus ein oder mehreren Vielecken besteht. Flächen mit mindestens einem Loch oder Flächen aus mindestens zwei räumlich getrennten Teilen haben einen Rand aus mehreren Vielecken. Zu deren Darstellung braucht man in OSM derzeit eine Relation mit type=multipolygon. Diese Bezeichnung “multipolygon” finde ich sehr vernünftig, da man das Ding braucht, wenn mehrere(=Multi) Vielecke(=Polygone, bei mir jedenfalls) vorkommen. Daher finde ich es auch logisch, die Tags einer durch mehrere Vielecke begrenzten Fläche an diese MP-Relation zu schreiben.
