Re: [Tagging] Rare route values route=inline_skates and route=running

[Sarah Hoffmann]

On Sat, Jan 11, 2020 at 02:21:50PM +0900, Joseph Eisenberg wrote:
> The tag  route=inline_skates was added to Map features, but it has
> only been added a few times in the past 4 years.
> 
> Are there actually signed, verifiable inline skate routes?

Yes, Switzerland has a whole network of those. See:
https://skating.waymarkedtrails.org/#routelist

And the Netherlands have started a network as well:
https://skating.waymarkedtrails.org/#routelist?map=13!51.9615!4.3303

Sarah

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

Re: [Tagging] Rare route values route=inline_skates and route=running

[Peter Elderson]

For Nederland: yes and yes.
Vr gr Peter Elderson


Op za 11 jan. 2020 om 06:23 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> The tag  route=inline_skates was added to Map features, but it has
> only been added a few times in the past 4 years.
>
> Are there actually signed, verifiable inline skate routes?
>
> Should a rare tag like this be in Map Features?
>
> Similar questions about route=running - are there real, signed running
> routes which are separate from walking or hiking routes?
>
> - Joseph Eisenberg
>
> ___
> 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] How to tag oneway restriction applying to pedestrians?

[Volker Schmidt]

On Thu, 9 Jan 2020, 22:04 Dave F via Tagging, 
wrote:

> On 09/01/2020 20:17, Volker Schmidt wrote:
> > oneway=yes|no needs indeed be applicable to vehicles only,
>
> That tag on footways would apply only to walkers.
>
> DaveF
>

... and what about all the roads that either have no separate sidewalks or
do not yet have them mapped, or all the mixed foot-cycle paths? We talk
hundreds of thousands of ways here.

>
>
> ___
> 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] amenity=vending_machine/vending=bottle_return - operator=

[Jake Edmonds via Tagging]

Is the different between recycling and reusing important for the average 
consumer who a) wants to claim their deposit and b)  doesn’t want to put the 
item into landfill? 

Even schemes designed to reused containers have a limit on the number of 
reuses, the container I return might be on it’s first use or it’s thirtieth use.


> On 10 Jan 2020, at 23:19, Graeme Fitzpatrick  wrote:
> 
> 
> 
> On Fri, 10 Jan 2020 at 18:55, Martin Koppenhoefer  > wrote:
> 
> Am Fr., 10. Jan. 2020 um 08:58 Uhr schrieb Marc Gemis  >:
> > amenity=reverse_vending_machine
> > reverse_vending=bottle_return
> >
> > Machines may take more than one type of item. Some here take bottles and 
> > bottle creates. Some take metal cans.
> 
> sometimes (e.g. common typology in German shops) you can add both, plastic 
> bottles for recycling and reusable bottles in plastic or glass (but usually 
> not bottles in glass for recycling) into the same "machine" (which will often 
> just be a conveyor belt with a scanner and a receipt printer, while sorting 
> takes place manually behind the curtain). Other machines are only for plastic 
> bottles for recycling and they will crush the bottles to reduce space 
> requirements. I have never seen a machine that accepts glass bottles for 
> recycling (but maybe they exist somewhere),
> 
> They certainly do! Here you go: 
> https://www.mytomra.com.au/home/qld-containers-for-change/ 
> 
> 
>   Thanks
> 
> Graeme
> ___
> 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] Rare route=* values - route=power

[Warin]

On 11/1/20 4:19 pm, Joseph Eisenberg wrote:

Who is using route=power?

It has no documentation except for a rather confusing Proposal page
(https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal/Tagging_similar_to_Transportation_routes)
but it's used 15,000 times.


Only used is very small parts of the world - as seen on taginfo map.
https://taginfo.openstreetmap.org/tags/route=power#map

For contrast there are over 500,000 power=line in the data base,
and the use is world wide..
https://taginfo.openstreetmap.org/tags/power=line#map




Is this feature actually useful and verifiable?


Not usefull.

Verifiable? As in there are power lines there, yes.

However I view them similar to roads .. there maybe a power line there .. but 
'traffic' can be in both directions.

I see no point in having a dedicated 'route' for power.




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

[Tagging] Correct use of height with kerb

[Alessandro Sarretta]

Dear all,

I'm doing some work cleaning the edits we've done around Padova for the 
local plan for the elimination of architectural barriers (some 
references here: https://doi.org/10.5281/zenodo.3370704).


The height of kerbs, in this context defined as the nodes at the 
intersection between sidewalks and crossings, is quite an important 
element for the evaluation of accessibility of sidewalks and crossings. 
I think the agreed tagging system is:


kerb=yes/lowered/raised/flush + kerb:height=

as described here 
https://wiki.openstreetmap.org/wiki/Key:kerb#kerb:height.3D.3Cheight.3E.3Cunit.3E


Around Padova I found some inconsistencies that I'm going to correct, 
but I see similar ones around the world and I'd like to ask you if you 
think they should be corrected, when found.


Here the questions:

 * should the tag barrier=kerb be always avoided in these cases and
   deleted when found? (
   
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb#Possible_Tagging_Mistakes
   )
 * is the tag height=* to be always changed into kerb:height=* ?

Thank you,

Ale

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

Re: [Tagging] Rare route values route=inline_skates and route=running

[Graeme Fitzpatrick]

On Sat, 11 Jan 2020 at 15:23, Joseph Eisenberg 
wrote:

>
> Similar questions about route=running - are there real, signed running
> routes which are separate from walking or hiking routes?
>

Sort of, perhaps? :-)

