BKG-Mapathon: allgemeinbildende Schulen

Ich hab damals mit eine Mapping Aktion “Luftbilder in Oberpfalz” die ersten Schritte in OSM gemacht :slight_smile:

Aktuell gäbe es wieder was vergleichbares…

https://forum.openstreetmap.org/viewtopic.php?pid=827330#p827330

Zum Einstieg in das Thema, leichtere Kost :slight_smile: grade mit JOSM… wenn noch alles neu ist.

Gruß Miche

Sollte es aber nicht.
Schule ist Schule. Tanzschulen sind amenity=dancing_school (leider nicht dokumentiert), Fahrschule amenity=driving_school und Musikschulen music_school… (jeweils etwa 4-stellig genutzt). Sollte jemand eine Fahrschule o.ä. als amenity=school kennzeichnen, wäre das nicht nach aktuellem Schema…

Genau - ich arbeite noch an einer Anleitung, die Tagging-Beispiele enthält.
Bei den Neben- / Zweigstandorten geht es uns darum, dass diese oft gänzlich fehlen. Daher möchten wir sie als Schulstandorte und über den operator-Key den Träger ergänzen. Gibt es einen tag, der auf einen Nebenstandort hinweist?

Den isced:level möchten wir erfassen und würden, falls aus den Quellen ersichtlich, den amenity=school tag bei unpassender Verwendung laut Liste unter https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool (Abgrenzung zu weiteren Bildungseinrichtungen) ändern.

Naja sollte … amenity=school-Beispiele in Berlin, keines davon schein mir eine allgemeinbildende Schule, um die es hier ja geht
https://www.openstreetmap.org/way/105785522
https://www.openstreetmap.org/node/2483543323
https://www.openstreetmap.org/way/97062895
https://www.openstreetmap.org/way/28256173
https://www.openstreetmap.org/node/2936806732
[…]

Häufig ist es so, dass die genauen Umstände aus dem name-Tag erraten werden müssen. 2019 war hier schon jemand vorstellig, der den name-Tag nutzen wollte um automatisiert isced:level-Tags zu generieren.
https://forum.openstreetmap.org/viewtopic.php?id=67146
Die Sache ist dann eingeschlafen - das Problem besteht weiterhin, insofern kann ich jemanden der ernsthaft die OSM-Situation bei allgemeinbildenden Schulen verbessern will nur raten, den isced:level-Tag zu nutzen.

[Übrigens sehe ich beim Editieren in der Vorschau einen neuen Beitrag von jeis_BKG - der aber in der normalen Ansicht nicht sichtbar ist]

muss wohl erst vom Moderator freigeschaltet werden.

Gute, zentrale Frage…
Die (geometrisch) perfekte Lösung in OSM sind dabei Relationen,
so kann man mit einer Relation type=site Standorte miteinander verbinden.
Das Thema OSM-Relationen ist aber nicht untrivial, da muss man aufpassen nicht ungewollt Daten-Dopplungen zu produzieren.

In der Erfassung einfacher ist eine lose Verbindung “irgendwie” auf Tagging-Ebene - dann habe ich aber kein OSM-Gesamtobjekt.
Einen “Zweigstellen-Tag” kenne ich offen gestanden nicht.

Kennt Jemand eine vorbildliche, vorhandene Lösung/Beispiel für externe Schul-Standorte ???

Puh, das ist kmplex. Es gibt ja nicht nur Schulen mit zwei oder drei Standorten, sondern auch gemeinsam von mehreren Schulen genutzte Gelände. Ich hab eben versucht, ein paar isced-levels zu verteilen …

Grundschule XY (yeah, das ist einfach)
Gymnasium AB und Stadtteilschule CD (gemeinsames Gelände)
Gymnasium AB (nur Oberstufe) und Stadtteilschule CD (Klasse 5-10) (gemeinsames Gelände)
Grundschule EF, Standort GH-Straße (es gibt an anderem Ort nen zweiten Standort)
usw.

Manche haben Relationen, bei manchen kann man die Verbindung nur aus dem Name-Tag schließen. Klar waren mir nur die Fälle, wo eine Schule = ein Standort. Das ist aber bei uns inzwischen recht selten.

Das Thema hatten wir vor einem Jahr hier: verteiltes Schulgelände/ Schule mit mehreren Standorten. Allerdings ohne eindeutiges Ergebnis.

Das sind alles keine amenity=school - sondern Nr 1 bis 3 amenity=college - Wenn überhaupt… ; Nr 4 ja ähm… - Nr. 5 für Nachhilfe gäbe es z.B. office=education (leider nicht dokumentiert)

