Re: [Tagging] Tagging for the renderer : One-way "flow" bicycle tracks

[Peter Elderson]

So, no signage?
Incline and mtb-scale still don't say you can't hike there.

Fr Gr. Peter Elderson


Op vr 8 sep 2023 om 23:01 schreef Mike Thompson :

> One of the trails was
> https://www.openstreetmap.org/way/593945914#map=19/37.99250/-122.50667
> highway <https://wiki.openstreetmap.org/wiki/Key:highway?uselang=en> path
> <https://wiki.openstreetmap.org/wiki/Tag:highway=path?uselang=en>
> horse <https://wiki.openstreetmap.org/wiki/Key:horse?uselang=en> no
> name <https://wiki.openstreetmap.org/wiki/Key:name?uselang=en> Bunny
> oneway:bicycle
> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle?uselang=en> yes
> <https://wiki.openstreetmap.org/wiki/Tag:oneway:bicycle=yes?uselang=en>
> surface <https://wiki.openstreetmap.org/wiki/Key:surface?uselang=en> dirt
> <https://wiki.openstreetmap.org/wiki/Tag:surface=dirt?uselang=en>
>
> The solution might be to add incline=* and mtb:scale=* and then improve
> the routing algorithm to avoid downhill-only mountain bike trails when
> hiking.
>
> Mike
>
> On Fri, Sep 8, 2023 at 2:15 PM Peter Elderson  wrote:
>
>> How did you find out what these paths are? Any kind of signage there?
>>
>> Fr Gr Peter Elderson
>>
>>
>> Op vr 8 sep 2023 om 19:08 schreef Bryce Nesbitt :
>>
>>>
>>> I recently went on a hike, guided only by OSMAnd.  We ended up planning
>>> a route
>>> that took us uphill on what turned out to be a long series of one way 
>>> downhill
>>> mountain bike flow tracks.
>>>
>>> I have no problem with the flow track: just had it been clearly
>>> delineated we would have planned a different route more suited to hiking.
>>> But I was left without clear tagging ideas.
>>>
>>>
>>>
>>>
>>> One of the trails was
>>> https://www.openstreetmap.org/way/593945914#map=19/37.99250/-122.50667
>>> highway <https://wiki.openstreetmap.org/wiki/Key:highway?uselang=en>
>>> path <https://wiki.openstreetmap.org/wiki/Tag:highway=path?uselang=en>
>>> horse <https://wiki.openstreetmap.org/wiki/Key:horse?uselang=en> no
>>> name <https://wiki.openstreetmap.org/wiki/Key:name?uselang=en> Bunny
>>> oneway:bicycle
>>> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle?uselang=en> yes
>>> <https://wiki.openstreetmap.org/wiki/Tag:oneway:bicycle=yes?uselang=en>
>>> surface <https://wiki.openstreetmap.org/wiki/Key:surface?uselang=en>
>>> dirt <https://wiki.openstreetmap.org/wiki/Tag:surface=dirt?uselang=en>With
>>> a clear direction, as it has jumps that can only be completed in a single
>>> direction, and is all but impossible to cycle the "wrong way" on.
>>>
>>>
>>>
>>>
>>> Is this trail tagged the best that can be?
>>>
>>> Is there a way to better hint to rendering that this should look
>>> different from a "standard" hiking trail, perhaps tagged:
>>> highway <https://wiki.openstreetmap.org/wiki/Key:highway?uselang=en>
>>> path <https://wiki.openstreetmap.org/wiki/Tag:highway=path?uselang=en>
>>> name Hiking Trail
>>> surface dirt
>>> bicycle
>>> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle?uselang=en>
>>> permissive
>>>
>>>
>>> I see that even *OpenCyclemap *does not draw directional arrows on the
>>> "Bunny" trail or other oneway:bicycle=yes routes.
>>>
>>> ___
>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging for the renderer : One-way "flow" bicycle tracks

[Peter Elderson]

How did you find out what these paths are? Any kind of signage there?

Fr Gr Peter Elderson


Op vr 8 sep 2023 om 19:08 schreef Bryce Nesbitt :

>
> I recently went on a hike, guided only by OSMAnd.  We ended up planning a
> route
> that took us uphill on what turned out to be a long series of one way downhill
> mountain bike flow tracks.
>
> I have no problem with the flow track: just had it been clearly
> delineated we would have planned a different route more suited to hiking.
> But I was left without clear tagging ideas.
>
>
>
>
> One of the trails was
> https://www.openstreetmap.org/way/593945914#map=19/37.99250/-122.50667
> highway <https://wiki.openstreetmap.org/wiki/Key:highway?uselang=en> path
> <https://wiki.openstreetmap.org/wiki/Tag:highway=path?uselang=en>
> horse <https://wiki.openstreetmap.org/wiki/Key:horse?uselang=en> no
> name <https://wiki.openstreetmap.org/wiki/Key:name?uselang=en> Bunny
> oneway:bicycle
> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle?uselang=en> yes
> <https://wiki.openstreetmap.org/wiki/Tag:oneway:bicycle=yes?uselang=en>
> surface <https://wiki.openstreetmap.org/wiki/Key:surface?uselang=en> dirt
> <https://wiki.openstreetmap.org/wiki/Tag:surface=dirt?uselang=en>With a
> clear direction, as it has jumps that can only be completed in a single
> direction, and is all but impossible to cycle the "wrong way" on.
>
>
>
>
> Is this trail tagged the best that can be?
>
> Is there a way to better hint to rendering that this should look different
> from a "standard" hiking trail, perhaps tagged:
> highway <https://wiki.openstreetmap.org/wiki/Key:highway?uselang=en> path
> <https://wiki.openstreetmap.org/wiki/Tag:highway=path?uselang=en>
> name Hiking Trail
> surface dirt
> bicycle
> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle?uselang=en>
> permissive
>
>
> I see that even *OpenCyclemap *does not draw directional arrows on the
> "Bunny" trail or other oneway:bicycle=yes routes.
>
> ___
> 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] [Talk-GB] Fords and how to provide information to help with routing apps

[Peter Elderson]

Fr gr Peter Elderson


Op vr 7 jul 2023 om 03:58 schreef Matija Nalis <
mnalis-openstreetmapl...@voyager.hr>:

> On Wed, 5 Jul 2023 18:00:26 +1000, Warin <61sundow...@gmail.com> wrote:
> > On 5/7/23 03:38, Mateusz Konieczny via Tagging wrote:
> >> ford=impassable makes no sense
> >> ford is by definition a passable place across waterway, if
> >> something is impassable then it is not a ford
>
> Agreed... and when not passable by anyone, I wouldn't draw it on OSM as
> any highway=* way nor related points like ford=*.
>
> However, if some traffic is NOT POSSIBLE but other traffic is, I'd
> probably still use access tags like foot=*,
> bicycle=* etc. even if those are primarily for LEGAL restrictions.
>
> E.g. if it is suicidal to try to cross such ford with bicycle there, I'd
> probably add bicycle=no.
> I should point out that it works out here, where attempted suicide is
> illegal (and you'll get fined for it :-)
> Otherwise tag purists would dislike it.
>
> > Many 'fords' in Australia are normally dry.
> >
> > When the river runs high those fords can become impassable for quite
> > some time .. weeks..
>
> Relatedly, there are:
>
> https://wiki.openstreetmap.org/wiki/Key:intermittent
> https://wiki.openstreetmap.org/wiki/Key:flood_prone
> https://wiki.openstreetmap.org/wiki/Key:seasonal
>
>
> which might be useful for such cases.
>
> --
> Opinions above are GNU-copylefted.
>
>
> ___
> 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

[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] Picnic_table with barbecue table extension.

[Peter Elderson]

barbecue=support ?

Mvg Peter Elderson

> Op 22 mei 2023 om 20:06 heeft Dave F via Tagging  
> het volgende geschreven:
> 
>   https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi
> I've a leisure=picnic_table but has an extended table top made of metal to 
> accommodate disposable barbecues.
> 
> Can anybody recommend a sub-tag that's more descriptive than barbecue=yes?
> 
> https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpicnic_table
> 
> https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpg
> 
> Cheers
> DaveF
> 
> 
> 
> 
> ___
> 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] [RFC] Feature Proposal - EV Charging Station Mapping

[Peter Elderson]

I think: A charging_station has one or more chargers. You cannot count the number of chargers by counting charging_stations. Since you can't assume that all charging_stations have their capacity (number of chargers) in a tag, nor that chargers are separately mapped (in addition, or standalone), nor that all charging stations have been mapped, you can't hope to get an accurate count of chargers from a query, unless the mapping and tagging is very active, complete and kept up to date.Fr Gr Peter EldersonOp 31 mrt. 2023 om 01:54 heeft Andy Townsend  het volgende geschreven:
  

  
  
On 30/03/2023 18:13, NKA mapper wrote:


  
  
tor. 30. mar. 2023 kl. 18:14 skrev Andy Townsend
  :


  

  How do I know if an "amenity=charging_station" in the
OSM data is a "single charge point" or a "group of
chargers"?

  
  The intention is to not have a difference. Both a single
charger location and a multi-charger location is a place
where you could charge your vehicle, and the proposal is to
map them the same way. This is similar to a fuel station,
where I would tag one single pump, typically at a rural
location, as amenity=fuel. 
  

  

That would be a problem, as trying to use the same tag for
  different physical objects always is in OSM.  If I
gis=> select count(*) from [some database table] where amenity
  = 'charging_station';
   count
  ---
     267
  (1 row)

How do I know what I am counting?  How do I count just "single
  charge points"?  How do I count "groups of chargers"



  

  
  
  Of course tags like capacity and socket would give
indications. 

  

If tagged, but plenty exist without those:
  https://overpass-turbo.eu/s/1ta8




  

  And if amenity=charging_station is tagged as an area
around a number of charge points, that would be a group. 

  

That'd need to be a spatially-aware query, and I wouldn't assume
  that data consumers can easily do that.  At the place where I
  detect charging stations I don't have that capability:
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1492
  .

If the same tag must be used for both, the only way to tell
  "single charge point" from "group of chargers" is to have a tag
  that is set to indicate which is which.  If "newtag=single" it
  means it's a single charge point, if "newtag=group" it's a group,
  and if "newtag" is not set, we don't yet know, and need to
  encourage local mappers to add the tag.

Recycling centres are similar, and I handle them like this:
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1648
  , though in this case the extra tag ("recycling_type=centre" ), if
  unset, suggests that we're just talking about a recycling bin not
  a recycling centre.
Best Regards,
Andy




  

___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=trailhead

[Peter Elderson]

Martin Koppenhoefer :

> I believe setting up voting to approve a tag with "de-facto"-status is a
> waste of time, particularly if you do not intend to refine the definition,
> and an approval will only "downgrade" the tag from "de-facto" to
> "approved". People have already voted on the tag by using it thousands of
> times.
>

I sort of agree...I let myself get sucked into it, while I only wanted to
upgrade from "in use" by simply polling opinion.
On the other hand, it feels unfinished to skip the end vote.

I would like to see it through now, but I probably won't do it again! I do
think my action has led to some attention and improvement, though.

You wouldn't vote "no" because of this, I hope?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=trailhead

[Peter Elderson]

Voting is about formal acceptance of the de facto usage.
I do not expect any no's, but maybe someone was against the tag al these
years and now finally gets the chance to say no.
A fail will not change anything to the de facto usage.

If a bunch of no votes appear, I will simply cancel my proposal. But I
trust it'll pass. So far, no criticism on the mapping itself has been
posted.

(If I had tried the same with landcover=trees|grass don't worry, I
won't)

Peter Elderson


Op vr 24 feb. 2023 om 11:51 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> Am Fr., 24. Feb. 2023 um 10:49 Uhr schrieb Peter Elderson <
> pelder...@gmail.com>:
>
>> Sorry, I wasn't clear. The current status of the tag is de facto (was: in
>> use, but someone, not me, amended that).  The proposal intends to alter
>> that from de facto to approved, by voting.
>>
>> Fr gr Peter Elderson
>>
>
>
> are you going to change the definition with the vote? Let's imagine you
> start a voting for the exact same text as is now on the tag definition
> page.
> If it wins it will change the tag status from "de-facto" to "approved". If
> it fails, will it change the tag status from "de-facto" to what? Strictly,
> voting is about a proposal, not about "tags" (it is about the
> definition/meaning that should be associated to the tags).
>
> Cheers,
> Martin
> ___
> 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] Feature Proposal - RFC - highway=trailhead

[Peter Elderson]

Sorry, I wasn't clear. The current status of the tag is de facto (was: in
use, but someone, not me, amended that).  The proposal intends to alter
that from de facto to approved, by voting.

Fr gr Peter Elderson


Op vr 24 feb. 2023 om 09:24 schreef Warin <61sundow...@gmail.com>:

>
> On 23/2/23 21:18, Peter Elderson wrote:
>
> I would like to change the status of this established tag to approved. I
> have altered the previous proposal
> <https://wiki.openstreetmap.org/wiki/Proposed_features/trailhead> to
> match the established practice.
>
>
> No, it has not been 'approved' so it would be misleading to claim it is
> 'approved'. (Approval is given by voting on a proposal these days.)
>
> The status might be 'de-facto'.
>
> ___
> 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] Feature Proposal - RFC - highway=trailhead

[Peter Elderson]

I would like to change the status of this established tag to approved. I
have altered the previous proposal
 to match
the established practice.

Any comments are welcome, but please note that I am not proposing changes
in mapping.
I have added one rendering suggestion. The original rendering suggestion
was a hiker symbol, but trailhead nodes can indicate starting points of
other recreational routes as well: bicycle/mtb, canoo, horse.
I have posted this RFC to the new forum

as well.

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

Re: [Tagging] tagging the diameter of a mini-roundabout

[Peter Elderson]

The mini-roundabout just adds priority on the MR to the general keep left rule, 
that is my understanding. 

Peter Elderson

> Op 29 jan. 2023 om 00:37 heeft Florian Lohoff  het volgende 
> geschreven:
> 
> On Sat, Jan 28, 2023 at 09:12:11PM +, Philip Barnes wrote:
>> Diameter implies there is something circular. The paint is often
>> round, not always, but most are just former T junctions or cross-roads
>> where there is nothing to measure the diameter of .
> 
> Thats exactly the point. The mini_roundabout is a UK speciality and most
> likely should not have appeared anywhere else.
> 
> 
> A mini_roundabout _must_ have a traversable center, a traversable center
> does _not_ make a mini_roundabout.
> 
> 
> Thats the major misconception a lot of people have.
> 
> 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] tagging the diameter of a mini-roundabout

[Peter Elderson]

Op za 28 jan. 2023 om 23:38 schreef Colin Smale :

> A form of roundabout common in the Netherlands has an inner ring which is
> often distinctly coloured and slightly raised, thus making it clear that
> traffic is intended to avoid it and use the outer ring, while keeping it
> perfectly usable by most vehicles.
> Example:
> https://nl.wikipedia.org/wiki/Rotonde_(verkeer)#/media/Bestand:N746-Noordergraafsingel-Harbrinkhoek.jpg
>
>

The raised part is the truck apron. Traffic, including trucks, is not
dsupposed to use the truck apron. The kerb and the raised part warn the
trucker who forgets that.
The roundabout shown there is a true roundabout. Mini-roundabouts do not
exist in Nederland, but we do have fake roundabouts (dot or circle in the
middle, possibly raised, no kerb, no roundabout rules.
Come to mention it, true roundabouts by themselves do not have special
priority rules in Nederland, just the oneway rule indicated by the
roundabout traffic signs. However, .priority is almost always indicated by
at least shark's teeth. If it isn't, traffic from the right has priority,
same as on regular junctions. (We're driving on the right).

As for diameters, I think the (minimal) turning circle or maximal rigid
vehicle length is what traffic needs. I am not sure that it can be
calculated from the diameters of inner centre circle, outer centre circle
and circumference of the entire traffic area.

On 28/01/2023 22:12 CET Philip Barnes  wrote:
>
>
> Diameter implies there is something circular. The paint is often round,
> not always, but most are just former T junctions or cross-roads where there
> is nothing to measure the diameter of .
>
> Phil (trigpoint)
>
> On 25 January 2023 17:50:54 GMT, Volker Schmidt 
> wrote:
>
> Is there an established way to tag the diameter of a mini-roundabout?
>
> We have the tag diameter, but I could not find it applied to
> mini-roundabouts.
>
> ___
> 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

Re: [Tagging] Feature Proposal - Voting - Announce proposals on the community forum

[Peter Elderson]

I get the tagging list mails and the forum messages in one inbox labeled
"Forums".

If you were to sent the next message to the forum instead of the mailling
list, it would land in exactly the same position in my inbox.

Fr gr Peter Elderson


Op za 7 jan. 2023 om 23:14 schreef Marc_marc :

> Le 07.01.23 à 21:15, Brian M. Sperlongano a écrit :
> > I checked out the site stats[1] and learned that over the last 30 days,
> > the French forum has averaged 36 messages per day with 257 active users.
> >
> > Then I headed over to talk-fr to investigate how much activity was
> > happening there.  In the whole month of December there were just 65
> > posts, and I counted 21 unique users.
> >
> > So it sounds like there is very little fragmentation
>
> you don't see of course that when user A post on the forum,
> the user B on the mailing doesn't respond
> and when the user B post on the mailing, the user A on the forum
> doesn't respond
> the overwall volume (forum+mailing) is lover that when everybody was
> only on one media
> and the sub-projects also took a beating:
> - don't look for the newcomers team, there is no real team anymore, some
> on the forum, some on the mailing list, no coordination or collective
> motivation
> - don't look for the systematic follow-up of the schoolchildren (in
> France, osm is taught at school), it's the same problem
> etc etc
>
> and all this because the pro-forum people confused haste with speed...
> by giving time to time Discourse could have been a federation, a place
> accessible/usable with the 2 interfaces instead of being an additional
> and therefore fragmenting place
>
>
>
> ___
> 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] Tagging a hole in the ground

[Peter Elderson]

If you cannot see what it is or what it is, it's just a hazard.

Peter Elderson


Op zo 1 jan. 2023 om 12:51 schreef Troels Arvin :

> Hello,
>
> When I was trekking south of Olympos in Tyrkey, I came across some ruins
> which were not on OSM. Within the ruins there is a hole in the ground,
> approximately 6 meters deep. I don't know what the hole has been used
> for. Maybe it's a dried out well, or it has been used for storage:
> http://troels.arvin.dk/osm/topics/hole_in_ground_in_tyrkey/
>
> I've tried to tag it in a meaningful way, first and foremost because the
> hole is easy to overlook when walking around in the area, and it would
> be rather harmful for anyone falling into it.
>
> However, my efforts don't result in anything showing up in
> openstreetmap.org default map:
> https://www.openstreetmap.org/node/10287990615#map=18/36.36082/30.47644
>
> Have I tagged this in a good way? Or does someone have suggestions for
> improving it?
>
> --
> Kind regards,
> Troels Arvin, Copenhagen
>
>
> ___
> 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] Route names being applied to tracks/paths

[Peter Elderson]

Vr 30 dec. 2022 om 20:51 schreef Dave F via Tagging <
tagging@openstreetmap.org>:

> I think this inconsistency is bad for OSM.
>
> Many ways don't have names, even if they have routes along them. They are
> just footpaths, & tracks etc.
>
> This instance on giving them a name tag is fake. It'll mean sections with
> one route will have their name tag rendered, but where additions routes
> join there will be no rendering.
>
> If multiple routes are of equal standing, but you insist on adding a name
> tag to the way, how do you decide which takes precedent?
>
> This thread reinforces my belief there's a lack of understand of route
> relations' purpose.
>

