Supermarkt in historischem Gebäude - Namenskonflikt

Ich wiederhole mich gerne. Macht doch POIs nur noch mit Punkten (wie das P schon sagt), das ist letztlich übersichtlicher. Daten auf Flächen werden viel leichter beim Updaten übersehen bzw. man muss sie mühsam suchen, außerdem überdecken sie oft noch die Adresse, sodass man denkt, diese würde fehlen, außerdem kann man den Punkt an den Eingang setzten, dann weiß der Router, wohin er bei einem größeren Gebäuden leiten soll.
Ich denke, irgendwann werden wir nur noch gebäudebezogene Daten wie Höhe, Dachform etc, auf die Fläche setzten, alles andere (POI, Adresse) bekommt Punkte im Gebäude.

Es ist deshalb “übersichtlicher”, weil es weniger Informationen enthält. Punkte sind dazuhin schlecht zu verfeinern und generieren topologische Unsicherheiten (ist ein danebenliegender anderer Punkt nun drin in dem anderen, oder nur daneben?). S.o.

Größere Gebäude haben oft mehrere Eingänge. Das kann man mit einem Punkt nur noch über Relationen lösen. Grundsätzlich halte ich es für falsch™ POIs auf Eingänge zu setzen, zum einen schafft man damit ein neues Problem ähnlich dem des OP (man weiss nicht mehr, ob die Informationen zum “POI” oder zum “Eingang” gehören), zum anderen ist es topologisch falsch™, weil sich Eingänge am Übergang von Innen und Aussen befinden, der POI aber innen ist.

Ich verstehe deine Argumentation nicht. Wenn neben dem Supermarkt noch ein Bäcker in dem Gebäude ist, muss man sowieso auf Punkte ausweichen. Daher kann man gleich die Inhalte eines Raumes, eine Fläche ist es ja sowieso nicht, als einen oder mehrere Punkte darstellen. Je mehr Informationen man auf den Grundriss legt, desto schwieriger wird das Überprüfen, ob auch wirklich alle so noch stimmen. Und POIs müssen ständig überprüft werden, daher sollten wir es uns leicht machen und diese deutlich von anderen Informationen trennen. Ich kenne nur ganz wenige Geschäfte oder sonstige Einrichtungen mit mehreren Eingängen. Mir fallen spontan nur ein Warenhaus und ein Modegeschäft ein. aber selbst hier sind die Eingänge meist nicht gekennzeichnet, sodass dein Argument eigentlich keins ist.
Wir können aber auch mal Argumente sammeln: Welche Vorteile haben POIs auf Flächen?

+1

+1

+1

In dem Falle der Kombination von Gebäudenamen und Shopnamen bleibt einem nichts anderes übrig, als mit Nodes zu arbeiten.
Ich würde im Node des Geschäfts noch das tag level hinzufügen.
Bitte nicht den shop Node (großes Geschäft) am Eingang. Das Geschäft befindet sich innen und ist nicht ein Minishop an der Haustür mit ein paar Quadratmeter. Den Eingang mit entrance=main taggen.

Wenn man Linien deckungsgleich übereinander legt (hier ein Polizeiposten und ein denkmalgeschütztes Gebäude), dann sieht das so aus: https://www.openstreetmap.org/way/102681836

JOSM meckert das auch an als Linien mit gleicher Position.

Die Lösung mit den Nodes finde ich nicht sonderlich elegant. Der Supermarkt hat ja eine Ausdehnung und die ist sogar klar erkennbar. Warum sollte ich diese Information nicht auch festhalten? Gerade mit Blick auf Indoor-Mapping erscheint mir das nicht als sinnvoll. old_name gefällt mir nicht, weil ja das Gebäude trotzdem so heißt, und nicht mal früher so hieß. Eigentlich wäre es sauber zu sagen:
building:name = “Rennbahnhof”
shop:name = “Bio Company”

Was dann der Renderer macht, ist mir dann theoretisch egal (praktisch natürlich nicht, da würde ich schon noch name = “Bio Company” ranschreiben.)

Was meint ihr?

Dann nutze doch alt_name für den shop und name fürs Gebäude - alt_name wird über die Suche auch gefunden.

Wobei ich das mit den POI bevorzugen würde.

Wenn man den Supermarkt nicht als POI erfassen will, dann sollte man darüber nachdenken, ob der Parkplatz und das drumherum nicht auch zum Supermarkt gehört - und damit ein Way um das Gebäude passender sein könnte als ein Way nur innerhalb.

Das ergibt das Problem, dass man nicht weiß, ob der Supermarkt auch einen “normalen” Namen hat. Oder ob das Gebäude zwei verschiedene Namen hat und niemand weiß, welcher Supermarkt das ist… :wink:

