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.
Ich möchte nochmal gerne nachhaken, da ich das gerne in meiner App konkret als Leitfaden angeben möchte:
Wohin sollen bei Flächen POIs die Tags besonders die Adress Tags ?
Ich kann leider kein einheitliches System feststellen momentan in den OSM Daten.
Problem bei den Tags an der Fläche: das ist bei großen Flächen recht ungenau, außerdem können ja durchaus mehrere Gebäude mit einer Adresse auf dem Schulgelände sein.
Bei den Tags an den Gebäuden wäre dann eine erst eine aufwändige Auswertung notwendig und es es müsste dann eine Richtline geben, wie zu taggen ist, um herauszufinden, dass die Adresse eines Gebäudes auch die Adresse der Schule ist.
Genau diese Relation ist überflüssig, da die Fläche als amenity=school getaggt ist. So stehts übrigens auch im Proposal der site. Wenn site, muß das amenity an der Fläche weg.
In der Theorie In der Praxis wird man wohl eher gelyncht wenn man das korrigieren würde und die tags von der Fläche entfernen würde, weil site eben nicht mal offiziell ist und wohl in keiner Anwendung bisher ausgewertet wird und somit auch nicht von mapnik in der Karte angezeigt wird.
Und auch wenn ich mich da schon wieder mal wiederhole: Wir brauchen einfache verständliche Regeln, die auch gut irgendwo dokumentiert sind. Das hilft Mappern und Auswertern, die sich daran halten können. Und dabei sind die POIs doch eigentlich noch was einfaches, wenn man sich die Diskussionen über Spurmapping oder ÖPNV ansieht.
Für Regeln bin ich von Anfang an und deswegen auchschon angeeckt.
Daß die Tags an der Fläche bei Anwenden der site unnötig sind, dürfte wohl klar sein. Ich hatte aber auch eindeutig geschrieben, daß die site in diesem einfachen Fall total überflüssig ist. BTW, JOSM bietet sogar eine Vorlage dafür und wir mappen nicht für Renderer, oder doch?
Ergo. Die site weg, Tags , die das ganze Gelände betreffen, an die Fläche, den POI weg.
Dreimal amenity=school ist Quark. Wie wärs denn, die Gebäude ebenfalls damit zu taggen. Findet/fand man auch.
Dann weg damit. Das area=yes ist IMHO ebenfalls überflüssig.
Zusatzfrage an Dich (etwas off topic): Kennst Du den Wendelinus-Radweg? Sieht in Bing größtenteils aus, als wäre es eine ehemalige Bahnstrecke IMHO auch nicht richtig getaggt, vom gleichen Mapper wie die Schulen.
Habe ihn angeschrieben:
der Radweg http://www.openstreetmap.org/browse/relation/180492 ist größtenteils mit ‘highway=service’ getaggt. Wenn dies ein reiner Rad-/Fußweg ist, ist dies nicht geeignet, IMHO sogar falsch. Besser wäre highway=cycleway + surface + foot=yes. Dann braucht es kein access=no, kein horse=no, bicyle=yes wäre dann auch unnötig. Das teilweise vorhandene tracktype ist eh verkehrt.
*Stehen da blaue Schilder für Rad-/Fußweg, dann müßte bicycle/foot=designated hin. *
Schießt du beim Wendelinus-Radweg nicht ein bischen über Ziel hinaus?
Nur weil das ein Radweg im Namen trägt und auf einer ehmaligen Bahnstrecke ist gleich auf einen Radweg zu schließen?
Die meisten Namens-Radwege führen auf Nichtradwegen (also ohne die Blauen Schilder) - die meisten haben das Schild mit Roten Kreis + Anlieger bzw. Fort u. Landwirtschaft frei …
Sowas kannst du nur vor Ort überprüfen und für Gemeinden ist es viel einfacher ein paar Hinweisschilder aufzustellen als öffiziell einen Radweg durchzubringen.
Kennst Du den Radweg?
Wenn nein, frage ich mich, was das rumgemeckere soll? Schließlich habe ich keine Tatsachen geschaffen.
Egal, wie es ist, highway=service dürfte fraglich sein.
Das ist kein Rumgemeckere sondern eine Feststellung!
Wie die highway Tags gesetzt sind gibts nichts zu meckern und auch service ist passend gesetzt.
Die Relation ist eine Route und nicht ein cycleway-Relation, das ist in den Ways richtig getaggt!
Einzig das er an die ganzen cycleway noch den namen drangepappt hat ist überflüssig - der reicht einmal in der Route-Relation, an den Ways braucht der nicht nochmal zu hängen!
Man sollte alle Ways anschauen und nicht nur die ersten 2 und sagen da fehlt cycleway !!!
DIe Änderung in cycleway ist am 30.04. erfolgt, Stunden nachdem ich den Mapper angeschrieben habe. Ergo haben etwas aneinander vorbei gewettert. Daß er so schnell reagiert, hatte ich nicht erwartet.
Jemand wollte bei meiner kleinen Themenkarte auch die Relationen im Bereich education angezeigt bekommen. Da er keine Email hinterlassen hat, evt. liest er ja hier mit. Jetzt werden auch die Realtionen angezeigt.
Das sehe ich inzwischen (*) auch so. wenn alle Objekte in einem räumlichen Kontex stehen - also alle innerhalb einer Area sind, bringt eine site-Relation fast nix.
Einerseits hat es der Renderer etwas einfacher, da er nicht suchen muss, andererseits müssen ALLE Mapper aufpassen, da nichts falsch zu machen.
Und da sind mir die Mapper näher
Sites sind z.B. prima für Bushaltestellen, da die alle irgendwie zusammen gehören aber doch über eine undefinierte Fläche verstreut sind.
Gruss
walter
*) „Man kann immer seinen Standpunkt ändern, weil dir niemand verbieten kann, klüger zu werden.“
oder etwas direkter: „Was interessiert mich mein Geschwätz von gestern.“
Konrad Adenauer
Das ganze Gelände ist als Schule markiert und mit Schulzentrum beschriftet.
Da drauf steht ein großes Schulgebäude in dem drei Schultypen (als Node) untergebracht sind.
Also gibt es jetzt viermal amenity=school.
Man könnte dies bei der Fläche weglassen, aber dann fällt die als Information weg, was auch blöd ist.
(Ich weiß, Adressen könnte man an die Fläche verschieben, aber darum geht es mir gerade nicht)
Noch zwei allgemeine Anmerkungen von mir als Anfänger:
Für so ein Konstrukt würde ich keine Relation angeben, da ja alles innerhalb der Fläche liegt.
Bei Straßen schreibt man ja auch nicht dazu in welcher Stadt die liegen.
Es mag ein Vorteil von OSM sein, dass es flexibel ist und jeder machen kann was er will,
aber als Einsteiger wünscht man sich doch klare Regeln damit man sicher sein kann,
dass die eigenen Daten auch genutzt werden.
Ausnahmefälle kommen dann früher oder später sowieso dazu.
Für das Zusammenfassen von Haltestellen gibt es eine eigene Relation.
Nach Public_Transport#Stop_area sind type=public_transport plus public_transport=stop_area für die Relation zu verwenden.