Hier ist u.a. ein Thread von 2019 auf tagging den ich gestartet habe.
https://www.mail-archive.com/tagging@openstreetmap.org/msg45128.html
Also - Die idee ist eine relation die im “gluecode” zwischen Geokodieren und Navigation hängt.
D.h. du suchst Nach A und bekommst eine Liste mit Zielen die eben nicht A sind - sondern was anderes.
Beispiel der return liste:
- transport: Car
Realto Destination B, name Foo
- transport: Car
Realto Destination C, name Bar
- transport: Foot
Realto Destination D, name Realfootentrance
Das Problem ist das ein POI eben nicht umsonst ein POINT of interest ist. Es gibt kein Flächenrouting, schon gar nicht als Ziel - Du kannst nicht zu einer Fläche als Ziel routen. Einfach systemimmanent ist routing die “günstigste” (Kostenfunktion) Verbindung in einem Graphen zwischen Zwei Knoten A und B. MEHR macht eine routing software nicht. Also brauchen wir zwingend als Ziel B einen PUNKT.
Jetzt ist die Frage wie kommen wir zu dem PUNKT. Wir haben aktuell z.b. bei VEKA Flächen. Oder beim Flughagen München. Riesiges Sammelsorium von Flächen, Linien, Punkten mit Namen.
Mein Gedanke dazu ist eine “navaid” relation (Name ist doof - siehe thread - navaid ist ein stehender Begriff in der Fliegerei) - aber wir bleiben mal dabei:
type=navaid
modeoftransport=car/motor_vehicle/bus/hgv/delivery/foot/bicycle (Standard established access)
name=Navigation display
Zielobjekte (Multiple) role=to
Realer Ziel Node (Nur einer) role=realto
Nehmen wir an es gibt 36 Abfertigungsrampen bei einer Spedition. Dann packst du die 36 Rampen, und das Firmengelände und weiss der Henker was in die relation als objekt mit der to role, und das Werkstor als realto=
name=VEKA Tor 1
modeoftransport=hgv;delivery
Object (name=Rampe 1) role=to
Node (das Werkstor) role=realto
Du suchst nach VEKA - Bekommst das dingen in der liste - Dein Navi weiss du bist ein LKW und zeigt dir statt des Mittelpunktes des Firmengeländes gleich das Werkstor an.
Hier kommen wir auch endlich mal davon weg das bei großen Firmengeländen massiver “name tag abuse” betrieben wird indem jedes rolltor, jede Zufahrt mit beschreibenden Name tags versehen wird.
Tor 1 ist dann nicht “loc_ref=Tor 1” sondern name=“Röhrig Abwassertechnik LKW Zufahrt Tor 1” und davon haben wir dann so 10-20 und die karte ist vollgekleistert mit beschreiben name tags.
Auch modalwechsel sind dann möglich. D.h. am Beispiel Centro Oberhausen.
Du nimmst dein Navi und suchst nach dem Centro Oberhausen. Du bekommst die Liste der Parkplätze. Navigierst einen an. Dann steigst du aus und dein Navi ändert die Modaliät d.h. jetzt “foot” und in der liste sind neben den modeoftransport=car auch modeoftransport=foot mit drin. Und schon kriegst du beim aussteigen eine neue route (obwohl du dein ziel erreicht hast) die dich via foot bis zum Eingang leitet.
Was noch fehlt ist sowas wie “Equivalence” also nehmen wir an du hast eine große Firma und die hat 20 Personaleingänge die du nur als Fußgänger benutzen kannst. Dann willst du mehr als einen Personaleingang aber eben den nächstgelegenen. Also mehrere realto= die equivalent sind, aber anhand der Distanz selektiert werden sollen. (Auch z.b. bei Nationalparks in den USA)
Eine Möglichkeit wäre in der relation mehrere “realto=” anzugeben (Was ich ungern machen würde) oder sowas wie “realto_alternate” als role. So das navis die das nicht supporten nur “realto” benutzen, und die die “on-the-fly” multiple distanzen errechnen können auch die alternates supporten.
Also - jede menge room for improvement. Wichtig ist das wir eine möglichkeit des expliziten taggings des Zielnodes für eine Destination und Modalität brauchen. Alles andere ist murks und wird immer wieder zu Problemen führen. Ja - Jedes individuelle Problem kann man durch rumfaken und frisieren an den Daten dazu bekommen “halbwegs” zu funktionieren. Aber mit sauberen Daten hat DAS dann wenig zu tun.
Flo
).