I agree that in general you do not apply the route's name to the way, but I
would not exclude it.
I have hiked a couple of paths actually named after a hiking trail; I have
hiked a paths created solely for a wellknown long trail, and locally called
by that name.

In Nederland this would not happen, because just about every path is used
by multiple foot routes and it's never necessary to create a dedicated path
for a hiking route. I guess in more nature-blessed environments can be a
different story.

Which means you can't correct naming errors without additional
verification, preferably local survey.

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

Re: [Tagging] Route names being applied to tracks/paths

[Peter Elderson]

I have seen some paths which actually had the same name as the hiking trail running over it. Normally this is not the case, the path usually has is own local name or no name at all. So most of the time this would be an error, but you can't be sure without survey.Fr Gr Peter EldersonOp 29 dec. 2022 om 18:28 heeft Tod Fitch  het volgende geschreven:It makes sense to me that each segment of a long distance walking/hiking route should be looked at individually. It might have no name (uses a section of a driveway), it might have a name of its own (the “San Clemente Beach Trail” near me is part of the long distance “California Coastal Trail”), or it might have been purpose built for that long distance route.My issue with hiking routes is that people seem to want to use the name field as a description. And they sometimes want to use the ref field as a description too. That makes it really hard for a data consumer to make use of the information. I wrote some stuff about that a bit over a year ago [1].Cheers,Tod[1] https://retiredtechie.fitchfamily.org/2021/09/12/california-hiking-routes-in-openstreetmap/On Dec 29, 2022, at 7:59 AM, Zeke Farwell  wrote:I've heard the assertion that a way has no name but the route that passes over it does many times.  While this is true in some cases, in others it is not.  Where the primary purpose of the way is not for the route, this does make sense.  For example mentioned by Jmapb where the Appalachian trail follows an unnamed driveway or sidewalk.  In these cases, the primary purpose is a driveway or sidewalk for local use, and the Appalachian Trail just happens to follow it as well.  Here putting the name Appalachian Trail on the way makes no sense.  However, there are also dedicated sections of trail built first and foremost to be a part of the Appalachian Trail and that have no other name.  Omitting the name Appalachian Trail in a case like that makes no sense to me.  That section of trail is indeed called the Appalachian Trail.  The whole route is also called the Appalachian Trail and that's ok.  On Thu, Dec 29, 2022 at 10:38 AM Jmapb  wrote:
  

  
  
On 12/29/2022 10:13 AM, Zeke Farwell
  wrote:


  
Yes, the way name tag should be the most local trail name. 
  However, sometimes there is no local trail name and the long
  distance route name is the only name.  In this case putting
  the long distance route name on the ways also makes sense.
  
I've been doing some mapping on the Appalachian Trail lately and
  this appears to be the common practice, although the AT is
  dominant enough that constituent trails sometimes lose their local
  names over time.Some mappers will take it a little too far and tag sections of
  sidewalk and driveway that the AT follows with name=Appalachian
  Trail (or even name=Appalachian National Scenic Trail... IMO this
  is an official_name, and probably only belongs on the route
  superrelation.)It's common to see ref=AT as well, which is fine on trails (even
  locally named ones) and perhaps ok on the sidewalks, but adding it
  to a vehicular road seems iffy.Jason




  

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

___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Peter Elderson]

In Nederland, zebra or zebra-path means just the striped pattern. No signs or 
signals are implied. It's the only named type of crossing*, everybody knows it. 
crossing=zebra is perfect for that; WYSIWIM (What You See Is What You Map). 
Very straightforward. Signals and signs may be present, but in no way do they 
define the crossing, so they have to be mapped as separate objects or 
attributes.

* Traffic experts may have many more names, just none that the general public 
knows.

Fr gr Peter Elderson

> Op 29 nov. 2022 om 11:06 heeft Minh Nguyen  het 
> volgende geschreven:
> 
> Vào lúc 23:01 2022-11-28, Martin Koppenhoefer đã viết:
>>>> On 29 Nov 2022, at 00:52, Minh Nguyen  wrote:
>>> 
>>> Even if it weren't for iD's long-gone preset, I don't think an ostensibly 
>>> global tag should be defined based on the narrow provisions of a specific 
>>> country's laws.
>> I don’t think this is about a specific country, although it is not about all 
>> countries there are many of them that apply the concept and that seem to 
>> have decided on the feature in 1949 in an international agreement.
> 
> No zebras were harmed in the drafting of either the 1949 Geneva Protocol on 
> Road Signs and Signals [1] or the 1978 Vienna Convention on Road Signs and 
> Signals [2]. Neither treaty mentions this species by name, but the national 
> laws of some parties to the Vienna Convention do define zebra crossings.
> 
> For example, the UK requires zebra crossings to have alternating stripes as 
> well as belisha beacons. [3] Other countries, such as Vietnam, use the term 
> "zebra" specifically for the striped marking pattern 
> (crossing:markings=zebra), by contrast with two parallel lines 
> (crossing:markings=lines), but make no other provisions apart from what any 
> crossing would have. [4] Meanwhile, here in the U.S., which is not a party to 
> the convention, we walk on a distinct species of "zebra crossing" that has 
> slanted stripes. What was the problem with crossing_ref=zebra again?
> 
> What you seem to be suggesting is that the definition of crossing=zebra 
> should favor the regulations of some parties to the Vienna Convention over 
> other parties to the convention, let alone other countries that use the term 
> "zebra" to refer to something slightly different. This is unsustainable. At 
> one point, it might've been reasonable to justify the use of one national 
> definition as a historical accident, based on squatter's rights. But since 
> then, for better or worse, that definition has been overwhelmed by usage that 
> we can't characterize as cleanly.
> 
> Mappers benefit when they can be confident that others will look at their 
> tagging later on and interpret it consistent with their original intention. 
> Someone using crossing=zebra today shouldn't be under any illusion that it 
> means anything more specific than a marked crossing in practice. In that 
> light, crossing=zebra deserves to be given the same deference as 
> crossing=marked.
> 
> [1] 
> <https://treaties.un.org/doc/Treaties/1953/12/19531220%2000-10%20AM/Ch_XI_B_1_2_3.pdf>
> [2] https://unece.org/fileadmin/DAM/trans/conventn/signalse.pdf#page=7
> [3] 
> <https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/851465/dft-traffic-signs-manual-chapter-6.pdf#page=127>
> [4] 
> <https://luatvietnam.vn/giao-thong/quy-chuan-ky-thuat-qcvn-41-2019-bgtvt-bao-hieu-duong-bo-186000-d3.html>,
>  p. 20; search for "vạch ngựa vằn", literally "zebra stripes"
> 
> -- 
> m...@nguyen.cincinnati.oh.us
> 
> 
> 
> ___
> 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] Feature Proposal - Voting - historic

[Peter Elderson]

I would say the lighting is slightly outdated.

Mvg Peter Elderson

> Op 4 nov. 2022 om 17:06 heeft Brian M. Sperlongano  het 
> volgende geschreven:
> 
> 
> I'll offer a well-known example from my country:
> 
> https://en.wikipedia.org/wiki/Welcome_to_Fabulous_Las_Vegas_sign
> 
> It's on the US National Register of Historic Places which should qualify it 
> as a historic sign.  Although I suppose those in Europe would just consider 
> the sign to be a little old.
> 
>> On Fri, Nov 4, 2022 at 11:56 AM Mateusz Konieczny via Tagging 
>>  wrote:
>> https://en.wikipedia.org/wiki/White_Post_Historic_District
>> 
>> 
>> Nov 4, 2022, 16:38 by annekadis...@web.de:
>> I wasn't aware bicycle parking and sign posts are considered historic now. :P
>> 
>> On 04/11/2022 15:33, Mateusz Konieczny via Tagging wrote:
>>> 
>>> 
>>> 
>>> Nov 4, 2022, 12:59 by annekadis...@web.de:
>>> I also noticed that the inscription key is used a lot where it should be 
>>> description. I think that's the "fault" of the iD editor form for historic 
>>> features. The inscription field only makes sense for memorials IMHO.
>>> 
>>> I used it for graves, crosses, monuments, amenity = drinking_water, 
>>> man_made = signpost,
>>> amenity = bicycle_parking
>>> 
>>> I see it also being validly used for many other objects.
>>> 
>>> 
>>> ___
>>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] improve the proposal procedure

[Peter Elderson]

I agree that it got a little out of hand, but there were some good
proposals and votes as well.
Proposing and voting should not be hard, so you always get some lesser
quality stuff.

Let's not throw away the baby with the wash water.

 Peter Elderson


Op do 20 okt. 2022 om 14:28 schreef Marc_marc :

> Hello,
>
> the past few weeks have been stormy for proposals:
> - people opening 4 or more RFCs to collect opinions
> - RFCs or votes that open and close in less than 12 hours
> - Proposals that go to vote on the 14th day, even though
> this is the minimum time limit and the problems in progress
> have sometimes not been resolved.
> - nominees to make even more simultaneous proposals
> without showing that it is just one person
>
> How could we improve this ?
> - limit to 1 simultaneous proposal per person?
> - limit this to active contributor status in the osmf sense?
> - encourage the use of the "resolved" tag in the talk page
> to see visually if the points have been addressed or not?
> - improve the wording for the 14 day minimum time limit which
> is too often understood lately as "pfff 14 days to wait" ?
> - limit the scope of proposal ?
> - any other ideas?
>
> Regards,
> Marc
>
>
>
> ___
> 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] RFC - More sensible values for fountain=*

[Peter Elderson]

Just a remark: I think a mainly decorative object is not an amenity. An
amenity may be near it, or attached to it, but that still does not make the
object an amenity.
An object that provides water for actual use, such as a tap or a pipe from
which water permanently flows, is an amenity. It may be decorated, or
fitted to a decorative object, but still is an amenity. The BE word
fountain, I understand, primarily means the decorative structure including
the decorative waterflow.
So, to me, any tagging using amenity=fountain sounds like a contradiction.

Peter Elderson


Op vr 14 okt. 2022 om 12:22 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Fr., 14. Okt. 2022 um 12:10 Uhr schrieb Davidoskky via Tagging <
> tagging@openstreetmap.org>:
>
>> This other fountain doesn't have such wall, thus it is not decorative
>> and it cannot be tagged as amenity=fountain (assuming we disregard the
>> recreational utility mentioned in the wiki).
>>
>>
>
>> https://upload.wikimedia.org/wikipedia/commons/5/56/Water_fountain_with_water_basin_near_Santiago_de_Compostela.jpg
>>
>>
>
> this other fountain happens to be decorated as well. Let's ignore this for
> a moment, and assume it wasn't. It could still be a decorative fountain, if
> it can be seen as street decor. Setting up a fountain requires some effort,
> so there will usually be a purpose, even if it isn't necessary now as it
> was when it was constructed. I would generally see amenity=fountain
> applicable for any fountain that is not only a drinking fountain and that
> is not set up as a watering place for animals only.
>
>
>
>
>> The shape and use of these two fountains looks the same to me.
>> Why would you tag them as different features?
>>
>
>
> I wouldn't
>
>
>
>>
>> I'm not necessarily saying they need to be tagged as amenity=fountain,
>> but I would expect their main tagging to be the same and maybe differ in
>> some secondary parameter.
>
>
>
> maybe, if you come up with an idea about these secondary parameters, we
> can discuss them.
>
> Cheers,
> Martin
> ___
> 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] Feature Proposal - RFC - Historic

[Peter Elderson]

Keeping the status as de facto, avoids confusion about approval status of the 
values.
I think it's best to pick another battle.

Peter Elderson

> Op 11 okt. 2022 om 17:14 heeft martianfreeloader 
>  het volgende geschreven:
> 
> I've reduced the proposal to the historic=* key itself. No values included 
> anymore.
> 
>> On 11/10/2022 17:03, Marc_marc wrote:
>>> Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit :
>>> Many ruins and memorials are "of historic interest" it is true, but that 
>>> could be tagged as a property ("historic=yes") of the object 
>>> "man_made=" .
>> witch main tag for aa ruins with historic interest ?
>> it's not a building=* anymore
>> and for a historic=archaeological_site ?
>> but I agree that several values don't add any information
>> historic=building on building=* is the same as historic=yes
>> ___
>> 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

Re: [Tagging] RFC - A broad look at fountains

[Peter Elderson]

I have the impression that slow running water points in Europe rapidly are 
fitted with a push button fot a limited amount of water or a limited tap time. 
Would that turn them into water taps? 

Peter Elderson

> Op 8 okt. 2022 om 19:26 heeft michael spreng (datendelphin) 
>  het volgende geschreven:
> 
> Hi
> 
> Yes, those examples from Eginhard are all fountains. I discussed this at 
> various times with other Swiss mappers. Reasons that some are not tagged as 
> fountain, from those conversations:
> 
> - The term "decorational" confuses
> - The examples on the wiki page are mostly exuberant examples. We should
>  add one of these images to the examples gallery
> - The icon in the editor and on the map also shows a rather fancy
>  fountain
> - It seems we have more specific terms in German for fountains.
>  Springbrunnen, Laufbrunnen, Brunnen... it confuses that in English,
>  everything is mapped to the same term (I'm not a native speaker,
>  please correct me if there are more).
> 
> From my biased German speaking view, it would be nice to have a category for 
> "Laufbrunnen", meaning water is discharged at low pressure, usually 
> horizontally. No on/off switch. You can fill your water bottle easily.
> 
> have a nice day
> Michael
> 
> 
>> On 08.10.22 12:38, Enno Hermann wrote:
>> Taps seem clearly defined to me and I don't think a combination of 
>> amenity=fountain, tap=yes would make sense for the examples on the wiki: 
>> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap 
>> <https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap>
>> One thing I keep wondering about on this topic is how to tag very simple 
>> fountains that are widespread in Switzerland along hiking paths 
>> (https://commons.wikimedia.org/wiki/File:Adlisberg_-_Gockhausen_IMG_4215.jpg 
>> <https://commons.wikimedia.org/wiki/File:Adlisberg_-_Gockhausen_IMG_4215.jpg>)
>>  or in villages 
>> (https://commons.wikimedia.org/wiki/File:Brunnen1886BassersdorfI.jpg 
>> <https://commons.wikimedia.org/wiki/File:Brunnen1886BassersdorfI.jpg>). 
>> Apparently they are not decorative enough for some people and should be 
>> tagged amenity=drinking_water. However, the same type of fountain could have 
>> a sign saying the water is not potable 
>> (https://commons.wikimedia.org/wiki/File:Brunnen_Waldweg.jpeg 
>> <https://commons.wikimedia.org/wiki/File:Brunnen_Waldweg.jpeg>, 
>> https://commons.wikimedia.org/wiki/File:2014-05-20-Yverdon_(Foto_Dietrich_Michael_Weidmann)_032.JPG
>>  
>> <https://commons.wikimedia.org/wiki/File:2014-05-20-Yverdon_(Foto_Dietrich_Michael_Weidmann)_032.JPG>);
>>  probably these are often only added later for legal reasons when the water 
>> is not tested. It does not make sense to me to use different tags for the 
>> same kind of feature, so I generally use amenity=fountain for these with 
>> appropriate subtags.
> ___
> 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] feature Proposal - Voting - settlement_type=crannog

[Peter Elderson]

I am one of those who didn't bother to look what it's about.
I share the wish to tag crannogs as important historical structures still
existing today.
I share the criticism that _type does not mean anything. At the same time I
don't care if it is there or not; settlement=* also does not say what kind
of categorisation is used for the values. But the settlement key ius
already in (scarce) use for something else, with values yes and no.

As for implicit approval of the higher tags, fine with me! They are in
actual use in a scheme, and for me that is good enough. If anyone would
start a separate vote for that, fine. If the current vote is postponed till
after, fine, it is the royal way I think, but I think it is not necessary.
I think we can be practical about this, not principal. It's just not big
enough.

Peter Elderson


Op vr 7 okt. 2022 om 13:10 schreef Andy Townsend :

>
> On 07/10/2022 11:27, Marc_marc wrote:
> > Hello,
> >
> > Le 07.10.22 à 12:11, Martin Koppenhoefer a écrit :
> >> who cares for "in use" or "approved"
> >
> > me :)
> >
> > approved that means that the subject has been discussed,
> > that people have spent time on it, that there has been
> > an opportunity to detect problems, to propose improvements
> > it's quite different from an "in use", because a guy invented
> >
> Unfortunately discussion and "voting" by people who have only the
> vaguest idea of what the thing being voted on is adds no value*. There
> is a place on the "B Ark" for them...
>
> The fact that there was only one comment during the fortnight of
> discussion means that people really don't know (or don't care) what
> these are, and people who do know and care (such as the proposer) should
> probably "just map these".  Whether that's via
> https://taginfo.openstreetmap.org/tags/defensive_settlement=crannog
> (which is slightly ahead in taginfo) or
> https://taginfo.openstreetmap.org/tags/settlement_type=crannog matters
> little; there are few of them in OSM right now, and the word "crannog"
> is characteristic enough, that they can fairly easily be remapped into
> some "better" archaeological scheme at some later stage.
>
> What matters is getting them mapped, and getting from the 10s currently
> in OSM to the 1500 or so that apparently do or did exist**.
>
> Best Regards,
>
> Andy
>
> * We still don't know what bicycle=designated means
>
> https://community.openstreetmap.org/t/use-of-bicycle-designated-vs-bicycle-yes-outside-of-germany/3230
>
>
> ** According to wikipedia.  I was surprised that there were apparently
> as many as 1200 in Ireland.
>
>
> ___
> 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] Terminology primary feature, main tag, etc..

[Peter Elderson]

The guideline refers to a list of "primary features" which lists all features 
with main key and values. No explanotion or list of non-primary features. The 
text of the guideline says a primary feature is the key-value pair remaining 
when all the attributes are gone. 

In short, "primary feature" does not seem to have any other meaning then just 
feature.

Peter Elderson

> Op 3 okt. 2022 om 23:17 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
>> Am Mo., 3. Okt. 2022 um 12:40 Uhr schrieb martianfreeloader 
>> :
>> 2) There is no such thing as a "primary feature".
> 
> 
> 
> hm, this seems strange, OSMF has the term in their collective database 
> guideline, it could be seen as important to understand whether the license 
> applies to your usecase and what the consequences are: 
> https://wiki.osmfoundation.org/w/index.php?oldid=3980#The_Guideline
> The term is used 7 times.
> 
> Cheers,
> Martin
> 
> ___
> 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] Terminology primary feature, main tag, etc..

[Peter Elderson]

I would avoid "primary key", because that is a term from database
management systems. It means the identifying attribute (Id) of an entity,
usually a unique identifier with an index (primary index), used to retrieve
records and to link the entity (table) to other tables. Something else
entirely.

Main key is better.

Further: the main key gives the type of object, the main tag gives a
category within that type of object. That is an important difference, in
documentation.

Feature tag, I think it means the tag that gives the object type (the main
key)  and the category within the object type (the value). So, equivalent
to main tag.
I think the term secondary tag(s) and secondary key(s) are often used for
the extra attributes of a feature, implying there should be a main tag
first, to give the secondary tags meaning.

Peter Elderson


Op ma 3 okt. 2022 om 12:40 schreef martianfreeloader <
martianfreeloa...@posteo.net>:

