Supermarkt in historischem Gebäude - Namenskonflikt

Hi,

ich habe ein Problem. Bei uns hat eine Bio Company aufgemacht in einem historischen Gebäude mit Namen “Rennbahnhof”. Da das komplette Gebäude zum Supermarkt umfunktioniert wurde, habe ich das Gebäudepolygon selbst zum shop = supermarket gemacht. Nun habe ich aber das Problem, dass es 2 Namen gibt: Für den shop und für das building. Aktuell habe ich den Gebäudenamen zu old_name gemacht, aber das gefällt mir nicht. Gibt es einen besseren Weg, oder sollte ich shop doch nur als Node klassifizieren?

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.

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 :slight_smile:

–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

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

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?