Die Grundfrage des Problems ist eigentlich eine andere: Sind die Eigenschaften des “POIs” am richtigen Element angehängt.
Die meisten “POIs”, die als Polygon gemappt sind, sind doch nur Tags an buildings. Und das ist meistens falsch. Warum? Weil das Gebäude eben nicht so wie der POI heißt oder wie bei Aldi meistens gar keinen Namen hat. Wenn man den Aldi schon als Polygon mappen will, dann schon gleich als Ring um Gebäude UND Parkplatz. Dann erübrigen sich auch häufige Fantasiename wie “Aldi-Parkplatz”, “Besucherparkplatz” und dergleichen.
Seit einiger Zeit sehe ich, dass dieses letztgenannte Taggingprinzip zumindest bei Schulen schon Schule macht Das Schulgelände bekommt den Schulnamen und die Einzelgebäude können “richtige” Namen -so vorhanden- oder auch lokale Namen (wie “Südflügel”) bekommen.
Leider gibt es genügend Mapper, die nach dem Prinzip “eine Fläche ist besser als ein Punkt” die Arbeit von Vor-Ort-Erfassern einfach abändern (der POI wird einfach an das darunterliegende Gebäude gehängt - auch wenn sich noch weitere (nicht gemappte) POIs und Wohnungen darin befinden). Das eigentlich sehr schöne buildings_tools-Plugin ist sogar standardmäßig so eingestellt, einen innerhalb des neuen Gebäudes liegenden POI zu verwursten (glücklicherweise habe ich die Einstellungsmöglichkeit gefunden - und sofort ausgeschaltet)
Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.
Wenn sich nur ein POI am Gebäude befindet, auch wenn es nur ein kleines ist, es gleich an das gesamte Gebäudepolygon zu hängen, ist auch ein wenig übertrieben. Wenn die Fläche bekannt ist, würde ich ein eigenes Polygon anstreben (mit Stockwerksangabe).
LG Jimmy
PS: Bitte nicht daran aufhängen, dass im POI “Point” steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.
ich bin da recht unemotional. Ändert aber nichts dran, dass ich POI als Polygon für falsch halte und das Problem mit den Wheelmapper mit POI-Punkten hätte auch vermieden werden können. Für mich heißt es auch sich der Realität der Anwendungen zu stellen, wenn man sich Gedanken über ein Datenmodell macht. Das ist ein Problem von OSM: Das Datenmodell ist historisch gewachsen und erfüllt nicht was man an allgemeinen Qualitätsmaßstäben an Geodaten anlegt - daran gemessen ist völliger Murks. Das kann man nun verteidigen oder schrittweise beheben.
danke für Deinen Hinweis. Das erschien mir schon so trivial, dass ich vergessen habe darauf hinzuweisen. Allein das ist schon Grund genug POI nur als Punkt zu mappen.
danke auch für Deinen Hinweis, über den ich erst mal nachdenken musste. Es ändert sich aber nichts für mich. Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von “is_in” als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.
so ist das nicht. Das Gebäude des Supermarkts ist doch da mit seiner Fläche. Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte. Und der Bäcker-Laden vorweg kann auch indoor kartiert werden, dazu ein POI auf den Eingang.
das hängt dann davon ab, wie der POI liegt - wenn er denn auf dem Eingang liegt, eine gute Idee. Ich würd das nicht mal vorschreiben wollen, vielleicht gibts auch Fälle wo man den POI nicht auf den Eingang legen will. Vielleicht gibt sogar Fälle, wo man den POI auf einen Zuweg mit einem Schild legen will, weil man sonst gar nicht hinfindet.
Dann wiedersprichst du dir jetzt gerade selber: Geradeeben sagst du der POI darf nicht irgendwo liegen sondern genau am eingang und jetzt liegt er aufeinmal am “Zuweg” - oder sollen wir POIs setzen? Ähnlich einer Krümelspur? Dann bräuchten wir auch keine routing-Software mehr - einfach der POIs-Kette folgen…
Also für mich ist und bleibt ein POI ein “Ort” und kein “Punkt” - ein Schloss/Burg kann ja zB ein “POI” sein - da will ich dann aber nicht nur einen Punkt im Innenhof sehen, sondern das Bauwerk in seiner Gesamtheit - somit bleibe ich bei Tagging-Schema alt: “Ein POI” > way/polygon - “mehrere POIs” > nodes
Aber was ist es genau? Es ist immer das, was der jeweilige Betrachter darin sieht. Für den einen sind es geschichtliche Orte, den anderen ehemalige Bahnstrecken, wieder andere Einkaufsläden, oder Taxistände. Dasraus ergibt sich für mich, daß ein POI sowohl Fläche, Linie oder Punkt sein kann (auch in Relationen). Diese POI’s immer als Punkte zu sehen, halte für unlogisch.
POI ist wie ein Gummituch. Jeder zieht es dahin, wo er es haben will.
Die is_in-Relation macht die Sachen aber für alle Seiten komplexer und ohne die geht die Beziehung zwischen Fläche und POI verloren. Den automatisch darin zu verorten ist noch wesentlich blöder für die Auswerter. Und es gibt ja durchaus verschiedene Auswerter. Für Rederer ist es Mist, wenn der POI auf dem Gebäuderand liegt wie ein Eingang, denn dann landet der Schriftzug völlig falsch oder man muss deutlich mehr Aufwand betreiben. Letzlich bleiben insgesamt fast nur Nachteile.
ich will die Relation oder “is_in”-Geschichte auch nicht haben. Mir reicht wenn der Punkt in der Fläche liegt. Und die Attribute für den POI an dem Punkt und nicht am Gebäude hängen. Wo der Renderer den Schriftzug hinsetzt ist mir eigentlich recht egal, mir ist wichtiger, dass man alle POI bekommt wenn man die z.B. über die Overpass-API abfragt.
Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.
Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt’s auf ein paar Pixel lechts oder rinks nicht an.
Du hast: “Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!” vergessen.
Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?
Das Zitat lese sich als ‘technisch kein Problem, leider noch nicht umgesetzt’
Natürlich tut das ein guter Renderer. Aber das kann er nur solange er den Zusammenhang kennt. Und wenn ich nunmal irgendwohin (weiter oben hieß es schon, auf den Parkplatz) einen Punkt setze, kann er den nicht mit der Fläche in Verbindung bringen. Man sollte es ihm doch nicht unnötig schwer machen, wenn doch eine der Hauptbegründungen für die Punktvariante war, dass sei für die Auswerter leichter - ist es eben nicht für alle, nur für bestimmte.
Ich habe nichts gegen eine Verbesserung. Aber hier sehe ich eben einen Rückschritt. Und es ist ja nun so, dass das Ganze seit längerem so praktiziert wird und die meisten damit keine Probleme haben und die Tool-Unterstützung schon recht gut ist.
Was uns verloren geht, wenn wir das umsetzen? Der Bezug von Fläche und Nutzung geht uns verloren. Das kann man natürlich unproblematisch finden, mich würde es stören. Viele Renderer stellen beispielsweise Gebäude mit POI anders da, als solche ohne, das verbessert die Orientierung auf der Karte doch gewaltig. OSM wirbt doch gerade auch damit, dass wir semantisch wertvolle Daten mit Beziehungen der geographischen Objekte untereinander und mit weiterführenden Informationen haben, und nicht nur, wie kommerzielle Datensätze, Punktwolken mit gerade so viel Information, wie für wenige Hauptanwendungsfälle gerade so notwendig.
Natürlich müssen wir darauf achten, dass unsere Daten leicht zu erfassen und leicht zu verwerten sind. Aber mal ehrlich: Zumindest mit JOSM (andere Editoren nutze ich zu wenig, um das beurteilen zu können) ist es kein bisschen komplexer, das mit Flächen zu erfassen. Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken. Aber mit Unterstützung der einschlägigen Werkzeuge (osmconvert wurde schon angesprochen) und der Tatsache, dass das als häufig benötigte und technisch nicht so komplexe Funktion ist und deshalb sicher auch von anderen Werkzeugen unterstützt werden wird (wie schon gesagt, schlagt es doch für die Overpass-API mal vor - wenn sie’s nicht doch schon kann), sehe ich auch keine allzu großen Hürden für Auswerter. Da haben wir wirklich wesentlich komplexere Daten, wenn es z.B. um Relationen, Multipolygone, ÖPNV-Linien geht.
Ok, ich habe ein großen Aldi (um beim Beispiel zu bleiben). Dieser hat zwei Eingänge. Einer ist nicht rollstuhltauglich, der andere schon. (nicht realitätsnah, aber egal
Aktuelles mapping:
Gebäude+Aldi polygon. Auf diesem sind zwei entrance=yes nodes, wheelchair=yes/no jeweils. Meine (fiktive?) wheelchair-Routingsoftware kann also mich zum Aldi führen und weiss, dass sie direkt den entrance node mit wheelchair=yes ansteuern muss. Einfach, weil sie sieht, dass der Such-Treffer ein polygon ist und der zwei entrances nodes hat.
Vorgeschlagenes Mapping:
Gebäudepolygon und in der Mitte ein Aldi-Node. Das Gebäude hat auch jeweils die Entrance Nodes.
Meine routing-software hat jetzt einen Berg arbeit vor sich, rauszufinden, ob der Such-Treffer-Node jetzt innerhalb eines Gebäudes liegt. Dazu muss sie zusätzlich raten, dass beide entrance-nodes hoffentlich auch wirklich in den Supermarkt führen.
Alternativ:
Gebäudepolygon mit Aldinode am Haupteingang. Damit weiss erst recht keiner, dass der 20 meter danebenliegende wheelchair entrance auch in den supermarkt führt…
Alternativ 2:
Gebäudepolygon mit Aldinode in der Mitte. Dazu zwei Eingänge auf dem Gebäude und zwei footways von den Eingängen zum Aldi-Node. wird dann aber erstens hässlich und zweitens aufwändiger zu mappen.
Da gefällt mir das aktuelle Datenmodell irgendwie besser.
Die “meisten” Mapper lesen dieses Forum nicht. Und die “meisten” von den hier Mitlesenden/-schreibenden arbeiten nicht in Projekten mit, die irgendwas zur Verfuegung stellen, dass dann von ‘Nicht-Mappern’ verwendet wird.
Leute wie moenk kriegen durch Fragen von Benutzern (anders als die “meisten”) mit, wie unlogisch und kompliziert unser Tagging-Modell an manchen Stellen ist und wie viele Probleme in der Praxis dadurch entstehen.
Wenn wir die Erfahrungen der “Verwerter” unserer Daten nicht Ernst nehmen, anstelle sie mit “Problem der Anwendung - mir doch egal, ich kippe in die DB was ich diese Woche gerade glaube, was en vogue ist!” abzubuegeln, dann werden wir dem Gedanken der “Foerderung freier Geodaten” wohl nicht wirklich gerecht.
Das Schulgelände bekommt den Schulnamen und die Einzelgebäude können “richtige” Namen -so vorhanden- oder auch lokale Namen (wie “Südflügel”) bekommen.