> Thank you all for the many insightful replies to my question!
>
> What I've learnt so far:
>
> 1) A feature is something in the physical world. This is well documented
> in the wiki: https://wiki.openstreetmap.org/wiki/Features
>
> 2) There is no such thing as a "primary feature".
>
> 3) The terms "main key", "primary key" and "feature tag" are synonymous,
> except for the tag/key distinction.
>
> 4) None of the above terms is official OSM terminology.
>
> 5) None of these terms is well documented in the wiki.
>
> ---
>
> It looks like a couple of things would be good to get done:
>
> A) We should get rid of the term "primary feature" in the wiki page
> https://wiki.openstreetmap.org/wiki/Map_features
>
> B) It would be useful if we agree on *one* official term for "main key",
> "primary key" or "feature tag". (I think "primary key/tag" is the most
> popular one)
>
> C) We should document what we mean by this.
>
> --
>
> Open questions:
> Q1) Which term should we choose as official term? ("main key"/"primary
> key"/"feature tag")
>
> Q2) Should one OSM object hold multiple "primary tags"? (ongoing
> discussion between Mateusz, Martin, Warin, Marc et al.)
>
>
>
> On 03/10/2022 12:16, Marc_marc wrote:
> > Le 03.10.22 à 10:47, Mateusz Konieczny via Tagging a écrit :
> >> there are cases where road is going in stream bed
> >
> > imho only one main feature/objet : the stream bed
> > and car use it, a bit like a bicycle uses a road.
> >
> > but we don't really have a secondary tag to say that
> > the stream bed is usable by a car... so we end up
> > describing this secondary use with a 2nd main tag...
> > this is not perfect
> >
> >
> >
> > ___
> > 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

Re: [Tagging] Terminology primary feature, main tag, etc..

[Peter Elderson]

I guess Primary key and Main key are the same. 

Peter Elderson

> Op 3 okt. 2022 om 04:06 heeft Minh Nguyen  het 
> volgende geschreven:
> 
> Vào lúc 10:36 2022-10-02, martianfreeloader đã viết:
>> Hi,
>> I'm unsure if I'm using correct terminology. I have come across these terms 
>> in the OSM ecosystem:
>> - primary feature [1]
>> - main key [2]
>> - primary key [3]
>> - feature tag [4]
>> 1) Are these synonyms (except for the key/tag distinction)?
>> 2) Is *one* of these terms "official" OSM speek with a clear definition?
>> (as is the case for things like "node", "way", "relation", "key", "value", 
>> "tag", "changeset")
> 
> "Primary feature" appears in the Collective Database Guideline Guideline 
> [sic] and Geocoding community guideline, which clarify the terms of use under 
> the ODbL. [1][2] "Feature type" appears in the Horizontal Map Layers 
> community guideline. [3]
> 
> [1] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3980#The_Guideline
> [2] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/4907#How_does_the_guideline_relate_to_other_existing_guidelines?
> [3] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3982#The_Guideline
> 
> -- 
> m...@nguyen.cincinnati.oh.us
> 
> 
> 
> 
> ___
> 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] Terminology primary feature, main tag, etc..

[Peter Elderson]

A feature is not a tag or a key, it's an object in the OSM database. I don't 
know which features are primary, secondary, ... and why. Anyway, the term 
primary feature is not equivalent to main key or main tag.

Talking about e.g. roads, the main key is highway= because that key defines the 
feature as a road or road component. Talking about a particular road, the 
highway=* tag is the main tag because it defines the type of the road or road 
component.

So main key and main tag are more or less alike, but not equivalent.

Feature tag is a vague term. I suppose it means: an attribute of an object, as 
opposed e.g. to an attribute of a changeset.

Mvg Peter Elderson

> Op 3 okt. 2022 om 04:06 heeft Minh Nguyen  het 
> volgende geschreven:
> 
> Vào lúc 10:36 2022-10-02, martianfreeloader đã viết:
>> Hi,
>> I'm unsure if I'm using correct terminology. I have come across these terms 
>> in the OSM ecosystem:
>> - primary feature [1]
>> - main key [2]
>> - primary key [3]
>> - feature tag [4]
>> 1) Are these synonyms (except for the key/tag distinction)?
>> 2) Is *one* of these terms "official" OSM speek with a clear definition?
>> (as is the case for things like "node", "way", "relation", "key", "value", 
>> "tag", "changeset")
> 
> "Primary feature" appears in the Collective Database Guideline Guideline 
> [sic] and Geocoding community guideline, which clarify the terms of use under 
> the ODbL. [1][2] "Feature type" appears in the Horizontal Map Layers 
> community guideline. [3]
> 
> [1] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3980#The_Guideline
> [2] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/4907#How_does_the_guideline_relate_to_other_existing_guidelines?
> [3] 
> https://wiki.osmfoundation.org/wiki/Special:PermanentLink/3982#The_Guideline
> 
> -- 
> m...@nguyen.cincinnati.oh.us
> 
> 
> 
> 
> ___
> 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] Feature Proposal - RFC - Bench: replace seats by capacity

[Peter Elderson]

I agree that the old text for seats=* is much better. I would add capacity=* 
with the new text: Number of people who can comfortably sit on the bench at one 
time. 
I think it's not a problem that mappers may estimate differently, most will 
agree most of the time, and if the previous mapper e.g. uses smaller "people", 
some mappers might amend it but most mappers will tolerate the estimate, as 
will walkers. Adaptive bunch, walkers.

Peter Elderson

> Op 2 okt. 2022 om 22:21 heeft Raphael  het volgende 
> geschreven:
> 
> Until very recently, the wiki said that seats=* means seats, not capacity:
> 
> https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dbench=2357111=2347958
> 
> In my opinion, this should be reverted.
> 
> Besides, i'm not very enthusiastic about using capacity=* because this
> is quite subjective - people have different figures (and feelings at
> which minimum distance to the neighbour they are still comfortable).
> It seems much better to tag the length of benches.
> 
> Best regards
> Raphael
> 
> 
>> On Thu, 29 Sept 2022 at 19:44, Peter Elderson  wrote:
>> 
>> I have stopped tagging seats, because most benches do not have seats. 
>> Capacity is ok with me, I will start using that, but still I don't think I 
>> will tag that very often, unless it's a huge bench for 20 (I have seen one!) 
>> or a very small one for 1 person. I don't mind if others tag seats or 
>> estimate the capacity different, as long as they don't remove my capacity 
>> tag.
>> 
>> Peter Elderson
>> 
>> 
>> Op do 29 sep. 2022 om 14:10 schreef martianfreeloader 
>> :
>>> 
>>> Facing heavy objections and no support, I have come to the conclusion
>>> that my proposal is not considered useful by the community.
>>> 
>>> I thus decided to retract it.
>>> 
>>> ___
>>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] service vs. unclassified, conflicting definitions

[Peter Elderson]

Unclassified, by definition, is a road on the traffic grid suitable for 
motorised vehicles. It is not necessarily paved. Access restrictions may apply, 
and usage may change in time, e.g the road still connects, but is legally 
closed for cars except emergency vehicles and people who live along the road. 
Or, a new railway intersects the road and no crossing is provided. In those 
cases, usually the road is still seen as an unclassified road.

Peter Elderson

> Op 30 sep. 2022 om 17:48 heeft grin via Tagging  
> het volgende geschreven:
> 
> Hello,
> 
> To open it for a larger audience please let me share my question from the osm 
> wiki:
> https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dservice#service_vs._unclassified,_conflicting_definitions
> 
> Quoting:
> 
> - - - - -
> 
> service vs. unclassified, conflicting definitions
> 
> There are some discrepancies between this page and highway=unclassified, and 
> the wording leaves a lot to interpretation and opinions.
> 
> This page suggests that service is a road which ends on some feature with no 
> through traffic (leading to a building, a parking place, etc). Is is also 
> specifically exclude frontage roads as an example to tag according to 
> function and not purpose. By following this definition a road with 
> throughfaring traffic (where both end is open, connecting to other roads or 
> tracks) cannot be service, so it should be unclassified.
> 
> However unclassified declares itself as "considered usable by motorcars" and 
> also "In rural contexts, narrow paved roads with only private access for 
> motorcars (maybe public access for agricultural motor-vehicles, cyclists and 
> pedestrians) should be tagged as highway=service and motorcar=private (maybe 
> motor_vehicle=agricultural)", suggesting that unclassified requires to be 
> motorcar=yes and suggests that "narrow paved roads with motorcar=private" 
> should be tagged as service.
> 
> These definitions quite contradict one another.
> 
> Take a pretty common road type in Europe, which goes on the embankment of a 
> river, which generally paved, narrow, legally open for walking and bicycling 
> people, often part of the national/international bicycle-road network, and 
> closed for motorcar traffic (usually only waterworks' cars are allowed). 
> What's that? Cannot be "unclassified" since motorcars aren't allowed, cannot 
> be service since it doesn't "leading to something". Some people tag it this 
> way, some that way. That's not good.
> 
> Either service should mean "one level below unclassified" and soften the 
> wording even more ("generally" to "in many cases", for example), or 
> unclassified shall drop requirement for motorcars and suggesting service for 
> "narrow paved roads w/ private motorcar access". I'd support the latter: I 
> would rather use unclassified here, but that's an opinion.
> 
> Your inputs are welcome. 
> 
> - - - - -
> 
> Here, as well as there.
> 
> Thank you,
> g
> 
> ___
> 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] Feature Proposal - RFC - Bench: replace seats by capacity

[Peter Elderson]

I have stopped tagging seats, because most benches do not have seats.
Capacity is ok with me, I will start using that, but still I don't think I
will tag that very often, unless it's a huge bench for 20 (I have seen
one!) or a very small one for 1 person. I don't mind if others tag seats or
estimate the capacity different, as long as they don't remove my capacity
tag.

Peter Elderson


Op do 29 sep. 2022 om 14:10 schreef martianfreeloader <
martianfreeloa...@posteo.net>:

> Facing heavy objections and no support, I have come to the conclusion
> that my proposal is not considered useful by the community.
>
> I thus decided to retract it.
>
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

Introducing a new highway value to replace rather common existing values can 
only succeed if the community agrees AND significant data users and renderers 
confirm they can and will handle it, AND local communities commit to implement 
it massively. And that is, assuming consensus is reached and documentation and 
tooling will be altered to reflect and incorporate the new guidelines.

The OSM world does not have the structure to implement such a change, I think. 
Theoretically, yes; in practice,  no. Feel free to regard this as a challenge, 
though!

I think adding *=yes tags for special sections could work, if they are set by 
communities in local/regional projects, properly documented, and offered for 
implementation as path-modifiers to relevant data consumers. The incentive 
being that it enables e.g. renderers to show relevant details on specialised 
maps, and e.g. routers to offer better routes for relevant profiles.

If one community does this and creates, publishes and maintains e.g. a 
specialised map and router for the region, it's worth it. Then other communites 
will follow. if not, no harm done, the data is still valid and nothing is 
broken.

Peter Elderson

> Op 20 sep. 2022 om 20:26 heeft Yves via Tagging  
> het volgende geschreven:
> 
> 
> 
> Le 20 septembre 2022 19:04:59 GMT+02:00, martianfreeloader 
>  a écrit :
>> 
>> How about this:
>> 
>> - keep highway=path for everything that can be walked by normal people (this 
>> means we don't need to re-tag millions of ways)
>> - introduce a new tag highway=demanding path for everything else.
>> 
> I think you forgot to mention we would need to re-tag the hundred of thousand 
> ways falling into your second bullet. That's normal, we tend to forget how 
> easily we manage competing tagging schemes ;-) 
> 
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

Mvg Peter Elderson

> Op 20 sep. 2022 om 13:49 heeft martianfreeloader 
>  het volgende geschreven:
> 
> This would mean that there is a new primary tag `highway=scramble` which 
> makes some currently existing primary tags obsolete:
> 1) `highway=via_ferrata` gets replaced by `highway=scramble + 
> scramble=via_ferrata`
> 2) `climbing=route` gets replaced by `highway=scramble + scramble=climbing`
> 3) Paths on the difficult end of `highway=path + sac_scale=*` get replaced by 
> `highway=scramble + scramble=alpine_hiking + sac_scale=*` (exact difficulty 
> threshold to be discussed, see below).

1. From previous discussion I got the impression that actual climbing and via 
ferrata are different from scrambling, i.e. not a type of scramble. 
2. sac_scale grading indicates the experience level and equipment needed. It 
seems odd to cut out some grades and tag them differently.


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

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

Wouldn't scramble=yes with highway=path do the trick? Hurts nobody, and carries 
the exact information you want.

Peter Elderson

> Op 15 sep. 2022 om 23:26 heeft Asa Hundert  het 
> volgende geschreven:
> 
> Am Do., 15. Sept. 2022 um 00:09 Uhr schrieb Peter Elderson
> :
>> 
>> I like this proposed highway value. I would probably apply it to the actual 
>> scramble sections, though, not including path sections leading up to the 
>> scramble part. Renderers can then show the actual scramble sections.
> 
> Well, that way, 5m path, 5m scramble, … you could achieve the
> dotted/dashed rendering on OSM Carto, that some of the "path"
> aficionados crave so much for, if only OSM Carto would follow their
> advise.
> 
> In earnest: Usage of the highway key originates from discussion on the
> forum, and I rather not take this lightly, it is indeed a new kind of
> highway, not another attribute of "path" that I propose.
> 
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

A sacscale isn't a thing, it's an assigned category. The same category includes 
different situations, none of which is necessarily actually present, you only 
know that at least one is there but not which one. So, if a path has a 
sac_scale which may or may not include a scramble section somewhere, sac_scale 
simply does not indicate scramble, let alone where it is, how long it is and 
other niceties.

If you split the way from just before the scramble section to just after, and 
tag only this section with appropriate sac_scale value and other attributes 
fitting for a scramble, that is a better indication, but it still does not say 
it's a scramble. 

Peter Elderson

> Op 15 sep. 2022 om 20:53 heeft Janko Mihelić  het volgende 
> geschreven:
> 
> 
> čet, 15. ruj 2022. 19:57 Peter Elderson  je napisao:
>> I know, but the scale does not indicate specific things you encounter, just 
>> that somewhere along the way you will be challenged. 
> 
> 
> That isn't true. If you tag a relation with sac_scale, then it is as you say. 
> But if you tag a way with sac_scale, then this says "this sac_scale is 
> exactly here, along this whole way".
> 
> Janko
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

I know, but the scale does not indicate specific things you encounter, just
that somewhere along the way you will be challenged.

To map a specific type of path, say, a scramble, none of the sac_scale
values specifically indicates that it is in fact there.
If you try rendering hand-and-foot climbs for hikers, comparable to how you
would render steps, or a busway, you cannot be sure that a specific
combination of sac_scale tags and maybe other tags indicates the presence,
length, course and location of the scramble. The same goes for any data
user who wants to do anything with scrambles.

You could argue a scramble is not a thing, or it is not important enough to
warrant special mapping, but complex categories and side attributes do not
a scramble make.

Peter Elderson


Op do 15 sep. 2022 om 18:53 schreef Yves via Tagging <
tagging@openstreetmap.org>:

> Peter, the sac_scale definition on the wiki is quite thorough.
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

Then you still cannot indicate "this is a scramble section", only that it
may be a scramble section OR something else making the section fall into
that sac category.

So I think highway=scramble does add information, enabling data users to
search, select, deselect, process and present the feature as they see fit.
Same as e.g. highway=steps.

Is it worth the effort? Don't know.
Will it render? Don't know, that's up to the renderer.
Can people use it for their own map style or application? Yes, if it's
clearly and uniquely mapped they can, but will they? Don't know, that's up
to them.

Peter Elderson


Op do 15 sep. 2022 om 17:43 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 15 Sep 2022, at 17:34, Peter Elderson  wrote:
> >
> > If you specifically want to know where the scramble sections are, the
> sac_scale doesn't tell you, correct?
>
>
> it depends how fine grained you tag sac_scale, on a hiking route it only
> tells you the most difficult level you will encounter, but not where and
> for how long, but on single way segments you can tag the difficulty in an
> atomic way
>
> Cheers Martin
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

So, a selection of sac_scale values may or may not include scramble
sections, beside other posible obstacles/hazards/challenges. If you
specifically want to know where the scramble sections are, the sac_scale
doesn't tell you, correct?


Op do 15 sep. 2022 om 15:23 schreef Janko Mihelić 

> čet, 15. ruj 2022. u 14:52 Peter Elderson  napisao
> je:
>
>> Which combination(s) of highway values, sac scale values and hazard
>> values would exclusively represent a scramble (Dutch verb: klauteren, i.e.
>> going up or down there using hands and feet) to a grown-up, non-challenged,
>> average hiker without climbing skills and without special gear other then a
>> cane, hiking shoes and gloves?
>>
>
> Any of the three combinations:
>
> highway=path + sac_scale=alpine_hiking
> highway=path + sac_scale=demanding_alpine_hiking
> highway=path + sac_scale=difficult_alpine_hiking
>
> Janko
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

Which combination(s) of highway values, sac scale values and hazard values 
would exclusively represent a scramble (Dutch verb: klauteren, i.e. going up or 
down there using hands and feet) to a grown-up, non-challenged, average hiker 
without climbing skills and without special gear other then a cane, hiking 
shoes and gloves?

Peter Elderson

> Op 15 sep. 2022 om 14:07 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
> We are having this discussion despite we already have the necessary tags to 
> describe all relevant aspects, only because some map data consumers do not 
> take them into account. And these tag are not only used, they are completely 
> established (sac scale, trail visibility, hazard, etc.). There will always be 
> people acting irresponsibly, people driving their cars into subway entrances 
> because it looked as if it was possible on their satnav. The best map will 
> not prevent this, and they will probably take these paths even if they are 
> not on their map. If some map publishers do not distinguish more difficult 
> paths from simpler ones, and people get into problems because of this, it 
> should be raised with them, in OSM the information is already available.
> 
> Otherwise, where will it stop, are we going to remove places from the map 
> where people are robbed or shot much more often than in others? In the past, 
> people wanted to tag perceived (or actually statiscally proven) dangers in 
> some urban areas in places with big social and economical heterogenity. 
> 
> Cheers,
> Martin
> ___
> 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] Feature Proposal - RFC - highway=scramble

[Peter Elderson]

I am a hiker, not a climber. I remember lots of sections I would have avoided 
if the map had shown them as scrambles. More adventurous people probably would 
seek them out. I like this proposed highway value. I would probably apply it to 
the actual scramble sections, though, not including path sections leading up to 
the scramble part. Renderers can then show the actual scramble sections. For 
routers, it doesn't really matter, because when a section of a path is a 
scramble and you use say a no scramble profile, the route over the path will 
get high penalty and will not gain preference.

If a sign says a path will make you scamble somewhere, map the sign and the 
actual scramble(s), that's what I would do.

Peter Elderson

> Op 14 sep. 2022 om 23:47 heeft martianfreeloader 
>  het volgende geschreven:
> 
> In the real world, you will *always* find borderline cases for *any* 
> property.
> 
> I don't think it should be an argument against a good proposal. If it were, 
> then it could be used against literally *any* tag on osm. (and funnily it 
> reliably does come up with any new proposal)
> 
> 
> 
> 
>> On 14/09/2022 22:59, Mateusz Konieczny via Tagging wrote:
>> The main problem here is that different people will need (or do not need) to 
>> use hands,
>> it also heavily depends on weather and other considtion
>> How we would deal with such borderline cases?
>> via ferrata value is far more likely to succeed and I would recommend trying 
>> to get it first
>> Sep 14, 2022, 11:42 by hungerb...@gmail.com:
>>It is proposed to create the tag highway=scramble as a base tag for
>>hiking paths, where use of hands is required, be that for keeping
>>balance or be it for pulling up.
>>Please discuss this proposal on its Wiki Talk page,
>>
>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/highway%3Dscramble
>>
>> <https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/highway%3Dscramble>
>>Thank you in advance
>>Asa
>> ___
>> 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

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[Peter Elderson]

Option 1
addr:range=* specifies the increment

addr:range=even
addr:housenumber=2..250

if .. is used, a hyphen combined with a range can be handled.

addr:range=odd
addr:housenumber=200-01..200-91

In these examples, a default of 2 would simplify things: .. infers a range,
increment is default 2 and - is never a range indicator.