Ich stimme zu, dass old_name in der geschilderten Situation nicht der richtige Schlüssel für den Gebäudenamen ist, und dass der Supermarkt idealerweise eine Fläche sein sollte.

Eine Lösung über Schlüssel wie shop:name ist aus meiner Sicht aber nicht sauber und ein klares Anzeichen dafür, dass man das Prinzip “ein Feature ⇔ ein OSM-Datenobjekt” verletzt. Das ist als pragmatische Abkürzung in einfacheren Fällen ganz ok. Aber Situationen wie hier (zwei Dinge werden am selben Way getaggt und sie haben beide ihren eigenen Namen) sind eigentlich ein Musterbeispiel dafür, warum es dieses Prinzip gibt. Daher sollte man zumindest in solchen Fällen dann eben zwei OSM-Objekte daraus machen, sei es Fläche + Node oder Fläche + Fläche. Und mit letzterer Lösung – eine Fläche fürs Gebäude, eine zweite Fläche für den Supermarkt – ist dann auch dessen Ausdehnung klar.

Alles klar, habe den shop zur Node gemacht. Danke für die Diskussion!

In dem Fall hier (bestehendes Objekt) halte ich das für schlecht vertretbar, weil dadurch enthaltene Informationen gelöscht werden (die Form, Lage und Ausdehnung des Supermarkts war vorhanden). Freie Wahl hat man nur, wenn man etwas neu anlegt, sonst sollte man m.E. intensiv versuchen, vorhandene Informationen zu erhalten.

Womit wir wieder beim Anfang wären :wink: Ich sehe es ja auch wie du, aber wie bewerkstelligen?

Vielleicht doch indoor mapping → https://wiki.openstreetmap.org/wiki/OpenLevelUp

https://openlevelup.net/?l=1#18/51.04013/13.73132
https://www.openstreetmap.org/#map=18/51.04013/13.73132

Statt einem Node eine zweite Fläche für den Supermarkt zu malen würde doch die bestehenden Infos zu Form, Lage und Ausdehnung erhalten? Das kann man dann mit Zusatzinfos wie level-Tag bis zum Indoormapping ausbauen, muss man aber nicht.

Hat aber den Nachteil, dass diese Fläche logisch nicht dem Gebäude zugeordnet ist, oder? Sie ist nur zufällig an der gleichen Stelle…

Wieso meinst Du, dass ein Programm noch mehr braucht, um eine logische Beziehung erkennen zu können? POI innerhalb einer Fläche bedeutet doch, dass der Laden in dem Gebäude liegt. “Echtes” 3D haben wir nämlich nicht. Daher kann jeder annehmen, dass der POI nicht im Flugzeug 3 km über Grund liegt :stuck_out_tongue:
keep KISS

Hat aber die prinzipielle Schwäche, dass Umriss und POI getrennt bewegt werden können, da in der DB eben nicht logisch verbunden.
Bei eng stehenden Gebäuden und vielen POIs (Altstadt) muss man z.B. beim Verschieben schon ziemlich aufpassen, sonst liegen einige POIs dann nicht mehr im Gebäude.
Deswegen liebe ich auch Hausnummern als POI nicht besonders.

Datentechnisch richtig. Aber richtig kriegsentscheidend ist doch wohl nicht, welchem Viereck auf der Karte das jetzt zugeordnet oder nicht zugeordnet wird. Dafür sind viel zu viele Gebäude in OSM vom Luftbild her “geraten” (was für Orientierungszwecke völlig ausreicht).

Außerdem geht es hier ja darum, dass Läden in der Regel ein Gebäude nur >nutzen< und das Gebäude selbst ganz andere Eigenschaften haben kann (zum Beispiel gar keinen Namen). Datentechnisch müsste man dann eine Relation zwischen dem POI/Way des Ladens und dem Way des Gebäudes erfassen - was ich definitiv hier nicht vorschlagen will. Weil wie gesagt: Das KISS-Prinzip sollte man nicht aus den Augen verlieren.

Das mit dem Verschieben ist nun auch nicht wirklich ein Argument. Die POIs sollen ja beispielsweise im Navi zu einem Restaurant führen da ist es unerheblich, ob sie nun außerhalb des Gebäude liegen. Wer mag kann sie auch auf die Gebäudelinie legen, wobei das dann Probleme macht, wenn man das Gebäude besser zeichnen will. Ich schrieb es schon mal weiter oben. Wenn wir wirklich mal so weit sind, dass jedes Gebäude für 3-D beschrieben wird, dann ist da einfach kein Platz mehr für andere Daten oder es wird so unübersichtlich, dass wir spezielle Editoren brauchen, die die Daten filtern. Daher plädiere ich für Trennung von Datensätzen.