Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 02:56 2023-06-18, Martin Koppenhoefer đã viết:



Am Sa., 17. Juni 2023 um 21:48 Uhr schrieb Minh Nguyen 
>:


Here in the U.S., the meaning of an address depends on who's using it.
To the tax authorities, it refers to the whole parcel. To emergency
responders, it's either the building or the beginning of the driveway.
To the postal service, it's the mailbox, which can be at the door, at
the street curb, or even at the neighborhood entrance.



This is probably how these are effectively interpretated / used. If the 
number refers to the whole parcel (tax), isn't this then a valid point 
of view for emergency responders as well? Won't they help you on every 
spot of the parcel, or do they require you go either into the building 
or to the beginning of the driveway before they will rescue you?


Certainly, they want to get to you as quickly as possible, wherever you 
might be. But consider a non-urban scenario: an ambulance responding to 
a call from [1] likely needs to access the house, or at least make it to 
the beginning of the driveway. The address contains "Adams Road", but 
the house is physically located 100 meters closer to State Route 48 (as 
the crow flies). Because it sits on a "flag lot" [2], the parcel's 
centroid is also closer to SR 48. If an ambulance travels from the 
nearest station to the centroid of either the house or the parcel, it 
will be delayed by at least 4 minutes, which can be the difference 
between life and death. [3][4]


This is a mild example that I picked at random. It isn't hard to find 
other examples that would delay an ambulance by tens of minutes as they 
search for a river crossing. These delays have caused enough problems 
that the state has developed a comprehensive address dataset 
specifically for emergency responders that places each point at the 
beginning of the driveway (i.e., at the mailbox). [5]


Obviously, mapping the driveway makes a big difference too. But 
sometimes the most direct driveway is the least accessible option; an 
application might be better off reverse-geocoding the raw coordinates to 
an address and then matching the address to a street. [6]



Mappers here generally treat the address as an attribute of a building,
POI, or something else. [1] 




in Italy, we also treat the address as an attribute of a POI - 
additionally, because from all the possible (assigned) addresses, there 
will often be a principal / official one which the business uses in 
their communications (this is somehow disputed in the community, some 
people do not want to "duplicate" addresses, so they add the poi 
information on the entrance node, which is not fully correct obviously, 
because the POI is usually inside and not on the perimeter, and the 
entrance is not the same as the POI so it goes against the one object 
one element rule. We never use addresses on buildings though.


I think the difficulty is that some software is treating 
addr:housenumber as a primary feature tag in its own right, whereas it's 
actually just a secondary attribute. Unlike other secondary attributes, 
we allow it to stand alone without any other primary feature tag, 
because it's often difficult to describe what exactly is at an address 
using other tags.



So the address point's coordinates don't
necessarily have any relation to where you would navigate to.



IMHO this is a problem, the addresses we add should indeed have a 
relation with where they are assigned to. A postbox with an address that 
is not on the site where the address belongs to, should not get "addr:*" 
tags of the far away place. There is "contact:street", 
"contact:housenumber" and others to add addresses that are elsewhere, as 
referers.


To clarify, in the scenarios I'm describing, the _address_ is relevant 
but not necessarily the coordinates where the addr:housenumber _point_ 
is located.


[1] https://www.openstreetmap.org/way/1182950336
[2] A parcel that is shaped like a flag on a flagpole, the flagpole 
being a narrow strip of land that follows the long driveway to the main 
street.
[3] 15 minutes 

[4] 19 minutes 

[5] 


[6] https://www.openstreetmap.org/way/34617394

--
m...@nguyen.cincinnati.oh.us



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Martin Koppenhoefer]

Am Sa., 17. Juni 2023 um 21:48 Uhr schrieb Minh Nguyen <
m...@nguyen.cincinnati.oh.us>:

> You're quite fortunate that the meaning of an address is unambiguous in
> Italy. At least you can be sure that a pedestrian route will lead to the
> main entrance, even if other modes aren't as well-served.



actually the real situation in Italy is more complicated than the theory.
For one, because the reality doesn't always follow the legal prescriptions
(every entrance to a building or site should get a housenumber according to
the law, i.e. also small gates leading to the garden, or similar), but
sometimes no housenumber is posted (maybe not assigned, maybe not displayed
by the owner, but either way not compatbile with the law), and sometimes,
"old" housenumbers (where there used to be a door but is now closed) are
still posted. And the law also declares that "potential" entrances should
get their own numbers, this refers mostly to shop windows, i.e. many
housenumbers are not assigned to a place where you can currently enter the
building/site.