Error to be expected: people just copying the housenumber plate may use
2-250.
When using the explicit addr:range tag, the format error may be detected
because .. is missing.

Peter Elderson


Op do 24 dec. 2020 om 15:12 schreef Paul Allen :

> On Thu, 24 Dec 2020 at 10:14, Martin Koppenhoefer 
> wrote:
>
>> maybe we should add an expression marker, like {10..20} to make it more
>> explicit and avoid confusion with typos?
>>
>
> In programming, you also have the ability to define the increment,
> which defaults to 1 if left unspecified.  That way you can distinguish
> between 10, 11, 12, 13, 14, 15, 16 and 10, 12, 14, 16 (or even
> 10, 13, 16).  You could argue that for addresses the increment
> ought to default to 2, since that is most commonly encountered.
>
> --
> Paul
>
> ___
> 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] Feature Proposal - RFC - Tag:traffic_calming=hillocky

[Peter Elderson]

I'd say they are small mounds.

Hillock sounds too, er, hilly.

Peter Elderson


Op zo 20 dec. 2020 om 11:39 schreef ael via Tagging <
tagging@openstreetmap.org>:

> > I'm uncomfortable with hillock/hillocky as a value.
>
> "Hillock" is quite common in British English, not that I am comfortable
> using it as a tag.
>
> ael
>
>
> ___
> 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] The saga of landuse=reservoir vs water=reservoir

[Peter Elderson]

I'll tag both ways then, or better map none at all? Shirt, another dilemma.
I need something stronger than tea.

Peter Elderson


Op wo 16 dec. 2020 om 17:04 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> Dec 16, 2020, 16:49 by tomasstrau...@gmail.com:
>
> 2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
>
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and common way of rendering things.
>
>
> How do you decide that it is most typical and common way of rendering
> things?
> ALL maps I created or seen in GIS/Cartography world, be it online or
> printed, interpret water classes differently, especially
> basins/riverbanks...
>
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
>
> https://www.openstreetmap.org/#map=14/54.3643/18.7150
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=C
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=T
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=H
> <https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>
>
> In contrast
> https://www.openstreetmap.org/#map=14/54.3666/18.7138=O
> <https://www.openstreetmap.org/#map=14/54.3666/18.7138=T>
> appears to distinguish seas/oceans
>
> Best system is to use codes, not names for keys/values, but that is a
> totally different "saga".
>
> Feel free to propose this one.
> ___
> 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 put a name tag on an area with more than one type?

[Peter Elderson]

stevea :

> (Personally, I find JOSM’s relation editor to be one of its most elegant
> features for a data structure as relatively complex as a relation.
>

I am not qualified to judge elegance, but I find JOSM's relation editor the
best there is. I don't think relations are very complex data structures,
but the construct is versatile. It's what people do with them that makes it
complex. But hey, the same goes for the node, the way and the area.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Peter Elderson]

Colin Smale  het volgende geschreven:
> 
> 
>> 
>> On 2020-12-13 21:53, Peter Elderson wrote:
>> 
>> Just to clarify:
>>  
>> > crossing=priority Indicates that the node is a pedestrian crossing  
>> when applied to highway=cycleway, should this read bicycle crossing?  
>>  
>> when applied to a highway=cycleway, does the tag imply priority for 
>> cyclists, pedestrians, or both?
>>  
> And what happens if a cycleway crosses a footway, as happens commonly here in 
> the Netherlands?
>  
> We also have an analogous problem here where cycle tracks cross roads. In 
> many (but nowhere near all) cases the cycleway has priority

To be clear, traffic from the right has priority, unless signing indicates 
otherwise. Pedestrians have to give way, unless zebra marking indicate they 
have right of way. Dismounted cyclists count as pedestrians. Flashing bulbs 
have been banished a long time ago, in favor of (fluorescent or backlighted) 
"zebra ahead" warning signs.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - crossing=priority

[Peter Elderson]

Just to clarify:

> crossing=priority Indicates that the node is a pedestrian crossing  
when applied to highway=cycleway, should this read bicycle crossing?

when applied to a highway=cycleway, does the tag imply priority for
cyclists, pedestrians, or both?

> belisha_beacon=yes|no
Is belisha beacon a generally known term outside the UK?
Since only presence is significant,  the value no is useless

> segregated=boolean (yes/no) (no default assumed)

Since the proposal talks about pedestrians, cycleways and horses crossing:
what exactly is segregated when segregated=yes is applied to a cycleway?
And with segregated=no, do motorists get a warning that horses may cross on
the cycleway?


Peter Elderson


Op zo 13 dec. 2020 om 21:08 schreef ipswichmapper--- via Tagging <
tagging@openstreetmap.org>:

> Yes, most likely this won't be required. However I have kept it there in
> case it works differently in other countries. Maybe not all zebra crossings
> in Singapore have belisha beacons (for example, I don't know if this is
> true). That is why I am leaving it open for discussion for now, if after
> the RFC it is decided that this is a bad idea I'll remove it.
>
> Thanks,
> IpswichMapper
>
> --
>
>
> 13 Dec 2020, 19:50 by tagging@openstreetmap.org:
>
> It seems to be proposing also belisha_beacon=yes that
> is now unused
> https://taginfo.openstreetmap.org//search?q=belisha_beacon%3Dyes
>
> At the same time it has
> "However, in countries like the UK, where belisha beacons are used, every
> single zebra crossing has belisha beacons installed, so there is no need
> to tag them"
>
> There is also
> "Indicates the presence of a "belisha beacon" at the crossing. (Most
> likely unnecessary, discuss below)"
>
> Given there is no indication that it would be useful or needed I think
> that it should be not proposed.
>
> If that it would be useful or needed it can be proposed separately.
>
> Note that having two proposals in one will result in people voting against
> if there are against any of them, so splitting would be a good idea
> anyway.
>
> Dec 13, 2020, 20:25 by tagging@openstreetmap.org:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority
> <https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dpriority#Tagging>
>
> Here is my first proposal for a tag to describe pedestrian crossings where
> the pedestrian has right of way over all vehicles on the road from the
> moment they have indicated their intent to cross. I created this because
> "crossing=zebra" or "crossing=marked" aren't clear enough. Please read the
> proposal for more details.
>
> Thanks,
> IpswichMapper
>
>
>
> ___
> 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 put a name tag on an area with more than one type?

[Peter Elderson]

My answer only targets the question in the subject.

No matter whether you put the same name on all parts, or on or some kind of
collective, you need a way for data users to know that all the parts
together have a name.
Tagging the same name on all parts makes the name a free text id
needing uniqueness - for me a bad choice.
Yet another polygon around the area, don't like that. I think we have too
many of those already.
Tagging all parts with a truly unique Id in a special key could do the
trick, but who issues/manages the unique ids?
Putting the parts as members in a relation achieves the same: a unique Id
common to all the parts; the name tag and possible other common attributes
go on the relation.
This gives renderers the exact extent of the total area, and the extents of
the subareas, which can have names and other attributes of their own.
Since an MP does not cover all possible layouts, you would need a different
type of relation. Maybe an existing type can be used, or a specialised type
can be defined.

I would think a pilot project could test the concept for mappers, renderers
and other data users. If succesful, showcase. If not, document and delete.

Peter Elderson


Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :

> Hello,
>
> I was on this list a while back expressing some frustration over
> limitations when tagging nature and thought about getting involved in a
> process for change, but I came to realize that it's not feasible for me
> in my current life situation, so I've decided to continue be a normal
> mapper as before, doing what I can do with features that exist today.
>
> Anyway, if to be a mapper at all, I still like to solve some of my
> naming issues in the best/least bad ways possible today. I'm currently
> mapping a national park in Sweden, Muddus. It's in Laponia and consists
> of mighty wetlands and old forest. These wetlands are named, like is
> common in Sweden and Sami lands. For us navigating in wildlife, names in
> nature are important.
>
> A wetland polygon can be named in OSM, so the situation is better than
> for example for named slopes (also common). However, a wetland here can
> consist of both bog and marsh (and it's important to make the
> difference, since one is easy to walk on, the other not so much). That's
> two different natural types and thus can't be in the same multipolygon
> (as outers).
>
> Asking on OSM Help website for a solution I got the answer to make a new
> containing multipolygon and set the name on that. That would be quite
> elegant for sure, but JOSM warns about that, can't have a name without a
> type, and if I set the type, say natural=wetland without any subtype, I
> get a JOSM warning that I have natural features on top of eachother. If
> I still upload it OSM-Carto does render out the name but you can see
> that the wetland pattern of the outer polygon is drawn on top of the
> contained polygons, so it does not seem to be the way to do it.
>
> The least bad way I've come up with is to just name all polygons
> belonging to the same wetlands the same, and hope for that in the future
> smart renderers will understand that polygons with shared borders and
> shared name is the same named entity.
>
> Any ideas or suggestions?
>
> /Anders
>
> ___
> 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 put a name tag on an area with more than one type?

[Peter Elderson]

Actually, there is no Rijn in Rotterdam. But that does not change the argument.

Mvg Peter Elderson

> Op 11 dec. 2020 om 18:11 heeft Christoph Hormann  het 
> volgende geschreven:
> 
> 
> 
>> Anders Torger  hat am 11.12.2020 17:07 geschrieben:
>> 
>> The least bad way I've come up with is to just name all polygons 
>> belonging to the same wetlands the same,
> 
> That is widely considered to be the correct way.  It is established practice 
> that mapping things like forest, wetland, farmland etc. can be split to 
> differentiate tagging (like leaf_type, wetland type, crop etc.).  The name 
> tag is then applied to all components.  Same as for waterways or roads where 
> you can also split and apply the name to the components.
> 
> This also matches the general concept in OSM that names are typically local 
> properties and only locally verifiable.  The Rhine river is called Rhein in 
> Koblenz but Rhin in Strasbourg and Rijn in Rotterdam.
> 
> -- 
> Christoph Hormann 
> http://www.imagico.de/
> 
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

[Peter Elderson]

Mass testing without the strict isolation doesn't work, no matter how
important the sport or the person. Strict isolation (not 'bubbles') without
mass testing will work.
Anyway, It's almost done, then all temp structures and facilities will
disappear in favour of soon forgotten "quick response" plans.

Peter Elderson


Op do 26 nov. 2020 om 21:07 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Do., 26. Nov. 2020 um 18:35 Uhr schrieb Peter Elderson <
> pelder...@gmail.com>:
>
>> Well, mass testing did not stop the virus anywhere, it just costs a lot,
>> drives people to despair and boosts the numbers.
>>
>
>
> this is off topic here, but apparently the Chinese have succeeded in
> stopping the pandemic there, by strict isolation and mass testing whenever
> a new case was discovered somewhere.
>
> Cheers
> Martin
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

[Peter Elderson]

Well, mass testing did not stop the virus anywhere, it just costs a lot,
drives people to despair and boosts the numbers. Anyway, as soon as
vaccination becomes common practice, COVID-19 is just another virus
disease  you can get vaccinated against in a regular way, same as others.
All the special facilities will disappear. OSM-forums will carry on the
debate whether they should be tagged as historic or abandoned until the
next pandemic.

Peter Elderson


Op do 26 nov. 2020 om 15:59 schreef Paul Allen :

> On Thu, 26 Nov 2020 at 02:35, stevea  wrote:
>
>> I'm in California, where it's almost cliché we love our cars and car
>> culture, but it is true that not only here but in many USA states, we have
>> "drive-thru" COVID-19 testing centers.
>
>
> In the UK we don't have much of a drive-thru anything except maybe some
> fast-food outlets of American origin.  Yet all the covid-19 testing
> centres I'm
> aware of are strictly drive-thru.  As in you're not allowed to turn up on
> foot,
> because if you're infected you may pass it on to other pedestrians you walk
> near.  And they're drive-thru because the swabs are taken in the open.
> The swabs are taken in the open because there is far less risk of
> transmission outdoors than indoors.
>
>
>>   I would guess that vaccination centers that are also "drive-thru" are
>> likely soon (early 2021?), too.
>
>
> The same reasons that make the test centres drive-thru apply to
> vaccination centres.  Eventually, when we have herd immunity
> (one way or another) indoor vaccination may be feasible (but
> probably undesirable).  The health workers will be vaccinated
> first so they won't be at risk either way, but these places will
> be handling large numbers of people and having them all wait
> indoors is a good way of infecting lots of people.
>
>
>>   These being mapped with "indefinite duration" seems a bit much (sorry,
>> Brian), but they are usually more of a "pop-up" kind of thing:  one-time or
>> "only on Saturdays" or something like that.
>
>
> There is a temporary, short-duration, won't be there for long, test centre
> just
> popped up in my town because a couple of weeks ago some idiots decided
> to celebrate the end of firebreak restrictions by going to the pubs and
> ignoring social distancing completely.  Fifty-five cases came of that, and
> three hundred contacts have been traced.  I expect it to go away in a few
> weeks if the outbreak gets under control.  I'm not confident the outbreak
> will be under control very soon because a lot of the celebrants were
> shop workers.
>
> But as well as that pop-up test centre because of the sudden surge, there
> is an existing test centre.  That's based at the leisure centre that was
> converted to an emergency overflow hospital several months ago. I only
> found out the test centre was there a few days ago because we try to
> keep their locations secret, so I probably won't map it.
>
> Vaccination centres are going to handle more people than test centres
> do because nearly the entire population will have to be vaccinated but
> only a very small fraction of the population is tested (we ought to be
> testing everyone at least once a week, but my country's government
> is somewhat incompetent).
>
> --
> Paul
>
> ___
> 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] RFC: vaccination / COVID-19 vaccination centres

[Peter Elderson]

We (Nederland) will likely use the flu vac system of local practitioners
and old people's homes to do groups at risk first, and health care
personnel will take care of themselves while administering.Will take two to
three weeks for the first shot, and if a second shot is needed, 6 weeks.

The rest will probably need to apply, and I think the Covid testing
facilities will be used for the mass vax. This will probably take months,
mainly because of supply chain and cold chain problems. Everybody will
turn into an opportunist, politicians will literally lose their voices
because of all the yelling at each other. Then it will become a standard
yearly vaccination and we will all return to normal. O, the stories we will
tell our grandchildren when they really just want to hang out with each
other and play games...

Best, Peter Elderson


Op wo 25 nov. 2020 om 22:33 schreef Paul Allen :

> On Wed, 25 Nov 2020 at 20:01, Philip Barnes  wrote:
>
> Although in this case I would expect the approach to be to set up sessions
>> for schools, universities and at larger employers and for the general
>> population it will simply attend an appointment at their local medical
>> centre.
>>
>
> Even back in the Before Times, flu jabs were not given at the local medical
> centre but in a large exercise hall.  I think that was more to do with
> numbers
> than anything else.  Covid is more infectious than flu (but less so than
> measles)
> and the indications are strong that you're at a lot greater risk indoors
> than
> outdoors.
>
> I doubt that testing or vaccination will take place at local medical
> centres.  All
> the testing centres I know of, whether short-term or longer-term have the
> testing conducted outdoors.
>
> Right now, because of a recent surge in cases in my town the medical
> centre is only permitting people to turn up if they get an appointment
> because it is "absolutely necessary" (their words, not mine) they see
> a doctor.
>
> I've been paying a lot of attention to this stuff (because of underlying
> health conditions which mean I'm very unlikely to survive it) and I
> seriously doubt we'll see testing or vaccination conducted indoors
> until all medical staff have been vaccinated and enough of the
> general population have been vaccinated to achieve herd
> immunity.
>
> --
> Paul
>
> ___
> 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] Tagging Cycle Route Relations vs. Ways

[Peter Elderson]

I see changeset source tags as the source(s) used for the work, not
necessarily the source of every change in the changeset.
Most of the source tags I see state the original source of the object, not
the latest source. The original source does not change when a tag or the
geometry is altered.

The history of objects tells me who has touched it, what has changed, but
not why and what the source was, and the associated changeset tags usually
only tell me why the object was affected, but nothing specific for the
object (unless the object happens to be the only thing changed in the
changeset).

I would rate this information: sometimes useful but not very reliable.
Technical improvements will not fix this.  What the mappers put there could
do with improvement. The challenge is how to get the mappers to do it.

Peter Elderson


Op wo 18 nov. 2020 om 19:09 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> Am Mi., 18. Nov. 2020 um 13:19 Uhr schrieb ael via Tagging <
> tagging@openstreetmap.org>:
>
>> On Wed, Nov 18, 2020 at 12:09:40AM +0100, Martin Koppenhoefer wrote:
>> We have tags like source:name and source:outline for more specific
>> tagging.
>>
>
>
> yes, every tag could get a source tag. It would mean a lot of additional
> work for mappers, and the benefit would probably be very small. Usually
> when you check an object for its correspondence with reality, you either
> find the tags accurate or wrong, for various reasons they could be wrong,
> most likely is a change of the thing in the real world. A source tag will
> not help you with this. To me, the most interesting information when
> looking at an edit is whether the person has been on the ground or not.
> source=Bing does not really tell you this, because many people use it when
> they are adding information and Bing is visible in the background, but it
> does not mean that every piece of information that they add actually comes
> from Bing.
>
>
>
>
>
>>
>> > From a practical point of view, I am mostly ignoring source tags,
>> because
>> > they are almost never accurate. Typically someone has added them some
>> > versions ago and nobody in between has bothered to remove or update the
>> > tag. To know this, you will have to dive into the object history anyway.
>>
>> Then  you are part of the problem :-) It is very annoying when the
>> source tag is accurate until someone, nearly always an armchair mapper,
>> who comes along and changes things without updating the source tag.
>>
>
>
> Most source tags I see are source=Bing and when I add information from a
> survey, I either do not change it, or sometimes I remove it because it is
> not valid any more at this point.
>
>
>>
>> Let's encourage people to use the source tag properly rather than cause
>> further decay. Or come up with a better solution, which is definitely
>> not a changeset comment.
>
>
>
> the changeset "comments" are actually structured tags, and from past
> discussions it is the preferred way over source tags on individual items.
> Source tags on items are the older method, they have already proven to fail
> in real world conditions in OSM ;-)
>
> Cheers
> Martin
> ___
> 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] Tagging Cycle Route Relations vs. Ways

[Peter Elderson]

AFAIK, a relation is meant to represent an entity of its own, which can be
observed and verified in the field.
Its tags should be the tags of this entity, not the tags shared by the
members. It's not a relational database model.

If many streets are called "Polygon Alley" you tag each one with
name=Polygon Alley. No normalization applies, just tag it.
Best, Peter Elderson


Op ma 16 nov. 2020 om 18:17 schreef Seth Deegan :

