Hallo OWL-Mappers, ich habe mich in den letzten Tagen (dienstlich) mit dem Konverter "Imposm" beschäftigt. Für die Kommunalverwaltung soll Imposm das Laden der PostGIS-DB aus den Shapefiles der Geofabrik ersetzen. Aus der PostGIS-DB wird dann die Karte als WMS präsentiert und nicht als gekachelt vorgerenderte Karte. Dabei stört ein Fehler, der systematisch auftritt. Auch ich selbst bin in diese Falle getappt. So kam's: In der Anfangszeit von OSM wurden die Standorte von Schulen, Kirchen und ähnlichen Einrichtungen erst mal grob als Punkt markiert und mit "amenity=school" bzw. "amenity=place_of_warship" getaggt. Bei der Verfeinerung der Karte durch das Mappen aus dem Luftbild sind dann später die Gebäudeumrisse dazu gekommen. Dabei wurden wahrscheinlich oft die alten Punkt-Tags auf das Gebäude übertragen. So entstanden Kombinationen wie "building=yes, amenity=school, name=...", die am Gebäudeumriss hängen. Einträge wie "amenity=school" werden nun aber ähnlich wie landuse-Tags konvertiert und dargestellt. Ich habe im Wiki geschaut und bin zu dem Schluss gekommen, das folgendes Tagging eigentlich korrekt wäre: Gebäude-Umriss: "building=school" (statt yes). Schul-Gelände (Grundstück): "amenity=school, name=... ". Analog bei Kirchen: Gebäude "building=church" (statt yes), Gelände/Grundstück: "amenity=place_of_warship". Die umgebende Nutzung "landuse=residential" sollte ausgespart werden, also nicht mit "amenity" überlappen. Dies gelingt einfacher, wenn man die residential-Fläche jeweils nur für einen Häuserblock bildet und nicht gleich für die ganze Stadt, denn dann müsste man mit Relationen Löcher raus schneiden. Kurz gesagt: Das anenity-Tag gehört nicht an den Gebäude-Umriss sondern kennzeichnet das Grundstück (Schulgelände/Kirchengelände). Vielleicht könntet ihr mal in euren Jagdgründen nachsehen ... Belege: http://wiki.openstreetmap.org/wiki/DE:Key:amenity "Wird ein aus mehreren Gebäuden und Plätzen bestehendes Areal mit einem Attribut amenity z.B. als öffentliche Einrichtung markiert, ..." http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dschool#Verwendung_des_Ta... "Setze einen Punkt Node oder zeichne die Fläche Area des Schulgeländes (die Schulgebäude können innerhalb dieser als Flächen mit building=school gezeichnet werden)" -- Frank
On Mon, Aug 05, 2013 at 06:37:51PM +0200, Frank wrote:
So entstanden Kombinationen wie "building=yes, amenity=school, name=...", die am Gebäudeumriss hängen.
Einträge wie "amenity=school" werden nun aber ähnlich wie landuse-Tags konvertiert und dargestellt. Ich habe im Wiki geschaut und bin zu dem Schluss gekommen, das folgendes Tagging eigentlich korrekt wäre:
Gebäude-Umriss: "building=school" (statt yes). Schul-Gelände (Grundstück): "amenity=school, name=... ".
Analog bei Kirchen: Gebäude "building=church" (statt yes), Gelände/Grundstück: "amenity=place_of_warship".
Die umgebende Nutzung "landuse=residential" sollte ausgespart werden, also nicht mit "amenity" überlappen. Dies gelingt einfacher, wenn man die residential-Fläche jeweils nur für einen Häuserblock bildet und nicht gleich für die ganze Stadt, denn dann müsste man mit Relationen Löcher raus schneiden.
Das sehe ich anders - ein Schulgelände gehört zur Wohnbebauung d.h. ein landuse=residential wird "aufgewertet" durch eine fläche amenity=school.
Kurz gesagt: Das anenity-Tag gehört nicht an den Gebäude-Umriss sondern kennzeichnet das Grundstück (Schulgelände/Kirchengelände).
Richtig - habe ich in GT und RhWd schonmal umgebaut weil mir das in MapOSMatic aufgefallen ist. Oftmals waren auf allen Gebaeudeteilen der Schule ein "amenity=school" was dazu führte das das im Index bei MapOSMatic korrekterweise 7-droelf mal aufgeführt wurde. Ist im ueberigen schwierig bei Schulzentren die aus mehreren Schulen bestehen. Da bin ich mir nicht sicher wie ich es mache. Entweder die amenity=school Fläche mehrfach übereinander, oder die Fläche zerschneiden - Im Prinzip ist letztes ja moeglich. In meinem fall sind die Gebäude den Schulen zugeordnet. http://osm.org/go/0GPtVqS8M- Hier habe ich es jetzt so das die Fläche das Einstein ist - und die Johannisschule als Node. Flo -- Florian Lohoff f@zz.de
Am 05.08.2013 18:57, schrieb Florian Lohoff: ..
Oftmals waren auf allen Gebaeudeteilen der Schule ein "amenity=school" was dazu führte das das im Index bei MapOSMatic korrekterweise 7-droelf mal aufgeführt wurde. ...
Flo
Hmmm, das war eigentlich auch mein Vorschlag, Schulgebäude nicht einfach mit "yes" sondern mit "builing=school" zu taggen. In meinem WMS lasse ich z.B. solche Gebäude in einer etwas anderen Farbe darstellen. Wenn der Name der Schule nur einmal am amenity hängt, also am Gesamtkomplex, kommt dann trotzdem X-mal die unknown-Schule (building) in dem MapOSMatic-Index? -- Frank
On Mon, Aug 05, 2013 at 07:11:51PM +0200, Frank wrote:
Am 05.08.2013 18:57, schrieb Florian Lohoff: ..
Oftmals waren auf allen Gebaeudeteilen der Schule ein "amenity=school" was dazu führte das das im Index bei MapOSMatic korrekterweise 7-droelf mal aufgeführt wurde. ... Hmmm, das war eigentlich auch mein Vorschlag, Schulgebäude nicht einfach mit "yes" sondern mit "builing=school" zu taggen. In meinem WMS lasse ich z.B. solche Gebäude in einer etwas anderen Farbe darstellen.
building=school - JA amenity=school auf jedem Gebaeude - NEIN
Wenn der Name der Schule nur einmal am amenity hängt, also am Gesamtkomplex, kommt dann trotzdem X-mal die unknown-Schule (building) in dem MapOSMatic-Index?
D.h. die Flaeche mit Gebaeuden, Schulhof, Lehrerparkplatz, Tartanbahn etc ist ein amenity=school + name=name der schule. Das Gebaeude hat ein building=school und entsprechend die addr tags. Was mir auch nicht klar ist wie die zusammenkommen. Darueber schweigen sich die Herren des Wikis auch aus. Ich vermute der Auswerter muss dann entsprechend die Adressen der Gebaeude im Umgebenden Schul-amenity-polygon suchen. Ich sage nicht das ich das ganze Thema gut finde wie es ist. Es ist nur die Praxis und das was z.b. MapOSMatic im Einklang mit dem Wiki auswertet. Flo -- Florian Lohoff f@zz.de
Hallo Frank, als generelle Regel stimme ich dir an der Stelle NICHT zu. Dein erster Themenblock: amenity=school auf Gelände oder Gebäude: a) Wenn die Schule nur ein Gebäude hat und keinen ihr eindeutig zuzuordnenden Schulhof etc., dann tagge ich die Daten der Schule einschließlich des amenity=school auf dem Gebäude. Ein zusätzliches landuse gleicher Größe halte ich dabei für einfach unsinnig, ein zusätzliches Landuse, das zusätzliche Fläche mit einschließt, wäre falsch, wenn diese nicht zur Schule gehört. Gehört der Schulhof zu mehreren Schulen gemeinsam, dann könnte man überlegen, ob sich hier mehrere amenity=school-Polygone überlappen und die Gebäude aussparen - aber das ist z.T. auch schwierig. b) Wenn die Schule ein deutlich abgrenzbares Schulgelände hat, kommt amenity=school ans Gelände und auf die einzelnen Gebäude nur building=school. c) Wenn die Schule mehrere Gebäude aber kein identifizierbares Schulgelände hat, gibt es ein Multipolygon mit amenity=school, das die Gebäude umfasst. Als Regel aufzustellen, wie du das vorhast, dasss amenity=school nicht ans Gebäude gehört, halte ich für fragwürdig, weil eine Schule ohne schuleigenes Gelände, eben auch nur über das Gebäude beschrieben wird. Für korrekt halte ich aber, dass nach Möglichkeit pro Schule auch nur ein amenity=school-Tag vergeben werden sollte - also Entweder an 'nem Schulgelände (das auch ein Multipolygon aus mehreren Gebäuden sein könnte) ODER an einem Gebäude. building=school halte ich übrigens nicht richtig, wenn das Gebäude kein Schulgebäude ist sondern ein als Schule genutztes Gebäude. Ein Schulgebäude hat meines Erachtens schon deutliche Eigenschaften, die sich von einem Wohngebäude, einer Kirche oder einem Turm abgrenzen, und nur weil eine Kapelle zu einer Schule gehört, wird aus building=chapel nicht building=school. Analoges gilt übrigens für Kirchen: Eine entwidmete Kirche kann durchaus buiding=church aber nicht mehr amenity=place_of_worship sein, wenn sie als Restaurant genutzt wird, die Charakteristik des Gebäudes, wie Kirchturm, hohe Fenster etc. qualifizieren das Gebäude dennoch als Kirchgebäude. Aber auch andersrum: nicht jede Kirche bekommt von mir building=church. Eine Kirche in einem Krankenhaus kann eine voll ausgestattete, voll funktionsfähige, geweihte [...] Kirche sein - das Gebäude bleibt trotzdem ein Krankenhaus, vielleicht bleibt das Gebäude sogar ein Kloster. building=church wäre jedenfalls auch hier fehl am Platz. landuse, amenity und building sind IMHO orthogonale Konzepte: landuse ist die vorrangige Nutzung eines Areals. Durch einen Kiosk wird aus landuse=residential nicht landuse=commercial, und durch eine Wohnung über einem Geschäft gehts auch andersrum nicht. Deshalb würde ich trotzdem ablehnen, den Kiosk aus dem residential-landuse auszusparen. Das machen Kommunalverwaltungen und Bebauungspläne übrigens auch nicht anders. amenity ist ein all-you-can-eat-Tag für alles mögliche, im Falle von amenity=place_of_worship und amenity=school kennzeichnet das eben genau das: eine Schule oder eine "Anbetungsstätte", Kirche, Moschee, Synagoge, Tempel oder was auch immer (weiß keine bessere Übersetzung). building=* ist ein Gebäude, wobei der Wert des Tags die Art(!) des Gebäudes beschreibt, nicht in erster Linie die Nutzung. Deshalb ist building=residential nicht mit landuse=residential gleichzusetzen und auch nicht einfach austauschbar. Auch ein als Wohngebäude genutzer Turm bekommt von mir nicht building=residential, sondern building=tower. Ein als solches entworfen und gebautes Hotel kriegt zum amenity=hotel auch noch building=hotel; ein Hotel, das in einem Wohnhaus eingerichtet wird, kriegt von mir letzteres nicht. - Die Tendenz dürfte klar geworden sein. Gruß Peter P.S.: Am 05.08.2013 18:37, schrieb Frank:
Hallo OWL-Mappers,
So kam's: In der Anfangszeit von OSM wurden die Standorte von Schulen, Kirchen und ähnlichen Einrichtungen erst mal grob als Punkt markiert und mit "amenity=school" bzw. "amenity=place_of_warship" getaggt. ähm... place of warship wäre ein Kriegsschauplatz - ich hoffe, das war ein Tippfehler ;) worship wärs für die Kirchen.
On Mon, Aug 05, 2013 at 07:34:24PM +0200, Peter Wendorff wrote:
Hallo Frank,
als generelle Regel stimme ich dir an der Stelle NICHT zu.
Dein erster Themenblock: amenity=school auf Gelände oder Gebäude:
a) Wenn die Schule nur ein Gebäude hat und keinen ihr eindeutig zuzuordnenden Schulhof etc., dann tagge ich die Daten der Schule einschließlich des amenity=school auf dem Gebäude. Ein zusätzliches landuse gleicher Größe halte ich dabei für einfach unsinnig, ein zusätzliches Landuse, das zusätzliche Fläche mit einschließt, wäre falsch, wenn diese nicht zur Schule gehört. Gehört der Schulhof zu mehreren Schulen gemeinsam, dann könnte man überlegen, ob sich hier mehrere amenity=school-Polygone überlappen und die Gebäude aussparen - aber das ist z.T. auch schwierig.
Wieso sollten sie die Gebaeude aussparen?
b) Wenn die Schule ein deutlich abgrenzbares Schulgelände hat, kommt amenity=school ans Gelände und auf die einzelnen Gebäude nur building=school.
c) Wenn die Schule mehrere Gebäude aber kein identifizierbares Schulgelände hat, gibt es ein Multipolygon mit amenity=school, das die Gebäude umfasst.
Als Regel aufzustellen, wie du das vorhast, dasss amenity=school nicht ans Gebäude gehört, halte ich für fragwürdig, weil eine Schule ohne schuleigenes Gelände, eben auch nur über das Gebäude beschrieben wird.
Sowas gibts? Ich kenne keine Schule ohne Lehrerparkplatz und Schulhof. Und DIE gehören eben mit in die Fläche der Schule - Da ist sich das Wiki ganz sicher. Und normalerweise sind gerade Schulgelände _sehr gut_ identifizierbar, ganz im gegensatz zu Industriegebieten.
building=school halte ich übrigens nicht richtig, wenn das Gebäude kein Schulgebäude ist sondern ein als Schule genutztes Gebäude.
Das ganze ist in jedem fall richtig. Ich habe das thema building != yes bisher nur wenig bis gar nicht genutzt (ausnahme garage). Ich habe es durchaus sinnvoll building mit leben zu fuellen - yes ist quasi ueber. Bis man sich dann mal geieinigt hat ob ins building die nutzung, angedachte nutzung, bauform oder was auch immer kommt kann man das ja schonmal miterfassen und später durch haarspalterei aufdröseln. Die betroffenen Gebaeude lassen sich dann aber schnell und automatisiert finden. Und was in das tag building kommt ist hoch umstritten. Flo -- Florian Lohoff f@zz.de
Am 05.08.2013 20:10, schrieb Florian Lohoff:
On Mon, Aug 05, 2013 at 07:34:24PM +0200, Peter Wendorff wrote:
Hallo Frank,
als generelle Regel stimme ich dir an der Stelle NICHT zu.
Dein erster Themenblock: amenity=school auf Gelände oder Gebäude:
a) Wenn die Schule nur ein Gebäude hat und keinen ihr eindeutig zuzuordnenden Schulhof etc., dann tagge ich die Daten der Schule einschließlich des amenity=school auf dem Gebäude. Ein zusätzliches landuse gleicher Größe halte ich dabei für einfach unsinnig, ein zusätzliches Landuse, das zusätzliche Fläche mit einschließt, wäre falsch, wenn diese nicht zur Schule gehört. Gehört der Schulhof zu mehreren Schulen gemeinsam, dann könnte man überlegen, ob sich hier mehrere amenity=school-Polygone überlappen und die Gebäude aussparen - aber das ist z.T. auch schwierig.
Wieso sollten sie die Gebaeude aussparen? Sorry, natürlich nur die Gebäude der anderen Schulen jeweils aussparen. Also: Eine Schule umfasst jeweils den gemeinsamen Schulhof sowie die eigenen Gebäude.
b) Wenn die Schule ein deutlich abgrenzbares Schulgelände hat, kommt amenity=school ans Gelände und auf die einzelnen Gebäude nur building=school.
c) Wenn die Schule mehrere Gebäude aber kein identifizierbares Schulgelände hat, gibt es ein Multipolygon mit amenity=school, das die Gebäude umfasst.
Als Regel aufzustellen, wie du das vorhast, dasss amenity=school nicht ans Gebäude gehört, halte ich für fragwürdig, weil eine Schule ohne schuleigenes Gelände, eben auch nur über das Gebäude beschrieben wird.
Sowas gibts? Ich kenne keine Schule ohne Lehrerparkplatz und Schulhof. Und DIE gehören eben mit in die Fläche der Schule - Da ist sich das Wiki ganz sicher.
Ich würds jedenfalls nicht ausschließen, dass es das gibt, denk bitte dabei auch international - und an Schulhöfe, die z.B. gleichzeitig Parks etc. sind. Lehrerparkplätze hat außerdem sicher nicht jede Schule (in Warburg bin ich mir z.B. ziemlich sicher, dass die Schulen im Schulzentrum (Haupt- und Realschule) keinen extra Lehrerparkplatz haben; und der "Parkplatz der Schule" gehört gleichzeitig zu Schwimmbad, Sportzentrum etc. - passt also auch nicht.
Und normalerweise sind gerade Schulgelände _sehr gut_ identifizierbar, ganz im gegensatz zu Industriegebieten. stimmt - normalerweise. Aber spätestens wenn Du Parkplätze ja offensichtlich teilweise mit einbeziehen willst, wirds schwierig, wenn am Parkplatz nicht dransteht, dass dieser nur für Angehörige/Besucher der Schule zur Verfügung stehe.
building=school halte ich übrigens nicht richtig, wenn das Gebäude kein Schulgebäude ist sondern ein als Schule genutztes Gebäude.
Das ganze ist in jedem fall richtig. Ich habe das thema building != yes bisher nur wenig bis gar nicht genutzt (ausnahme garage). Ich habe es durchaus sinnvoll building mit leben zu fuellen - yes ist quasi ueber.
Bis man sich dann mal geieinigt hat ob ins building die nutzung, angedachte nutzung, bauform oder was auch immer kommt kann man das ja schonmal miterfassen und später durch haarspalterei aufdröseln. Die betroffenen Gebaeude lassen sich dann aber schnell und automatisiert finden.
Und was in das tag building kommt ist hoch umstritten. Die Begründung zum building-Tag war, wie gesagt, meine persönliche Meinung zu dem Thema, sicher nicht ein allgemeingültiger Konsens, deshalb "halte ich das [für] nicht richtig", nicht "deshalb ist es falsch".
Gruß Peter
participants (3)
-
Florian Lohoff -
Frank -
Peter Wendorff