As a result, many businesses and homes have more than one housenumber.
Adresses always are assigned to points and never directly to buildings
(although one could say a "buillding has several housenumbers" if you look
at the collection of numbers that lead to the building, and POIs usually
either indicate a of their housenumbers, or use the one that is actually
usable,  or sometimes use one that is now a closed door (e.g. because it is
their official address where they have registered the business).

You cannot assume that where a housenumber is posted this means access for
pedestrians, because "vehicle only" access points also get housenumbers
(AFAIK).


Here in the U.S., the meaning of an address depends on who's using it.
> To the tax authorities, it refers to the whole parcel. To emergency
> responders, it's either the building or the beginning of the driveway.
> To the postal service, it's the mailbox, which can be at the door, at
> the street curb, or even at the neighborhood entrance.
>


This is probably how these are effectively interpretated / used. If the
number refers to the whole parcel (tax), isn't this then a valid point of
view for emergency responders as well? Won't they help you on every spot of
the parcel, or do they require you go either into the building or to the
beginning of the driveway before they will rescue you?



>
> Mappers here generally treat the address as an attribute of a building,
> POI, or something else. [1]



in Italy, we also treat the address as an attribute of a POI -
additionally, because from all the possible (assigned) addresses, there
will often be a principal / official one which the business uses in their
communications (this is somehow disputed in the community, some people do
not want to "duplicate" addresses, so they add the poi information on the
entrance node, which is not fully correct obviously, because the POI is
usually inside and not on the perimeter, and the entrance is not the same
as the POI so it goes against the one object one element rule. We never use
addresses on buildings though.



> So the address point's coordinates don't
> necessarily have any relation to where you would navigate to.



IMHO this is a problem, the addresses we add should indeed have a relation
with where they are assigned to. A postbox with an address that is not on
the site where the address belongs to, should not get "addr:*" tags of the
far away place. There is "contact:street", "contact:housenumber" and others
to add addresses that are elsewhere, as referers.



>
> This is another good reason why I'd advocate for objectively
> micromapping features that data consumers (whether routers or geocoders)
> could recognize as navigable points or not, depending on the situation.
>


+1

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 21:59 2023-06-16, Volker Schmidt đã viết:
When trying to reach a destination that is defined by a complete address 
(city, street name, house number or name) is that the last meters of the 
route are, potentially,  much different for a 
ciclist/pedestrian/car-driver/delivery-van/ambulance/...
One of the many problems is that we would need for any given address a 
navigation aid for each of the potential means of transport.


I have come across one aspect of this when I noticed that Amazon 
Logistics staff systematically changed access tags on driveways around 
here from "private" to "yes" (or similar).


Micromapping correctly the last meters for all the different means of 
transport is the correct theoretical solution. But is it practical ?


Navigation aid?
In Italy the house numbers are assigned to the pedestrian entrance point 
for the house/business/shop/airport/...


You're quite fortunate that the meaning of an address is unambiguous in 
Italy. At least you can be sure that a pedestrian route will lead to the 
main entrance, even if other modes aren't as well-served. Each country 
has different addressing standards, so what may be sufficient in one 
country might be insufficient in another.


Here in the U.S., the meaning of an address depends on who's using it. 
To the tax authorities, it refers to the whole parcel. To emergency 
responders, it's either the building or the beginning of the driveway. 
To the postal service, it's the mailbox, which can be at the door, at 
the street curb, or even at the neighborhood entrance.


Mappers here generally treat the address as an attribute of a building, 
POI, or something else. [1] So the address point's coordinates don't 
necessarily have any relation to where you would navigate to. But 
addr:street is usually either the name of the street that the building 
faces, or the name of the street that the letter carrier uses to get to 
the mailbox (wherever it is). So at least we know that street is more 
related to the feature than the other nearby streets.


For the majority of cases, that assumption is a good one for navigation, 
but not always. For example, in the suburbs, a house at a street corner 
often has a mailbox at the curb along one street (hence addr:street) -- 
but to get to the front entrance, you use a walkway from a different 
street. To illustrate the point, these examples are fully micromapped 
with mailboxes, entrances, driveways, and walkways:


Mailbox on one street, car and pedestrian entrances on another:
https://www.openstreetmap.org/way/37018678

Mailbox and pedestrian entrance on one street, car entrance on another:
https://www.openstreetmap.org/way/38064995
https://www.openstreetmap.org/way/34618091

Mailbox and car entrance on one street, pedestrian entrance on another:
https://www.openstreetmap.org/way/37018646

Mailbox on one street, car and pedestrian entrances accessible from 
either street:

https://www.openstreetmap.org/way/34618083

Everything on one street, but addr:street names a different street. 
(What's a rule without an exception?)

https://www.openstreetmap.org/way/32602856
https://www.openstreetmap.org/way/34618143

These are trivial cases where getting to the wrong street isn't much of 
a problem for most people, though enough of this misdirection could 
throw a delivery person off schedule. If the style of micromapping in 
these examples becomes widespread enough, then the addr:street-based 
heuristic becomes unnecessary. But that's a herculean task, even bigger 
than mapping all the addresses in the first place.


Take an address in a pedestrian area within a limited-access zone in my 
city.
Take car access. During the night the car access for drop-down is 
somewhere in walking distance outside the pedestrian area, but within 
the limited-traffic zone (which is not active at night). During the day 
it is most likely a park-and-ride location outside the city centre.


This is another good reason why I'd advocate for objectively 
micromapping features that data consumers (whether routers or geocoders) 
could recognize as navigable points or not, depending on the situation. 
For the difficult, indescribable cases, there's already a catch-all site 
relation type.


--
m...@nguyen.cincinnati.oh.us



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Volker Schmidt]

I read this discussion with interest (as end user) and ignorance
router-wise.

Some unsorted early-morning thoughts on this subject:

When trying to reach a destination that is defined by a complete address
(city, street name, house number or name) is that the last meters of the
route are, potentially,  much different for a
ciclist/pedestrian/car-driver/delivery-van/ambulance/...
One of the many problems is that we would need for any given address a
navigation aid for each of the potential means of transport.

I have come across one aspect of this when I noticed that Amazon Logistics
staff systematically changed access tags on driveways around here from
"private" to "yes" (or similar).

Micromapping correctly the last meters for all the different means of
transport is the correct theoretical solution. But is it practical ?

Navigation aid?
In Italy the house numbers are assigned to the pedestrian entrance point
for the house/business/shop/airport/...
Take an address in a pedestrian area within a limited-access zone in my
city.
Take car access. During the night the car access for drop-down is somewhere
in walking distance outside the pedestrian area, but within the
limited-traffic zone (which is not active at night). During the day it is
most likely a park-and-ride location outside the city centre.

You can construct many more examples.

Volker






On Sat, 17 Jun 2023, 00:16 Minh Nguyen, 
wrote:

> Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:
> > On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:
> >> I neglected to mention another common heuristic: the geocoder can
> >> automatically bias the address point toward the street named in
> addr:street
> >> when coming up with a navigable point. The Mapbox Geocoding API is an
> >> example of a geocoder that does this [1][2], though unfortunately
> neither
> >> Nominatim nor Pelias has a similar feature so far.
> >
> > You need to remember that routers are only one kind of client of
> > Geocoders and certainly not the most important by far. While a nice
> > gimmick, I certainly wouldn't consider it a main task of a geocoder to
> > return a routeable point. The main task is to return the place/object you
> > were searching for. In that sense, the root of the issue is that
> > routers usually underspecify their search query. If the query is
> > 'airport Frankfurt', then the airport is what the geocoder returns. One
> can't
> > expect the geocoder to determine that what you actually wanted is the
> > street closest to the main entrance or the parking or the main bus stop.
> > 'parking near airport frankfurt' does yield results although we'd have
> > to do something about priority ordering.
>
> To be clear, all this talk about "navigable points" is about something
> that would supplement, not replace, the centroid coordinate that a
> geocoder already returns. If an end user searches for "airport
> Frankfurt", what Nominatim returns is quite sufficient for centering the
> map on the airfield. However, nowadays, the user also expects to see a
> row of buttons for navigating to a specific terminal, parking lot, or
> tram stop. This was not the case several years ago, but all you have to
> do is look at the most popular navigation applications to see why this
> topic keeps coming up.
>
> >> Then again, none of this complexity is necessary if OSM has a publicly
> >> accessible driveway or footpath leading right up to the building. A
> router
> >> should consider that driveway or footpath to be part of the most direct
> >> route.
> >
> > Exactly. It would be kind of counter-productive to add all this
> > functionality to a geocoder. A good router has all the right
> > data structures to make an informed decision about the navigation start
> point
> > and also the information about mode of transport etc. A geocoder's
> > data structures are rather unsuitable to solve these examples.
> >
> > The initial examples of Florian are quite telling in that way. The
> > closest road to
> >
> https://osm.zz.de/dbview/?db=addresses-nrw=namemismatch#51.98796,8.57338,17z
> > would in fact be the service way right next to the buildings. The fault
> > is with the router who does not include non-accessible roads to
> > determine the access and thus finds the wrong road. If it would create a
> > full routing network that includes inaccessible service roads and
> footways,
> > it would be able to make the right decision and bring the car to the
> gate.
>
> I agree that routers should consider inaccessible service roads more
> than they do now. However, this would not be a panacea. For one thing,
> if the router finds the nearest inaccessible service road to an airport
> centroid, more often than not, it will be along a vehicle service road
> (VSR) for ground support equipment, surrounded by taxiways or even runways.
>
> Nominatim returns a centroid for the San Francisco International Airport
> that's about 80 meters from a VSR used only by airfield maintenance
> 

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 11:48 2023-06-15, Sarah Hoffmann via Tagging đã viết:

On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:

I neglected to mention another common heuristic: the geocoder can
automatically bias the address point toward the street named in addr:street
when coming up with a navigable point. The Mapbox Geocoding API is an
example of a geocoder that does this [1][2], though unfortunately neither
Nominatim nor Pelias has a similar feature so far.


You need to remember that routers are only one kind of client of
Geocoders and certainly not the most important by far. While a nice
gimmick, I certainly wouldn't consider it a main task of a geocoder to
return a routeable point. The main task is to return the place/object you
were searching for. In that sense, the root of the issue is that
routers usually underspecify their search query. If the query is
'airport Frankfurt', then the airport is what the geocoder returns. One can't
expect the geocoder to determine that what you actually wanted is the
street closest to the main entrance or the parking or the main bus stop.
'parking near airport frankfurt' does yield results although we'd have
to do something about priority ordering.


To be clear, all this talk about "navigable points" is about something 
that would supplement, not replace, the centroid coordinate that a 
geocoder already returns. If an end user searches for "airport 
Frankfurt", what Nominatim returns is quite sufficient for centering the 
map on the airfield. However, nowadays, the user also expects to see a 
row of buttons for navigating to a specific terminal, parking lot, or 
tram stop. This was not the case several years ago, but all you have to 
do is look at the most popular navigation applications to see why this 
topic keeps coming up.



Then again, none of this complexity is necessary if OSM has a publicly
accessible driveway or footpath leading right up to the building. A router
should consider that driveway or footpath to be part of the most direct
route.


Exactly. It would be kind of counter-productive to add all this
functionality to a geocoder. A good router has all the right
data structures to make an informed decision about the navigation start point
and also the information about mode of transport etc. A geocoder's
data structures are rather unsuitable to solve these examples.

The initial examples of Florian are quite telling in that way. The
closest road to
https://osm.zz.de/dbview/?db=addresses-nrw=namemismatch#51.98796,8.57338,17z
would in fact be the service way right next to the buildings. The fault
is with the router who does not include non-accessible roads to
determine the access and thus finds the wrong road. If it would create a
full routing network that includes inaccessible service roads and footways,
it would be able to make the right decision and bring the car to the gate.


I agree that routers should consider inaccessible service roads more 
than they do now. However, this would not be a panacea. For one thing, 
if the router finds the nearest inaccessible service road to an airport 
centroid, more often than not, it will be along a vehicle service road 
(VSR) for ground support equipment, surrounded by taxiways or even runways.


Nominatim returns a centroid for the San Francisco International Airport 
that's about 80 meters from a VSR used only by airfield maintenance 
crews; this is the closest road. [1] The restricted entrance that most 
directly leads to the VSRs is almost 4 kilometers from the domestic 
terminal's front entrance. [2] (This is a real service road. Last week, 
from my armchair in Economy, I watched a maintenance vehicle wait at a 
stop sign on the VSR as my plane passed by.)


In more mundane cases, footways could definitely help a router send a 
ride-sharing driver directly to a drop-off point (albeit at the expense 
of a driver or cyclist needing to park their vehicle). This 
functionality is often lumped together with the idea of multimodal 
routing, but unlike true multimodal routing, it doesn't require looking 
up route schedules and timing transfers.



I'm not sure if there is any router around which does something even marginally
more clever than determining the closest road to the centroid. This even goes
as far as this:
https://www.openstreetmap.org/directions?engine=graphhopper_foot=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889
(starting point given as: "47, Rue du Rouet, Marseille")


Routers can only be more clever if they have more context. You gave an 
address to Nominatim, but all you ultimately gave to GraphHopper was a 
coordinate pair. For all GraphHopper knows, you need a route that begins 
on the Tunnel du Prado Carénage because you're already walking down that 
tunnel. (highway=trunk doesn't imply anything about foot=*.)


OSRM and Valhalla allow you to pass in a "bearing" that filters out 
candidate routes based on the initial direction. This would be useful if 
a driver or cyclist is in 

Re: [Tagging] navigational aid relation

[Florian Lohoff]

Hi Sarah,

On Thu, Jun 15, 2023 at 08:48:36PM +0200, Sarah Hoffmann via Tagging wrote:
> The initial examples of Florian are quite telling in that way. The
> closest road to
> https://osm.zz.de/dbview/?db=addresses-nrw=namemismatch#51.98796,8.57338,17z
> would in fact be the service way right next to the buildings. The fault
> is with the router who does not include non-accessible roads to
> determine the access and thus finds the wrong road. If it would create a
> full routing network that includes inaccessible service roads and footways,
> it would be able to make the right decision and bring the car to the gate.

But thats only one of hundrets of examples. One could imaging a thousand
ways of "fixing" this algorithmically in one or the other way, but in
the end all of this has its limitations and will work in one case, and
break horribly in others.

This is why i am "proposing" or trying to find some way to explicitly
make this available for mappers to hint this.

> That said, I do think it would be a good idea if Nominatim could return
> entrances for larger buildings or areas. That's why
> https://github.com/osm-search/Nominatim/issues/536 is still open.
> I would just draw the line where the geocoder needs to make any policy
> decisions like deciding which is the best entrance point, as this
> largely depends on the client's requirements. (It pretty much rules out
> the Mapbox approach which is biased towards vehicle routing.)

But its not like only "entrances" or something. As with the fire_station
within an industrial compound, the fire_station will have an entrance,
the industrial compound may have an entrance. So which one to return!? 

I cant image a "one algorithm fixes this all" way of dealing with the
issue.

> Maybe a separate service that computes navigation points for an OSM
> object wouldn't be such a bad idea. It might be easier to play around
> with heuristics based on micro-mapping using a separate software instead
> of trying to cram it into exising routers or geocoders which are optimised
> for other use cases.

Even if we find a 95% algorithm we let down our users in 5% of the
cases. 

And its not like "Finding the right spot". Sometimes POIs have multitude
of points. 

Like navigating to large industrial compound, you may a touristic visitor 
and like to be brought to the "Visitors Center". As a Truck Driver you
may want to brought to the "Goods Delivery Warehouse". As a customer you
may be navigated to the Main Office building.

There is no such thing as "Volkswagen Wolfsburg" - Thats a multitude of 
POIs. 

So i'd like to have a solution where i can "hint" or "fix" these issues
at once.

So i have a 1:n:m relation for

OSM Object -> Mode of Transport -> Locations to be navigated to.

And sometimes you intermediate change the mode of transport. So you say
i want to go to "Centro Oberhausen". A Menu pops up and shows "Car park
east" "Car park west" etc ... You choose a car park and get there. Then
you change mode of transport and continue by foot to the final location.


For the easy stuff like "Where is the entrance of Berlin Zoo" this might
be fixable algorithmically. But what if there are multiple entrances and 
some of them are only for disabled? Or one is for Pedestrians and one is
only by car?

So i envision something like 

Search for "Frankfurt Airport" - And whatever service returns the
additional objects returns

"Terminal 1 Arrival"
"Terminal 1 Departure"
"Terminal 2 Arrival"
"Terminal 2 Departure"
"Car park A"
"Car park B"
"Car park C"

The user may then choose the correct location.

When looking for the "Fire Station Mitsubishi Papers, Bielefeld" i simply
get "Mitsubishi Papers, Gate 1" or something to navigate to.

So - we have a multitude of issues where there is no "One location does
fit all" and i'd like a way to hint the correct/final destinations in
the process between geocoder and router.

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Peter Elderson]

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