Aber ich stimme auch zu, für den Bildungsweg wäre ein System über das isced mit Abzubilden ist auch sehr sinnvoll. (Auch wenn ich das zu kurz finde - da der Schultypus nicht direkt abgeleitet werden kann, aber dafür sind wir auch in D mit 16 Bildungssystemen zu unterschiedlich)

Da würde es wirklich sinn ergeben, auf eine Site-Relation aufzubauen.
Also eine Relation mit den Eigenschaften:

type=site
amenity=school
{Infos der Schule}

Und dann an Subobjekten keine Doppelungen. Also, was in der Relation erfasst ist, wird nicht noch mal in Unterelementen erfasst.

Hier gibt es u.a. ein Proposal, dass durch mich erstellt ist und eigentlich noch diese Woche ins Voting gehen sollte. (Folge dem Link ins Wiki)
Effektiv ergibt sich aus diesem Proposal:
Eine Schule an einem Standort: → Fläche oder Node mit amenity=school (ggf. landuse=educational)
Mehrere Schulen an einem Standort: → Fläche mit landuse=educational & Node miz den amenity=school
Eine Schule an mehreren Standorten → Site-Relation (unverändert)

Ist halt nicht alles so easy abbildbar - aber das ist halt nunmal die Realität :confused:

Danke für Deine Idee! Ich verstehe die site-Relation so, dass mehrere Gebäude auf einem Grundstück einer Einrichtung zugeordnet werden, z.B. hier:
https://www.openstreetmap.org/relation/9301908
Hast Du ein Beispiel für eine Schule mit mehreren Standorten?

Für Schulgelände mit unterschiedlichen Schulen habe ich es öfter gesehen, dass die Gelände unterteilt wurden und dann den Schulen zugeordnet wurden (auch wenn die so nicht unbedingt abgrenzbar sind), z.B. hier: https://www.openstreetmap.org/way/195106954

Den Ansatz mit landuse=educational finde ich sinnvoll. Wo setze ich jedoch die nodes (amenity=school), wenn mehrere Gebäude zu einer Schule gehören? Zentral?

Ja, und das ist ein super Beispiel, das zeigt, wie man site-Relationen nicht verwenden sollte. Denn dass diese Objekte zu der Schule gehören, erlange ich ja schon dadurch, dass sie auf der Fläche liegen.
Site-Relationen sind hat um weiter getrennte Flächen/Objekte miteinander zu kombinieren. Im Bereich Schulen z.B.: https://www.openstreetmap.org/relation/7733783 (wobei ich in Zukunft, sollte das landuse=education - Achtung, hier hatte ich einen Schreibfehler! - angenommen werden, auch auf das amenity=school an den Schulgeländen verzichten würde - da es ja nur eine “Schule” gibt…)

Muss man gucken. Ich würde die zentral im Bereich positionieren, der hauptsächlich von der jeweiligen Schule genutzt wird (wie bei nodes allgemein).

Mmh, das scheint mir eher eine Nonsens-Relation

Schau dir mal diese site-Relation an:
https://www.openstreetmap.org/relation/11376169
Die 3 (hier weit) verteilten Standorte der PTB werden per site-Relation zusammengefasst, wobei die einzelnen Standorte ihr individuelles Eigentagging haben, sprich amenity=research_institute ist den Standorten zugeordnet (genau genommen nur bei 2 von 3 weil eines nur ein einzelnes Gebäude ist)


Nachtrag zum Beispiel von SafetyIng
https://www.openstreetmap.org/relation/7733783
Ja, das ist eine vernünftige Nutzung einer site-Relation (allerdings ist der amenity-Tag in der Relation gedoppelt)

Ne, gerade nicht. Da gehört amenity=school an die Relation, nicht an die einzelnen Standorte. Denn amenity=school ist die Schule an sich.

Jein - ich ahnte, dass dies noch Thema wird;-) daher ausführlich

Hier eine Relation type=boundary[!] ein Naturschutzgebiet aus 8 getrennten Teilflächen
https://www.openstreetmap.org/relation/12032594
Alle Tags sind der Relation zugeordnet - die menber sind quasie eigenschaftslos (nur note oder description-Tags)
Das ganze funktioniert prima, die member (Areas) erben (beim Rendern) die Eigenschaften der Relation.

Sicher dass dies auch bei site-Relationen (bei möglichst vielen Auswertern) zuverlässig funktioniert?
OSM-Suche nach “Fritz-Schumacher-Schule Hamburg” findet die site-Relation nichteinmal:
https://www.openstreetmap.org/search?query=Fritz-Schumacher-Schule%20Hamburg#map=15/53.6562/10.0235