Have a look at:
https://www.google.com/maps/@-28.0710528,153.44337,3a,28.5y,165.88h,77.38t/data=!3m7!1e1!3m5!1sCZTxZjp282QBbbNHHJpVGA!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3DCZTxZjp282QBbbNHHJpVGA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D137.41283%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656


The blue dashed lines up the middle of the traffic lanes show the route for
the annual Marathon, down then back up on the return leg.

& runners are expected to stay in their lane!

Don't know if this would count as a marked running route?

  Thanks

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

[Tagging] Rare route values route=inline_skates and route=running

[Joseph Eisenberg]

The tag  route=inline_skates was added to Map features, but it has
only been added a few times in the past 4 years.

Are there actually signed, verifiable inline skate routes?

Should a rare tag like this be in Map Features?

Similar questions about route=running - are there real, signed running
routes which are separate from walking or hiking routes?

- Joseph Eisenberg

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

[Tagging] Rare route=* values - route=power

[Joseph Eisenberg]

Who is using route=power?

It has no documentation except for a rather confusing Proposal page
(https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal/Tagging_similar_to_Transportation_routes)
but it's used 15,000 times.

Is this feature actually useful and verifiable?

- Joseph Eisenberg

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

[Tagging] Addition of amenity=conference_center to Map Features page

[Joseph Eisenberg]

Another wiki user recently added amenity=conference_center to the list
of Map Features, with the description "A large building that is
designed to hold a convention".

The linked wiki page, made in January 2015, says "A conference centre
(convention center - American English) is a large building used to
hold a convention, where individuals and groups gather to promote and
share common interests. Convention centers typically offer sufficient
floor area to accommodate several thousand attendees. Some large
hotels include a conference center"

This tag has been used a little over 1000 times, and it is distributed
in a number of different countries and continents. It was already used
100 times back in 2011 and has slowly increased, according to
https://taghistory.raifer.tech.

Is there any issue with this tag? Should it be added to Map Features?

- Joseph Eisenberg

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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Jarek Piórkowski]

On Fri, 10 Jan 2020 at 18:04, Florian Lohoff  wrote:
> On Fri, Jan 10, 2020 at 09:34:32AM -0500, Jarek Piórkowski wrote:
> > On Fri, 10 Jan 2020 at 04:22, Florian Lohoff  wrote:
> > > OTOH in the dense urban areas you have the problem of Address for road A
> > > nearer to Road B. So you get navigated to the wrong spot on the road
> > > network. This view is generated with the OSRM Car profile and mapping
> > > all addr:* objects with the "nearest" function and comparing the highway
> > > name and the addr:street. If both are "filled" and non equal -> fail.
> > >
> > > https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z
> >
> > In the case of Cheruskerstraße 107g it looks like by far the easiest
> > way to solve it is for the router to take footways into account. Or I
> > guess we could create a new tag for "motor vehicle stop location to
> > get to a given address" to work around router shortcomings...?
>
> How can a router take footways into account when your mode of transport
> is by car? Can it take ALL footways in the routing graph? Only some?
> Which?

I guess it could be only those footways that change which motor
vehicle road is nearest to a given destination. That is, ignore most
sidewalks.

--

I was thinking about this whole thing earlier. Caution, wall of text.

At the risk of being philosophical, what is an address exactly?

Our wiki doesn't specify which address we're talking about:

1. Where lettermail is delivered?
2. Where a package or a shipment of a given size is delivered?
3. Where a vehicle of a given type making the delivery would stop?
4. Where a pizza is delivered?
5. Where a vehicle of a given type making the pizza delivery would stop?
6. Where emergency responders go?
7. What a government says?

In the specific case of Cheruskerstraße 107g in Bielefeld given above,
I'm guessing (with some familiarity with German urban built form, but
not the specific area): #2, #4, #6 are a front door of the building
tagged with the address; #1 might be away from that front door; #3 and
#5 are probably along Cheruskerstr. about 80 m away or maybe in the
little parking lot near the intersection with Auf den Köppen; #7 is
unknown - if that complex is a condominium or similar structure, 107g
might not even exist as far as land registry is concerned.

In some regions, land plots are identified by addresses (that is,
owners are registered with a cadastral authority or a land registry as
owning a piece of land identified as 123 Main Street). Given enough
data with a suitable licence, we could have each land plot as a way
and tag it with the address. These land plots might have zero, one, or
more buildings on it. In some regions, some of these buildings are
commonly identified as having the same address, some (like garages or
sheds) usually not. The boundaries of the building are often more
verifiable than the boundaries of the land plot, because they are more
reliably seen on satellite imagery.