>
> 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= - Optional
> source= - Original object we like to reach
> destination:motor_vehicle= - 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:" 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=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=
> source=
> destination=
>
> 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=namemismatch#52.1,8.6192,17z
>
> type=navaid
> source=
> destination=
>
> 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...@zz.de
>   Any sufficiently advanced technology is indistinguishable from magic.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Sebastian Gürtler]

Am 15.06.23 um 18:38 schrieb Minh Nguyen:

Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết:

You only would have to change the wiki page Key:entrance and encourage
people to allow single nodes with the tag entrance=yes and addr:xyz
(like this: https://www.openstreetmap.org/node/10979019687) if it is not
obvious where the entrance to the property is. (What happened before for
the whole row of houses you still can see if you plan a route to "Am
Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
any entrance nor the house due to a high hedge, and you sometimes see
people walking down the Voltmannstraße looking for entrances...
Difficult, because you would have to turn in "Am Rottmannshof" to get to
"Am Rehwinkel" ;-) )



In your example, the entrance is on Am Rehwinkel not only because the
address names Am Rehwinkel, but also because there's a hedge along
Voltmannstraße. Ideally, a geocoder would compute a visibility graph
to determine the most accessible street, blurring the lines between a
geocoder and a router.


The hedge is an older try to inform routers not to lead through it...
The tags entrance I just added a few hours ago after reading this
discussion. I omitted Am Rehwinkel 19 because I didn't know the exact
location of the entrance to the property - and to leave it for
illustrating the routing problems.

