Re: [Tagging] What separator do you use for multiple value

[Simon Poole]

Am 14.06.2023 um 11:26 schrieb Martin Koppenhoefer:
...for housenumbers periods are an alternative to semicolons. 
You probably wanted to write "commas", periods are not in use as 
separators for house numbers. See 
https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers


OpenPGP_signature
Description: OpenPGP digital signature
___
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 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] What separator do you use for multiple value

[Martin Koppenhoefer]

sent from a phone

> On 15 Jun 2023, at 09:41, Simon Poole  wrote:
> 
> 
>> Am 14.06.2023 um 11:26 schrieb Martin Koppenhoefer:
>> ...for housenumbers periods are an alternative to semicolons. 
> You probably wanted to write "commas", periods are not in use as separators 
> for house numbers. See 
> https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers
> 


yes indeed wanted to write commas, thank you for correcting, 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Andy Townsend]

On 15/06/2023 20:47, Jez Nicholson wrote:
Whilst it is a great idea to capture local knowledge about flooding, 
especially where it is currently not available, I am concerned that 
this doesn't have on-the-ground verification.


I don't think that anyone has suggested that - at least not in this thread?

The original email said "The location and extent of these hazard areas 
is often well known by local communities with knowledge of past events."


When I talked about "what is currently flooded based on current measured 
level and previous observations"I meant exactly that - recording that 
when a river level at a known point reads X, land at Y (in the vicinity 
of X) will also be flooded.




Flood risk areas are predictions generated via modelling software and 
it depends on which software you use, and the quality of the input data.


Indeed - the Environment Agency in the UK (and other agencies elsewhere) 
make extensive use of this sort of model, but I suspect that mapping 
this sort of thing goes  bit beyond what can usefully done within OSM, 
though of course it can be combined with OSM data by a data consumer to 
create "risk maps".




The current hazardous areas get away with it by mapping areas marked 
out by signage. Sure, the signs may have been placed following 
predictions, but they are physically there to be seen.


I suspect that this isn't true for all "boundary=hazard" in OSM at the 
moment (picking one at random, the signage for 
https://www.openstreetmap.org/way/500428513 and the wider 
https://www.openstreetmap.org/relation/15680620 doesn't look especially 
extensive - see 
https://www.abc.net.au/radio/programs/australia-wide/australia-wide/13490888#:~:text=Wittenoom%20is%20the%20largest%20contaminated,site%20in%20Western%20Australia%27s%20Pilbara. 
)


Best Regards,

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

[Tagging] [Voting] Level crossing train horn usage

[Clay Smalley]

Voting has started on the proposal to introduce the key crossing:whistle=*.

Please vote on the wiki page
https://wiki.openstreetmap.org/wiki/Proposal:Level_crossing_train_horn_usage

(posted here by request of UrbanUnPlanner in
https://community.openstreetmap.org/t/voting-feature-proposal-level-crossing-train-horn-usage-quiet-zones-whistle-bans/100171
)
___
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

[Tagging] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Cornelia Scholz via Tagging]

Dear all,

I would like to propose to add* 'flood'* as value to the *key 'hazard'* (to
be used in combination with the tag* boundary=hazard*).

Proposal:

Hazard =flood would be used
in combination with boundary=hazard


Area hazards are a sub-group of the values of the key:hazard
 (Proposal
) which
apply to areas already tagged as boundary=hazard. For area hazards of
natural hazards the tags hazard=avalanche
 and
hazard=quicksand
 already
exist. What is currently missing is an option to tag an area hazard as
flood hazard. Therefore, the proposed tag hazard=flood is an addition to
the existing and approved tag boundary=hazard to allow to tag flood hazard
areas.

Rationale:

The intended use of the tag hazard=flood for area hazards is to map areas
where floods  (an overflow of water
that submerges land that is usually dry) occur. The location and extent of
these hazard areas is often well known by local communities with knowledge
of past events. Alternatively, NGOs and national agencies can sometimes
provide information on hazard areas but capturing and mapping community
knowledge of flood occurrences is the preferred use case. The potential use
of the data includes supporting exposure analysis of flood hazards for
disaster risk reduction programs, raising awareness of flood risks,
supporting project plannings of NGOs and local authorities and providing
information on routing in case of flooding.

A valuable addition to the tag would be to add information on the
recurrence of flood extent (return period). The  OpenHazardMap
 suggest following
classification, which is tailored to capture community knowledge:

   -

   < 3 years: any hazard that occurs almost every year (seasonal flood,
   spring avalanche...). Those are very well-known from communities, as they
   impact there life and activities every year)
   -

   3 - 50 years: any hazard that occurs more than once in a lifetime
   -

   > 50 years: any hazard that happens once (or less in a lifetime)

What already exists is the key  flood_prone
=* which is mainly for
roads that are known to be flooded frequently. The mapping descriptions
include instructions for mapping flood prone waterway crossings, bridges,
and highways. However, it is not intended to tag areas, which would be
covered by the proposed new tag of hazard=flood for areas tagged as
boundary=hazard.

The discussed but not approved OpenHazardMap
 project was reviewed as
well. However, since this project suggests introducing a row of entirely
new tags, it was suggestedto rather add a tag hazard=flood to the already
existing and approved key:hazard and boundary=hazard and align with the
existing tags of natural hazards (hazard=avalanche; hazard=quicksand).


Please let me know your thoughts!

Kind regards,

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

Re: [Tagging] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Andy Townsend]

On 15/06/2023 16:59, Cornelia Scholz via Tagging wrote:

Dear all,

I would like to propose to add*'flood'* as value to the *key 'hazard'* 
(to be used in combination with the tag*boundary=hazard*).



...
What already exists is the key flood_prone 
=*which is mainly 
for roads that are known to be flooded frequently. The mapping 
descriptions include instructions for mapping flood prone waterway 
crossings, bridges, and highways. However, it is not intended to tag 
areas, which would be covered by the proposed new tag of hazard=flood 
for areas tagged as boundary=hazard.


Hello,

flood_prone=yes on areas does actually get a reasonable amount of use:

https://overpass-turbo.eu/s/1w7k

(about 3000 worldwide)

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dhazard has much less use

https://overpass-turbo.eu/s/1w7l

and seems so far been restricted to "fixed" areas such as (clicking at 
random)


 * A shooting range: https://www.openstreetmap.org/way/1149857565
 * An explosives depot: https://www.openstreetmap.org/way/1166217800

hazard=flooding is used, but mostly on hghways:

https://overpass-turbo.eu/s/1w7m

I'd suggest exploring taginfo (and the overpass links from it) to see 
what keys and values are in use already.  There may well be a use case 
for some new key/value, but I'm not convinced yet.  See e.g. 
https://taginfo.openstreetmap.org/keys/hazard#values and filter the 
various values.


Is "OpenHazardMap" an actual map or just a wiki page?  I ask because I 
live somewhere where river flooding is a thing (although usually of very 
low impact in terms of people or property) and I have created maps of 
"what is currently flooded" based on current measured level and previous 
observations.  See 
https://www.openstreetmap.org/user/SomeoneElse/diary/398374 .


Best Regards,

Andy




___
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

[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

[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

[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] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Jez Nicholson]

Whilst it is a great idea to capture local knowledge about flooding,
especially where it is currently not available, I am concerned that this
doesn't have on-the-ground verification.

Flood risk areas are predictions generated via modelling software and it
depends on which software you use, and the quality of the input data.

The current hazardous areas get away with it by mapping areas marked out by
signage. Sure, the signs may have been placed following predictions, but
they are physically there to be seen.


On Thu, 15 Jun 2023, 18:25 Andy Townsend,  wrote:

> On 15/06/2023 16:59, Cornelia Scholz via Tagging wrote:
>
> Dear all,
>
> I would like to propose to add* 'flood'* as value to the *key 'hazard'*
> (to be used in combination with the tag* boundary=hazard*).
>
> ...
>
> What already exists is the key  flood_prone
> =* which is mainly
> for roads that are known to be flooded frequently. The mapping descriptions
> include instructions for mapping flood prone waterway crossings, bridges,
> and highways. However, it is not intended to tag areas, which would be
> covered by the proposed new tag of hazard=flood for areas tagged as
> boundary=hazard.
>
> Hello,
>
> flood_prone=yes on areas does actually get a reasonable amount of use:
>
> https://overpass-turbo.eu/s/1w7k
>
> (about 3000 worldwide)
>
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dhazard has much less
> use
>
> https://overpass-turbo.eu/s/1w7l
>
> and seems so far been restricted to "fixed" areas such as (clicking at
> random)
>
>- A shooting range: https://www.openstreetmap.org/way/1149857565
>- An explosives depot: https://www.openstreetmap.org/way/1166217800
>
> hazard=flooding is used, but mostly on hghways:
>
> https://overpass-turbo.eu/s/1w7m
>
> I'd suggest exploring taginfo (and the overpass links from it) to see what
> keys and values are in use already.  There may well be a use case for some
> new key/value, but I'm not convinced yet.  See e.g.
> https://taginfo.openstreetmap.org/keys/hazard#values and filter the
> various values.
>
> Is "OpenHazardMap" an actual map or just a wiki page?  I ask because I
> live somewhere where river flooding is a thing (although usually of very
> low impact in terms of people or property) and I have created maps of "what
> is currently flooded" based on current measured level and previous
> observations.  See
> https://www.openstreetmap.org/user/SomeoneElse/diary/398374 .
>
> Best Regards,
>
> Andy
>
>
>
>
>
> ___
> 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

[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