Auf solche Argumente steh ich ja - das haben wir noch nie so gemacht, das machen wir auch künftig nicht. Ich werd auch nicht damit anfangen, ich mappe auch weiter so, wie ich erkenne das andere das auch machen. Nicht aus einem Mangel aus Induvidualität, sondern einfach um bei den Fluss in diesem schönen Projekt nicht zu stören sondern die Entwicklung voranzubringen.
Fakt ist aber, bei OSM ist die Qualität der Geodaten nach normalen Kriterien ziemlicher Schrott, ohne das hier weiter auszuführen. Sowohl Punkte als auch die “Polygone” sollten vollständig sein. Wir kommen natürlich auch mit solchen “mal so, mal so” Layern klar, und überhaupt ist die OSM trotz der mangelnden Qualität von unbestreitbar hohem praktischen Nutzen.
So eingefahren wie die Entwicklung ist wird ist es auch schwer da noch irgendwas dran zu drehen, allein ein kleiner Lizenzwechsel macht schon einen riesigen Bohei, da sollte lieber alles so weiter laufen, auch wenn das nicht optimal ist. Letztlich gibts da ja auch verschiedene Vorstellungen, was zu verbessern wäre.
Nein, das ist ein eindeutiges Negativbeispiel. Selbst wenn man die Relation ignoriert, gibt’s da nämlich zwei Schulen - eine als Node und eine ohne weitere Tags als Fläche. Dass das nicht gemacht werden soll, ist doch eigentlich klar?
Man muss also für Kritik an deinem Beispiel nicht mal die Relation heranziehen (wo die Situation wirklich noch nicht ausdiskutiert ist).
Durch Straße geteilt ist nicht mehr "größtmöglich zusammenhängend2, wie ich schrieb. Beide Flächen bekämen bei mir dann unabhängig voneinander amenity=school. Was soll das MP da bringen?
Da reicht doch an jedem Gebäude building=school. Das Problem wäre nur für name=* relevant, damit nicht an jedem Schulgebäude der Name separat klebt.
Klasse, wir machen es uns einfach und die Auswertung hat das Problem
Dann hast du zwei Schulen eingetragen. Ob das sinnvoll ist oder der Realität entspricht?
So eine ganz andere Idee…evtl. sollte man mal ein inverses planet-file anbieten. Das mit Relationen beginnt, dann die ways und am Schluss erst die Nodes. Für so Auswertungen wäre das durchaus sinnvoll.
Die logische Interpretation einer dummen Maschine ist aber: Hier sind 2 Schulen. amenity=school sagt nämlich genau dies aus. Daher sollte es auch an ein Konstrukt getagt werden, dass die gesamte Schule abbildet.
Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.
Da liegst du leider leicht daneben: “ein” Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern … der Fall, wenn sie in mehreren Teilflächen erfasst werden.
Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefsst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).
Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!
Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefsst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).
Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!
Dort wird einfach eine zusätzliche Datenbank verwendet die für POIs Relationen, Wege und Punkte auswertet und nur als Punkt wieder zur Verfügung stellt. Wenn eine solche Datenbank zentral zur Verfügung steht könnten Auswerter einfach auf die POIs zurückgreifen. Die Daten selber würden aber weiterhin als Relationen, Wege und Punkte in der eigentlichen OSM-Datenbank zur Verfügung stehen.
Ansonsten führt jeder Auswerter diesen Ansatz mehr oder weniger bei sich selber durch. Sei es in einer Datenbank oder nur in einer Liste.
Das ganze funktioniert dann genau wie mit den Karten-Server. Ein Auswerter kann entweder auf die Daten zurückgreifen, bei speziellen Wünschen aber auch die Daten selbständig aufbereiten.
Mittlerweile sind wir leider vollkommen OT und wieder in einer dieser MP-Diskussionen.
Zusätzlich wird das ganze auch noch durch unterschiedliche Interpretation von Begriffen befeuert. Für mich ist der Harz (oder Schwarzwald usw.) kein Wald im Sinne der Erfassung in OSM mit landuse=forest, weshalnb das Beispiel für mich hinkt.
Zum zweiten Absatz “Einheitliches tagging…” stimme ich dir voll zu.
Leider erinnere ich mich an keinen thread hier, der bei solchen Diskussionen nicht irgendwann ergebnislos im Sande verlief.
Wie sieht eigentlich das optimale Tagging für Flächen POIs aus ? Am Beispiel einer Schule ?
Wo sollten die Adress Tags hin ? Gibt es da ne Wiki Seite mit Hinweisen ?
Beim Analysieren konnte ich wenig einheitliches finden.
Tags an der Fläche, Tags an einem Gebäude, Tags an mehreren Gebäuden, Tags am Eingang eines Gebäudes, Tags an einem Node, und auch viele wo die Tags gleich an der Fläche, am Gebäude, und an einem Node 3-fach vorhanden sind.
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool
ich lese hier s:
Alle Infos, Namen, Adresse usw an die amenity=school die das kompl. gebiet abgrenzt.
Innerhalb der Fläche dann einzelne gebäude nur mit bulding=yes/school, leisure=pitch usw.
In Cottbus sind keine Adressen an der Fläche, sondern am Gebäude
Sehr nett für Auswerter, denn die müssen, um an die Adressen zu kommen, noch räumliche Abragen machen:
Ist auf dem Gelände mit amenity=school evt. ein Gebäude mit der Adresse ? oder noch ein Node ? oder beides ? oder mehrere Gebäude mit mehreren Adressen ? Kann ich am Tagging sehen dass die Adresse auch tatsächlich die Adresse der Schule ist ?
Schön wird es dann zu entscheiden, welche Adresse denn die richtige für die Schule ist, im Falle wenn da noch das Hausmeisterhaus auf dem Gelände ist oder mehrere Gebäude mit unterschiedlichen Adressen sind.
bei komplexeren/größeren Anlagen sind die (unterschiedlichen) Adressen am Gebäude sicherlich sinnvoll.
Auch wenn sich die Bezeichnung der Gebäude unterscheidet sind names angebracht zB “Bau 3”, aber eben nicht “Schule xy” als name an 5 benachbarte Gebäude pappen.
irgendwas doppelt einzutragen versuch ich zu vermeiden. Entweder, oder.
Ergänz ich die area, kommt der node in den Müll.
Ab wann ist eine Anlage komplex ? Wie soll getagged werden dass man bei größeren Anlagen, wo die Adresse nicht am Gelände ist sondern an einem Gebäude, so dass man erkennen kann dass das auch die ofizielle Adresse der Schule ist ? Wo ist das beschrieben ?
Ein Anfänger und ein Auswerter hält sich erst mal an das Wiki:
Setze einen Punkt oder zeichne die Fläche des Schulgeländes (die Schulgebäude können innerhalb dieser als Flächen mit building=school gezeichnet werden)
Dort steht ja nicht mal wohin die Tags gehören … im Grunde steht da nur was von dem Schulgelände. Jeder macht dann daraus mehr oder weniger was er will. Und so sieht dann auch das Tagging in der Realtiät aus. Jeder setzt die Tags hin wo er will.
Ganz zu schweigen von der unnötigen Zeit und Rechenpower die man braucht um räumliche Abfragen machen zu müssen um an die Adresse einer Schule zu kommen.