I assume that the local delivery services rely on routers that take the
nominatim data I really would like to leave it the way it is now. A
quick way to correct the routings, every other way (placing ways etc.
which you have to find and map) is more difficult. And if you look at
the surrounding you find a house "Voltmannstraße 97" whose access is
from "Am Rottmannshof" (as I remember, have to check that before
tagging...). There is really no way for any algorithm to find that out
if you don't give the clear information in the map data. This in fact no
big problem because people can look around the corner and find the
entrance...

Sebastian



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Sarah Hoffmann via Tagging]

On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:
> Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết:
> > You only would have to change the wiki page Key:entrance and encourage
> > people to allow single nodes with the tag entrance=yes and addr:xyz
> > (like this: https://www.openstreetmap.org/node/10979019687) if it is not
> > obvious where the entrance to the property is. (What happened before for
> > the whole row of houses you still can see if you plan a route to "Am
> > Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
> > any entrance nor the house due to a high hedge, and you sometimes see
> > people walking down the Voltmannstraße looking for entrances...
> > Difficult, because you would have to turn in "Am Rottmannshof" to get to
> > "Am Rehwinkel" ;-) )
> 
> I neglected to mention another common heuristic: the geocoder can
> automatically bias the address point toward the street named in addr:street
> when coming up with a navigable point. The Mapbox Geocoding API is an
> example of a geocoder that does this [1][2], though unfortunately neither
> Nominatim nor Pelias has a similar feature so far.

