x

Verständnisfrage "gedoppelten" POIs


  1. Verständnisfrage "gedoppelten" POIs · fle0 (Gast) · 03.01.2021 12:25 · [flux]

    Hallo zusammen,

    ich bin seit kurzem tiefer in OSM eingestiegen und beschäftige mich aktuell mit dem Versuch Wanderungen zu planen. Dabei bin ich auf einige Merkwürdigkeiten, was Restaurants und Hotels bzw. die Beziehung zu den Gebäuden angeht, gestoßen.

    Beispiele z.B.:
    - Doppelte Nodes für ein POI (1315434524, 275390224 / 1731690185, 372746018)
    - Gebäude, das als Hotel+Restaurant getagt ist mit zusätzlichem Node fürs Restaurant (296522038, 3558325926)
    - Gebäude und zusätzlich eigener Node als Restaurant getagt (4686577452, 98653795)

    Das Einzige, was ich im Wiki zu der Thematik gefunden habe, ist:

    Befindet sich ein Restaurant in dem Hotel, sollte es mit einem gesonderten Punkt Knoten oder Punkt erfasst werden. So können die Eigenschaften besser zugeordnet werden und bei einer Suche nach POIs wird auch dieses gefunden.

    Demnach ist es erwünscht für ein Hotel+Restaurant zwei eigene Elemente anzulegen.
    Auch habe ich hier im Forum schon gefunden, dass es durchaus Sinn ergeben kann ein Gebäude und zusätzlich einen Node als POI im Inneren des Gebäudes einzufügen. Aber würde man in dem Fall z.B. auch das Gebäude als Restaurant tagen?

    Und wie ist mit den anderen Fällen umzugehen? Ist es eurer Meinung nach z.B. sinnvoll bei Punkt 1) ein Element zu löschen oder bei Punkt 3 das Gebäude nicht als Restaurant zu tagen?


    • Re: Verständnisfrage "gedoppelten" POIs · highflyer74 (Gast) · 03.01.2021 12:49 · [flux]

      Das wird regional unterschiedlich gehandhabt.

      In meiner Gegend haben wir uns darauf geeinigt, dass man die Gebäudedaten von den POI Daten vorzugsweise getrennt hält. Ich würde in dem Fall das Gebäude mappen und in das Gebäude jeweils einen Node für Restaurant und Hotel setzen, da es sich um verschiedene Dinge handelt, die auch vielleicht unterschiedliche Öffnungszeiten o.ä. haben.

      Grundsätzlich versuchen wir, doppelte Einträge zu vermeiden (https://wiki.openstreetmap.org/wiki/DE:Good_practice).


    • Re: Verständnisfrage "gedoppelten" POIs · pyram (Gast) · 03.01.2021 14:21 · [flux]

      highflyer74 wrote:

      In meiner Gegend haben wir uns darauf geeinigt, dass man die Gebäudedaten von den POI Daten vorzugsweise getrennt hält...

      Das hat sich auch ansonsten gegenüber früher so entwickelt. Ist schließlich auch logischer:

      fle0 wrote:

      Aber würde man in dem Fall z.B. auch das Gebäude als Restaurant tagen?

      Das Restaurant ist *in* dem Gebäude. Und der Name gilt für das Restaurant. Das Mischen der Gebäude- und POI-Eigenschaften ist eine Vereinfachung der Datenstruktur, aber keine bessere Struktur...


    • Re: Verständnisfrage "gedoppelten" POIs · Mammi71 (Gast) · 03.01.2021 18:00 · [flux]

      pyram wrote:

      Das Restaurant ist *in* dem Gebäude. Und der Name gilt für das Restaurant. Das Mischen der Gebäude- und POI-Eigenschaften ist eine Vereinfachung der Datenstruktur, aber keine bessere Struktur...

      finde ich etwas zu kurz gedacht. Wenn ein Gebäude ausschließlich das Restaurant beherbergt, ja explizit als Restaurant gebaut wurde, spricht nichts dagegen, direkt das Gebäude als Restaurant zu mappen. Und das dürfte auch ziemlich oft vorkommen.


    • Re: Verständnisfrage "gedoppelten" POIs · highflyer74 (Gast) · 03.01.2021 21:34 · [flux]

      Mammi71 wrote:

      Wenn ein Gebäude ausschließlich das Restaurant beherbergt

      Da wirst Du unterschiedliche Meinungen zu sehen. Logischer finde ich, ein Gebäude und seine Daten (bei uns teilweise z.B. auch Daten zum Denkmalschutz oder die immer mehr vorkommenden Daten zu Gebäudehöhen, Stockwerken, Dachformen etc.) von dem zu trennen, was sich in ihm befindet.

      Letzteres wechselt häufiger mal, bei Edits unerfahrener Mapper werden dann z.B. der Name des POI vom Gebäude entfernt, aber das Haupt-Tag oder die Telefonnummer übersehen. Der neue POI wird als Node gemappt und schon hat man zwei POI in der Datenbank. Da halte ich eine klare Trennung für sinnvoller.