[Tagging] navigational aid relation
Peter Elderson
pelderson at gmail.com
Thu Jun 15 19:05:55 UTC 2023
Trying to understand. If I read this right you want the router/navigator to
replace the target address of a routing request with a different object or
location, then start routing, right?
Why not simply tag the object_id or other identifier of the
replace-destination on the source object (in your terms)?
route_to=<object>
with optional suffixes for transport types.
Wouldn't solve muliple replacement options for one address, but it seems to
me that is not a basic requirement.
Op wo 14 jun 2023 om 09:32 schreef Florian Lohoff <f at zz.de>:
>
> Hi,
>
> Management Summary:
> In navigation/routing the point the router is routing to is the nearest
> point on the routable network from the poi/address we like to navigate
> to. The nearest point may not be a location where the address/poi can be
> reached from.
> I suggest a navigational aid relation hinting the link between
> geocoding and router to use a different point on the routable network.
>
>
> In 2019 i already sketched a problem where the normal "Geocode Address",
> "Look for the nearest road" fails miserable for some addresses. There is
> a multitude of issues here. Access tag overblocking, huge industrial
> complexes, or simply addresses which do not have an easy way for your
> mode of transport.
>
> So i suggest a relation like this
>
> type=navaid
> name=<Name of destination> - Optional
> source=<node, way, relation> - Original object we like to reach
> destination:motor_vehicle=<node> - Exakt navigation point to get to
>
> So when the geocoder returns a node, way, relation given in the "source"
> of this navaid relation, and our mode of transportation is listed in the
> "destination:<modeoftransport>" we replace the location from the
> geocoder with the destination from the relation.
>
> Example 1:
>
> This is a map i am producing weekly for parts of Germany which shows
> addresses on a map when their "nearest road" has a different name. Its
> not perfect but you get the idea. (Data bases on the nearest API call in
> OSRM)
>
>
> https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#51.98796,8.57338,17z
>
> In this case we have the addresses 114a, and 114b which are behind a
> long driveway which somebody tagged as unaccessible. The public road
> has a life_gate so there is no real way to get there. But we most likely
> want people get to the lift gate. So we would create a navaid relation
> for
> type=navaid
> source=<building way of 114a>
> source=<building way of 114b>
> destination=<node of the lift_gate>
>
> Example 2:
>
> This is the Corporate Fire Brigade within a large industrial compound.
> You'll be routed to the next Motorway.
>
>
> https://osm.zz.de/dbview/?db=addresses-nrw&layer=namemismatch#52.00001,8.6192,17z
>
> type=navaid
> source=<building way of fire_station>
> destination=<gate of industrial compound>
>
> Possibly adding all POI and Addresses within that compound as source so
> all people visiting Mitsubishi Papers in Bielefeld will be routed to the
> Gate not some street around.
>
>
> You may pan around the map and find solutions for all those problems.
> Sometimes its just the house at the corner - i'd say - okay - no issue.
> But sometimes its so utterly broken and people end up on the Motorway,
> in the middle of the Woods, on the other side of the Canal etc
> with the message "You have reached your destination".
>
>
> I am not really interested in discussions about necessity of this
> relation, as it is obvious that this or something similiar is needed and
> the problem is unfixable with data manipulation while keeping to
> "Ground truth". I am more interested in people Geocoding and Routing
> whether this would be a viable way to go, or if anyone can envision
> simpler solutions.
>
> Flo
> --
> Florian Lohoff f at zz.de
> Any sufficiently advanced technology is indistinguishable from magic.
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20230615/06416830/attachment.htm>
More information about the Tagging
mailing list