You need to remember that routers are only one kind of client of
Geocoders and certainly not the most important by far. While a nice
gimmick, I certainly wouldn't consider it a main task of a geocoder to
return a routeable point. The main task is to return the place/object you
were searching for. In that sense, the root of the issue is that
routers usually underspecify their search query. If the query is
'airport Frankfurt', then the airport is what the geocoder returns. One can't
expect the geocoder to determine that what you actually wanted is the
street closest to the main entrance or the parking or the main bus stop.
'parking near airport frankfurt' does yield results although we'd have
to do something about priority ordering.

> Essentially, even if the address point corresponds to a rooftop, it can
> figure out where the driveway entrance or freestanding mailbox is likely to
> be. Typically, this is pretty crude, just a matter of finding the point on
> the named street that's closest to the address point.
> 
> In your example, the entrance is on Am Rehwinkel not only because the
> address names Am Rehwinkel, but also because there's a hedge along
> Voltmannstraße. Ideally, a geocoder would compute a visibility graph to
> determine the most accessible street, blurring the lines between a geocoder
> and a router.
> 
> Then again, none of this complexity is necessary if OSM has a publicly
> accessible driveway or footpath leading right up to the building. A router
> should consider that driveway or footpath to be part of the most direct
> route.

Exactly. It would be kind of counter-productive to add all this
functionality to a geocoder. A good router has all the right
data structures to make an informed decision about the navigation start point
and also the information about mode of transport etc. A geocoder's
data structures are rather unsuitable to solve these examples.

The initial examples of Florian are quite telling in that way. The
closest road to
https://osm.zz.de/dbview/?db=addresses-nrw=namemismatch#51.98796,8.57338,17z
would in fact be the service way right next to the buildings. The fault
is with the router who does not include non-accessible roads to
determine the access and thus finds the wrong road. If it would create a
full routing network that includes inaccessible service roads and footways,
it would be able to make the right decision and bring the car to the gate.

I'm not sure if there is any router around which does something even marginally
more clever than determining the closest road to the centroid. This even goes
as far as this:
https://www.openstreetmap.org/directions?engine=graphhopper_foot=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889
(starting point given as: "47, Rue du Rouet, Marseille")

So there is a lot of room for improvement in the routers by just using
the information already available. Another example: the heuristic you mention
above, that the geocoder should bias the start point towards the street named
in address street, this is something that could be just as easily implemented
by routers when determining the start point. Street names are usually
available to them.

That said, I do think it would be a good idea if Nominatim could return
entrances for larger buildings or areas. That's why
https://github.com/osm-search/Nominatim/issues/536 is still open.
I would just draw the line where the geocoder needs to make any policy
decisions like deciding which is the best entrance point, as this
largely depends on the client's requirements. (It pretty much rules out
the Mapbox approach which is biased towards vehicle routing.)

Maybe a separate service that computes navigation points for an OSM
object wouldn't be such a bad idea. It might be easier to play around
with heuristics based on micro-mapping using a 

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết:

You only would have to change the wiki page Key:entrance and encourage
people to allow single nodes with the tag entrance=yes and addr:xyz
(like this: https://www.openstreetmap.org/node/10979019687) if it is not
obvious where the entrance to the property is. (What happened before for
the whole row of houses you still can see if you plan a route to "Am
Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
any entrance nor the house due to a high hedge, and you sometimes see
people walking down the Voltmannstraße looking for entrances...
Difficult, because you would have to turn in "Am Rottmannshof" to get to
"Am Rehwinkel" ;-) )


I neglected to mention another common heuristic: the geocoder can 
automatically bias the address point toward the street named in 
addr:street when coming up with a navigable point. The Mapbox Geocoding 
API is an example of a geocoder that does this [1][2], though 
unfortunately neither Nominatim nor Pelias has a similar feature so far.


Essentially, even if the address point corresponds to a rooftop, it can 
figure out where the driveway entrance or freestanding mailbox is likely 
to be. Typically, this is pretty crude, just a matter of finding the 
point on the named street that's closest to the address point.


In your example, the entrance is on Am Rehwinkel not only because the 
address names Am Rehwinkel, but also because there's a hedge along 
Voltmannstraße. Ideally, a geocoder would compute a visibility graph to 
determine the most accessible street, blurring the lines between a 
geocoder and a router.


