Supermarkt in historischem Gebäude - Namenskonflikt

Wenn irgendwo noch "Rennbahnhof" an dem Gebäude steht, würde ich den Supermarkt als Node setzen. Wenn aber überall nur noch "Bio Company" steht, dann ist "Rennbahnhof" nur noch ein historischer Name und ich würde ihn ins old_name schreiben.

Ich würde den Shop-Eingang im Gebäudeumriss mit den Shop-Daten versehen.
Dann bleibt das "historische Gebäude" erhalten mit richtigerweise old_name=*, falls nicht am Gebäude der Name "Rennbahnhof" steht.

Ein weiterer Weg wäre, den Namen des Supermarktes als shop:name=* dranzutaggen. Wird aber wohl nicht breit ausgewertet. Ich würde auch die Node-Lösung wählen.

Discostu36 wrote:

Wenn irgendwo noch "Rennbahnhof" an dem Gebäude steht,

Das wäre bei mir nicht zwingend. Wenn das Gebäude im allgemeinen Sprachgebrauch so genannt wird, ist das sein aktueller Name, ob er dransteht oder nicht. Ja, das entspricht nicht ganz der OTG-Regel, sondern meinem Pragmatismus. Streng nach OTG-Regel dürfte kaum ein Bach oder Hügel im Mittelgebirge ein name=* haben – außer es steht ein Schild dran 🙂

--ks

Hallo,

wenn der Supermarkt das gesamte Gebäude ausfüllt, kann man auch einfach einen zweiten Way zeichnen, der exakt dieselben Nodes wie das Gebäude hat. Dieser trägt dann die Tags, die zum Supermarkt gehören. Es ist also im Prinzip, wie eine Straßenbahn ohne eigenen Gleiskörper, die eine andere Höchstgeschwindigkeit (oder anderes Tag) als der Individualverkehr hat.

Viele Grüße

Michael

Nakaner wrote:

Hallo,

wenn der Supermarkt das gesamte Gebäude ausfüllt, kann man auch einfach einen zweiten Way zeichnen, der exakt dieselben Nodes wie das Gebäude hat. Dieser trägt dann die Tags, die zum Supermarkt gehören. Es ist also im Prinzip, wie eine Straßenbahn ohne eigenen Gleiskörper, die eine andere Höchstgeschwindigkeit (oder anderes Tag) als der Individualverkehr hat.

Viele Grüße

Michael

Oder eine paralelle Linie vom Gebäudeumriss nehmen (die Funktion gibt es ja in JOSM) und dann an den inneren Ring alles den Supermarkt betreffende Dranpappen. Hätte auch den Vorteil, dass es evtl. eindeutiger ist als wenn zwei Linien übereinander liegen und ggf. wäre es irgendwie auch korrekter, da der Supermarkt ja nicht mit der Außenkontur abschließt sondern eher mit der Innenkontur (also den Innenwänden, nicht den Außenwänden).

Klingt vielleicht komisch, aber was spräche dagegen?

Grundproblem ist, dass die Regel 1 Real World Objekt für ein OSM Objekt nicht eingehalten wird, wenn man beides auf demselben way taggt. 😉 Das ist als shortcut zwar bequem, stößt aber oft an seine Grenzen, wenn man mehr Detail eintragen will wie z.B. einen Gebäudenamen.

(Edit: Sorry, das war hinsichtlich der Regelverletzung ironisch, weil es immer Ansichtssache / Interpretation / Modell ist, was "1 Objekt" ist, wenn man anfängt, das Ganze der Welt in Teile aufzuteilen, im Prinzip funktioniert diese Regel nur, wenn sich alle einig sind, was "1 Objekt" ist)

Es gibt ein Gebäude (1 Objekt), darin ist
1 Supermarktnutzung (anderes Objekt).

Um das zu entdröseln kann man nun entweder einen Node für den Supermarkt innerhalb des ways für das Gebäude setzen, oder eben eine Fläche. Mit der Fläche transportiert man mehr Informationen:
- Größe
- Form
- Lage / Ausrichtung
und hat mehr Erweiterungsmöglichkeiten (mehrere Eingänge und Lage, andere Dinge innerhalb des Supermarkts, wie Kiosk, Bäcker, Pfandautomat, Einkaufswagen"lager", Passfotoautomat, Geldautomat, etc.)

Die Fläche kann man (wie von Nakaner vorgeschlagen) mit einem überlappenden way abbilden, oder z.B. auch durch ein multipolygon (Gebäude als outer member).

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.

wegavision wrote:

Ich wiederhole mich gerne. Macht doch POIs nur noch mit Punkten (wie das P schon sagt), das ist letztlich übersichtlicher.

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.

wegavision wrote:

außerdem kann man den Punkt an den Eingang setzten, dann weiß der Router, wohin er bei einem größeren Gebäuden leiten soll.

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.

dieterdreist wrote:

wegavision wrote:

Ich wiederhole mich gerne. Macht doch POIs nur noch mit Punkten (wie das P schon sagt), das ist letztlich übersichtlicher.

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.

wegavision wrote:

außerdem kann man den Punkt an den Eingang setzten, dann weiß der Router, wohin er bei einem größeren Gebäuden leiten soll.

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?

dieterdreist wrote:

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.

+1

kreuzschnabel wrote:

Wenn das Gebäude im allgemeinen Sprachgebrauch so genannt wird, ist das sein aktueller Name, ob er dransteht oder nicht. Ja, das entspricht nicht ganz der OTG-Regel, sondern meinem Pragmatismus. Streng nach OTG-Regel dürfte kaum ein Bach oder Hügel im Mittelgebirge ein name=* haben – außer es steht ein Schild dran

+1

dieterdreist wrote:

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.

+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.

geri-oc wrote:

Dann nutze doch alt_name für den shop und name fürs Gebäude...

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... ;-)

S-Man42 wrote:

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"

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!

S-Man42 wrote:

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 😉 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

S-Man42 wrote:

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

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...

S-Man42 wrote:

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 :-P
keep KISS

pyram wrote:

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.

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.

seichter wrote:

Hat aber die prinzipielle Schwäche...

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.

seichter wrote:

pyram wrote:

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.

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.

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.