Finde ich aber nicht schlimm, man muss sich halt auf den Standpunkt stellen, dass die Gewichtung bei site-Relationen umgekehrt der o.a. boundary-Relation ist.

  • starke member, die die Tagging-Hauptlast tragen
  • schwache site-Relation als Klammerung mit minimal-Tagging
    Und insofern würde ich an der site-Relation statt
    amenity=school
    besser ein
    description=Die Fritz-Schumacher-Schule ist auf 4 Standorte verteilt.
    setzen.

Naja, dann ist das aber der DataConsumer schuld. Hat aber nominatim mit mehreren Objekten auf Relationsbasis… (siehe z.B. stop-areas oder ähnliches) Also sollten wir da eher ansetzen und Nominatim verbessern. Gehe ich gerne mit.
amenity=school sagt hier ist eine Schule. Und eine Schule mit 4 getrennten Standorten ist immernoch eine Schule ↔ nicht 4 Schulen. Somit gehören allgemeine Daten an die Relation.

Naja, wie dein Hamburger Beispiel zeigt unterscheiden sich diese Standorte ja auch ganz erheblich
(wäre das Gelände von Grundschule x durch die Bundesstraße y getrennt, dann mag eine simple Relation type=multipolygon mit Tagging nur an der Relation die bessere Wahl sein).
Ich denke, dass jeis_BKG mit derartigen Grundsatzüberlegungen wg. Zeitfenster nicht weitergeholfen ist - Kurzum:

Halte site-Relationen bei verteilten Schulstandorten für einen korrekten und praxistauglichen Ansatz,
die einzelnen Standorte müssen dann aber halt auch als Schulen getaggt sein, sonst wird das AFAIK nix.

Unterliegt der Schul-Datensatz auch solchen Einschränkungen? Falls ja, werden dann die im Mapathon vorgenommenen Ergänzunen mit der OSM-Teilnehmervereinbarung zu vereinbaren sein?

Es ist natürlich erlaubt, OSM-Daten mit anderen geschützten Daten zu vergleichen und die dabei festgestellten Differenzen zu analysieren. Die Mitarbeiter können wohl in dem seltesten Fällen direkt vor Ort nachschauen bzw. haben eigene aktuelle Ortskenntnisse. Wie sollen dann wirklich freie Informationen gewonnen werden, um diese in OSM einzutragen?

Wir dürfen die Attribute unseres Datensatzes nicht weitergeben. Wir machen jedoch einen räumlichen Vergleich zwischen unserem Schuldatensatz und OSM. Sofern an einem Standort unter OSM keine Schule besteht, recherchieren wir über die Lageparameter die Internetseite der Schule und erfassen daraus die Schul-Tags. Die entsprechende Quelle wird natürlich beim Upload genannt.

Ich finde die Aktion gut. Da wird man an Dinge erinnert, die man schon längst mal machen wollte und immer vergessen hat…

CS https://www.openstreetmap.org/changeset/104963124 erinnerte mich daran, nun endlich mal das gesamte Schulgelände zu separieren: https://www.openstreetmap.org/changeset/104967895 Eine Aufgabe für mich hab ich noch: Das Gebäude https://www.openstreetmap.org/way/387434770 gehörte früher auch zur Schule am Neuhaus… ob noch?, ich muß mal hinfahren.

Sven

Hallo zusammen,

vor gut einem Jahr habe ich an dieser Stelle auf einen ersten Mapathon zum Thema “Allgemeinbildende Schulen in Deutschland” hingewiesen, den wir im Bundesamt für Kartographie und Geodäsie (BKG) durchgeführt haben. Inzwischen habe ich zwei Präsentationen von den vergangenen FOSSGIS-Konferenzen mit einigen Ergebnis-Folien ins OSM-Wiki gestellt. Ihr findet sie über unsere Seite dort (https://wiki.openstreetmap.org/wiki/DE:Bundesamt_f%C3%BCr_Kartographie_und_Geod%C3%A4sie).
Im letzten Jahr gab es eine sehr produktive Zusammenarbeit mit den OSM-Mappern. Ihr habt vor allem auf die Notes reagiert, die wir an Objekte setzten, zu denen wir über eine Internetrecherche kaum Informationen finden konnten.
In diesem Jahr werden wir am 23./24. Mai bei einem zweiten BKG-Mapathon an dem Thema “Allgemeinbildende Schulen” weiterarbeiten. Und ich würde mich freuen, wenn Ihr wieder die Notes und Änderungssätze mit dem #BKG im Blick behalten könntet.

Vielen Dank und Grüße,
Joachim