Then again, none of this complexity is necessary if OSM has a publicly 
accessible driveway or footpath leading right up to the building. A 
router should consider that driveway or footpath to be part of the most 
direct route.


[1] https://docs.mapbox.com/api/search/geocoding/#forward-geocoding 
(search for "routing")
[2] 
https://github.com/mapbox/MapboxGeocoder.swift/blob/10c497840c9e1142194563f402ddc903310a935d/Sources/MapboxGeocoder/MBPlacemark.swift#L446


--
m...@nguyen.cincinnati.oh.us



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Sebastian Gürtler]

Hi there,

I just tried looking from the other perspective: Why is it so difficult
to extract proper routes from the osm data and what has already been tried.

I just looked over the the issues and some first-sight information on
github and have seen that we're facing two different problems here:

The first thing is to find the proper coordinates of the routing
destination (job of Nominatim:
https://github.com/osm-search/Nominatim/issues/536  Open issue since
2016 - the statement by lonvia that nominatim didn't take any entrance
information into account seems to be outdated).

The other thing is to find the appropriate route once you have found the
proper coordinates, which can be complicated if access rules block the
most suitable way.

The solution of the second problem could be via the first point: just
only try routing to a suitable public access point to the destination -
then you can give coordinates where you can do a routing to.

For the first problem it is quite already solved as nominatim returns
the coordinates of a simple node with entrance=yes and an addr:
information.

You only would have to change the wiki page Key:entrance and encourage
people to allow single nodes with the tag entrance=yes and addr:xyz
(like this: https://www.openstreetmap.org/node/10979019687) if it is not
obvious where the entrance to the property is. (What happened before for
the whole row of houses you still can see if you plan a route to "Am
Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
any entrance nor the house due to a high hedge, and you sometimes see
people walking down the Voltmannstraße looking for entrances...
Difficult, because you would have to turn in "Am Rottmannshof" to get to
"Am Rehwinkel" ;-) )

Maybe an easy solution would be just to use the access-tags here
possibly introduce some additional tags for "entrance". In some
situations this would be a wider sense of "entrance" (in this examples
at any place there is a gate, but it works even without the mapping of a
gate and is still correct in the narrow sense). But even without an
distinct entrance it could be some kind of an entrance if you have to
leave your vehicle and enter an area of another transport mode like
walking.

Greetings,

Sebastian

Am 15.06.23 um 09:34 schrieb Minh Nguyen:

Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết:

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 there is a need for geocoders to produce more
routing-friendly locations than the centroid. Navigable points are
nothing new in the field of location services. Most geocoders already
do this, including some that are often used with OSM-based maps,
although none are open source as far as I can tell.

I've written something of a white paper on the subject of navigable
points. [1] The short story is that most scenarios would be well
served by micromapping in OSM combined with some clever heuristics in
the geocoder, without the need for a new relation type. I've provided
some example OverpassQL queries to prove the concept, but in reality a
serious data consumer would perform spatial queries or traverse the
relation hierarchy more directly, without the help of a separate API.

With this heuristics-based approach, we can take advantage of the
large and growing body of data that's implicitly optimized for
routing. Mappers generally wouldn't have to familiarize themselves
with routing engines; they can just map what they observe, but in
greater detail.

When none of the heuristics applies, the last resort can be a site
relation, using each relation member's role to clarify why the
application might want to present the member as an option. I've used
site relations in a few cases where a spatial query won't turn up any
useful results.

For example, a nearby American football stadium [2] has multiple
parking lots, but all of them are off-site, on the grounds of an
amusement park, a college, and some office parks. A driver would only
be interested in the parking lot that corresponds to the ticket they
purchased. The parking lots are members of a site relation with the
stadium. [3] We have no hope of precisely modeling ticket classes in
OSM, but the application can simply list the lots by name and let the
user choose manually.

Unfortunately, I'm unaware of any OSM-based data consumer that
implements these heuristics, but routers aren't the only reason to map
building entrances or site relations.

[1]
https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen/Navigating_between_entrances
[2] https://www.openstreetmap.org/way/296503400
[3] https://www.openstreetmap.org/relation/14507813

Re: [Tagging] navigational aid relation