In some regions, cadastral registries do not identify plots with
addresses but with other schemes.

In another definition, an address is somewhere where the local mail
service (or sometimes competitive mail services) delivers lettermail.
In some regions this is usually near a building, a mailbox attached to
the building itself, or a mail slot in the building door. In some
other regions, this is usually a mailbox near the nearest public road
to the building, and some yet other regions have community mailboxes,
so the lettermail or small package delivery location is quite far away
from where the people receiving this mail actually live.

Some buildings have more than one postal address. I suppose there are
also cases of buildings that occupy more than one legal land plot. And
of course there are addresses that might have mailboxes or accept
deliveries but not actually have a building associated with that
address.

In cases where land plots are identified by addresses, the cadastral
address might not match the postal address (due to drift of
definitions over time like the London post town or the Ontario
municipal amalgamations, or just straight-up database errors, or
inconsistencies: Canada Post and City of Toronto don't agree on
spelling of several street names).

There are also deliveries, such as packages, larger shipments, or food
delivery. They don't necessarily go the same location as the
lettermail mailbox. In some cases a motor vehicle will stop as close
as you can to the door and deliver; in other cases there are explicit
systems of driveways and loading docks often quite far away from main
entrances or mailboxes. In some cases, the locally prescribed way of
making a delivery is to use a designated delivery parking area and
deliver the last meters on foot or with a cargo trolley. You might
want to know both where to park a vehicle and where the receiver's
door is. Then there's increasingly different kinds of delivery
vehicles, some with different legal access rights ("zero emission

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 09:34:32AM -0500, Jarek Piórkowski wrote:
> On Fri, 10 Jan 2020 at 04:22, Florian Lohoff  wrote:
> > OTOH in the dense urban areas you have the problem of Address for road A
> > nearer to Road B. So you get navigated to the wrong spot on the road
> > network. This view is generated with the OSRM Car profile and mapping
> > all addr:* objects with the "nearest" function and comparing the highway
> > name and the addr:street. If both are "filled" and non equal -> fail.
> >
> > https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z
> 
> In the example of Cheruskerstraße 125a, how is it actually reached?
> Esri satellite imagery seems to suggest it's actually reached from Zum
> Alten Hammer. The tool flags this as a problem because of street name
> mismatch but it actually appears correct.
> 
> In the case of Cheruskerstraße 107g it looks like by far the easiest
> way to solve it is for the router to take footways into account. Or I
> guess we could create a new tag for "motor vehicle stop location to
> get to a given address" to work around router shortcomings...?

How can a router take footways into account when your mode of transport
is by car? Can it take ALL footways in the routing graph? Only some?
Which?

> Same with your later example of bicycle routing not checking for
> barriers like rivers and removing ways with access=private. That seems
> a lot easier to fix with software than by reorganizing the database.
> But then I'm not a router developer.

The processing of finding a point on the routeable network is a spatial
"nearest". I know if no nav solution which does something more
sophisticated. I'd like to be proven wrong.

And access=private has the mapper say - "This highway is NOT for general
consumption" so it is the correct processing in excluding this way from
routing. And i have heard this argument a hundret times. If you
take access=private into routing you break a gazillion of other cases
where the mapper explicitly wanted to exclude this way from routing.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 04:10:36PM +0100, Martin Koppenhoefer wrote:
> it is already linked spatially. What you have to do is map the campsite as
> area and map the reception within this area. Similarly for the parkings.
> Routing software should solve this contextually. If I am walking I want to
> be led to the main entrance (or given the choice which entrance), while
> when I am driving I will typically want a parking. A parking must not
> necessarily be inside the area, it can also be close by.

The point is there are literally thousands of possibilities and they may
even differ based on mode of transport. You go to point A by Foot, B if
on a Bike, C if using Car and D if you are in a HGV. 

Think of Ferry Terminal.

And for a single mode of transport you may even offer multiple destinations.  

So

- Mall A by Car and you get offered Parking North and Parking West
- Mall A by Bike you get offered the Bicycle Parking
- Mall A by Foot and you get offered the different entrances.

And i have literally thousands of buildings in my surrounding which fail
because they belong to street A, and have their parking on street A and
a footway to the entrance. Still they are nearest to street B. So anyone
routing there by car will end up on street B.
There is no way you'll be able to solve this by a spatial relation.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Fwd: amenity=vending_machine/vending=bottle_return - operator=

[Graeme Fitzpatrick]

On Fri, 10 Jan 2020 at 18:55, Martin Koppenhoefer 
wrote:

>
> Am Fr., 10. Jan. 2020 um 08:58 Uhr schrieb Marc Gemis <
> marc.ge...@gmail.com>:
>
>> > amenity=reverse_vending_machine
>> > reverse_vending=bottle_return
>> >
>> > Machines may take more than one type of item. Some here take bottles
>> and bottle creates. Some take metal cans.
>>
>
> sometimes (e.g. common typology in German shops) you can add both, plastic
> bottles for recycling and reusable bottles in plastic or glass (but usually
> not bottles in glass for recycling) into the same "machine" (which will
> often just be a conveyor belt with a scanner and a receipt printer, while
> sorting takes place manually behind the curtain). Other machines are only
> for plastic bottles for recycling and they will crush the bottles to reduce
> space requirements. I have never seen a machine that accepts glass bottles
> for recycling (but maybe they exist somewhere),
>

They certainly do! Here you go:
https://www.mytomra.com.au/home/qld-containers-for-change/

  Thanks

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

[Tagging] Indoor highway=steps+repeat_on=*

[Jeremiah Rose]

I've been tagging some indoor routes in buildings already mapped with Simple 
Indoor Tagging, using highway=footway+indoor=yes, but am having a problem with 
flights of stairs. With most elements that are repeated between floors (and 
would thus have identical lat/longs), such as elevator or stairwell doors, you 
use repeat_on=* to specify additional levels that it's found on, and the levels 
are specified with either a semicolon or a hyphen to denote level ranges. 
However, this doesn't work with elements that span multiple floors and are 
repeated on multiple floor ranges, such as flights of stairs. 

Compare this (correct)
https://projets.pavie.info/id-indoor/#background=Bing=w762348666=0=22.20/-85.71469/38.25695

with this (incorrect I guess)
https://projets.pavie.info/id-indoor/#background=Bing=w742518979=0=22.20/-85.71456/38.25689

Is there any way to tag these flights of stairs with repeat_on=*? I want to do 
this because step_count=* is potentially useful information for visually 
impaired travelers, and it's much more useful to say that a specific flight of 
stairs has 9 steps than that a whole staircase has 72 steps. 

Jeremiah Rose 

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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Martin Koppenhoefer]

