-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 14 Jun 2023 09:26:43 +0200 Florian Lohoff <f...@zz.de> wrote:
> >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. I agree that something should be done. I am not sure that a relation is the solution. Some of the issues could be handled better by the data consumers. I.e., matching names of addresses and roads, routing to gates and entrances in parks, routing to terminals in airports. 7 years ago I opened an issue for OsmAnd: https://github.com/osmandapp/Osmand/issues/3210 But there has not been much improvement. E.g., when routing from Tårnby to Copenhagen Airport, ORSM still routes you away from the airport. (at least what most people would consider the airport) https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=55.6282%2C12.5998%3B55.6091%2C12.6510 ORSM will also make a route for e.g., Germany to France which makes little sense. On the other hand if you use OsmAnd to navigate to a tiny town, it will insist that you pick a streetname and a house-number. >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 -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTFiAV7M5dCBbueFnXaxL9tj5Q+NAUCZInFigAKCRDaxL9tj5Q+ NIdGAJ0aHP8hmQAv0wyuHZcx/dheUnN5CQCfa2t1dXsjKKaO+H7QX3TORIO5NWE= =sWq9 -----END PGP SIGNATURE----- _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