[Niels Elgaard Larsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jun 2023 19:08:11 +0200
Florian Lohoff  wrote:


>> 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.  
>
>This is an argument which is coming up all the time and nobody solved
>it yet. And IMHO this is unsolvable. There is no "one generalizing
>algorithm can solve this".

Agree, but there are things that could be generalized.
E.g., by using "entrance" tags or something similar on the perimeter.

Or route_to_here:motorist=yes, route_to_here:public_transport=yes on
nodes on the perimeter.

And then fall back to relations when e.g., you have an airport where the
terminal is not at the perimeter.


>> 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=55.6282%2C12.5998%3B55.6091%2C12.6510
>
>With this link you already are past the problem. There are
>geo-coordinates in them. Now its to late to correct the destination.


I know. That is why I mentioned the place names. As far as I know I
cannot make an URL with the place names in them.

If you go to https://www.openstreetmap.org/
press the "find direction" icon and put in 
"Tårnby" and "Copenhagen Airport", this is what you get.



>The process is 
>
>- Geocode something
>- Get a geo coordinate - possibly an object
>- Get the "nearest coordinate on the routable network" for that geo
>  coordinate from the POI
>- Route to the geo coordinate on the road network.
>
>Now - We get a geo coordinate for "Frankfurt Airport" which is the
>centroid of the object with the name "Frankfurt Airport" which is the
>WHOLE of the collection of the airport.
>
>Now we call "nearest" and just by pure luck we possibly get a good
>geo coordinate on the road network.
>
>And by Example 2 i posted you see - this breaks all the time at much
>simpler setups. And for the corporate fire station there is no "gate"
>or "entrance". Yeah - the fire_station has an entrance, but thats
>equally broken. It enclosed in an industrial landuse or a
>man_made=works. That centroid may also be completely off.
>
>Try routing to
>
>
>Class poi - Large "Polygon POI" - random location to end up:
>
>"Frankfurt Airport" (South of Airport on a perimeter Road)
>"Flughafen Paderborn" (North of Airport in the Woords)
>"Claas, Harsewinkel" (Gate 3, instead Gate 1)
>"Miele, Gütersloh" (On a higher class road next to their warehouse,
>rail inbetween) "Generalfeldmarschall-Rommel-Kaserne" (Road next to
>the fence, 2km from the entrance) "Zoo Berlin" (On the opposite side
>of the Zoo than the parking) "Tagebau Garzweiler" (Somewhere on a
>track near the big dig)
>
>Addresses with long distance to the road network. The next road is
>basically a dead-end for this address:
>
>"45883 Gelsenkirchen, Grothusstraße 199" (On the other side of the
>Canal) "45357 Essen, Klaumerbruch 40a" (On the other side of the Canal)
>"46535 Dinslaken, Am Alten Drahtwerk 27" (On the other side of a rail
>track)
>
>
>So take any large polygon POI in your vicinity and try routing there.
>80% of them are broken. And this is not algorithmically solvable.
>
>Flo

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQTFiAV7M5dCBbueFnXaxL9tj5Q+NAUCZIrTgwAKCRDaxL9tj5Q+
NIUqAKDQOCJs0Y3gkocDyxV5JjdzRgZUqACgnnLZYrBDYb5zBgu9qr4lRwDbTuQ=
=210l
-END PGP SIGNATURE-
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Minh Nguyen]

Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết:

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 there is a need for geocoders to produce more 
routing-friendly locations than the centroid. Navigable points are 
nothing new in the field of location services. Most geocoders already do 
this, including some that are often used with OSM-based maps, although 
none are open source as far as I can tell.


I've written something of a white paper on the subject of navigable 
points. [1] The short story is that most scenarios would be well served 
by micromapping in OSM combined with some clever heuristics in the 
geocoder, without the need for a new relation type. I've provided some 
example OverpassQL queries to prove the concept, but in reality a 
serious data consumer would perform spatial queries or traverse the 
relation hierarchy more directly, without the help of a separate API.


With this heuristics-based approach, we can take advantage of the large 
and growing body of data that's implicitly optimized for routing. 
Mappers generally wouldn't have to familiarize themselves with routing 
engines; they can just map what they observe, but in greater detail.


When none of the heuristics applies, the last resort can be a site 
relation, using each relation member's role to clarify why the 
application might want to present the member as an option. I've used 
site relations in a few cases where a spatial query won't turn up any 
useful results.


For example, a nearby American football stadium [2] has multiple parking 
lots, but all of them are off-site, on the grounds of an amusement park, 
a college, and some office parks. A driver would only be interested in 
the parking lot that corresponds to the ticket they purchased. The 
parking lots are members of a site relation with the stadium. [3] We 
have no hope of precisely modeling ticket classes in OSM, but the 
application can simply list the lots by name and let the user choose 
manually.


Unfortunately, I'm unaware of any OSM-based data consumer that 
implements these heuristics, but routers aren't the only reason to map 
building entrances or site relations.


[1] 
https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen/Navigating_between_entrances

[2] https://www.openstreetmap.org/way/296503400
[3] https://www.openstreetmap.org/relation/14507813

--
m...@nguyen.cincinnati.oh.us



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Marc_marc]

Le 14.06.23 à 19:08, Florian Lohoff a écrit :

the centroid of the object



this is not algorithmically solvable.


you state the problem that makes the algorithm bad :)
when you want to go to a surface object, you don't want
to go to the centroid

for surface objects, take :
- all entrance=* objects on the outer with priority given to main 
entrances (and parking if you're in vehicle mode)

- if there are none, take the intersection with all highway=*
- classify these itineraries as any other (fastest, shortest, ...)



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Marc_marc]

Le 14.06.23 à 09:26, Florian Lohoff a écrit :

source= - Original object we like to reach


not source=* !  we  already have 3 meanings for it :
- how was the data acquired (for ex source=survey)
- the context of a data (for ex source:maxspeed=urban)
- the primary energy (for ex generator:source=solar)

maybe for=* / destination=*

your idea could be used for POIs where the parking lot isn't
in front of the door

but if your house is marked with a path to the door, it's obvious
that this is the path that should be proposed and any 
"not-using-an-existing-highway=*" should have a gig penality to be used only

when the last highway=* is missing

for the example 1 you give seems to me to be more of a problem
1) misuse of the private tag: not only can you walk past the barrier, 
but if you want people to go to the barrier and then continue by car to 
their destination, then it would probably be better to put 
motor_vehicle=destination in the way

2) penalty for no highway=* too low: crossing the forest should
be much more penalizing than using the private road.
3) bad penality for =destination and =private
https://www.openstreetmap.org/directions?engine=graphhopper_car=51.98881%2C8.57457%3B51.98836%2C8.57434#map=16/51.9898/8.5832
very fun... but i didn't see why the routing do that



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Florian Lohoff]

On Wed, Jun 14, 2023 at 03:50:02PM +0200, Niels Elgaard Larsen 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.

This is an argument which is coming up all the time and nobody solved it
yet. And IMHO this is unsolvable. There is no "one generalizing
algorithm can solve this".

We need to have a non-algorithmic approach to make the destination
explicit.

> 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=55.6282%2C12.5998%3B55.6091%2C12.6510

With this link you already are past the problem. There are
geo-coordinates in them. Now its to late to correct the destination.

The process is 