> Honestly I think I'm just confused.
> I guess ways *do have* official names, it's just that I keep on thinking
> about the possible *conceptual* conflicts between two different Routes
> under one way (this statement probably doesn't make sense).
>
> Also, I'm someone who loves relations and finds myself thinking about
> putting all of the elements that share a tag under a relation constantly!
> I guess just keeping them in their original Ways is the way to go.
>
> However, *if there was a way* to indicate the "primary" relation for a
> Way, then I'd be all for it.
> IDK. Save space wherever possible seems to be the common theme.
> Problems with this though would be that renderers/data consumers would
> have to go into the relation every time they want to find more tags for an
> element.
> There are pros and cons. I'm also aware relations aren't categories.
>
> Thank you for the clarification.
>
> On Mon, Nov 16, 2020 at 10:55 AM Hidde Wieringa 
> wrote:
>
>> Hello,
>>
>> Route relations 'group' together the nodes/ways/relations that form a
>> cycling route. The nodes/ways/relations themselves should not be tagged
>> with the name of the route, like you quoted the wiki.
>>
>> The name of a way should be the official name of the way, not the name of
>> the relation(s) that way is part of. I refer to Key:name [1] which states
>> "The names should be restricted to the name of the item in question only
>> and should not include additional information not contained in the official
>> name such as categories, types, descriptions, addresses, refs, or notes."
>>
>> So the question remains for the ways you mention that are tagged with
>> name of the cycling route. Are those ways officially named exactly as the
>> relation name? If not, I would classify this situation as 'tagging for the
>> renderer' (getting the renderer to show the name of the cycling route).
>>
>> On the subject of rendering: there are many renderers that show cycling
>> route relations [2]. Some of them [3] are even advanced enough to grasp the
>> concept of 'superroutes'/'parentroutes' [4] that are common when tagging
>> gigantic routes that span Europe like the EuroVelo cycling routes [5].
>>
>> Kind regards,
>> *Hidde Wieringa*
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:name
>> [2] https://wiki.openstreetmap.org/wiki/Cycle_routes#Rendered_cycle_maps
>> [3] https://cycling.waymarkedtrails.org
>> [4] https://wiki.openstreetmap.org/wiki/Relation:superroute
>> [5]
>> https://cycling.waymarkedtrails.org/#route?id=2763798=4!57.9189!7.9873
>>
>>
>> On 16-11-2020 17:17, Seth Deegan wrote:
>>
>> The Cycle Routes Wiki Page
>> <https://wiki.openstreetmap.org/wiki/Cycle_routes#Tagging_cycle_route_networks>
>> states:
>> "It is preferred to tag the cycle routes using relations instead of
>> tagging the ways."
>>
>> If I come across a route that has the Ways already tagged with the name
>> <https://wiki.openstreetmap.org/wiki/Key:name>=* of the route, can I
>> delete the name <https://wiki.openstreetmap.org/wiki/Key:name>=*s in the
>> Ways and just create a Route Relation with the name?
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>> However, some benefits of doing this might be:
>>
>>- Takes up less space in the DB
>>- More tags that apply to the whole coute could be added to the
>>Relation like surface
>><https://wiki.openstreetmap.org/wiki/Key:surface>=* and source
>><https://wiki.openstreetmap.org/wiki/Key:source>=* (like the official
>>map of the route).
>>- Ways with two or more routes wouldn't be tagged name
>><https://wiki.openstreetmap.org/wiki/Key:name>=route 1 & route 2
>>
>> <https://wiki.openstreetmap.org/w/index.php?title=Tag:name%3Droute_1_%26_route_2=edit=1>
>>  and
>>instead have their respective Relations. This could help with preferred
>>routing/data usage in general.
>>
>>
>> I would propose th

Re: [Tagging] Deprecate water=pond?

[Peter Elderson]

Ah, profiling! Hadn't thought of that yet.

Best, Peter Elderson


Op vr 13 nov. 2020 om 10:18 schreef Michael Patrick :

>
> I am surprised nobody has suggested a pondness or lakicity scale yet.
>>
>
> It isn't unusual outside of OSM for relative percentages of the different
> meanings to be accounted for. For example for Great Pond (
> https://www.topoquest.com/map.php?lat=44.5=-69.8=nad83=16
> ) with a surface area of 13 square miles
>
> lake 15%
> reservoir 84%   ( volume added to the original lake by the dam )
> pond 1%
>
>
>
> <#m_2101975028351855335_m_-6680278241776399936_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Deprecate water=pond?

[Peter Elderson]

I am surprised nobody has suggested a pondness or lakicity scale yet.

Best, Peter Elderson


Op do 12 nov. 2020 om 02:46 schreef stevea :

> If we're going to do "this:"
> > So perhaps we could create a new tag water=natural_pond for small,
> natural or semi-natural lakes which are currently tagged as water=pond, and
> water=artificial_pond or water=man_made_pond for the majority of water=pond
> features which are clearly not natural, such as ponds in gardens.
>
> it seems we should ponder (sorry, couldn't resist) the myriad
> possibilities for ponds both artificial AND natural and make a formal
> proposal that "covers all cases," at least as best we can in a formal
> proposal.  This would clarify (sorry, couldn't resist) what they're all
> "used for," as in settling in the case of a wastewater treatment plant,
> decorative as in somebody's backyard garden, natural, as in "shallow,
> nature-created, not-deep-enough to be called lake..." and so on.  Don't
> forget to consider (and document) potential overlap with things like
> leisure=swimming_pool and possibly others.
>
> We might get a good start on doing this in a talk page, but I think it
> would greatly benefit from the thought that goes into a formal proposal:
> worldwide consideration of the semantic space being described, rather clear
> syntax and namespaces described, how to decide one from the other,
> linguistic differences (as Joseph mentioned there can be a flattening in
> particular languages that might deserve extra clarity), how to migrate from
> existing tagging to the proposed tagging, and all the rest that formal
> proposals treat (what wiki need to update, et cetera).
>
> I admire Joseph's "tossing here" what he wrote, as it gets things started,
> but I believe the subject is much richer than this.
>
> It would also focus efforts by those who care and in as much detail and in
> one place as such a specific topic deserves.  While I don't write this to
> discourage posts to this list (I don't, as this list is a valuable place to
> discuss), I have also noticed a trend towards formal proposals.  "Ponds"
> seems like an excellent candidate for one.
>
> SteveA
> ___
> 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] Deprecate water=pond?

[Peter Elderson]

There is no "it". Everybody has their own "it", and even that may be
inconsistent.
I am not opposed to ponds and lakes - I just don't see a common definition
coming up without "generally" (but not always), "typically"(but may be
different), "usually"(except where it's not), "in most countries" (but not
everywhere) etc etc.

I don't think most bodies of water can be tagged as pond or lake by any
common standard, in a way that all agree. Nor do I think that is a problem.

Best, Peter Elderson


Op wo 11 nov. 2020 om 19:51 schreef Brian M. Sperlongano <
zelonew...@gmail.com>:

>
>
> On Wed, Nov 11, 2020 at 12:29 PM Peter Elderson 
> wrote:
>
>
>> Everybody knows a difference,
>>
>
> If "everybody knows it", then let's define what that difference is and
> write it down.  That is why this list exists.  It is a bad idea to presume
> that different cultures and languages share a common understanding and
> terminology.  The reason we are even discussing this in the first place is
> precisely because the difference between pond and lake is not universally
> clear.
> ___
> 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] Deprecate water=pond?

[Peter Elderson]

I am getting a foot vs hiking feeling. Everybody knows a difference, nobody has 
the same difference. In the end, it does not matter.

Mvg Peter Elderson

> Op 11 nov. 2020 om 16:02 heeft Brian M. Sperlongano  
> het volgende geschreven:
> 
> 
> If the consensus is to go with a limnological definition - I think that's 
> fine.  Let's lay out the limnological description of "pond" and "lake" and 
> let mappers sort out edge cases based on their best interpretation of the 
> definitions provided.  That's no different than the wetland= tag in which 
> there are lots of edge cases in the real world that are not quite one or the 
> other.  I assume there will be cases where "such and such pond" is properly 
> tagged water=lake and vice versa, but that's fine if there's a definition to 
> stand on.
> 
> If we are going with a "what people call it" definition, then the distinction 
> is purely redundant and worse may not translate appropriately into other 
> languages which might have a different array of terms for such bodies of 
> water.
> 
>> On Wed, Nov 11, 2020 at 8:30 AM Paul Allen  wrote:
>>> On Wed, 11 Nov 2020 at 13:12, Brian M. Sperlongano  
>>> wrote:
>> 
>>> Is it actually desirable to distinguish a "lake" from a "pond"?  If so, 
>>> what is the difference?  Is it just that a body of water is named "XYZ 
>>> Pond" versus "XYZ Lake"?  If so, isn't water=pond versus water=lake derived 
>>> from and redundant with name?
>> 
>> It's possible to make the distinction.  It's not clear-cut.  There are 
>> several
>> definitions which are not entirely compatible with each other, but they
>> have more similarities than differences.  Edge cases are hard.
>> 
>> See, for example:
>> 
>> https://lakes.grace.edu/ponds-vs-lakes-whats-the-difference/
>> https://www.lakemat.com/whats-the-difference-between-a-lake-and-a-pond/
>> https://www.des.nh.gov/organization/commissioner/pip/factsheets/bb/documents/bb-49.pdf
>> https://www.lakescientist.com/lake-facts/how-lakes-differ/
>> 
>> Most of them agree that lakes have aphotic zones (deep areas that receive
>> no sunlight, preventing plants from growing there).  But wave height, 
>> uniformity
>> of temperature, and area of water may play a part.  And, of course, there's 
>> what
>> the locals call it.
>>> 
>>> Is there a conceivable scenario where a data consumer or renderer would 
>>> care about the distinction between these two tags?
>> 
>> Renderers will probably treat them identically  A limnologist would find the
>> distinction useful. 
>> 
>> There is also a distinction between pools and ponds.  However, since pools
>> are supplied by a spring or a stream, most can be distinguished by other
>> water=* occurring in conjunction with them (a lot of the ponds I've mapped
>> are actually pools).
>> 
>> https://www.askdifference.com/pool-vs-pond/
>> 
>> -- 
>> Paul
>> 
>> ___
>> 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

Re: [Tagging] Deprecate water=pond?

[Peter Elderson]

The problem is that natural and artificial are not neatly separated IRL. In 
Nederland, nature is neatly cut, shaven and shaped. Currently, natural style is 
preferred. "New nature" is the hype, where heavy machinery creates new 
landscapes including ponds, lakes, streams and wetlands. Sea dykes are shaped 
like dunes. Etc. So every pond is made to look natural, and every lake is 
reshaped and maintained. 

We have words for pond ("vijver") and lake ("meer") but very loosely defined, 
and many more terms for other bodies of water. 

I think a clearcut definition would not help at all in this case.

Peter Elderson

> Op 10 nov. 2020 om 06:30 heeft Joseph Eisenberg  
> het volgende geschreven:
> 
> 
> The tag water=pond was added with a large number of other types of "water=*" 
> in 2011, but it has a poorly defined description. 
> 
> "A pond: a body of standing water, man-made in most cases, that is usually 
> smaller than a lake. Salt evaporation ponds should be tagged with 
> landuse=salt_pond, open-air swimming pools — with leisure=swimming_pool."
> 
> So it might be artificial, like a landuse=reservoir or water=reservoir, but 
> smallish. Or it might be natural like a water=lake, but smallish. However, 
> nothing on the water=lake page defines a lower limit for the size of a lake.
> 
> This is a shame, because all the other values of water=* are clearly defined 
> as only natural, or only artificial, and waterway=* features are also clearly 
> divided. Furthermore, the original lags landuse=reservoir and landuse=basin 
> were also clearly artificial, while lakes were natural.
> 
> But the biggest problem is that there is no way to define a lower size for a 
> lake or reservoir, or an upper size for a pond. And the size of the area is 
> easier available from the geometry of the feature, so it doesn't need to be 
> mentioned in the tag. 
> 
> I think the best option is to deprecate water=pond and suggest using 
> water=lake for natural lakes, even small ones, and use water=reservoir or 
> water=basin (or landuse=reservoir or =basin if you prefer) for the artificial 
> ones. 
> 
> -- 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] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Peter Elderson]

In Nederland it is a normal option to arrange a temporary mourning room 
("rouwkamer") in the house. Any room could be used. I don't think this counts 
as a mappable amenity. Most people, though, use a permanent mourning facility, 
usually with several viewing/mourning rooms because people do not die on 
schedule one at a time.

Peter Elderson

> Op 5 nov. 2020 om 19:56 heeft Joseph Eisenberg  
> het volgende geschreven:
> 
> 
> I'm not able to find any website which clearly talks about a specific 
> "mourning room", though it is certainly documented that the front room of a 
> house, often known as a "parlour" at the time, would be used to view the 
> corpse of a deceased family member. This practice is still common in 
> Southeast Asia, BTW. This room might also have been called a "sitting room", 
> and now is likely the "living room".
> 
> Do you have a link? Do you think that anyone in the 2000s is likely to be 
> confused by the term amenity=mourning_room?
> 
> -- Joseph Eisenberg
> 
>> On Thu, Nov 5, 2020 at 10:36 AM Paul Allen  wrote:
>>> On Thu, 5 Nov 2020 at 18:19, Steve Doerr  wrote:
>>>> On Thu, Nov 5, 2020 at 1:14 PM Paul Allen  wrote:
>>> 
>>>>> On Thu, 5 Nov 2020 at 08:46,  wrote:
>>>  
>>>>> amenity=mourning_room
>>>> 
>>>> Unacceptable.  "Mourning room" was the old name for what is now
>>>> known as a "living room" (and was also known as a "parlour"),  A
>>>> room in somebody's house which was pressed into use for the
>>>> display of a corpse when needed.
>>>> 
>>> 
>>> I think you'll find that's a 'morning room', defined by the OED as 'a room 
>>> used as a sitting room during the morning or early part of the day'.
>> 
>> Those existed too, if you were rich enough to have a very large house
>> and could move from room to room to follow the sun.  For most
>> people, there was only one sitting room which also served as a place
>> to put a corpse.  I thought I gave a link explaining this.
>> 
>> -- 
>> Paul
>> 
>> ___
>> 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

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

[Peter Elderson]

> rate the following "favourable", "acceptable" or "unfavourable"?
>
> amenity=mourning
>

acceptable, though I think an amenity should be a feature, not an activity


> amenity=place_of_mourning
>

favourable. Secondary tags could add details if necessary


> amenity=mourning_room
>

unfavourable. Too specific.


> amenity=viewing_arrangements
>

unfavourable. I think an amenity should describe a feature, not
arrangements.


> amenity=deceased_viewing
>

unfavourable.


> 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] religious bias - Re: Feature Proposal - Voting - (Chapel of rest)

[Peter Elderson]

place_of_mourning then? Just like place_of_worship?

One could argue that this misses the point, because it's about viewing the
deceased and you can mourn anywhere. Then again, you can worship anywhere,
but in these special places the worshipped entity is usually represented
and highlighted by objects and decorations, and often actually presumed
present. The deceased may also be just represented.


Peter Elderson


Op wo 4 nov. 2020 om 23:30 schreef Paul Allen :

> On Wed, 4 Nov 2020 at 20:50, Tom Pfeifer  wrote:
>
>> I was surprised that this tag is rushed into voting despite the arguments
>> against it even here in the tagging list discussions.
>>
>
> The proposal itself contains paragraphs indicating it is a work in progress
> rather than a finished proposal.  I would have commented but the wiki
> is using a black-hole service that has blocked a large chunk of
> addresses belonging to my mobile network because some open
> proxies were detected.  This is not really ideal for a mobile
> service where IP addresses are very volatile.
>
>>
>> Let's summarize the criticism first, and look into the alternative
>> "mourning room"
>>
>
> Not in current use in British English.  And even when it was used, it
> generally referred to the room in a house that we now call the
> "living room."  See
> https://www.vintag.es/2018/01/living-room-what-we-call-today-was.html
> Also not really suited to a large, dedicated building with more than one
> room
> for this purpose.  It's that "room" bit that is the problem.
>
> * Vollis (the proposer) 18 Sep: ""chapel" will be opposed by some for
>> being religiously connotated"
>>
>
> He was correct.  But it's rare for a proposal to get unanimous approval.
>
>>
>> * Peter Elderson 21 Sep: "I have heard mourning chapel, mourning room,
>> funeral chapel, funeral room.
>> Chapel of rest does not seem right to me"
>>
>
> As I understand it, English (British, American or any other variety) is not
> Peter's first language.
>
>>
>> * Clifford Snow 24 Sep: "Chapel of Rest" sounds to me more like a
>> marketing term not something we should be using in OSM.
>>
>
> What something "sounds like" to an individual is not a strong determinant
> of
> its propriety.
>
>>
>> * Michael Patrick 24 Sep: 'Chapel of Rest' seems to be a dated UK
>> specific term.
>
>
> It's what they're known as in my part of the UK.  So still contemporary in
> at least
> parts of the UK.
>
>
>> ... The euphemistic 'Chapel of Rest' is more generically known as
>> 'Viewing /Visitation Service',
>>
>
> "amenity=visitatation_service" makes even less semantic sense than
> "amenity=mourning_room."  It's not a term I've encountered, anyway.
>
>
>> * 27 Sep: 'Chapel of Rest' seems to be one of those terms like 'Take the
>> goat to the butcher...
>>
>
> That sentence no sense makes.
>
>
>> * 28 Sep: since OSM is an international project, my practice is to make
>> it as easy as possible for non-native English users.
>>
>
> That is why editors have translations of their presets.
>
>>
>> Indeed, the proposed value contains 'chapel' which is biased to christian
>> religion.
>
> It might be used in British English, however that is biased itself for
>> having
>>
> Christianity as a cultural background.
>>
>
> Congratulations.  You have successfully argued that we must change from
> using British English to the language of a country which has no
> religious cultural background whatsoever.  Offhand, I can't think of
> such a country but why should that stop us?
>
> "Chapel of rest" is an euphemism that avoids death-related terminology,
>> butmight be mistaken for a chapel where somebody could rest along a hiking
>> or pilgrim route.
>
>
> Except that the correct name for such a chapel is "chapel of ease" not
> "chapel of rest."
>
>
>> OSM is a map for the whole world, and it does not improve acceptance when
>>
> a bunch of old white males (such as myself) chose a biased term for a
>> feature
>>
> that naturally exists in other cultural/religious contexts as well.
>
>
> Do other religions have such places?  If so, what do they call them?  And
> can we then abstract a neutral name from that?
>
>
>> To close with an alternative, "mourning room" would be a neutral
>> alternative from my perspective, reflecting the process of mourning which I
>> suppose exists in all cultures.
>>
>
> I object to room being applied to a building which may have many such
> rooms.
> I'd have less of a problem with amenity=mourning.
>
> --
> Paul
>
> ___
> 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] Feature Proposal - Voting - (Chapel of rest)

[Peter Elderson]

woll...@posteo.de:
> 
> Dear all,
> 
> ...someone who has died before their funeral

I should hope so

> ___
> 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] Parking fee only after some time period

[Peter Elderson]

towing_penalty=no means your car is towed away for free? In Nederland, towing 
always comes with a penalty, even if you don't want your car back.

Maybe a tag for consequences should be introduced. I suggest or_else=cargone.

Best, Peter Elderson

> Op 21 okt. 2020 om 10:32 heeft stevea  het 
> volgende geschreven:
> 
> In California, a common (not quite frequent, certainly not always) 
> arrangement at malls, supermarkets and other places with parking lots (large 
> and small) is a sign that reads "you can park here for three hours, but after 
> that we have the right to tow your car away."  (Sometimes punctuated with 
> 'video surveillance active' to make the point fairly direct and that "they 
> mean business").  In my experience of driving-and-parking for many decades, I 
> personally have never gotten towed (the few times I've gone over a time 
> limit), I've never heard of anybody (that I personally know) getting towed, 
> but I have seen the extremely infrequent tow truck towing a car that has 
> likely been there a while — perhaps it was abandoned, used for illegal 
> purposes or was otherwise a public nuisance.
> 
> So, while that "moderately serious consequence" of getting towed is possible, 
> it's rare.  And, while this is not a "fee," it certainly turns into a fairly 
> large one once the bottom-line-costs, tow truck driver and storage charges 
> (per day, usually) are added together and paid to get one's car back from the 
> impound lot.
> 
> If you are writing a proposal, this is a reality in certain parts of the 
> world the proposal should consider, if it wants to convey the full situation 
> (on Earth, in cars, with humans, on parking lots).  In short, what appears to 
> be "simply" a fee can be fairly full-throated when it comes to describing the 
> entire semantic richness of the situation.
> 
> A tag like maxstay is a good beginning.  An additional tag of something like 
> towing_penalty=yes|no is a start down this road.
> 
> SteveA
> ___
> 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] Proposal to change key:man_made to key:human_made

[Peter Elderson]

Or, let's acknowledge that many distinctions are pointless because an awful lot 
of primary keys just mean "thing", so the key does not really matter, only the 
value counts. Who cares what the *  in *=bus_stop says, it's a bus stop.

Peter Elderson

>> Op 19 okt. 2020 om 19:43 heeft Martin Koppenhoefer  
>> het volgende geschreven:
> 
>> Am Mo., 19. Okt. 2020 um 15:04 Uhr schrieb Dave F via Tagging 
>> :
>> I mean, *everything* is either man made or natural. 
> 
> 
> 
> if we push this forward, humans are part of the natural world as well. Lets 
> get rid of these dichotomies, and strive for a unified vision of the world, 
> where human and nature aren't opposing poles but where the humans live in and 
> with the nature, as part of it.
> 
> And yes, if we are moving away from "man made" we can at this point also have 
> a look how the objects under this key could be organized better. I agree that 
> "artificial" would not be beneficial in this context, but rather a renaming 
> with the same issues (or even worse, think of things like "man_made=works", 
> wouldn't it be horrible to have "artificial=works"?)
> 
> 
> Cheers
> Martin
> ___
> 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] Proposal to change key:man_made to key:human_made

[Peter Elderson]

Another illusion shattered... where is this world going to?

Best, Peter Elderson

> Op 19 okt. 2020 om 13:48 heeft Jo  het volgende 
> geschreven:
> 
> 
> It would be best to first consider the consequences of such a change. Weigh 
> the benefits against what we lose in time (humanhours?) and resources/energy. 
> And then there is still the point that many objects will get new timestamps 
> for a change that's not really a change.
> 
> Anyway, artificial sounds like made up to me. artificial=dyke, not really a 
> dyke, but it looks like it.
> 
> man_made has the advantage of being succinct. Most people will immediately 
> understand what is meant by it. Almost nobody will think women were not 
> involved in the creation of the feature.
> 
> Polyglot
> 
>> On Mon, Oct 19, 2020 at 12:42 PM Robert Delmenico  wrote:
>> Nice investigating Nathan,
>> 
>> I would be open to using artificial instead of human_made.
>> 
>> 
>> Would it be best to change the proposal or start a second proposal?
>> Change man_made= to artificial=
>> 
>> Rob
>> 
>> 
>>> On Mon, 19 Oct 2020 at 21:14, nathan case  wrote:
>>> Pros and cons aside, “human-made” is not a term that is in current 
>>> widespread usage. As a native English GB speaker, I find it clunky and 
>>> somewhat distracting.
>>> 
>>> A better gender neutral term might be “artificial”, which is already a 
>>> synonym for “man-made” and is already widely used. 
>>> 
>>> Indeed, the Handbook of Nonsexist Writing suggests: "artificial, handmade, 
>>> hand-built, synthetic, manufactured, fabricated, machine-made, and 
>>> constructed" as options instead of man-made. Presumably the majority (if 
>>> not all) of OSM "man-made" tags relate to objects which are not naturally 
>>> occurring. Therefore "artificial" seems to hold.
>>> 
>>> Other sources: 
>>> https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/ 
>>> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
>>> https://dictionary.cambridge.org/dictionary/english/man-made
>>> 
>>> An issue may arise if artificial is already being used as a tag however.
>>> 
>>> Best,
>>> 
>>> Nathan
>>> ___
>>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Battery swapping spot in a charging station or being an individual tag?

[Peter Elderson]

Would that be a new sub-tag or a value of an existing sub-tag?

Best, Peter Elderson


Op di 6 okt. 2020 om 09:27 schreef Jez Nicholson :

> Myself, I would prefer *not* to have a new tag. Swapping a battery is a
> form of recharging and can be detailed in a subtag.
>
> On Tue, 6 Oct 2020, 04:51 德泉 談 via Tagging, 
> wrote:
>
>> When my e-scooter run out of energy I would go to the swapping stations
>> to have a new battery since the battery must be rented by the battery
>> provider.
>>
>> It just like charging the battery in very short time (even faster than
>> refueling in the gas station). But it truly more like to have a new bottled
>> gas when my kitchen runs out of fuel.
>>
>> Due to the requirement of a large power system, sometimes battery
>> swapping station and charging station are located at the same place.
>>
>> - Tan
>>
>> 於 星期二, 10月 6, 2020, 5:34 上午，Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org> 寫道：
>>
>> Oct 5, 2020, 18:58 by tagging@openstreetmap.org:
>>
>> Hi All,
>>
>> I want to write a new proposal about the battery swapping system for the
>> automotive vehicle. I'm not sure if modifying amenity=charging_station is
>> better or creating a new tag amenity=battery_swapping. I prefer to use
>> amenity=charging_station but found that is not a easy thing to do that.
>>
>> In case of a new tag - what would happen with place that offers both
>> charging and battery swapping?
>>
>> I wonder how such swap battery station acts from viewpoints of user -
>> is it functionally an equivalent to a very fast charging station?
>>
>> ___
>> 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

Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

[Peter Elderson]

Is it private sale?

Vr gr Peter Elderson


Op za 3 okt. 2020 om 23:37 schreef Graeme Fitzpatrick :

>
>
>
> On Sun, 4 Oct 2020 at 00:39, Paul Allen  wrote:
>
>>
>> More important is if there is a sign,
>>
>
> Hand-painted signs saying "Horse manure", "Avo's", "Firewood", "Eggs" & so
> on good enough?
>
> We see lot's of them whenever we go for a drive in the country, & even the
> occasional one in town!
>
> shop=farm_gate would work for those stalls set up literally at the farm's
> front gate, but not sure about the ones in town such as
>
> https://www.google.com.au/maps/@-28.0794558,153.4353269,3a,44.3y,353.08h,84.13t/data=!3m6!1e1!3m4!1srvTirWlBxaboKXGY_z4YiQ!2e0!7i16384!8i8192?hl=en
> (Sorry, there's a bus in the way! but the sign says "Horse manure for
> sale")
> or
>
> https://www.google.com.au/maps/@-28.0830057,153.4348792,3a,19.6y,207.92h,79.69t/data=!3m6!1e1!3m4!1stYPeGpJj91C6jw_hQGFTZA!2e0!7i13312!8i6656?hl=en
>
> 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] Feature Proposal - RFC - (shop=direct marketing)

[Peter Elderson]

I think for tagging it should be more than the occasional road-side sale?

Best, Peter Elderson


Op za 3 okt. 2020 om 14:38 schreef Paul Allen :

> On Sat, 3 Oct 2020 at 13:22, Martin Koppenhoefer 
> wrote:
>
>>
>> shop=* seems ok for me.
>
>
> And for me.  There are "formal" shops which open only 2 days a week.  Or
> have limited hours.  Or surly staff.  You go there and buy stuff, it's a
> shop.
>
>
>> Maybe “game” would be ok as value.
>>
>
> I think not.  Too easy to confuse "game" and "games."  Better to use
> shop=butcher + produce=game.
>
> --
> Paul
>
> ___
> 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] "width" on streets: Time for a recommendation

[Peter Elderson]

What about the many streets and roads where the kerb or lining is bended
and curled to cut the parking lane into sections?

Best, Peter Elderson


Op di 29 sep. 2020 om 11:40 schreef Supaplex :

> Now I am a little confused.
>
> As I understand Pieter, you used "width:carriageway" in Bruges in a way
> that includes parking:lanes (although you can estimate later how much is
> effectively not available for flowing traffic if using parking:lanes).
>
> My initiative for a clarification of the tagging was motivated among other
> things to find a distinction between width *with* and *without* parking
> lanes in order to not only indirectly estimate the effective width but to
> measure it directly. Personally, I had understood "width:carriageway" to
> mean only the effective width available for flowing traffic. But maybe this
> is exactly the right term for the measurement from curb to curb and we
> still need a new term for the effective width ("width:traffic_area")? Or is
> it anyway illusory to specify the effective width of a roadway, because it
> has no "fixed limit" (parking cars are changeable) and you can only
> estimate it anyway by a combination with "parking:lane"...?
>
> I think it would be helpful to be able to specify an effective width if
> needed. After all, this is the most interesting parameter for assessing the
> quality/usability of a street. Even with a full parking:lane-tagging the
> estimation is worse than simply measuring it directly. For example, in the
> case of "half_on_kerb" parking it is not clear to assume that exactly half
> the average vehicle width is "lost" on the carriageway - sometimes there is
> only one tire on the sidewalk and two thirds of the vehicle occupies the
> roadway. Also global assumptions for the loss of width when parking
> "diagonal" or "perpendicular" seem unrealistic to me. De facto, parking
> lanes almost always occupy a constant area, and the effective width of the
> carriageway can be specified to within a few decimeters on site or on
> aerial photographs.
> What do we do now? My (new) suggestion: "width:carriageway" means the
> total road width from curb to curb or from edge to edge of the road
> surface. "width:traffic_area" (or another suitable term; so far nothing
> comparable is in use as far as I see) could be used to indicate the
> effective width available for flowing traffic.
>
> Alex
>
>
> Am 27.09.20 um 22:47 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>
> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  
>  wrote:
> This width was tagged with 'width:carriageway'.
>
>
> I think this is a good tagging decision, being explicit about which width you 
> have measured seems the way to avoid ambiguity. (and it still leaves room for 
> the next project which could measure sidewalk widths ;-) ).
>
> Cheers Martin
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

[Peter Elderson]

Clifford Snow :

> I'm not sure there would be a consensus agreement to revise the wiki to
> indicate landuse=forest should be used for timber production.  Thoughts?
>

I am sure there would not. landuse=forest just means the area has trees. I
think there is some consensus about that.
natural=forest: same.
The idea that natural=wood is for natural woods and landuse=forest is for
managed forests has too little practical support.
Since there is no consensus about other aspects than "there are trees",
data users and renderers will stick to this.




> ___
> 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] Feature Proposal - RFC - (Chapel of rest)

[Peter Elderson]

Funeral viewing room sounds like a room where you can view the funeral. I 
suspect modern ones have very large screens and nice sound effects.

Mvg Peter Elderson

> Op 27 sep. 2020 om 19:39 heeft woll...@posteo.de het volgende geschreven:
> 
> "In any case, the proposer seems to feel that chapel of rest
> should be used only for dedicated buildings and a different
> tag should be added to indicate a funeral director's with a
> viewing room."
> The proposer feels that a subtag should be used for a funeral director's with 
> a viewing room. But the proposer's preference goes to using the same term for 
> the amenity tag and for the subtag (examples given in the proposal).
> 
> At the same time, may I ask for comments on "funeral viewing rooms"? Apart 
> from its length, it only seems to have advantages.
> 
> Am 27.09.2020 13:55 schrieb Paul Allen:
>> On Sun, 27 Sep 2020 at 10:02, Michael Patrick 
>> wrote:
>>>>>> From: Paul Allen 
>>>>> Problem 1. "Viewing Service" is the name of a process, not the
>>>> name
>>>>> of the building or room it takes place in. "Turn left after
>>>> the Viewing
>>>>> Service" > makes no sense, any more than "Turn right after the
>>>> prayer" as an alternative to "Turn right after the church."
>>> Mmmm  I agree, that's my point. 'Chapel of Rest' isn't a place,
>>> at best it
>>> sometimes might be a dedicated room in a funeral establishment.
>>> Apparently,
>>> it is not infrequently the showroom for caskets if a larger
>>> attendance needs to
>>> be accommodated.
>> It may be as you state it in some cases.  It is not true of all.
>> Here's
>> one where the chapel of rest is a building solely for that purpose:
>> https://www.colinphillipsfunerals.com/our-services/private-chapel/ [6]
>> That does not serve any other purpose.  It is not his offices or
>> showroom.  I know of another one like that a few miles from it.
>> Also, a chapel, even in the religious sense, is not necessarily a
>> separate building.  It originally referred to a small room within
>> a church with its own altar, or a room with an alta in a
>> non-religious building.
>> In any case, the proposer seems to feel that chapel of rest
>> should be used only for dedicated buildings and a different
>> tag should be added to indicate a funeral director's with a
>> viewing room.
>>>>> Problem 2. "Viewing service" implies some sort of formalized
>>>> event,
>>>>> probably religious with a speaker delivering a eulogy. A
>>>> Chapel of
>>>>> Rest is for looking at a dead body, with no formal ceremony.
>>>> Possibly
>>>>> in complete silence. Possible with only one live person in the
>>>> room.
>>>>> Contrast this with a religious service, which has prayers,
>>>> hymns,
>>>>> a sermon, bouts of kneeling, etc.
>>> Connotation of 'service' as in 'floral service', embalming service',
>>> 'cremation service' or otherwise business task / activity like
>>> 'automotive repair service', rather than the religious service
>>> denotation like a mass.
>> I wouldn't expect a religious service at a florist or a car mechanic.
>> When it comes
>> to funerals, however...
>>> From the US Federal Trade Checklist at
>> https://www.consumer.ftc.gov/articles/0301-funeral-costs-and-pricing-checklist
>>> [1]
>>> Visitation/viewing — staff and facilities __
>>> Funeral or memorial service — staff and facilities __
>>> Graveside service, including staff and equipment __
>> That's nice.  But it's not British English.  You can, however, use it
>> to argue that editor translations for US English should use visitation
>> for the preset name.
>>> UK funeral industry shows both 'Chapel of Rest', or that term with
>>> visitation / viewing, some just have 'venue rental'. CoR is fairly
>>> typical.
>> Precisely.  CoR seems to be the commonest term for it.  And less
>> ambiguous than "visitation" (people visit patients in hospitals) or
>> "viewing" (people view paintings in art galleries).
>>>>> Problem 3. I've not encountered that term as a synonym for a
>>>> chapel of
>>>>> rest. But I've not looked very hard. Citation needed.
>>> https://funeralresources.com/resources/viewing-and-visitation-costs/
>>> [2]
>>> https://funerals.org/?consumers=read-funeral-home-p

Re: [Tagging] Feature Proposal - RFC - (Chapel of rest)

[Peter Elderson]

I would suggest respectorium, but I do not want to start a new hype in the 
funeral branch. 

Mvg Peter Elderson

> Op 25 sep. 2020 om 17:10 heeft woll...@posteo.de het volgende geschreven:
> 
> "Wake rooms" was at one time my favorite, but then I was told that some 
> people might associate "wake" with a particular denomination as well.
> 
> I'm not a native speaker either, so I can't judge.
> 
> Something with "viewing" might be nice as well; "funeral viewing room" 
> (between quotation marks) yields some interesting results on Google. A bit 
> long, but at this point, I'd take that as a minor incovenience.
> 
> Am 25.09.2020 15:09 schrieb Martin Koppenhoefer:
>> sent from a phone
>>>> On 25. Sep 2020, at 00:51, Michael Patrick  wrote:
>>> ( I once went to one in Detroit, where the open casket and reception line 
>>> was right there with tables of people eating brunch ('wake')).
>> so it could be “wake_room”?
>> Now this might sound a tad euphemistic as well, but search engines
>> actually restitute pertinent results.
>> Cheers Martin
>> ___
>> 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

Re: [Tagging] Linking Sidewalks to Highways

[Peter Elderson]

Jeroen Hoek :

> I have been applying highway=cycleway + cycleway=link as well to see how
> this feels. Some early documentation I have been preparing:
>
> https://wiki.openstreetmap.org/wiki/User:JeroenHoek#cycleway.3Dlink
>

Why the diagonal link to the center intersection node?
Wouldn't it be more logical / practical to continue the cycleways straight
up to the way of the crossing road?
No link tag needed there, I think.





> ___
> 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] Feature Proposal - RFC - (Chapel of rest)

[Peter Elderson]

I have heard mourning chapel, mourning room, funeral chapel, funeral room.
Chapel of rest does not seem right to me, though I understand how the
funeral business would like that term better.

But I'm not a native speaker. PCMIIW.

Peter Elderson


Op ma 21 sep. 2020 om 21:14 schreef :

> Dear all,
>
> As already mentioned, another ripple effect of my first proposal has
> materialised, the need to be able to properly tag chapels of rest as
> well.
>
> Therefore please comment on the following proposal:
>
> Chapel of rest: a room or building where families and friends can come
> and view someone who has died before their funeral
>
> Proposal page:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Chapel_of_rest
> Discussion page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Chapel_of_rest
>
> Thanks!
>
> Vollis
>
>
> ___
> 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] Linking Sidewalks to Highways

[Peter Elderson]

So we need a way to determine the crossability of a road for walkers and 
cyclists, probably using a combination of highway value of the crossed way, 
maybe the access tag (foot=yes probably can be crossed on foot) and some 
indicator tag for crossing access (foot:crossing=yes/no ?) to tag exceptions.  

Currently I do map short footways/paths where I know pedestrians will cross the 
road, even when no physically marked crossing exists. Opposite lowered kerbs or 
the fact that nearby dirt paths exists at both sides, not too far apart, 
already is a luxury.

Mvg Peter Elderson

> Op 21 sep. 2020 om 14:57 heeft Paul Allen  het volgende 
> geschreven:
> 
> 
>> On Mon, 21 Sep 2020 at 11:06, Supaplex  wrote:
>> 
> 
>> The problem remains that physically non-existent road crossings ("wildly 
>> crossing the street"), which in reality represent a crossing possibility for 
>> many users, are still not available for routing. In my opinion, this problem 
>> is not very relevant if separate way"  are well mapped (which they often are 
>> unfortunately not!) and all essential routable connections are in the 
>> database. At the beginning and at the end of the route, people can use their 
>> brains ("destination across the street") if their routers do not solve this 
>> task for them.
> 
> This isn't as simple as you make out.  Assume that I am at point A and wish to
> go to point B, which involves a "wild crossing" at some point between the two.
> However, there is a real crossing at point C, a mile beyond point B,  A router
> will direct me to travel to point C (a mile further than my destination) in 
> order
> to cross the road there, so I can then walk a mile back to B.
> 
> -- 
> Paul
> 
> ___
> 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] Powerbank Sharing Systems

[Peter Elderson]

Wouldn't that just duplicate the location systems they offer? And on top of
that,  a sizable maintenance burden to keep up with the changes? Who is
going to want this on OSM after committing to a chain?

Best, Peter Elderson


Op za 19 sep. 2020 om 13:02 schreef Jake Edmonds via Tagging <
tagging@openstreetmap.org>:

>
> https://commons.wikimedia.org/wiki/Category:Powerbank-sharing_systems_by_name
> https://heychimpy.com
> https://www.wecharge.me
>
>
> I can’t see any tagging related to powerbank sharing systems.
>
> Unless anyone can point me to existing tagging, I will submit a proposal,
> based on amenity=bicycle_sharing, titled amenity=powerbank_sharing for
> tagging docking station.
>
> Chimpy (linked above) appears to use docking stations and over-the-counter
> rentals. Should an additional tag, such as service:powerbank:rental=yes, be
> included for existing features?
>
> Thanks
> Jake
> ___
> 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] automated edits seem to remove crossing=zebra drastically

[Peter Elderson]

>
> Maybe crossing=marked + marked=???
> where ??? is the "type" of crossing - UK_zebra (as well as all their other
> birds & animals!), US_zebra, EU_zebra & so on, so if you know exactly what
> it is you can specify, but if you can only see a crossing marked there, you
> can just call it a marked crossing?
>

Isn't it obvious from the location what the country is?

Crossings can have all sorts of markings. Most markings just indicate that
it's a crossing, i.e. a preferred location for pedestrians to cross the
road. Those markings result in the *=crossing tag.

UK has a rich wildlife of crossings, but afaik all have controls except the
zebra, so you can tag the control if you think it's worthwhile.

Priority is regarded as a mappable attribute. It seems that, in many
countries, zebra striping is used to grant priority to pedestrians. If
mappers do not think crossing=zebra combined with the location is clear
enough about the priority, then I suggest to add a tag for priority.

In Nederland, zebra also implies drivers are not allowed to park on or
within a certain distance from the crossing. If that's deemed important and
should not just be implied by the zebra tag, it should be tagged on the
section of the road itself.

In Nederland, pedestrians are not allowed to cross the road near the zebra
within a certain distance (50 m or so).
This is important for pedestrian routing. I think this is handled already
by the presence of the way for pedestrians.  I may be wrong, but I believe
routing over a way is preferred to crossing wildly over a road.

In short, I think crossing=zebra says what you see, the implications can be
read from the country the location is in,  and if that's not sure enough
tag the implications separately and precisely.

Changing to crossing=marked then specifying that it's a zebra just makes it
more work, and harder to interpret.


Vr gr Peter Elderson___
> 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] automated edits seem to remove crossing=zebra drastically

[Peter Elderson]

In Nederland, the zebra is a very clear and specific type of crossing with
legal rules including yield to pedestrians walking on or even toward the
zebra.

I think this will continue to be the case even after Europe leaves the
British Union.

Vr gr Peter Elderson


Op do 17 sep. 2020 om 20:12 schreef Matthew Woehlke <
mwoehlke.fl...@gmail.com>:

> On 17/09/2020 13.44, Tod Fitch wrote:
> >> On Sep 17, 2020, at 9:30 AM, Matthew Woehlke wrote:
> >> On 17/09/2020 10.07, Shawn K. Quinn wrote:
> >>> On 9/17/20 08:15, Matthew Woehlke wrote:
> >>>> It's also atrocious because it can *only* be verified by survey. As
> >>>> much as we prefer surveys, the reality is that a lot of mapping
> >>>> happens just from aerials, where crossings (both marked and, in some
> >>>> cases, unmarked) can be seen, but signals cannot.
> >>> I have mapped many traffic signals (and, for that matter, stop and
> yield
> >>> signs) based on shadows visible on the satellite photos. If you look
> >>> carefully enough (Bing and Mapbox Satellite at least), they are there.
> >>> (Local knowledge helps too in some cases.)
> >>
> >> *Traffic* lights I can buy. I am more suspicious of the claim that
> >> you can tell whether they have pedestrian crossing signals or not,
> >> or that you can reliably identify other signage based solely on
> >> outline. *Maybe* if you get lucky and have a very clear shadow at
> >> the right angle, but if you try to tell me you can identify
> >> https://www.openstreetmap.org/node/7695704414 (n.b. a yield sign)
> >> from a shadow in aerial imagery, I am going to be deeply suspicious
> >> ;-).
> >
> > Not from the signs or shadows of the signs, but in my area the
> > pavement markings can often tell you if it is a stop or yield. Some
> > times it is easy (“STOP” or “YIELD” painted on the pavement). But it
> > seems that newer road work uses a different style limit line for a
> > stop versus yield.
>
> Ah, that's fair; I was under the impression we were talking about
> *signs*. Possibly because most of the yields I see are to yield to other
> *vehicles*, not pedestrians. (I *have* seen "yield to pedestrians", now
> that I think about it, but not sure I've ever seen *lane markings* where
> it's clear that what you are supposed to yield for is pedestrians. Other
> than crosswalks, anyway. Which... makes me wonder if
> "crossing=uncontrolled" is even correct; even more reason to not use
> that! My understanding was "uncontrolled" meant by traffic signals, but
> now I'm not so sure.)
>
> I've tagged some yields based on lane markings myself, e.g.
> https://www.openstreetmap.org/node/7714853074.
>
> > Back to the original topic: I am not really sure what, if any, the
> > US version of a “zebra" crossing is versus a “marked” crossing. So I
> > usually just tag as “marked” as that seems to be the more generic
> > item.
>
> Likewise. Even the wiki notes that this is unclear "outside the UK" (as
> I previously observed).
>
> > The crossing you linked to *might* be an example of a US “zebra”
> > crossing. Can anyone verify that for me. Also, there are no tags on
> > the intersection node itself. Should there be? I have assumed that
> > there should so that vehicle based navigation would have the
> > information needed to advise the driver of particular type of
> > crossing ahead.
>
> As I understand it, yes, and I've tagged that in other places (e.g. the
> above example). I actually have no idea why that node is marked as a
> yield; I don't think there's actually a yield there, but I'm hesitant to
> just delete it (even though apparently I'm the one that added it).
> Unfortunately I can't go survey it right now. (Have to try to remember
> to do that when/if I ever make it back to that Cracker Barrel :-).)
>
> --
> Matthew
>
> ___
> 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] automated edits seem to remove crossing=zebra drastically

[Peter Elderson]

In Nederland zebra crossings are very common, and go by the name zebra.This is 
also the name used in legislation. Zebra crossings give priority to pedestrians 
crossing the street on the zebra. Hm how should this be tagged... maybe 
crossing=pathtocrosstheroadmarkedwithstripeslikeazebratograntprioritytopedestrians?

Peter Elderson

>> Op 16 sep. 2020 om 23:47 heeft Graeme Fitzpatrick  
>> het volgende geschreven:
> 
> 
> 
>> On Wed, 16 Sep 2020 at 20:01, Martin Koppenhoefer  
>> wrote:
>> while the very generic crossing=marked, which was quite unpopular before 
>> (2013-2018 below 6000 uses) now went through the roof and is leading the 
>> tagstats with more than 1 million uses.
> 
> You may find that it is partly, at least, iD's "fault"? Crossings now "error" 
> in iD to say that "this street crosses an unmarked crossing", despite the 
> crossing being mapped & tagged? eg 
> https://www.openstreetmap.org/edit#map=19/-28.06439/153.43854
> 
> The "fix" inserts an "Unmarked Crossing" node on the junction of the street & 
> crossing.
> eg https://www.openstreetmap.org/node/7914347813
> 
>> What do you think about it, shouldn't we be encouraging people to use more 
>> specific tags like crossing=zebra or crossing=traffic_signals instead?
> 
> I must admit that I only do crossings as =traffic_signals; =marked (by 
> itself) for zebra crossings; & =unmarked where there is provision to cross 
> the road but no signage or roadway markings on any sort.
> 
> 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] Tagging for board games themed pubs

[Peter Elderson]

I would tag board_games=* for the availability of board_games at the venue.
Values: yes, no, or a colon separated list of available games.

For theme meaning style, maybe simply style=*, or pub_style=*, or
pub:style=*,

For theme meaning the specialty or focus: specialty=* or focus=* or the
like.

I'm not sure how to tag solar terrace orientation and terrace cover type,
though

Vr gr Peter Elderson


Op za 12 sep. 2020 om 11:01 schreef Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> 12 Sep 2020, 00:50 by graemefi...@gmail.com:
>
>
>
> On Fri, 11 Sep 2020 at 22:06, Niels Elgaard Larsen 
> wrote:
>
> Mateusz Konieczny via Tagging:
>
> > A lot of pubs have board games available for customers to play, or
> they did in
> > normal times.
>
>
> How about pubs that host trivia games one night a week?
>
> I think it is clearly not a board game.
>
>
>
> could we have something like board_games=yes/no/permitted/designated ?
>
>
> But if it's =no, would that mean that you can't pull out a pack of cards &
> have a game of solitaire?
>
>
> 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] Tagging for board games themed pubs

[Peter Elderson]

Focus?

Mvg Peter Elderson

> Op 11 sep. 2020 om 20:40 heeft Paul Allen  het volgende 
> geschreven:
> 
> 
>> On Fri, 11 Sep 2020 at 19:09, Martin Koppenhoefer  
>> wrote:
> 
>> > Themed implies that is the raison d'etre for the pubs existance and you 
>> > would only go there to play board games, which would attract a very 
>> > limited clientel.
>> 
>> +1, this is also my interpretation.
> 
> Not my interpretation of "theme."  Most pubs I've been in, themes have
> been about decor.  Like the pub named "Walpurgisnacht" and decorated
> accordingly, but there were no battles against witchcraft there.  Like
> the pub with many shelves of books, which nobody read.  Like
> the pub with a fake tree built into a corner.  Like the pub called The
> Buccaneer, decked out [pun intended] as a sailing ship, but there
> were no acts of piracy.
> 
> "Theme" is the wrong word to use.  A pub with many pool tables
> is not themed around playing pool.  A pub with many dart boards
> for practise by its darts team is not themed around darts.  Right
> now I can't think of a good word for a pub specializing in a
> particular interest (many pool tables rather than just one), but
> "theme" isn't it,
> 
> -- 
> Paul
> 
> ___
> 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] Rail segment in a bike route

[Peter Elderson]

Volker Schmidt :

> The double role issue, if it occurs, is there in either case, separate
> relation or role in the bicycle route relation.
>

If a way or a chain of ways in a route relation has no
forward/backward role,  you can assign it a transfer/transport role.Easy
for e.g. ferries operating in both directions.

If the bicycle has split directions and transfer/transport is also
different for the travel directions, I think a route_master relation is
needed for the transfer. The superroute will have as members: the bicycle
relation up to the transport; the routemaster relation with the
transfer role, and the section of the bicycle route at the other side of
the transfer.

I think for most bicycle routes this kind of transfer will have a shared
way or shared point near the transport. So I think this will not happen
very often.But if it does, tagging can be done as described above without
ever having to combine roles. Processing is another matter, though.


> Regarding travel details of ferry/rail/bus sections within bicycle routes:
> This information, if available, should go on the the ferry/rail/bus route
> relations, as these means of transport are not exclusive to the bike route,
> at least in most cases, and therefore should have their own relations
> independently of bicycle travel.
>
> In more general terms, this intermodal transport problem is a big black
> hole in OSM in general. The commercial competition is spending a lot of
> money in that sector. I am not sure we can or even want to compete with
> that.
>

 The development is instant point-to-point routing over different
networks and transport modes. Route relations pre-combine elements to
form a fixed route for a particular  purpose, e.g. a theme or named trail
to be followed exactly. I don't think roles in fixed route relations will
solve the instant routing challenge!


> On Mon, 31 Aug 2020 at 09:53, Peter Elderson  wrote:
>
>> Jo:
>>
>>> I added that it's not needed for ferries in the proposal on the wiki.
>>> It's alright if we have more than 1 way to do it and leave it up to the
>>> mapper to decide whether to map as a single route relation or split them
>>> and use a superroute relation.
>>>
>>
>> Wouldn't this apply to other transfer/transport sections as well?
>>
>>
>>> If I start doing a bicycle tour, I want to know in advance if I'll be
>>> able to cycle the whole stretch, or if there will be waiting time for other
>>> means of transportation. I would also like to know if there will be a fee
>>> to pay for these means of transportation and whether it's necessary to
>>> hurry, in case there is only 1 per x hours, or they don't function at
>>> night. By using separate route relations, it becomes possible to add
>>> opening hours and a frequency/period on them.
>>>
>>
>> Wouldn't this apply to ferries as well?
>> _
>>
>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rail segment in a bike route

[Peter Elderson]

Jo:

> I added that it's not needed for ferries in the proposal on the wiki. It's
> alright if we have more than 1 way to do it and leave it up to the mapper
> to decide whether to map as a single route relation or split them and use a
> superroute relation.
>

Wouldn't this apply to other transfer/transport sections as well?


> If I start doing a bicycle tour, I want to know in advance if I'll be able
> to cycle the whole stretch, or if there will be waiting time for other
> means of transportation. I would also like to know if there will be a fee
> to pay for these means of transportation and whether it's necessary to
> hurry, in case there is only 1 per x hours, or they don't function at
> night. By using separate route relations, it becomes possible to add
> opening hours and a frequency/period on them.
>

Wouldn't this apply to ferries as well?
_

> 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] Rail segment in a bike route

[Peter Elderson]

'transport' role, 'transportation' role ... is this in use and
documented somewhere?

In bicycle routes, when the ways are different for the two directions,
forward and backward roles apply to the ways in the relation.  If a
transfer/transport/transportation is to be applied as well, how would you
combine this? Multiple roles are currently not defined.

Vr gr Peter Elderson


Op ma 31 aug. 2020 om 08:16 schreef Warin <61sundow...@gmail.com>:

> On 31/8/20 8:25 am, Volker Schmidt wrote:
> > Keep it simple, if the simple solution does not limit you.
> >
>
> Agreed. I see no reason why a way as a member of a simple route relation
> could not have the role 'transport'.
>
>
>
> ___
> 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] Rail segment in a bike route

[Peter Elderson]

Route hierarchy is regular practice.The parent relation holds child
relations. This is the case for many types of route,

As far as I can see, there are two new elements:

1. A child relation (route section) can be of a different route type.
2. Provided it has a special role

Since the type is in the child relation, you don't need to specify that in
the role.

This is valid for many route types. I would suggest not to present it as a
complex bicycle route, but as a way to incorporate transfer sections of
different types in routes of any transport type.

Best, Peter Elderson


Op zo 30 aug. 2020 om 17:52 schreef Jo :

> Hi Francesco,
>
> I started a proposal on the wiki:
>
> https://wiki.openstreetmap.org/wiki/More_complex_cycle_routes
>
> It will probably need to be moved to the proposal name space, but we can
> work on it over there before putting it up for a vote.
>
> Jo
>
> On Sun, Aug 30, 2020 at 3:09 PM Francesco Ansanelli 
> wrote:
>
>> I saw your changes... LGTM.
>> Thanks!
>> It would be great to have a page to document your proposal.
>> Cheers
>> Francesco
>>
>> Il dom 30 ago 2020, 12:03 Jo  ha scritto:
>>
>>> Hi Francesco,
>>>
>>> I will create the superroute and route relations as an example. If you
>>> don't like the solution, feel free to remove those relations again
>>> afterwards. I will only fix a small error in the original relation, but
>>> keep it for now, so both solutions can be analysed next to each other.
>>>
>>> I don't really like the idea of a role 'transfer' on all those railway
>>> ways in a single route relation. In the case of your example, there is only
>>> a single railway, but in theory there could be one for each direction of
>>> travel of the train. So if you want to describe that in the route relation,
>>> you would need role forward/backward in the route relation, which cannot be
>>> combined with role transfer.
>>>
>>> Jo
>>>
>>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
>>> franci...@gmail.com> wrote:
>>>
>>>> Dear Polyglot,
>>>>
>>>> it sounds good to me. But what roles do you suggest for such superroute?
>>>> Many thanks
>>>> Francesco
>>>>
>>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>>> scritto:
>>>>
>>>>> How would you feel about mapping it with a superroute relation?
>>>>>
>>>>> The superroute would then contain 3 route relations.
>>>>>
>>>>> 1 for the first part by bicycle
>>>>> 1 for the middle part by train
>>>>> 1 for the last part by bicycle
>>>>>
>>>>> If we give the train part a different role in the superroute, we can
>>>>> make it such that the continuity line in JOSM is still drawn.
>>>>>
>>>>> This solution might also work to indicate that certain parts of a
>>>>> bicycle route need to be done on foot. Although creating separate route
>>>>> relations for such short stretches may feel like overkill.
>>>>>
>>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>>> it's unlikely we'll create a route relation for this, but not
>>>>> impossible/unthinkable).
>>>>>
>>>>> In JOSM PT_Assistant there will soon be a convenience button to
>>>>> extract route relations from route or superroute relations, to make a
>>>>> conversion from route to superroute+route relations easier to do.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>>> franci...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> a new example that could benefit of this proposal:
>>>>>>
>>>>>> https://www.openstreetmap.org/relation/10605853
>>>>>>
>>>>>> Can someone please go ahead and make a proposal?
>>>>>>
>>>>>> Many thanks
>>>>>> Best regards
>>>>>> Francesco
>>>>>>
>>>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  h

Re: [Tagging] Rail segment in a bike route

[Peter Elderson]

To clarify: the transfer role could be added to the role value list:

*None* or main The role value for the main section(s) of a signposted or in
any way waymarked route.
alternative A signposted or otherwise waymarked alternative branching off
then rejoining the main route at a significantly different point. The
alternative is used instead of a section of the main route.
excursion A signposted or otherwise waymarked side track which rejoins the
main track at or close to the same point where it left, e.g. to visit a
place of interest. The excursion is an optional addition to the main route.
approach Signposted or otherwise waymarked access route to or from
transport infrastructure e.g. parking, train station, bus station, cable
car. An approach is used in addition to the main route.
connection Signposted or otherwise waymarked link route from one
recreational route to another recreational route and vice versa. A
connection is used to switch from one route to another. Note that an
approach might act as a connection, e.g. when it ends/begins at a major
train station where other routes also pass through. In that case, use the
role approach.

Given this definition, the connection should appear in both routes involved.
*| transfer | Route section where a different mode of transport is
necessary, e.g. cable car transfer in a hikingh trail, train transfer in a
bicycle route, bus transfer through a tunnel. A transfer section is an
integral part of the route. |*

Best, Peter Elderson

Op zo 30 aug. 2020 om 12:47 schreef Peter Elderson :

> True. In that case, a transfer relation in a superroute is necessary. Like
> all the other roles: do not combine these roles on ways with with
> forward/backward, use a relation instead.
>
> Vr gr Peter Elderson
>
>
> Op zo 30 aug. 2020 om 12:06 schreef Jo :
>
>> Hi Francesco,
>>
>> I will create the superroute and route relations as an example. If you
>> don't like the solution, feel free to remove those relations again
>> afterwards. I will only fix a small error in the original relation, but
>> keep it for now, so both solutions can be analysed next to each other.
>>
>> I don't really like the idea of a role 'transfer' on all those railway
>> ways in a single route relation. In the case of your example, there is only
>> a single railway, but in theory there could be one for each direction of
>> travel of the train. So if you want to describe that in the route relation,
>> you would need role forward/backward in the route relation, which cannot be
>> combined with role transfer.
>>
>> Jo
>>
>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
>> wrote:
>>
>>> Dear Polyglot,
>>>
>>> it sounds good to me. But what roles do you suggest for such superroute?
>>> Many thanks
>>> Francesco
>>>
>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>> scritto:
>>>
>>>> How would you feel about mapping it with a superroute relation?
>>>>
>>>> The superroute would then contain 3 route relations.
>>>>
>>>> 1 for the first part by bicycle
>>>> 1 for the middle part by train
>>>> 1 for the last part by bicycle
>>>>
>>>> If we give the train part a different role in the superroute, we can
>>>> make it such that the continuity line in JOSM is still drawn.
>>>>
>>>> This solution might also work to indicate that certain parts of a
>>>> bicycle route need to be done on foot. Although creating separate route
>>>> relations for such short stretches may feel like overkill.
>>>>
>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>> it's unlikely we'll create a route relation for this, but not
>>>> impossible/unthinkable).
>>>>
>>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>>> route relations from route or superroute relations, to make a conversion
>>>> from route to superroute+route relations easier to do.
>>>>
>>>> Polyglot
>>>>
>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>> franci...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> a new example that could benefit of this proposal:
>>>>>
>>>>> https://www.openstreetmap.

Re: [Tagging] Rail segment in a bike route

[Peter Elderson]

I think the transfer section only needs the role transfer. The exact way of
transport there is tagged on the child relation which is a route in itself.
(type=route, route=*).

Peter Elderson


Op zo 30 aug. 2020 om 13:11 schreef Jo :

> I was in a hurry to go and eat and forgot to say this:
>
> In the Italian station, I added a footway through the station building and
> across the rails. That's not correct, of course. This should be improved
> with more detail. Is there a tunnel to cross the railway? A bridge? Do
> people have to risk it at an unsupervised level_crossing?
>
> If there is a tunnel or a bridge, most likely there is also a part with
> stairs.
>
> Possibly the train always arrives near the station building and never on
> the southern track as it is mapped now?
>
> I now added a role transfer in the superroute relation. Maybe a role
> transfer_on_foot, transfer_by_train, transfer_by_ferry,
> transfer_by_funicular would be more descriptive? For this we would need to
> create a proposal, but at the moment I'm mostly interested in your
> opinions. Creating a proposal and following up on it is a lot of work. I'm
> not sure if I have the stamina for it. But anyone can do it, so if you feel
> like it, go ahead.
>
> Jo
>
> On Sun, Aug 30, 2020 at 12:39 PM Jo  wrote:
>
>> I uploaded my way to solve this:
>>
>> https://www.openstreetmap.org/relation/11560387
>>
>> Polyglot
>>
>> On Sun, Aug 30, 2020 at 12:03 PM Jo  wrote:
>>
>>> Hi Francesco,
>>>
>>> I will create the superroute and route relations as an example. If you
>>> don't like the solution, feel free to remove those relations again
>>> afterwards. I will only fix a small error in the original relation, but
>>> keep it for now, so both solutions can be analysed next to each other.
>>>
>>> I don't really like the idea of a role 'transfer' on all those railway
>>> ways in a single route relation. In the case of your example, there is only
>>> a single railway, but in theory there could be one for each direction of
>>> travel of the train. So if you want to describe that in the route relation,
>>> you would need role forward/backward in the route relation, which cannot be
>>> combined with role transfer.
>>>
>>> Jo
>>>
>>> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli <
>>> franci...@gmail.com> wrote:
>>>
>>>> Dear Polyglot,
>>>>
>>>> it sounds good to me. But what roles do you suggest for such superroute?
>>>> Many thanks
>>>> Francesco
>>>>
>>>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>>>> scritto:
>>>>
>>>>> How would you feel about mapping it with a superroute relation?
>>>>>
>>>>> The superroute would then contain 3 route relations.
>>>>>
>>>>> 1 for the first part by bicycle
>>>>> 1 for the middle part by train
>>>>> 1 for the last part by bicycle
>>>>>
>>>>> If we give the train part a different role in the superroute, we can
>>>>> make it such that the continuity line in JOSM is still drawn.
>>>>>
>>>>> This solution might also work to indicate that certain parts of a
>>>>> bicycle route need to be done on foot. Although creating separate route
>>>>> relations for such short stretches may feel like overkill.
>>>>>
>>>>> The other 'interruption' of a bicycle route I can think of, is where a
>>>>> ferry needs to be taken. In theory this could also be a funicular. In
>>>>> Antwerpen there is a special bus service that takes cyclists through a
>>>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>>>> it's unlikely we'll create a route relation for this, but not
>>>>> impossible/unthinkable).
>>>>>
>>>>> In JOSM PT_Assistant there will soon be a convenience button to
>>>>> extract route relations from route or superroute relations, to make a
>>>>> conversion from route to superroute+route relations easier to do.
>>>>>
>>>>> Polyglot
>>>>>
>>>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli <
>>>>> franci...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> a new example that could benefit of this proposal:
>>>>>>
>>>>>> https://www.openstreetma

Re: [Tagging] Rail segment in a bike route

[Peter Elderson]

True. In that case, a transfer relation in a superroute is necessary. Like
all the other roles: do not combine these roles on ways with with
forward/backward, use a relation instead.

Vr gr Peter Elderson


Op zo 30 aug. 2020 om 12:06 schreef Jo :

> Hi Francesco,
>
> I will create the superroute and route relations as an example. If you
> don't like the solution, feel free to remove those relations again
> afterwards. I will only fix a small error in the original relation, but
> keep it for now, so both solutions can be analysed next to each other.
>
> I don't really like the idea of a role 'transfer' on all those railway
> ways in a single route relation. In the case of your example, there is only
> a single railway, but in theory there could be one for each direction of
> travel of the train. So if you want to describe that in the route relation,
> you would need role forward/backward in the route relation, which cannot be
> combined with role transfer.
>
> Jo
>
> On Sun, Aug 30, 2020 at 11:24 AM Francesco Ansanelli 
> wrote:
>
>> Dear Polyglot,
>>
>> it sounds good to me. But what roles do you suggest for such superroute?
>> Many thanks
>> Francesco
>>
>> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
>> scritto:
>>
>>> How would you feel about mapping it with a superroute relation?
>>>
>>> The superroute would then contain 3 route relations.
>>>
>>> 1 for the first part by bicycle
>>> 1 for the middle part by train
>>> 1 for the last part by bicycle
>>>
>>> If we give the train part a different role in the superroute, we can
>>> make it such that the continuity line in JOSM is still drawn.
>>>
>>> This solution might also work to indicate that certain parts of a
>>> bicycle route need to be done on foot. Although creating separate route
>>> relations for such short stretches may feel like overkill.
>>>
>>> The other 'interruption' of a bicycle route I can think of, is where a
>>> ferry needs to be taken. In theory this could also be a funicular. In
>>> Antwerpen there is a special bus service that takes cyclists through a
>>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>>> it's unlikely we'll create a route relation for this, but not
>>> impossible/unthinkable).
>>>
>>> In JOSM PT_Assistant there will soon be a convenience button to extract
>>> route relations from route or superroute relations, to make a conversion
>>> from route to superroute+route relations easier to do.
>>>
>>> Polyglot
>>>
>>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> a new example that could benefit of this proposal:
>>>>
>>>> https://www.openstreetmap.org/relation/10605853
>>>>
>>>> Can someone please go ahead and make a proposal?
>>>>
>>>> Many thanks
>>>> Best regards
>>>> Francesco
>>>>
>>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>>> scritto:
>>>>
>>>>> For the record, I think a transfer role is a generic solution  for the
>>>>> issue raised here, applicable to the cable car transfer and other types of
>>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>>
>>>>> Anyone who wants to do it has my support, though.
>>>>>
>>>>> Vr gr Peter Elderson
>>>>>
>>>>>
>>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>>> dieterdre...@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> sent from a phone
>>>>>>
>>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>>> >
>>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>>> restricted then in OSM it should be marked *=no.
>>>>>>
>>>>>>
>>>>>> for roads access=yes is assumed, it is not necessarily the default
>>>>>> for all kind of features.
>>>>>>
>>>>>>
>>>>>> Cheers Martin
>>>>>> ___
>>>>>> 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
>>>>
>>> ___
>>> 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

Re: [Tagging] Rail segment in a bike route

[Peter Elderson]

I suggest: role transfer for the transfer part.

The transfer part could be a route separate relation in a superroute, the
transfer type is given by the relation route type.
The transfer part could be a way or a chain of ways in a regular oute
relation, the transfer type is then determined by the tags of the ways.
editors, QA-tools and datausers would have to handle the role.

It fits in nicely with the accepted roles for recreational routes,
https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations


Best, Peter Elderson


Op zo 30 aug. 2020 om 11:26 schreef Francesco Ansanelli :

> Dear Polyglot,
>
> it sounds good to me. But what roles do you suggest for such superroute?
> Many thanks
> Francesco
>
> Il giorno dom 30 ago 2020 alle ore 11:00 Jo  ha
> scritto:
>
>> How would you feel about mapping it with a superroute relation?
>>
>> The superroute would then contain 3 route relations.
>>
>> 1 for the first part by bicycle
>> 1 for the middle part by train
>> 1 for the last part by bicycle
>>
>> If we give the train part a different role in the superroute, we can make
>> it such that the continuity line in JOSM is still drawn.
>>
>> This solution might also work to indicate that certain parts of a bicycle
>> route need to be done on foot. Although creating separate route relations
>> for such short stretches may feel like overkill.
>>
>> The other 'interruption' of a bicycle route I can think of, is where a
>> ferry needs to be taken. In theory this could also be a funicular. In
>> Antwerpen there is a special bus service that takes cyclists through a
>> tunnel under river Schelde (for commuters, where a ferry was abolished,
>> it's unlikely we'll create a route relation for this, but not
>> impossible/unthinkable).
>>
>> In JOSM PT_Assistant there will soon be a convenience button to extract
>> route relations from route or superroute relations, to make a conversion
>> from route to superroute+route relations easier to do.
>>
>> Polyglot
>>
>> On Sun, Aug 30, 2020 at 9:59 AM Francesco Ansanelli 
>> wrote:
>>
>>> Hello,
>>>
>>> a new example that could benefit of this proposal:
>>>
>>> https://www.openstreetmap.org/relation/10605853
>>>
>>> Can someone please go ahead and make a proposal?
>>>
>>> Many thanks
>>> Best regards
>>> Francesco
>>>
>>> Il mer 24 giu 2020, 23:25 Peter Elderson  ha
>>> scritto:
>>>
>>>> For the record, I think a transfer role is a generic solution  for the
>>>> issue raised here, applicable to the cable car transfer and other types of
>>>> transfer in routes, but I will not propose a new role value any time soon.
>>>>
>>>> Anyone who wants to do it has my support, though.
>>>>
>>>> Vr gr Peter Elderson
>>>>
>>>>
>>>> Op za 20 jun. 2020 om 09:13 schreef Martin Koppenhoefer <
>>>> dieterdre...@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> sent from a phone
>>>>>
>>>>> > On 20. Jun 2020, at 01:58, Warin <61sundow...@gmail.com> wrote:
>>>>> >
>>>>> > Normal OSM access is assumed to be access=yes, where some access is
>>>>> restricted then in OSM it should be marked *=no.
>>>>>
>>>>>
>>>>> for roads access=yes is assumed, it is not necessarily the default for
>>>>> all kind of features.
>>>>>
>>>>>
>>>>> Cheers Martin
>>>>> ___
>>>>> 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
>>>
>> ___
>> 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

Re: [Tagging] Network-tag needs extension

[Peter Elderson]

>
> how could you change the definition of an undocumented tag?
>

 Easy. It happens all the time, you just never hear about it.

___
> 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] Benches and hostile architecture

[Peter Elderson]

Wouln't it be more osm to describe visible and verifiable attributes of 
features, rather than architectural design principles or supposed intentions?

Mvg Peter Elderson

> Op 24 aug. 2020 om 12:11 heeft Florian Lohoff  het volgende 
> geschreven:
> 
> On Sun, Aug 23, 2020 at 01:22:38PM -0700, Joseph Eisenberg wrote:
>> The term "hostile architecture" is too vague. As an alternative
>> "anti-homeless" is also not precise enough. We are getting closer with the
>> initial suggestion that the feature is to prevent lying down, sleeping or
>> sitting.
> 
> Its not just anti-homeless there are also features which are explicitly 
> anti-skateboard etc
> 
> Flo
> -- 
> Florian Lohoff f...@zz.de
>UTF-8 Test: The  ran after a , but the  ran away
> ___
> 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] Benches and hostile architecture

[Peter Elderson]

The British really call bench construction "architecture"? Amazing. I can see 
this going the same way as village green.

Mvg Peter Elderson

> Op 23 aug. 2020 om 22:59 heeft Andy Townsend  het volgende 
> geschreven:
> 
> On 23/08/2020 21:22, Joseph Eisenberg wrote:
>> The term "hostile architecture" is too vague.
> 
> It is the normal British English (at least) description of this stuff.
> 
> 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] Canopy Walkways

[Peter Elderson]

I would say the feature is a kind of highway.
The construction is bridge, so bridge=yes on the highway.
The highway is a footway, and this kind of footway is called a canopy
walkway.

The footway part is kind of redundant, which is probably nice if you render
all footways, but unnecessary when you render canopy_walkways specifically.


Best Peter Elderson


Op za 22 aug. 2020 om 11:16 schreef Jake Edmonds via Tagging <
tagging@openstreetmap.org>:

> Should the key be bridge?
> I feel like canopy walkways are more like bridges than boardwalks.
>
> Sent from Jake Edmonds' iPhone
>
> On 22 Aug 2020, at 11:08, Alan Mackie  wrote:
>
> 
>
>
> On Fri, 21 Aug 2020, 21:46 Martin Koppenhoefer, 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 21. Aug 2020, at 22:25, Andy Mabbett 
>> wrote:
>> >
>> > "public building" and "trunk highway" are also common terms.
>> >
>> > Do we tag
>> >
>> >building=public_building
>> >
>> > or
>> >
>> >highway=trunk_hghway
>>
>>
>> these are different because it would be a literal repetition. What we do
>> is footway=sidewalk rather than „side“
>>
>> If general opinion is towards footway=canopy I could live with it, but my
>> preference goes to canopy_walkway
>> I’m not expecting so many that the extra characters will be significant
>> ;-)
>>
>
> I have had to remind myself several times as this thread has developed
> that this is not intended as a synonym for breezeway or other covered=yes
> footways.
>
> If the previously suggested =treetop isn't accurate perhaps a more
> explicit =forest_canopy ?
>
>
>> Cheers Martin
>> ___
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Canopy Walkways

[Peter Elderson]

Do we tag 
 highway=motor ?

Mvg Peter Elderson

> Op 22 aug. 2020 om 00:37 heeft Andy Mabbett  het 
> volgende geschreven:
> 
> On Fri, 21 Aug 2020 at 21:44, Martin Koppenhoefer
>  wrote:
> 
>>>   highway=trunk_hghway
> 
>> these are different because it would be a literal repetition.
> 
> Do we tag:
> 
>   highway=trunk_road ?
> 
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> 
> ___
> 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] Feature Proposal - Voting - kerb=regular

[Peter Elderson]

Nederland: stoeprand (/stooprund/);  officially: trottoirband
(/trotwharbund/)
I wonder what it is in Burundi and Iceland.

Vr gr Peter Elderson


Op vr 21 aug. 2020 om 09:39 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 21. Aug 2020, at 03:34, 80hnhtv4agou--- via Tagging <
> tagging@openstreetmap.org> wrote:
> >
> > in the united states it is Curb.
>
>
> in Germany it is Bordstein
>
> Cheers Martin
> ___
> 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] Canopy Walkways

[Peter Elderson]

footway on bridge construction, so highway=footway, bridge=yes seems ok.

Canopy walkway is the term I see used everywhere, not canopy bridge.

Makes sense to attach the canopy detail to the footway then. So
footway=canopy_walkway sounds right to me.


Best, Peter Elderson


Op vr 21 aug. 2020 om 08:46 schreef Volker Schmidt :

> The footway= approach isn't so good. A canopy walkway is more a bridge
> type.
>
> On Fri, 21 Aug 2020, 00:28 Graeme Fitzpatrick, 
> wrote:
>
>>
>>
>>
>> On Fri, 21 Aug 2020 at 07:50, Martin Koppenhoefer 
>> wrote:
>>
>>>
>>> Or maybe footway=canopy_walkway? highway= Footway and bridge=yes seem
>>> essential for a basic description.
>>>
>>
>> The combination of the three of them seems like a good, simple solution!
>>
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Peter Elderson]

Two dots are used in some circles to indicate inclusive range. eg 21..27.

Best, Peter Elderson


Op wo 19 aug. 2020 om 00:25 schreef Tod Fitch :

>
> On Aug 18, 2020, at 2:29 PM, Colin Smale  wrote:
>
>
> Maybe we should use a different character to indicate a range, such as a
> slash?
>
>
>
> In the United States it is not too uncommon for infill housing in urban
> areas to have fractional street numbers. So you can see addresses like “123
> 1/2 North Main Street” for a building located between 123 and 125 (odd
> numbers are usually on one side of the street so 124 is not available in
> this example). I already am annoyed by QA checkers that flag that as an
> error. Defining a slash to mean something other that the, to me, obvious
> use as a fraction would make things worse.
>
> Cheers,
>
> Tod
>
>
> ___
> 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] new page for tree_lined=*

[Peter Elderson]

Martin Koppenhoefer:

> I think we can assume that a line of trees in the middle is sufficient to
> make mappers use 2 highways instead of 1!? How can we distinguish between
> the following sections
> tree - road - tree - road - tree
> and
> tree - road - tree - tree - road - tree
> and
> tree - road - tree - significant “void“ space - tree - road - tree?
>

I would not make too much of it. The attribute gives the aspect of the
road, not the actual feature with details. So, all cases: both roads look
tree lined at both sides, so they get tree_lined=both.

If the space is significant, better map it as a landuse feature. Sometimes
a complete wildlife reserve can be found between road halves.

Example:  trees - road - trees - cycleway : the road gets tree_lined=both
and the cycleway tree_lined=left (assuming forward direction of the way and
righthand driving).

___
> 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] new page for tree_lined=*

[Peter Elderson]

Nederland has an awful lot of ways, waterways, railways, rivers, parkings,
churchyards, and other linear and area features which are lined with a row
of trees. And if I say a row of trees, think of 10 Km almost straight with
a continuous line of evenly spaced trees at both sides, sometimes also in
the middle, sometimes double or triple rows at each side, often with a
separately lined cycleway and tree_lined ditches.

Even in the woods, roads often have a separate distinct tree lining, often
between the road and the cycleways on both sides.

As it is a distinctive and verifiable (by survey, by viewers and by
satellite imagery) attribute of the road, it is worth mapping as
secondary tag. The purpose varies and can be guessed but seldom verified,
so best not try to define by purpose, just map what you see. Unlike
cycleways and sidepaths along roads, no routing has to be done over a line
of trees, but the attribute is nice to know for cyclists, hikers and
motorists.

One thing: we have tree rows in the middle of a road, not always combined
with a side tree row.
Maybe map that as a tree_row feature?

About generic: I wouldn't call tree_lined a generic attribute. It
specifically says the feature is lined by trees. Generic tagging IMO would
be: lined=* where the value specifies which lining is used.
If you want further specification of the tree_line details, I would suggest
to use natural=tree_row and tag everything you wish to record about the
trees.

I don't really care if it's on a separate tree_line page.

Best, Peter Elderson


Op vr 14 aug. 2020 om 01:08 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I’ve set up an initial documentation page for the tree_lined attribute
> (used mainly in conjunction with highways and waterways) and welcome
> comments for it:
>
> https://wiki.openstreetmap.org/wiki/Key:tree_lined
>
>
> This used to be a redirect to natural=tree_row (which is a different tag,
> as it is for a feature, not an attribute).
> There are also already translations in
> cs, de, es and uk (also redirects), which should be updated.
>
> Cheers Martin
>
>
> sent from a phone
> ___
> 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] new page for tree_lined=*

[Peter Elderson]

I can see how an area such as a parking, a churchyard or pedestrian area
can be tree lined. A node feature, not so much.

Best, Peter Elderson


Op vr 14 aug. 2020 om 01:08 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

> I’ve set up an initial documentation page for the tree_lined attribute
> (used mainly in conjunction with highways and waterways) and welcome
> comments for it:
>
> https://wiki.openstreetmap.org/wiki/Key:tree_lined
>
>
> This used to be a redirect to natural=tree_row (which is a different tag,
> as it is for a feature, not an attribute).
> There are also already translations in
> cs, de, es and uk (also redirects), which should be updated.
>
> Cheers Martin
>
>
> sent from a phone
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

[Peter Elderson]

Mvg Peter Elderson

> Op 25 jul. 2020 om 22:43 heeft Allroads  het 
> volgende geschreven:
> 
> The earlier mentioned,
> bicycle=leave
> This is for me, leave the bicycle behind at the sign.
> More native English speakers can give a comment on that?

If you're not with bike, the sign/access doesn't apply. If you are with bike, 
you will have to leave it there before passing the sign. if you are planning/ 
routing, the software will warn that you will have to leave the bike there if 
you want to pass. 

Looks useless, but in fact a lot of places have a no bike perimeter, usually 
with bicycle parking of sorts.

Works with anything you can carry, push or lead. 

>  ___
> 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