Am Fr., 10. Jan. 2020 um 13:57 Uhr schrieb Florian Lohoff :

> On Fri, Jan 10, 2020 at 12:37:21PM +0100, Martin Koppenhoefer wrote:
> > For big buildings/POIs mapped as areas, I would expect the routing engine
> > to bring me to the main entrance, or if not available, any entrance.
>


> It doesnt. It generates a centroid of the area, searches for the nearest
> road for that POINT. Routing is always to a POINT so you need to map
> an area to a point. How do you achieve that?
>


yes, the problem is with too stupid routing software. Routing to the
nearest street of a centroid works well for small areas but can completely
fail for big ones.



Heuristics will solve 90% for you - Normal buildings and a single

> street.  This is what we have. How do you solve the rest of the 10%?
> This is what i was talking about. Huge areas, Multiple Entrances,
> Multiple Parking lots with different refs etc. You'd like to say -
> "I'd like to go to Mall A" and the Nav Software asks "Parking West or
> Parking North". How do you link that information?
>

> How do you link the reception of a campsite to the area of the campsite?
>
>

it is already linked spatially. What you have to do is map the campsite as
area and map the reception within this area. Similarly for the parkings.
Routing software should solve this contextually. If I am walking I want to
be led to the main entrance (or given the choice which entrance), while
when I am driving I will typically want a parking. A parking must not
necessarily be inside the area, it can also be close by.


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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Jarek Piórkowski]

On Fri, 10 Jan 2020 at 04:22, Florian Lohoff  wrote:
> OTOH in the dense urban areas you have the problem of Address for road A
> nearer to Road B. So you get navigated to the wrong spot on the road
> network. This view is generated with the OSRM Car profile and mapping
> all addr:* objects with the "nearest" function and comparing the highway
> name and the addr:street. If both are "filled" and non equal -> fail.
>
> https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z

In the example of Cheruskerstraße 125a, how is it actually reached?
Esri satellite imagery seems to suggest it's actually reached from Zum
Alten Hammer. The tool flags this as a problem because of street name
mismatch but it actually appears correct.

In the case of Cheruskerstraße 107g it looks like by far the easiest
way to solve it is for the router to take footways into account. Or I
guess we could create a new tag for "motor vehicle stop location to
get to a given address" to work around router shortcomings...?

Same with your later example of bicycle routing not checking for
barriers like rivers and removing ways with access=private. That seems
a lot easier to fix with software than by reorganizing the database.
But then I'm not a router developer.

--Jarek

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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 12:37:21PM +0100, Martin Koppenhoefer wrote:
> For big buildings/POIs mapped as areas, I would expect the routing engine
> to bring me to the main entrance, or if not available, any entrance. I also

It doesnt. It generates a centroid of the area, searches for the nearest
road for that POINT. Routing is always to a POINT so you need to map
an area to a point. How do you achieve that?

> have seen similar problems, for example with the biggest airport in Rome:
> https://www.openstreetmap.org/search?query=fco
> Routing starts about 8 kilometers off the entrance and terminal buildings:
> https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.9010%2C12.5014#map=12/41.8377/12.3629
> 
> Route to the actual entrance:
> https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.7949%2C12.2522
> 
> I agree it will require more complicated heuristics to solve problems of
> this kind (e.g. a router could know, like a human does, that in an airport
> you want to arrive at the terminal, and not in front of a security fence at
> the closest point to some arbitrary "centre point"). IMHO the solution to
> the problem is not adding an address as a point (if it applies to a big
> area), but rather giving additional information (because where exactly you
> want to arrive may also depend on where inside the feature you want to go,
> so there won't be a single answer many of the times).

Heuristics will solve 90% for you - Normal buildings and a single
street.  This is what we have. How do you solve the rest of the 10%?
This is what i was talking about. Huge areas, Multiple Entrances,
Multiple Parking lots with different refs etc. You'd like to say -
"I'd like to go to Mall A" and the Nav Software asks "Parking West or
Parking North". How do you link that information?

How do you link the reception of a campsite to the area of the campsite?

I had the situation that i navigated to the campsite. I could see it -
just 30m in front of me. But a river inbetween. It was a 10km bicycle
ride to the next bridge. And from the algorithmic part everything
was correct in that case - Still broken for the user experience.

The cause was that all roads on the campsite were access=private so they
fell of the routing graph. So the nearest road to the area of the
campsite was the road on the other side of the river.

You need additional hinting to solve this. A machine cant do that for
you.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Martin Koppenhoefer]

For big buildings/POIs mapped as areas, I would expect the routing engine
to bring me to the main entrance, or if not available, any entrance. I also
have seen similar problems, for example with the biggest airport in Rome:
https://www.openstreetmap.org/search?query=fco
Routing starts about 8 kilometers off the entrance and terminal buildings:
https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.9010%2C12.5014#map=12/41.8377/12.3629

Route to the actual entrance:
https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.7949%2C12.2522

I agree it will require more complicated heuristics to solve problems of
this kind (e.g. a router could know, like a human does, that in an airport
you want to arrive at the terminal, and not in front of a security fence at
the closest point to some arbitrary "centre point"). IMHO the solution to
the problem is not adding an address as a point (if it applies to a big
area), but rather giving additional information (because where exactly you
want to arrive may also depend on where inside the feature you want to go,
so there won't be a single answer many of the times).

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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 12:11:10PM +0100, Marc Gemis wrote:
> > Footways are not part of the by car routeable network. And
> > access=no/access=private or highway=track and neither.

> This depends on the router, AFAIK Magic Earth navigates over private
> roads. It even combines it with access=destination roads that are
> connected to them.

I havent seen one in common use which does this. And i dont think any
navigatio solution right now does inter-modal selection of the nearest
spot on a road network, which you would need to do to include footways.

> > Commercial dataset map addresses back to nodes on the road - On specific
> > points. We as OSM rely on algorithms to do this automatically - And
> > fail in an astonishing large amount of cases.
> >
> > If you go to the center of a park by car there is no way the algorithm
> > can decide on the best spot to go there by _car_. So it uses the centroid
> > of the park, tries to find the nearest highway usable by your mode of
> > transportation. If that happens to be by car you might end up multiple
> > kilometers away from the optimal place to be. And there is nothing
> > we can do about it with this level of data abstraction.
> 
> There is no single 1 spot that is the best, even not for cars (or
> vehicles). Satnavs should allow you to refine the search for
> centroids. After telling the system that you want to drive to a park,
> it should (or could) offer you a few choices. Whether this is based on
> park entrances being mapped or parking places nearby is up to the
> software. I think this is not always solvable by mappers.

It is not solvable by algorithms. Mappers could select a node, or
multiple like on an Airport selecting multiple terminals and their
spots to go to.

> As for car navigation not taking paths and driveways into account.

> Again, that is a problem of the navigation software.
> I know OsmAnd uses driveways, as it always took my neighbour's
> driveway since in OSM it comes close to my house than my own driveway.
> OsmAnd does ignore any fence you draw. BTW, the private footpath to
> the frontdoor is not mapped.
> I do not think mappers should try to work around software limitations
> of their favourite satnav program. Those programs should be improved.

OSMAnd uses driveways, this is something i use extensively to fix
a lot of problems. But there are cases your CANT solve with this.
But OSMAnd (As all other Nav solutions - are not using inter-modal
road network nearest selection).

Think - Gated community with only footways. There is always a random
road near the building. But you never will get to the official parking
spot.

> We are so used to give an address and assume the software will bring
> us to the right spot, perhaps that flow has to be changed and not the
> data driving that flow.

Its not only we expect to reach the building for an address. We expect
this for ANY POI which is in our Database.

And as long as the mapper does not specific a very specific node
it is pure luck that we and up in the right spot. POIs on areas,
or addresses on areas and using a centroid of that area is just a
very broken approximation.

And the expectation is that a Nav Software offering a destination
to go to should REALLY know how to get there - Or show some
error bar e.g. "I can get you near the spot but its just an
approximation and my the error range is 1.5km"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Marc Gemis]

On Fri, Jan 10, 2020 at 11:58 AM Florian Lohoff  wrote:
>

> Footways are not part of the by car routeable network. And
> access=no/access=private or highway=track and neither.
>

This depends on the router, AFAIK Magic Earth navigates over private
roads. It even combines it with access=destination roads that are
connected to them.

> > IMHO, this also does not matter for POIs with an address on a building. The
> > satnav should take the coordinates of the POI, not the centre of the
> > building in which it is placed. Taking the centre of the (large) building
> > might lead to problems.
> >
> > So yes, one should try to map as many service roads, paths, internal
> > corridors as possible to help routers. And yes, the coordinates taken by
> > the router for the endpoint are important.
> > but is this caused by addresses on buildings vs. on nodes ? no, not always,
> > e.g for (apartment) buildings with multiple entrances with only address
> > info on the building, it can go wrong. Not for small detached family houses.
>
> Commercial dataset map addresses back to nodes on the road - On specific
> points. We as OSM rely on algorithms to do this automatically - And
> fail in an astonishing large amount of cases.
>
> If you go to the center of a park by car there is no way the algorithm
> can decide on the best spot to go there by _car_. So it uses the centroid
> of the park, tries to find the nearest highway usable by your mode of
> transportation. If that happens to be by car you might end up multiple
> kilometers away from the optimal place to be. And there is nothing
> we can do about it with this level of data abstraction.

There is no single 1 spot that is the best, even not for cars (or
vehicles). Satnavs should allow you to refine the search for
centroids. After telling the system that you want to drive to a park,
it should (or could) offer you a few choices. Whether this is based on
park entrances being mapped or parking places nearby is up to the
software. I think this is not always solvable by mappers.

As for car navigation not taking paths and driveways into account.
Again, that is a problem of the navigation software.
I know OsmAnd uses driveways, as it always took my neighbour's
driveway since in OSM it comes close to my house than my own driveway.
OsmAnd does ignore any fence you draw. BTW, the private footpath to
the frontdoor is not mapped.
I do not think mappers should try to work around software limitations
of their favourite satnav program. Those programs should be improved.

We are so used to give an address and assume the software will bring
us to the right spot, perhaps that flow has to be changed and not the
data driving that flow.

regards

m.

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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 10:48:02AM +0100, Marc Gemis wrote:
> > OTOH in the dense urban areas you have the problem of Address for road A
> > nearer to Road B. So you get navigated to the wrong spot on the road
> > network.
> 
> I don't understand what this has to do with addresses on buildings vs.
> nodes. I would expect that an address is converted to coordinates. Then a
> route is created to get as close as possible to that point, regardless of
> the street names.
> So yes, if the router does not take services roads, footpaths etc. into
> account (or when they are not mapped), you might end up in the wrong
> street.

Footways are not part of the by car routeable network. And
access=no/access=private or highway=track and neither.

> IMHO, this also does not matter for POIs with an address on a building. The
> satnav should take the coordinates of the POI, not the centre of the
> building in which it is placed. Taking the centre of the (large) building
> might lead to problems.
> 
> So yes, one should try to map as many service roads, paths, internal
> corridors as possible to help routers. And yes, the coordinates taken by
> the router for the endpoint are important.
> but is this caused by addresses on buildings vs. on nodes ? no, not always,
> e.g for (apartment) buildings with multiple entrances with only address
> info on the building, it can go wrong. Not for small detached family houses.

Commercial dataset map addresses back to nodes on the road - On specific
points. We as OSM rely on algorithms to do this automatically - And
fail in an astonishing large amount of cases.

If you go to the center of a park by car there is no way the algorithm
can decide on the best spot to go there by _car_. So it uses the centroid
of the park, tries to find the nearest highway usable by your mode of
transportation. If that happens to be by car you might end up multiple
kilometers away from the optimal place to be. And there is nothing
we can do about it with this level of data abstraction.

The only decision is right now "nearest road with matching mode of
transport" and nearest is in a large number of cases not the place to
be.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Marc Gemis]

>
>
>
> OTOH in the dense urban areas you have the problem of Address for road A
> nearer to Road B. So you get navigated to the wrong spot on the road
> network.
>

I don't understand what this has to do with addresses on buildings vs.
nodes. I would expect that an address is converted to coordinates. Then a
route is created to get as close as possible to that point, regardless of
the street names.
So yes, if the router does not take services roads, footpaths etc. into
account (or when they are not mapped), you might end up in the wrong
street.

IMHO, this also does not matter for POIs with an address on a building. The
satnav should take the coordinates of the POI, not the centre of the
building in which it is placed. Taking the centre of the (large) building
might lead to problems.

So yes, one should try to map as many service roads, paths, internal
corridors as possible to help routers. And yes, the coordinates taken by
the router for the endpoint are important.
but is this caused by addresses on buildings vs. on nodes ? no, not always,
e.g for (apartment) buildings with multiple entrances with only address
info on the building, it can go wrong. Not for small detached family houses.

regards

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

Re: [Tagging] addresses on buildings

[Florian Lohoff]

On Fri, Jan 10, 2020 at 07:04:20AM +0100, Marc Gemis wrote:
> Perhaps I was not clear, what was pointed out is that it is sufficient
> to have the address on the building, there is no need to repeat it on
> the POI (besides the parts that are different such as unit_nr or
> floor).
> Although I now think that person said that it would be OK to have the
> address on a separate node next to the POI, which does not work if you
> only see a list of nearby Foobar POIs. In that list you want to see
> addresses as well.

I duplicate the address on the POI as then the POI is self contained. So
once the POI disappears the complete object may be deleted and not some
tags sorted.

A huge issue in workflow IMHO is that tags stay behind after some POI
disappears, or better, parts of the address get accidentally deleted
by someone editing the POIs information from an tag aggregating Object.

So i try to seperate out the individual functions of the objects. Makes
it much simpler in maintaining the data.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

[Tagging] POI data and Addresses on areas - Was: addresses on buildings

[Florian Lohoff]

On Thu, Jan 09, 2020 at 11:04:21PM +, marc marc wrote:
> Le 06.01.20 à 08:47, Florian Lohoff a écrit :
> > If you have HUGE Buildings i use a node with an address.
> 
> it's amazing the difference in usage.
> I find that addr nodes are very problematic for hudge buildings like
> shopping malls or train stations. the localisation of the node forces
> the routing to go to a specific location when you may be closer to
> another entrance.
> By putting the address on the building, you can not only allow quality
> reverse geocoding for the whole building, but also allow advanced
> routing to select the closest entry instead of going to the preferred
> entry of the contributor who entered the address.

That is a Huge problem putting informations POI, Addresses on Areas. I
addressed this on tagging a while back and was shot down that i should
tag sufficient. But there are tons of problems with non-explicit route
guidance.

My solution/proposal was to have a route/nav-aid relation. If you want
to reach Object A, with transport method B, you need to navigate to node C.

Just to get an impression about the impact i am creating to 2 debug
views (for myself and other interested partys) for parts of Germany.

A problem in the countryside are long driveways, sometimes not mapped,
tagged with random access tags or falsely tagged as tracks:

https://osm.zz.de/dbview/?db=addresses-nrw=routeable#51.63009,7.13605,15z


OTOH in the dense urban areas you have the problem of Address for road A
nearer to Road B. So you get navigated to the wrong spot on the road
network. This view is generated with the OSRM Car profile and mapping
all addr:* objects with the "nearest" function and comparing the highway
name and the addr:street. If both are "filled" and non equal -> fail.

https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z

Just pan around and you'll easily spot horrible problems. The simple
case its just at a corner. But there are a lot of cases where you end up
significantly far away from the real address on a completely unrealated
road.


So yes - there are serious issues with the way OSM maps POIs and
Addresses and their usage for navigation.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Fwd: amenity=vending_machine/vending=bottle_return - operator=

[Martin Koppenhoefer]

Am Fr., 10. Jan. 2020 um 08:58 Uhr schrieb Marc Gemis :

> > amenity=reverse_vending_machine
> > reverse_vending=bottle_return
> >
> > Machines may take more than one type of item. Some here take bottles and
> bottle creates. Some take metal cans.
> >
> > Reverse vending machines are not the only vending machine type that’s
> not technically a vending machine, although you are exchanging one thing
> for another.
> >
> > I propose
> > amenity=vending_machine
> > vending=reverse_vending (or keep bottle_return as its already in use)
> > recycling:glass_bottles=yes/no (already is use)
> > recycling:=yes/no
>
> Since you use recycling tags, why not use amenity=recycling with some
> subtags to indicate that you get money. Why stick to vending machine?



sometimes (e.g. common typology in German shops) you can add both, plastic
bottles for recycling and reusable bottles in plastic or glass (but usually
not bottles in glass for recycling) into the same "machine" (which will
often just be a conveyor belt with a scanner and a receipt printer, while
sorting takes place manually behind the curtain). Other machines are only
for plastic bottles for recycling and they will crush the bottles to reduce
space requirements. I have never seen a machine that accepts glass bottles
for recycling (but maybe they exist somewhere), usually there are
containers for the collection of glass or the bottles will be reused.

Technically, the term "reverse vending" only applies to machines where you
get something for the items you have put in (is typical for reusable
containers but may often not be true in the case of containers destined for
recycling), maybe if we want to lump them together we should prefer a more
generic tag for it?

Cheers,
Martin

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

Re: [Tagging] recreational vs functional routes

[Peter Elderson]

Andy Townsend :

> Peter Elderson wrote:
> > Warin <61sundow...@gmail.com> het volgende geschreven
> >
> >> I think;
> >> Those who bicycle know why there needs to be these classes.
> >> Those who don't ride a bicycle regularly see no need for these classes.
> > I wonder which of these groups you think I am in...
> >
> > Hint: Nederland.
>
> Ahem.  How can I put this tactfully - the Netherlands doesn't exactly
> have the widest variety of cycling terrain in the world, and has a
> generally good network of separated cycleways.
>

You would be surprised... but that wasn't the issue. THe examples show no
extrapordinary  ways or routes. Characteristics of ways in a route are
tagged on the way, such as surface, elevation, speed, access, oneway.
Characteristics of the whole route are tagged on the relation. I would only
create a route relation for a route that's actually visible, i.e.
waymarked. For bicycles we have route=bicycle, for mtb we have route=mtb.
Chracterizing routes as especially suited for or designated as touristic or
speed cycling, if that was a common thing visible on the ground, no
problem. I am sure examples can be found. I am not sure it is enough to
warrant tagging.
On the other hand, if someone or a group of cyclists intend to tag the
visible or obvious (?)  purpose(s) of routes in a particular country in
more detail, and makes a nice special interest map of it, fine! I would not
expect random mappers around the globe to map it, though.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] recreational vs functional routes

[Martin Koppenhoefer]

Am Fr., 10. Jan. 2020 um 09:09 Uhr schrieb Warin <61sundow...@gmail.com>:

> A 'tourist' route would usually target scenery, history the occasional eatery.
> It should be 'interesting' to the visitor.
>
>

Yes, a tourist route may sometimes be identified unambiguously, for example
if it is a noexit route to a historic site like a castle, where you have to
take the same way back as you came. Nobody could use this route to commute.
But these are very few of all routes. Most of the times, you will use any
route for commuting, while tourists use routes that either take them where
they want to go, or where the route itself is delighting (or ideally both).
So almost any route could be commute=yes, and many might be interesting for
tourists (although this goes more into the recommendation direction than
describing unquestionable hard facts).

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

Re: [Tagging] recreational vs functional routes

[Warin]

A 'tourist' route would usually target scenery, history the occasional eatery.
It should be 'interesting' to the visitor.
The surface, smoothness is of concern to the sports car driver or the road 
racing bicycle rider where they want a good road.
For different reasons the tourist in a 4WD or MTB may prefer a far less well 
developed 'road'.
But both the above groups will be after 'interest' for them in a 'tourist' 
route.

A 'commuting' route would usually be the quickest way from A to Z without 
regard to beauty, history etc.
Of no real interest to the user other than to get from A to Z.

Beauty, scenery are not things well tagged in OSM, and not something that would 
be well evaluated by remote mapping.

The other thing of real concern to bicycle riders is elevation changes.. these 
are challenging. Bicycle routes usually avoid them, there are those after that 
challenge though.
Again this is not something well mapped in OSM.

Some will say 'interest' is a subjective thing. Well it is recognized by 
tourist boards who establish them, provide maps and sign post them.
Those who have used them find some better than others, but again that is 
subjective.



On 10/1/20 3:37 pm, Marc Gemis wrote:

I assume those characteristics are mapped on the OSM-ways representing
the roads, not on the relation.
As far as I understand Peter's arguments, the fact that a bicycle
route is suitable for recreation, commuting, skilled MTB'ers and so
on, should be determined from the characteristics of the roads in the
relation, not from some tag on the relation.

If we go back the Joost's original question of cycle highways vs. node
network or local roundtrip routes. Do we need a tag on the relation to
distinguish one as commute and the other as recreational? Where is
this information useful?

Suppose I want a fast commute, can the router give me a ride over a
lot of bicycle highways without tags on the relation? Or can that be
done just by the characteristics of the roads in that relation? Or
because they form an almost uninterrupted straight line next to a
railway?

On the other hand, can the system give me touristic routes that allow
me to explore an area, or will it send me over cycle highways which
are not meant for that purpose? A node network or a local round trip
is meant for that.

The original question was how can we tag the difference between a
route representing a cycle highway and a note network. Peter, you
recently worked hard to introduce a new tag to distinguish cycle
networks from other routes. Can we use that tag, with a different
value, for cycle highways to separate them from the others?

But then we do not solve the problems for touristic car routes and for
the examples Florimand gave.

regards

m

On Fri, Jan 10, 2020 at 1:08 AM Andy Townsend  wrote:

On 09/01/2020 23:14, Peter Elderson wrote:

Warin <61sundow...@gmail.com> het volgende geschreven


I think;
Those who bicycle know why there needs to be these classes.
Those who don't ride a bicycle regularly see no need for these classes.

I wonder which of these groups you think I am in...

Hint: Nederland.

Ahem.  How can I put this tactfully - the Netherlands doesn't exactly
have the widest variety of cycling terrain in the world, and has a
generally good network of separated cycleways.  That isn't true
everywhere - regularly when I'm out walking I'm asking myself "how do I
tag this so that a poor mistaken cyclist doesn't think it'd be a good
shortcut".  An example is https://www.openstreetmap.org/way/353193650 ,
where I was on Monday - is an example.  It's a public bridleway in the
UK, so as well as walkers, horse riders and cyclists can legally use it
too - but any horse bigger than a small pony wouldn't fit (not without
the rider being impaled on a tree branch), and the 45 degree angle of
the hill, and the slippery mess on the ground, make it challenging for
walkers never mind cyclists.

Not so far away is
https://www.openstreetmap.org/relation/9487#map=13/54.3595/-1.2685 which
is actually part of a cycle route.  The worst of that section is
probably "only" mtb:scale=1, but I certainly wouldn't recommend it to a
normal road bike user (or someone used to comfort as they're riding along).

Outside of "small" countries like the Netherlands or England other
factors such as sheer scale come into play - for example the
https://en.wikipedia.org/wiki/Munda_Biddi_Trail that has opened between
Perth and Albany in Australia (see
https://www.openstreetmap.org/relation/5810814 ), or one of the long US
routes.

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



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