- Geocode something
- Get a geo coordinate - possibly an object
- Get the "nearest coordinate on the routable network" for that geo
  coordinate from the POI
- Route to the geo coordinate on the road network.

Now - We get a geo coordinate for "Frankfurt Airport" which is the
centroid of the object with the name "Frankfurt Airport" which is the
WHOLE of the collection of the airport.

Now we call "nearest" and just by pure luck we possibly get a good
geo coordinate on the road network.

And by Example 2 i posted you see - this breaks all the time at much
simpler setups. And for the corporate fire station there is no "gate" or
"entrance". Yeah - the fire_station has an entrance, but thats equally
broken. It enclosed in an industrial landuse or a man_made=works. That
centroid may also be completely off.

Try routing to


Class poi - Large "Polygon POI" - random location to end up:

"Frankfurt Airport" (South of Airport on a perimeter Road)
"Flughafen Paderborn" (North of Airport in the Woords)
"Claas, Harsewinkel" (Gate 3, instead Gate 1)
"Miele, Gütersloh" (On a higher class road next to their warehouse, rail 
inbetween)
"Generalfeldmarschall-Rommel-Kaserne" (Road next to the fence, 2km from the 
entrance)
"Zoo Berlin" (On the opposite side of the Zoo than the parking)
"Tagebau Garzweiler" (Somewhere on a track near the big dig)

Addresses with long distance to the road network. The next road is
basically a dead-end for this address:

"45883 Gelsenkirchen, Grothusstraße 199" (On the other side of the Canal)
"45357 Essen, Klaumerbruch 40a" (On the other side of the Canal)
"46535 Dinslaken, Am Alten Drahtwerk 27" (On the other side of a rail track)


So take any large polygon POI in your vicinity and try routing there.
80% of them are broken. And this is not algorithmically solvable.

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Florian Lohoff]

On Wed, Jun 14, 2023 at 09:47:28AM +0200, Frederik Ramm wrote:
> Hi,
> 
> "navaid" may not be the best term since it is used in aviation for actual
> physical installations that help with navigations, like radio beacons or
> lights.

Yeah - i know - call it "navigational_hint" or something. 
 
> I am also concerned about the verifiability; is there not a danger that
> people will disagree about what the "best" way is to reach something?
 
I am open to anything which solves the issue. With more and better data
more of these problems crop up that we, be having only a very
rudimentary generalized approach to mapping pois/addresses to the road
network, make pretty broken assumptions.

So sooner than later we need a more fine-grained controlled approach to 
letting the navigation know where to get us to.

> Have you considered to, instead of using a relation that links sources and
> destinations (and btw I'd swap the terms in your examples) simply placing a
> node on the street network that is tagged as an "access point" for a certain
> address, without the relation and all?

The issue is - do i replicate the POIs information or the Address to the
node on the road network. How do i tell the automatism to prefer the
node on the road network?

I am open to a solution.

In 2019 i had further examples e.g. for big malls which have multiple
parking lots we may have more than one relation - So you search for
e.g. "Frankfurt Airport" and a Menu pops up shows you 
"Parking lot A", "Parking lot B" as destinations for going to "Frankfurt
Airport". This is why i wanted a "name" in the relation.

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Sebastian Gürtler]

Am 14.06.23 um 09:47 schrieb Frederik Ramm:

Hi,

"navaid" may not be the best term since it is used in aviation for
actual physical installations that help with navigations, like radio
beacons or lights.

I am also concerned about the verifiability; is there not a danger
that people will disagree about what the "best" way is to reach
something?


Hi there,

I'm not thinking about anything that would have to be used in every
address, but in cases where there are really wrong routings.

I live at a place where increasingly people (craftsmen, delivery
services) don't find our address because the building is closer to
another street than to the street with the entrance. And there is no
possibility to get to the house from this other street. In this case it
is a very easily verifiable information. Go to the street with the
correct name, look for the correct house number and see the entrance.
This is in this case the "best" way to reach it (and in this case the
only way).

But this matching of street name and routing is not easily done from the
OSM-data, and not done by any routing application based on osm at all.
(I guess google maps uses additional information about the "best point",
not available in osm). And: there are cases where the access is not from
the street of the address. (Usually you have signs like "for xyzstreet
5-7 use entrance from abcstreet", sometimes a little map).


Have you considered to, instead of using a relation that links sources
and destinations (and btw I'd swap the terms in your examples) simply
placing a node on the street network that is tagged as an "access
point" for a certain address, without the relation and all?


IMHO that could be a possibility, allowing for the use of the addr:xyz
tags on points of a highway. But that could result in several very close
points for places, where you can reach several addresses from just
single point of the highway, eg. terraced houses.

Greetings

Sebastian



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Snusmumriken]

On Wed, 2023-06-14 at 09:26 +0200, Florian Lohoff 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.

Please have a look at 
https://wiki.openstreetmap.org/wiki/Proposal:Provides_feature

Would that solve some of the issues you mention? Also note that the
list of roles is open-ended 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Niels Elgaard Larsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jun 2023 09:26:43 +0200
Florian Lohoff  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=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= - Optional
>   source= - Original object we like to reach
>   destination:motor_vehicle= - 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:" 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=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=
>   source=
>   destination=
>
>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=namemismatch#52.1,8.6192,17z
>
>   type=navaid
>   source=
>   destination=
>
>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

Re: [Tagging] navigational aid relation

[Frederik Ramm]

Hi,

"navaid" may not be the best term since it is used in aviation for 
actual physical installations that help with navigations, like radio 
beacons or lights.


I am also concerned about the verifiability; is there not a danger that 
people will disagree about what the "best" way is to reach something?


Have you considered to, instead of using a relation that links sources 
and destinations (and btw I'd swap the terms in your examples) simply 
placing a node on the street network that is tagged as an "access point" 
for a certain address, without the relation and all?


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging