Re: [Tagging] Mapping bicycle-only turn lanes

[Jan Michel]

On 12.12.20 17:47, Paul Johnson wrote:
On Sat, Dec 12, 2020 at 10:46 AM Jan Michel 
<mailto:j...@mueschelsoft.de>> wrote:


On 12.12.20 17:25, Paul Johnson wrote:

 > Sure, if you manually torque tag it to match the incorrect
 > documentation.  As soon as you open the lane editor, it rightly
corrects
 > it to lanes=5, since you have 2 lanes in one way and 3 in the other.

The "incorrect documentation" was voted on and it was approved.


I'm pretty sure it was done without consideration for reserved lanes as 
lane access tagging wasn't something yet available.  Now it is, and it's 
time to reconsider that.


I'm refering to the proposal of exactly this: the :lanes extension. It 
was clearly and unambiguously taken into account:

https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag



Setting tags according to documentation is hardly "torquing tags". 


Which "lane editor" do you refer to? If any tool does this, it needs
to be fixed.


JOSM.

Please be more precise. JOSM has no built-in lane-editor.




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

Re: [Tagging] Mapping bicycle-only turn lanes

[Jan Michel]

On 12.12.20 17:25, Paul Johnson wrote:

Sure, if you manually torque tag it to match the incorrect 
documentation.  As soon as you open the lane editor, it rightly corrects 
it to lanes=5, since you have 2 lanes in one way and 3 in the other.


The "incorrect documentation" was voted on and it was approved.
Setting tags according to documentation is hardly "torquing tags".
Which "lane editor" do you refer to? If any tool does this, it needs
to be fixed.


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

Re: [Tagging] Mapping bicycle-only turn lanes

[Jan Michel]

On 12.12.20 14:25, Paul Johnson wrote:
On Sat, Dec 12, 2020 at 5:25 AM Jan Michel 
<mailto:j...@mueschelsoft.de>> wrote:


Hi,
where do you see a problem here? The current situation might not be
perfect, but it is usable as it is. The only thing to keep in mind is
that the number of "lanes" does not need to match the number of entries
in the "XY:lanes" tags.


That disagrees with literally every lane editing and validation tool in 
existence at this time.


Please check for example this way:

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

It perfectly validates in all tools I tried - JOSM, OSMI, Keepright...
Rendering in the lane attribute style in JOSM is fine as well.

Even the examples in the Wiki show exactly this:
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles

It was mentioned in the original proposal for the :lanes suffix 8 years ago.

So, it *agrees* "with literally every lane editing and validation tool 
in existence" as well as documentation.



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

Re: [Tagging] Mapping bicycle-only turn lanes

[Jan Michel]

Hi,
where do you see a problem here? The current situation might not be 
perfect, but it is usable as it is. The only thing to keep in mind is 
that the number of "lanes" does not need to match the number of entries 
in the "XY:lanes" tags.


On the other hand, the "lanes" tag has some real problems, e.g.
lanes = 2
lanes:psv = 1
lanes:hov = 1
Is there any lane for regular traffic or not?

In my opinion the "lanes" tag is just a rough estimate for the width and 
capacity of a road - all actual numbers have to be read from more 
detailed tags such as cycleway, busway and all XY:lanes.


Jan


On 09.12.20 00:19, Paul Johnson wrote:
I've been saying for a while now that it's time we fix the tagging 
problems with bicycle and motorcycle lanes by /actually including them 
as lanes/, because it cleanly handles exactly this kind of situation 
concisely and cleanly.  They're still lanes, just a reserved kind of 
lane like a carpool lane or HOV lane.  JOSM already handles this with 
its lane tagging features beautifully.  Any data consumers that can deal 
with lane access (which, if they're not, this is /already/ a bug, 
because HOV and bus lanes are things, too) will be able to handle it 
without problems.


Or we can just keep trying to pretend bicycle lanes aren't actually 
lanes and try to figure out how to fix something while simultaneously 
keeping it permanently broken because the original lanes proposal only 
considered private motorists.



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

Re: [Tagging] Mapping bicycle-only turn lanes

[Jan Michel via Tagging]

On 08.12.20 23:08, Mateusz Konieczny via Tagging wrote:

highway, name, lit=yes, surface=asphalt etc
oneway=yes
oneway:biycle=no
lanes=1 (as bicycle lanes are not counted)
vehicle:lanes:forward=no|yes
bicycle:lanes:forward=designated|yes
turn:bicycle:lanes:forward=left|
turn:lanes:forward=|
vehicle:lanes:backward=no
bicycle:lanes:backward=designated
cycleway:left=lane
cycleway:right= - there is left turn lane only, so 
cycleway:right=lane would be
not entirely correct but there is a left turn lane, cycleway:right would 
be worse


In my opinion this is correct. There is no cycleway:right here. The 
:lanes tags describe the situation perfectly well.


You can add
cycleway:left:oneway = no
That adds "there is a cycleway on the left, and it can be used in both 
directions".


Jan


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

Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site

[Jan Michel]

On 31.10.20 14:40, Sven Geggus wrote:


We are already using plural when tagging caravans=yes/no and tents=yes/no.

Thus I would not suggents to tag this singular in case of capacity.

Looking at the current state of tagging in taginfo we have:

capacity:caravans 65
capacity:caravan 4
capacity:tents 241
capacity:tent 0



Thus I do not see a real argument for using singular here.


To complete this list:
capacity:motorhome  32
capacity:motorhomes 0

The thing about caravan and caravans is a mess. Both keys actually exist...
- 'caravan' refers to the vehicle in form of a trailer and whether it is 
allowed to access some highway / area
- 'caravans' refers to either trailers or full motorhomes and only 
applies to camp_sites.


So, capacity:caravan should be used on parking lots that have spaces for 
cars with trailers, while capacity:caravans should be used on camp_sites 
that accomodate either caravan trailers or motorhomes, but there is no 
distinction possible between both kinds of vehicles.


As a result this is a fully valid tagging:

amenity = camp_site
caravan = no
capacity:caravans = 10

That would be a camp site you can enter with a motorhome, but not with a 
trailer.



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

Re: [Tagging] Defining the meaning of capacity tag for tourism=camp_site

[Jan Michel]

On 31.10.20 12:03, Sven Geggus wrote:

* Instead the following tags should be used in future:
   - capacity:persons
   - capacity:tents
   - capacity:caravans


I agree.
There is a slight problem here regarding singular/plural.

- vehicle types are usually given in singular (e.g. capacity:bicycle)
- other 'things' are often given in plural (seats, persons, tents)

In fact, capacity:caravan and capacity:motorhome are used more often
compared to caravans and motorhomes.

I would go for

- capacity:persons
- capacity:tents
- capacity:caravan
- capacity:motorhome


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

Re: [Tagging] Feature Proposal - RFC - electricity=*

[Jan Michel]

Hi,

I don't see a need to introduce new 'electricity:XY' keys.
The current definition of 'electricity' is to mark how an
amenity or building is supplied with energy. There is no intention
to have this key mark things like access for other people to this
energy source.
Access to electricity is tagged using 'power_supply' - and all your 
ideas would fit perfectly into the already existing

'power_supply' key. It seems to be the ideal occassion to revisit
this tag and bring it to a good shape.

Here's what I would do:

- There is no formal proposal for power_supply yet, so we should write one

- The option to have socket types as values is listed in the Wiki, but 
hardly ever used (93% of uses are plain yes/no), so this should be 
dropped as its mixing different things into one tag.


- Propose the new subtags according to your ideas, i.e.
power_supply -> adjust values to be yes/no/grid/generator ...
power_supply:socket -> values and meaning as in Key:socket
	power_supply:source -> values and meaning as described for power:source 
and generator:source

power_supply:fee -> already in use!
power_supply:access -> like in common tags like toilets:access


Jan 


On 30.10.20 13:44, Lukas Richert wrote:
Since a lot of people apparently didnt see the RFC the first time, I'll 
go back to RFC status for now. (I thought the threads were sorted by 
subject title of the email and didnt check online if it was actually 
visible. )


--

The original message:

Hello all,

after the comments on the confusing nature of the word 'source' in my 
original proposal of 'electricity:source', I have now changed the name 
to 'electricity:origin' as suggested on the discussion page. 
Furthermore, I would like to revive and extend the proposal of the key 
'electricity' as this previously conflicted with parts of the 
electricity:source proposal and was not consistent.


Both proposal pages:

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/electricity

[2] 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/electricity:source 



The idea now is to allow for the tagging of buildings or amenities that 
have electricity. The rationale is described in more detail at [1]. Tags 
such as access, fee, schedule and origin can then narrow down the 
availability to the public and the question of financial or direct 
origin of the electricity.


This is distinct from the drafted tag power_supply as it is used to 
describe the type of sockets used at a specific outlet. The values for 
that tag are still currently under discussion.


I would also not tag this as a subset of power=* as this maps the 
facilities and features that relate to the generation and distribution 
of electrical power and should not be used to map the consumers of 
electricity.



I am eager to hear the feedback to the revised proposals!
---

Also, perhaps relevant: both the power_supply 
 and socket 
 keys describe the same 
feature. power_supply so far has occasionally been used in the manner 
that electricity proposes to be. Unfortunately, the proposal for 
power_supply is relatively inconsistent. I think the socket:* tag is 
better thought out and also currently more used. I would be in favor of 
deprecating power_supply and separating the two meanings it currently 
has into electricity=* and socket:*=#.


Regards,

Lukas


___
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 - electrcity=*

[Jan Michel]

Hi Lukas,
I guess that most people (like me) missed your RFC.
You posted it as a reply to a completely different topic
about railway=station and not as a separate thread.

I'd like to ask you to stop voting, repost the RFC for
everybody to read and wait for comments.

Jan


On 29.10.20 17:50, Lukas Richert wrote:

Good evening,

as I've received no further comments to the proposal and all points 
brought up should be resolved, 
https://wiki.openstreetmap.org/wiki/Proposed_features/electricity is 
open for voting now.


Cheers, Lukas


___
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

[Jan Michel]

On 20.10.20 22:43, Martin Koppenhoefer wrote:
I am not usually mapping this detail of parking fees, but from my 
understanding the above suggested tags would work and could be seen as 
covered by current state of tagging, no need for a proposal, just use it.

https://taginfo.openstreetmap.org/keys/fee%3Aconditional#values



A)
fee=yes
fee:conditional = no @ maxstay < 3h


I fully agree with this tagging scheme, although it should be 'stay' 
instead of 'maxstay'. We're refering to the actual length of the stay 
here, not to a limit. It's the same as with e.g.

maxspeed:conditional = 50 @ weight > 3.5
Here we use 'weight' here, not 'maxweight'.


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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jan Michel]

Hi,
I think that's fine, with two remarks from my side:

You write "shoulder:width" but "sidewalk::width". It should be 
made clear that  (left,right,both) can be used in all cases, but 
is optional. E.g. there is no difference between sidewalk:width and 
sidewalk:both:width.



"If the width cannot be measured exactly, but is only an estimation, 
est_width=* should be used."
I disagree here - the obvious problem is how to define "exactly" and 
"estimation". Why should the tag change depending on how precise the 
mapping is? Should we have a "est_building" tag if we can't draw a 
precise outline? How is "width" different?





On 21.09.20 15:52, Supaplex wrote:
As a result of this discussion I would like to add a clarifying 
paragraph on the corresponding wiki page. The core statement is: "To 
avoid these ambiguities, some tags are in use to specify the width of 
different elements: ..." See the Talk Page: 
https://wiki.openstreetmap.org/wiki/Talk:Key:width#.22width.22_on_streets.2Fhighway


Maybe someone has time and motivation to make a proposal(?) to directly 
define "width" in these cases. Since there are different opinions on 
this, I would leave it at a clarifying paragraph for now.


- Alex -




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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jan Michel]

On 16.09.20 10:30, Martin Koppenhoefer wrote:

On 15. Sep 2020, at 19:05, Jan Michel  wrote:

If you want to tag how much space there is for some kind of vehicle moving in 
some direction, there are the specific width tags like width:lanes, 
sidewalk:width, cycleway:width, shoulder:width, verge:width
and so on.


following your initial statement (all parts), you would include the verges in 
the width?


That's a difficult point. I'm not a friend of the 'verge' tag at all (as 
opposed to the 'shoulder' which is an area traffic can make use of). It 
was somehow invented and put to use in 2016, but as far as I know never 
discussed. I definitely prefer to tag verges as separate objects - even 
one of the examples in the Wiki shows a ~5m wide park like area with 
trees to be tagged as verge. I think it's really far-fetched to call 
this a part of the highway.


To answer your question - no, because I don't see verges as part of the 
road.




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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jan Michel]

On 15.09.20 10:52, Martin Koppenhoefer wrote:

Looking at width tag variants:
https://taginfo.openstreetmap.org/search?q=width

here are those with more than 1K uses


Please be careful with such a list. E.g. width:shoulder stems
from a user in Finland and from something that looks like an old
(un-)organized edit in Nepal that used several other uncommon tags as 
well. The documented tag is 'shoulder:width'



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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jan Michel]

I expect the "width" of a way to be the actual width of the object it 
represents.

This obviously changes depending on the mapping style applied, e.g.

- if it's a highway with sidewalk and cycleway tags, it's the width of 
all of it


- if it's just a road with footways mapped as separate ways next to it, 
then it's the width of just the road.


If you want to tag how much space there is for some kind of vehicle 
moving in some direction, there are the specific width tags like 
width:lanes, sidewalk:width, cycleway:width, shoulder:width, verge:width

and so on.

Jan


On 14.09.20 20:34, Supaplex wrote:

1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with 
parked cars when they are on street

3) Width including sidewalks / roadside paths



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

[Tagging] How to tag body height limits on attractions?

[Jan Michel]

Hi,
in the comments of a changeset [1], there is a discussion about how to 
tag the required body height for users of an attraction in a theme park.

Likewise, some playgrounds have restrictions on the size of children.

Currently there is no well-defined tagging scheme for this and there is 
an awful lot of different tagging applied. These tags are currently in 
use on attractions - which scheme gets your support?



1. minheight / maxheight - like the common tag on roads for the height 
of vehicles (used ~50 times each)


2. attraction:minheight / attraction:maxheight (used 37 and 11 times, 
respectively)


3. min_height / (max_height) - used a few times in this context, but 
indistinguishable to the 3D-tagging of the lower end of the attraction 
itself.


4. minimum_height_requirement / maximum_height_requirement  (used 143 
and 4 times)


5. height_requirement - with both minimum and maximum size in one value 
(used 7 times)



I'm very much in favor of the first option.



[1] https://www.openstreetmap.org/changeset/90228325


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

Re: [Tagging] Network-tag needs extension

[Jan Michel]

On 21.08.20 14:30, Michael Schmidt via Tagging wrote:

Maybe for all these options the network tag could look like
network=*
network:short=*
network:district=*
network:district:short=*
network:state=*
network:state:short=*
network:national=*
network:national:short=*


Hi,
In my opinion, this information that does not belong into the OSM 
database. Maintaining short names, abbreviated names and hierarchies on 
each and every node that belongs to some network is way too much work 
and creates way too much redundant data.


Ideally, we find one common spelling of the name of each network and use 
this throughout all objects that belong to it. The further details like 
different spellings and the hierarchy can then be established in further 
documentation, e.g. in the Wiki.


Jan


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

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 08.08.20 15:30, Martin Koppenhoefer wrote:



sent from a phone

On 8. Aug 2020, at 14:48, Jan Michel 
 wrote:

amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=ye
this doesn’t allow for bicycles to be parked. It also doesn’t seem to be 
a subtype of parking. If it would be just for motorcycles and 
kick_scooters, why not

amenity=motorcycle_parking
kick_scooter=yes ?


Because this gives too many options on how to tag parking for 
kick_scooters depending on what other vehicles are allowed as well:


amenity=parking + kick_scooter = yes
amenity=bicycle_parking + kick_scooter = yes
amenity=motorcycle_parking + kick_scooter = yes
and last but not least the scooter-only parking where none of the three 
options above applies.


That will just be a mess of tags nobody can actually use - orders of 
magnitude worse than having one common tag for all motorized vehicle 
parking and access tags for individual vehicle types.



amenity=small_vehicle_parking  + motorcycle=yes + kick_scooter(*)=yes



not sure what a “small vehicle” is supposed to be. 
Needs to be defined, like any other new tag. What is a 'kick_scooter'? 
With a motor? without a motor? with a tiny seat?
Most likely it will boil down to something like single-tracked, open 
vehicle for two people at most.



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

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 08.08.20 14:22, Martin Koppenhoefer wrote:

On 8. Aug 2020, at 13:46, Jan Michel  wrote:
If I just enter 'scooter parking' into Google Image Search, I find plenty 
examples of designated parking areas for both bicycles and scooters combined. 
There are also some moped/mofa parkings that allow (kick-)scooters to be found.

then find a tag for them ;-) (de:Zweiradstellplatz), around here these are 
separate, distinct features, either bicycle or motorcycle and scooter parkings.


I already proposed two options. You didn't like either.

amenity=parking + vehicle=no + motorcycle=yes + kick_scooter(*)=yes

amenity=small_vehicle_parking  + motorcycle=yes + kick_scooter(*)=yes


(*) just a placeholder for the yet-to-be-defined proper tag


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

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 07.08.20 23:33, Martin Koppenhoefer wrote:


sent from a phone


On 7. Aug 2020, at 17:57, Jan Michel  wrote:

I propose to not introduce new top-level keys because they are not flexible 
enough. I'm very well aware that we have parking, bicycle_parking and 
motorcycle_parking already, but it just doesn't scale with the amount of 
different vehicle types.


I don’t see why the tags should be flexible as the parkings aren’t. You cannot 
park a bicycle at a motorcycle parking nor the contrary.


If I just enter 'scooter parking' into Google Image Search, I find 
plenty examples of designated parking areas for both bicycles and 
scooters combined. There are also some moped/mofa parkings that allow 
(kick-)scooters to be found.



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

Re: [Tagging] Feature Proposal - RFC - more parking types

[Jan Michel]

On 07.08.20 19:11, Tobias Knerr wrote:

On 06.08.20 22:52, Matthew Woehlke wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking

I like it, thanks for working on this topic! Two suggestions:

Could you add a short definition of "compact"? I can guess that it's
supposed to mean parking spaces for compact cars,


You also have to keep in mind that what a 'compact car' is strongly 
depends on the region. What counts as 'compact' in the US is a 'regular 
sized' car in Europe and is a 'large' car in densly populated areas like 
Tokyo.



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

Re: [Tagging] Electric scooter parking

[Jan Michel]

On 07.08.20 19:09, Paul Johnson wrote:
On Fri, Aug 7, 2020 at 12:00 PM Mateusz Konieczny via Tagging 
> wrote:

Aug 7, 2020, 18:05 by ba...@ursamundi.org
:
On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging
mailto:tagging@openstreetmap.org>>
wrote:
amenity=parking + vehicle=no + electric_scooter=yes
seems like a terrible idea to me
Why?  That's actually pretty good.  amenity=parking is for motor
vehicle parking, electric scooters are a part of that.
Mostly because it will break all current users of amenity=parking
and at least for me place to place
electric scooter is not the same object as a car parking (in the
same way as bicycle parking
is not the same object as a car parking).
I feel like a data consumer unable to deal with access tagging is 
already broken in advance.


+1 from my side.

It might be useful to have two different top-level amenity tags for 
parking lots for large and small vehicles, but not one tag for every 
type of vehicle.


Any new tagging scheme must be able to support parking lots that are 
dedicated to several types of vehicles - at least those of similar size.
We must be able to tag a shared motorcycle/moped/electric scooter 
parking area.


If we really need a new top-level tag, it has to be something like
*amenity=small_vehicle_parking* and comprise all of motorcycles, moped, 
mofa, speed_pedelec, scooters (of any kind) and so on. Further details 
could then be given by access tags to specify which kind of vehicles can 
be parked there.




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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

It started as my personal summary of tags, but in the meantime it looks 
like it got a rather comprehensive summary of current tagging practice.


I don't really know where to start cleaning up the Wiki, because this 
also means to remove some of the existing pages and replace them.


I'm happy if my work somehow helps to improve the main wiki pages, but I 
think this is not something one person alone should do.


On 02.08.20 10:53, David Marchal via Tagging wrote:

Jan,
I see you have done much work on this topic on your page 
(https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging); 
why didn't you include these informations on the general Wiki pages 
instead of your user pages?



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

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 16:23, Martin Koppenhoefer wrote:
No, "gross" refers to the German "Gesamt" as in "total weight of 
vehicle, driver and load". The precise translation of "gross weight" 
is "Bruttogewicht" or "Gesamtgewicht".

that’s what I said, maximum payload included


Sorry for not being more clear: There is no connotation of a "maximum" 
or "allowable limit" in neither the English nor the German term.
"gross weight" or "Gesamtgewicht" is just the current total weight, 
without any statement about how much additional load might be possible.
An empty truck has a lower gross weight than a full one, although the 
gross weight rating stays the same.



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

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 15:36, Martin Koppenhoefer wrote:

On 1. Aug 2020, at 15:27, Jan Michel  wrote:
General terminology point of view:
As I understand it, the term 'rating' already refers to the allowed limit. Note 
that it's called 'gross weight rating', but not 'maximum gross weight rating'.

I guess the “gross” part refers to a maximum.
As in “zulässige Gesamtmasse”
which implies empty mass plus maximum mass of payload.


No, "gross" refers to the German "Gesamt" as in "total weight of 
vehicle, driver and load". The precise translation of "gross weight" is 
"Bruttogewicht" or "Gesamtgewicht".



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

Hi,

On 01.08.20 15:48, David Marchal via Tagging wrote:
Hm, it seems a smart way to manage such cases; I could add the 
restrictions on the relation, like hazmat:water=no or maxweight=12. I 
assume that, in such cases, I must create a destination_sign relation 
for unrestricted destinations, and one for each destination restriction 
(if there are several restrictions, one relation for each restriction).


Is it widestream to have several destinations in one single relation, or 
is it necessary to add a relation per destination? Having one relation 
per destination would be a pain in the ass.


I'd say "yes" from my personal experience, but that might be biased. I'm 
inclined to use the destination* tags on a relation in the same way as 
those on ways.


What about application support? Are destination_sign relations widely 
supported, or are they mostly ignored by software like Osmand?


I'm not aware of any users despite of hiking maps (i.e. waymarkedtrails.org)

I would like to add this possibility on the Wiki; do you think it would 
be necessary to fill a proposal, or could I just add it, as it is a 
simple, self-explaining, combination of preexisting tags?


Using a vehicle type (bicycle, foot) is already used several thousand 
times on the relations and even more often on the destination signs 
themselves. So I don't see a problem to just use e.g. hgv as well.

We should add a statement in the Wiki documentation.

On the other hand, I wouldn't use access tags like maxweight without a 
detailed discussion.

(As always, that's just my personal opinion)

Jan


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

[Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 15:03, Martin Koppenhoefer wrote:

On 1. Aug 2020, at 11:28, Jan Michel  wrote:
The access tag is 'maxweightrating' like 'maxweight' or 'maxheight'. In the 
value of conditional tags there is no 'max' because there we refer to actual 
values and not limits. We use 'weight', 'height' and hence also 'weightrating' 
there.

the difference is that weight and height are actual weights and heights, while 
the rating is for a maxweight, hence I believe it should be “maxweightrating” 
when it’s about the actual maxweightrating.


Well, this is quite off-topic here, but this interpretation wouldn't be 
consistent. Let me use the term GVWR to refer to the weight rating of a 
vehicle to make it easier to read:


OSM Tagging point of view:
The access tag 'maxweightrating' doesn't refer to a specific GVWR, but 
to all vehicles with a GVWR less than the given number. So, if we use 
the term 'maxweightrating' to refer to the GVWR, the access tag should 
be 'maxmaxweightrating', but can't be 'maxweightrating' because that 
would specify a defined GVWR.


General terminology point of view:
As I understand it, the term 'rating' already refers to the allowed 
limit. Note that it's called 'gross weight rating', but not 'maximum 
gross weight rating'.



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

On 31.07.20 21:07, Martin Koppenhoefer wrote:

On 31. Jul 2020, at 18:01, Jan Michel  wrote:

I'm not familiar with French rules, but is it the actual weight or the allowed 
total weight of the vehicle that matters? If it's the latter, you can use 
'weightrating' instead of 'weight'.

shouldn’t that be „maxweightrating“?



The access tag is 'maxweightrating' like 'maxweight' or 'maxheight'. In 
the value of conditional tags there is no 'max' because there we refer 
to actual values and not limits. We use 'weight', 'height' and hence 
also 'weightrating' there.



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

Hi David,

On 31.07.20 15:53, David Marchal via Tagging wrote:

Hello, there.

I'm wondering, there are destination signs which only apply to some kind 
of vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 
12t… How would I tag such destinations? The simple way would be to use, 
respectively, destination:hgv=*, destination:bicycle=*, 
destination:foot=*, destination:conditional="* @ weight<12". Am I right 
to assume these?


Yes, I agree. 'destination:bicycle' is already used "a bit".
I would try to stay with the simple vehicle types and use conditionals 
as rarely as possible.
That's actually what I also mentioned in my 'destination' summary some 
years ago:

https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging#:forward.2C_:backward_and_:lanes

But, one word of caution: I think we shouldn't add too much detail here. 
For actual routing we don't need this information as it should use 
actual access rules - which are in most cases present somewhere along 
the route. The only actual reason to have this in the database (IMHO) is 
to have a proper display of destination signs.




If so, some examples:
[...]
Is that correct? 


They all seem correct to me. One exception is 'destination:fee' for the 
'paege' addition. We use the tag 'toll' on roads, so the destination-tag
should use this as well. On the other hand, we could also tag it as 
destination:symbol = paege. This seems easier to extent to other toll

systems like the Austrian or Swiss "Vignette" and there respective symbols.

I'm not familiar with French rules, but is it the actual weight or the 
allowed total weight of the vehicle that matters? If it's the latter, 
you can use 'weightrating' instead of 'weight'.


Can I edit the Wiki destination tag page to give these 
informations, or maybe should I submit a RFC to formalize this?


The whole 'destination' eco-system of tags was established without 
voting on anything. What we currently lack most is a proper documentation.
But, the tags you propose here are just what follows naturally from 
existing tagging schemes - e.g. transportation types can be added after 
a key to restrict it to a certain vehicle type. In so far I don't see 
the need for a dedicated proposal here.



Jan


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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Jan Michel]

On 23.07.20 18:57, Paul Allen wrote:

Here's an example I used to travel past regularly.  But that was years ago,
and the last time I saw it was a couple of years before I started mapping.
https://goo.gl/maps/fWvzsKneyMtSAFuW6  I remember roughly where it was,
but not well enough to map it, so I haven't added it. If I did map it, standard 
carto
would show it as a stylized fingerpost.



Interesting. I would classify this as a trailblaze, but not as a 
guidepost. A guidepost is something that shows me which destinations a 
way leads to. A trailblaze is a small sign that shows where the way is 
I'm already following.


To me a guidepost is a guidepost, no matter whether it has fingers and a 
post or not. That's minor details that can be handled by minor tags.
I think this matches very well the style many other tagging rules are 
using. E.g. a "highway" is any kind of way, no matter the size and its 
intended use and how it relates to the common use of the term "highway".





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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Jan Michel]

Hi Michal,
I would stay with information=guidepost for those.
They serve exactly the same purpose, so they should get the same major 
tag. It's only the way the sign is made that is different. You can add 
the common tags like "support", "material", "location" or "colour" to 
give further details about the style of the marker.


If it's really needed, we can also add another tag to specify the type 
of marker. Unfortunately guidepost=* has already been taken for 
something different, so one could define guidepost:type=*.


Jan

On 21.07.20 14:41, Michal Fabík wrote:

On 7/21/20 1:31 PM, Andy Townsend wrote:
I've used "tourism=information; information=route_marker" for these. 
"trail_blaze" is also frequently used


That doesn't sound right to me. If I understand the description on the 
Wiki[1] correctly, what is tagged as "information=route_marker" or 
"information=trail_blaze" doesn't carry any information other than "this 
is where the path is" 
What I'm talking about is the same information that one can find on a 
regular guidepost (i.e. names of destinations, distances to them and 
directions marked with arrows), the only difference being the "technical 
implementation", so to say, i.e. metal plates screwed to a pole vs. 
painting on a rock surface, among others.





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

Re: [Tagging] Finger- or guide-post text

[Jan Michel]

Hi Kevin,

On 20.07.20 05:51, Kevin Kenny wrote:
[In the context of relation type=destination_sign]
Do I understand the intent correctly that the direction should be the 
way that the finger is pointing, and not the cardinal direction of the 
route? 

Yes, the tags on the relation describe the finger.
You can even use a number to give the precise direction in degrees.

I ask because in the US, we often describe a direction as "trail 
north" or whatever in that a hiker going 'northbound' on the route will 
be walking in that direction - which may be any direction at all on the 
compass.
Following my accustomed habit of jumping right in with the awkward 
cases, I might try to compose the relations for 
https://www.flickr.com/photos/ke9tv/7881561738/in/album-72157631291668040/ Note 
that the top two signs are 'north' and the bottom two are 'south' in 
terms of trail directions.  

I don't think we have a scheme for trail directions yet.
But, displaying the trail name automatically is not an issue - the 'to' 
member yields a node or way, and the software can easily look up the 
relations this way belongs to.




Simply having "to" as a distant node could yield a horribly misleading.  
Oh, wait, 'to' is the next node along the way, not the ultimate 
destination. 
Correct. I prefer to use a way as 'to', and this way should start/end at 
the intersection. This makes it easier to use the data and less prone 
for ambiguities.


Is there a way to give a node ref for what the 
'destination' corresponds to?  On the sign in question, it might be nice 
to be able to indicate where Wawayanda Shelter is, since it's about 40 
km distant. 


Nothing established. There are 200 cases of the role 'destination', 
which I assume are used for exactly this purpose.



Jan


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

Re: [Tagging] Finger- or guide-post text

[Jan Michel]

Hi Andy,
we already have (not well documented) tags for this:

Either you use destination_sign relations as Sarah pointed out. Or, if 
you prefer a more simple approach, there are eight defined keys to add 
the information with approximate directions:


direction_north, ..., direction_southwest, direction_northeast, ...

For some reason they are only mentioned on the German Wiki page
https://wiki.openstreetmap.org/wiki/DE:Tag:information%3Dguidepost

But they are used almost 30,000 times already, see e.g.
https://taginfo.openstreetmap.org/keys/direction_south

These eight cardinal directions seem to be quite imprecise, but if you 
look at common intersections, they are able to cover almost all cases.


Jan


On 16.07.20 20:24, Andy Mabbett wrote:

I am mapping a fingerpost, aka guidepost:

https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost

I would like to add the inscription, for each of the three fingers,
with their compass points. I note:

https://wiki.openstreetmap.org/wiki/Key:destination
destination:337.5:=foo

What do folk think?




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

Re: [Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

[Jan Michel]

On 09.06.20 17:37, Volker Schmidt wrote:

an S-pedelec is a Light Moped, [...]
mofa (which I presume is a Light Moped in OSM)


No, most speed pedelecs are more like mopeds (limited to 45 km/h)
than mofas (limited to 25 km/h).



For the Tuebingen example one could use moped:electric=yes


This misses the fact that there are also classic mopeds with
an electric motor. These are not allowed in the Tübingen tunnel
and are in many places different to speed pedelecs, e.g. they
are not sold and serviced in typical bicycle shops while speed-
pedelecs are.


Can you indicate any situation where the new tags will be used and the existing 
categories don't work?


As it is stated in the proposal, if the vehicle is treated identically
to any of the traditional vehicles (moped, bicycle, mofa), then this
traditional key should be used.
The new keys are solely for situations where the difference matters.
This can be cases with explicit traffic signs (see Tübingen), shops,
amenities and so on.
There is no conflilct with existing vehicle categories - if a road is
closed for e.g. moped, this immediately applies to speed-pedelecs as
well (at least in EU countries that have this legislature), no new tag
is needed.



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

Re: [Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

[Jan Michel]

Voting has ended after 14 days. There were 28 votes, 27 'yes' and one 
'abstain'.
This means, the two keywords 'electric_bicycle' and 'speed_pedelec' have 
been approved for use and two new vehicle categories have been 
introduced. Let's see how this works out in our daily mapping tasks.


There were some comments raised about the system used in some US states 
- unfortunately this wasn't mentioned during the 7 months of RFC. The 
system forsees three classes, numbered 1 to 3. To cope with this, I 
suggest to amend the 'electric_bicycle' tag with sub-categories like 
'electric_bicycle:class2". I will leave this to a separate proposal, 
preferably written by someone more familiar with these classes.


Thank you very much for your participation!
Jan


On 23.05.20 16:37, Jan Michel wrote:

The proposal for keywords for electric bicycles is now open for voting:

https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles




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

[Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

[Jan Michel]

The proposal for keywords for electric bicycles is now open for voting:

https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles


Thank you very much, people who participated in the discussion and
Thank you very much in advance for adding your vote!

Jan



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

[Tagging] Feature Proposal - RFC - electric_bicycle and speed_pedelec

[Jan Michel]

Dear all,
some time ago I started the proposal to define tags for several light 
electric vehicles. It turned out to be difficult to come up with names 
for keys that unambiguously describes all these vehicles.


During discussion the idea came up to separate the proposal in two 
parts. This first proposal covers the two keys electric_bicycle and 
speed_pedelec for the two types of bicycles with electric motors that 
are recognized by law in several European countries.


The full proposal can be found here:
https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicycles

I would like to ask you for further comments and aim for putting this 
proposal up for voting in two weeks from now.


Jan


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

Re: [Tagging] Doorzone bicycle lanes

[Jan Michel]

On 03.05.20 19:16, Volker Schmidt wrote:
I would advocate a more generic approach that remains open to other 
types of hazards (there are many, unfortunately).
A generic 
hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever


I agree, but I would rather use
cycleway:(left|right|both|):hazard
'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's 
more like an hazard that is a "feature" of the cycleway. Everybody close 
to the cycleway is part of the hazard (whether active or passive) but 
bicycles in other places of the road are not affected.



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

Re: [Tagging] Doorzone bicycle lanes

[Jan Michel]

Hi Florimond,

On 03.05.20 11:04, Florimond Berthoux wrote:

And I'd say yes also for :
cycleway:lane:exclusive
In which case is this tag needed? A cycleway=lane shouldn't be shared 
with anybody else, and we already have values for shared lanes, e.g.

share_busway or shared_lane.


cycleway:lane:width
cycleway:lane:color


Why do you want to add the ':lane' part into the tags?
The keys without it are already in widespread use:
cycleway:width, cycleway:[left|right|both]:width
cycleway:colour, cycleway:[left|right|both]:colour
(also note the BE spelling 'colour')

Jan



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

Re: [Tagging] Doorzone bicycle lanes

[Jan Michel]

Hi,
I oppose adding this officially to the top-level cycleway:lane tag.
I see this information as one more property of the cycleway, like
surface, smoothness, width and so on.

We already have a documented key 'cycleway:buffer' that is described
as the width of the buffer space between car lanes and the bicycle lane.
The 'cycleway:buffer' tag is also used combined with :left and :right to 
denote the buffer on left-hand and right-hand side of the cycleway.


Mappers in Berlin worked on a more detailed tagging of buffer and 
protection of bicycle lanes, see (unfortunately in German only)

https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege

I'd suggest to get in contact with them and discuss this. I imagine that
this information could fit very well into the cycleway:buffer tag - A 
door zone is a non-existent buffer, so instead of 'no' one could use

'doorzone' as one of the non-numeric values.

Jan



On 03.05.20 08:37, Andrew Harvey wrote:
For a while myself and others have been using cycleway:lane=doorzone to 
say the bicycle lane is in a doorzone, I've now added documentation of 
this as "in use" at 
https://wiki.openstreetmap.org/wiki/Key:cycleway:lane. However this 
conflicts with the other "in use" cycleway:lane=exclusive/advisory, 
since you can have exclusive/advisory lanes which are doorzone or not.


None of these have gone through a proposal process and both are 
independently in use.



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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Jan Michel]

On 20.03.20 11:44, Martin Koppenhoefer wrote:
but isn't this referring to post office boxes, as opposed to the other 
kind of lockers and boxes that the OP mentioned? Are you suggesting to 
use this for all kind of such boxes 
Yes. We shouldn't have a separate tag for each and every company that 
offers such services. The value of the tag should be what needs to be on 
the address label and this has to contain information on the kind of box 
or the operator.



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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Jan Michel]

Hi,
I don't think we need another tag here, but we have to define one common 
way to tag these.

There are several different keys already in use:

addr:postbox   (214)
addr:pobox (185)
contact:pobox  (114)
contact:p.o.box (84)
addr:po_box (16)

I'm personally in favor of contact:pobox - it's not an address, but a 
way of contact.
I'd disfavor any spelling of 'post box' in this context, because this 
term is already used in OSM to mark boxes letters are delivered to and 
might cause some confusion.


Jan


On 19.03.20 00:24, Warin wrote:

Hi,

While there are methods of entering street addresses there don't appear 
to be any way to enter addresses that use Post Office Boxes and other 
delivery types.


There is a proposal to may the existence of PO Boxes but no way to enter the 
address data for those that use them.

As well as PO Boxes there exits several types of delivery methods in Australia, 
below are listed all of the officially accepted types with their officially 
accepted abbreviations.




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

Re: [Tagging] Public refrigerators

[Jan Michel]

Hi,
isn't this exactly what a amenity=give_box is? Just for food and not for 
toys or clothes.
With your proposed tags, we would need yet another one for non-cooled 
food, so this is a bad idea in my opinion.


So, I suggest:
amenity = give_box
food = only
refrigerated = yes


Jan

On 25.02.20 16:44, Markus wrote:

Hello all

I've noticed that recycling:food= has been added [1] to
amenity=recycling wiki page with the meaning "community fridge [2] to
help reduce food waste".



As we already use amenity=public_bookcase and amenity=give_box for two
very similar facilities, it seems better to use something like
amenity=public_refrigerator or amenity=community_fridge.



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

Re: [Tagging] Tagging venues which give away free condoms?

[Jan Michel]

Hi,
I'm more in favour of a generic scheme for anything that is given away 
free of charge instead of a dedicated tag for one special item.


So, why don't we propose 'free:*' as a generic namespace for this?


Or, one more step: Wouldn't it be even more useful to have one common 
scheme for items that are distributed free of charge *or* for a small fee?

That could be something along the lines
distribute:ITEM = (yes|no|free|1 USD|tip|donation)


Jan




On 20.02.20 21:44, Rory McCann wrote:

Some places give away free condoms to fight the spread of STDs (incl.
HIV/AIDS). Is there a good way to map that in OSM?

I suggest `free:condoms=yes/no`, since it's descriptive, matches the
`sells:X=yes/no` scheme. And the `vending:X=yes/no` scheme.



Any feedback? Thoughts? (Hopes? Fears? Dreams? )




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

Re: [Tagging] How to match multiple destinations and destination:ref?

[Jan Michel]

On 13.02.20 18:02, António Madeira via Tagging wrote:

Thank you, Jan!
This was exactly what I was searching for.
So, for destination:ref you propose using ";;" for empty values and for
destination:symbol you propose "none"?


There are different options:
destination:ref = ;123;;
destination:ref = none;123;none;none
destination:ref =  ;123; ;

I personally prefer the first one, but while interpreting tags I treat 
all of them the same. In any case I would decide for one style and use
this for all tags. Note that 'none' as a placeholder might be ambiguous 
in some cases, because some tags also have 'none' as a valid value (e.g. 
maxheight = none) and then there is the case of the Italian city 'None'.



How come this is not in the destination tag wiki?
This scheme was never officially proposed or discussed, it's just an 
extension of the (old but never voted on) proposal for extended 
destination:XYZ tags.


At least in Germany it's currently used to quite some extent to 
represent more complicated signs properly, e.g.

http://osm.mueschelsoft.de/destinationsign/example/index.htm#way=153364494_sgn=1_way=1=DE


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

Re: [Tagging] How to match multiple destinations and destination:ref?

[Jan Michel]

Hi,
You can just add empty entries to the destination:ref tag, like
destination:ref=;123;;
Some people prefer to use 'none' instead of empty entries, but I would
not recommend that.

I don't know if you have found it, but there is some documentation I
wrote in the Wiki:
https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging


Jan


On 13.02.20 16:07, António Madeira via Tagging wrote:

Hi there.

I've stumbled with a problem for which I couldn't find a satisfactory
answer.
Say I have a destination sign in a motorway junction exit with 4
destinations, but only the second one has a ref. How do we match the
right destination with its ref?

I've noticed that we can use "none" in the destination:symbol tag. Could
this be applied here too?

Regards.

___
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 - Small electric vehicles - keys updated

[Jan Michel]

Hi Joseph,

On 23.12.19 01:00, Joseph Eisenberg wrote:
small_electric_vehicle for segways and electric kick scooters seems 
confusing to me: I would imagine this including electric golf carts 
(already tagged golf_cart=yes/designated/no) and perhaps other things.

The term is borrowed from European law. If there are better alternatives
we haven't found them yet.

It’s also a bit odd that electric pedal-assist bicycles with limited top 
speed are to be tagged electric_bicycle= but faster e-bikes would be 
tagged “speed_pedelec=“ - shouldn’t it be “high_speed_electric_bicycle=“ 
or similar?
As Volker already said, both "electric bicycle" and "speed pedelec" are 
quite well-know terms in several languages in Europe.

I very much favor this over a newly made up key.




Joseph

On Sun, Dec 22, 2019 at 11:34 PM Jan Michel 
<mailto:j...@mueschelsoft.de>> wrote:


Taking the various comments and suggestions into account,
I revised some of the tags proposed and also included electric mopeds
in the proposal.


https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters



The current set of tags is:

* electric_bicycle - bicycles with motor assistance
* speed_pedelec - fast electric bicycles, similar to mopeds
* kick_scooter - the 'childrens style' scooter
* small_electric_vehicle - electric scooters (similar to kick
scooters),
Segway etc. These refer to a class of vehicles in European (French,
German) law
* moped:electric - slow electric motorcycles (EU: up to 25 km/h
typically)
* mofa:electric -medium fast electric motorcycles  (EU: up to 45 km/h
typically)

I hope that this set of tags is able to cope with most existing and
planned regulations and is free of ambiguities.
Please let me know your opinion and further suggestions!

Jan


On 10.11.19 18:05, Jan Michel wrote:
 > Hi,
 > up to now we don't have documented tags for small electric
vehicles like
 > bicycles and scooters. On the other hand, special access rules and
 > amenities become more and more common.
 >
 > These new keys are not only necessary for access tags, but also
intended
 > for use with any other kind of amenity like parking, shops, service,
 > charging...
 >
 > I wrote a proposal [1] to define common keywords for these vehicles.
 > Please let me know your opinion and further suggestions!
 >
 >
 > Jan
 >
 >
 > [1]
 >

https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters

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



___
Tagging mailing list
Tagging@openstreetmap.org
<mailto: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 - Small electric vehicles - keys updated

[Jan Michel]

Taking the various comments and suggestions into account,
I revised some of the tags proposed and also included electric mopeds
in the proposal.

https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters 



The current set of tags is:

* electric_bicycle - bicycles with motor assistance
* speed_pedelec - fast electric bicycles, similar to mopeds
* kick_scooter - the 'childrens style' scooter
* small_electric_vehicle - electric scooters (similar to kick scooters), 
Segway etc. These refer to a class of vehicles in European (French, 
German) law

* moped:electric - slow electric motorcycles (EU: up to 25 km/h typically)
* mofa:electric -medium fast electric motorcycles  (EU: up to 45 km/h 
typically)


I hope that this set of tags is able to cope with most existing and 
planned regulations and is free of ambiguities.

Please let me know your opinion and further suggestions!

Jan


On 10.11.19 18:05, Jan Michel wrote:

Hi,
up to now we don't have documented tags for small electric vehicles like 
bicycles and scooters. On the other hand, special access rules and 
amenities become more and more common.


These new keys are not only necessary for access tags, but also intended 
for use with any other kind of amenity like parking, shops, service, 
charging...


I wrote a proposal [1] to define common keywords for these vehicles.
Please let me know your opinion and further suggestions!


Jan


[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters 




___
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] What access key for cargo bike ?

[Jan Michel]

I agree that "cargo_bike" is a nice word for this kind of vehicle.
However, I would like to point out that the term 'bike' is not very
common in OSM, mostly due to the ambiguity between 'bicycle' and
'motorcycle'. To prevent this, we should think about building a tag
around the terms bicycle and cargo, e.g. cargo_bicycle, or
bicycle:cargo.

On 21.12.19 01:30, Joseph Eisenberg wrote:

+1 for "cargo_bike", including cargo tricycles and pedalled electric
bicycles and trikes.



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

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Jan Michel]

Hi,
I very much prefer the already accepted version. There is nothing wrong 
with semicolon separated values. Searching for one key and splitting its 
value is so much faster than searching with wildcards in a huge database 
like ours.
Also, introducing another set of 7 tags for such a minor piece of 
information is (at least to me) an absolute overkill.


Jan

On 05.12.19 14:39, Sören Reinecke via Tagging wrote:

Hey all,

A new but small proposal to change the specification for subkey 
`changing_table:location` because of a discussion yesterday about using 
seperators in values. I totally agree that we should avoid using 
seperators when possible.
Proposal: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Subkey:changing_table:location

Definition: Tagging of the location of the nappy changing facility in a POI



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

Re: [Tagging] Barrier=berm

[Jan Michel]

Hi Graeme,

On 26.11.19 03:50, Graeme Fitzpatrick wrote:
Following the recent discussions of protective walls, I've created a 
page for barrier=berm https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dberm


I think it's a good idea to have a dedicated tag for this type of walls. 
I don't want to comment on the name - this is something native speakers 
should decide. But I have some comments:


- We should have a defined way to tag the purpose of the berm - e.g. 
berm = noise_barrier


- How do we separate berms and dams along rivers? Their physical 
appearance and structure is identical, only the purpose is different.


- If mapped as a way, how is the width=* of the object defined? At the 
bottom? At half the height?



Jan


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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

Thanks for the details in the Belgian law!

On 22.11.19 19:17, s8evq wrote:

We currently have Class A (mofa, up to 25 km/h). Class B (moped up to 45 km/h) 
and now Class P (speed pedelec up to 45 km / h).

Some examples:
https://wiki.openstreetmap.org/wiki/File:C3_met_jaagpad_met_uitzondering_voor_speed_pedelecs.png
Class A (mofa) and P (speedpedelec) allowed, not B (moped)


https://wiki.openstreetmap.org/w/images/4/44/M11NL.png
This sign makes an exception for regular bicycle and speed pedelecs in for 
example one way streets, but not for mofa or mopeds.

Thanks for these links, let me add this to the list of examples.



So in Belgium, I think we do need a specific access tag for speed pedelecs. 
People have been using moped_p=* for a while now, but this never went through 
the proposal process.


To summarize, there is a special class for speed pedelecs, called 
moped_p at the moment. This term seems to be used only in Belgian law, 
but not in other countries. I would opt to change it for an equally 
unique, but globally usable tag like the proposed 'speed_pedelec'. This 
keeps the interpretation of data much simpler, even if there are some 
country-specific details in the definition of this class.





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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

On 11.11.19 09:41, Martin Koppenhoefer wrote:


if the vehicle class is treated exactly like another one (e.g. pedelec 
like a bicycle), I agree there is no need to add an extra key for it, on 
the contrary you should not do it (don't tag your local legislation). If 
there are differences, we should have a key for every class that makes a 
difference (this is how we usually do it with access-tags).


Hi,
I added a section "When NOT to use" - I hope this addresses your 
concerns about redundant tagging.


https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters#Where_to_use



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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

On 11.11.19 09:41, Martin Koppenhoefer wrote:
if the vehicle class is treated exactly like another one (e.g. pedelec 
like a bicycle), I agree there is no need to add an extra key for it, on 
the contrary you should not do it (don't tag your local legislation). If 
there are differences, we should have a key for every class that makes a 
difference (this is how we usually do it with access-tags).


I agree that we should not use this as an additional access tag, in 
cases where there is no difference to a regular bicycle.
But a tag like this is needed in combination with shops and amenities. 
The proposal aims not only at access tags, but also at all the other 
usages of "vehicle type" tags - and when it comes to shops and workshops 
there is a real difference. Not every place sells and services all kinds.



we do not need to add those "electric" to any of these classes as long 
as it doesn't matter for the access restriction whether the motor is 
combustion or electrical. 
Traffic laws do already distinguish between electrical and other 
vehicles. We have to be able to map this difference. But this is not 
part of my current proposal.



it doesn't help if a tag is in widespread use when the meaning is 
unclear. IMHO we should discourage the term even if it is widely used.
Agreed. But we can't discourage this tag if we don't have a better one 
to replace it.



Jan


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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

On 11.11.19 01:09, Martin Koppenhoefer wrote:
I generally agree with your remarks, just here I would like to point out 
that there aren’t any scooters in the “mofa”-class (AFAIK, not limited 
to Piaggio Vespas), (motorized) scooters begin in the moped class.


Many of them can be ordered with a reduced maximum speed to be driven 
with a 'mofa' license.



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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

Thanks for the comments, Volker!

On 10.11.19 22:09, Volker Schmidt wrote:

Looked at the proposal.

It's a spiny set of issues.

I would discourage electrical_bicycle as this is form the start 
ambiguous in many jurisdictions: both pedelecs and S-pedelecs are 
electric bicycles and in many jurisdictions these two are treated very 
differently.
I asked several international OSM contributors about the term 'pedelec' 
and it turned out this term isn't as widespread as it seemed to me. Most 
people were familiar with 'electric bicycle' but didn't hear the word 
'pedelec' before.
I don't really like the idea to introduce both 'electric_bicycle' as a 
generic term and 'pedelec', 'speed_pedelec' as more narrow tags in case 
we need to be specific.


In most EEU counties I believe pedelecs are treated like bicycles and 
S-pedelecs as mofas or light motorcycles. So for these two vehicles we 
do not need new access tags. They are covered by existing tags.
Correct. At this moment I didn't encounter any specific rules for these 
vehicles. Some legislature will for sure come up with them pretty soon...




"scooter" is problematic as it has many different types of uses.

  * The first vehicle type that comes in mind as "scooters" are Vespa
scooters that come with different motorizations and therefore can
fall in different categories  from mofa to motorcycle.
Exactly - that's why I kept them outside of this proposal. If we get to 
larger vehicles, tagging gets more and more complicated due to the vast 
amount of vehicle classes that exist. We need a more generic tagging 
scheme to add the feature 'electric' to any of these classes, but this 
will need a lot more discussion.



  * Then here motor-less "kick-scooters"
  * And then there are "electrical scooters", for which I believe many
countries have not yet developed rules.

Hence the keys "scooter" and "electric_scooter" are out for me.
I'm aware of this ambiguity. However, the term 'scooter' is already 
widespread as a tag. If you have a better name, I'm happy to change it.




The above argumentation is about the legal access use.



However it could be argued that for tag classifiers the story is different:
e.g. "service:electric_bicycle="seems to be a perfect description for 
places that service electrical-bicycle-like vehicles, i.e. pedelecs and 
S pedelecs and electricalscooters.

That's exactly where I currently see most use of these tags.

Jan


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

[Tagging] Feature Proposal - RFC - Small electric vehicles

[Jan Michel]

Hi,
up to now we don't have documented tags for small electric vehicles like 
bicycles and scooters. On the other hand, special access rules and 
amenities become more and more common.


These new keys are not only necessary for access tags, but also intended 
for use with any other kind of amenity like parking, shops, service, 
charging...


I wrote a proposal [1] to define common keywords for these vehicles.
Please let me know your opinion and further suggestions!


Jan


[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters



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

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

[Jan Michel]

On 10.11.19 13:51, Dave F via Tagging wrote:

Hi

Simple question (which I presume has been previously discussed) :

Why the different key tags to describe what are essentially synonymous 
entities?


One of them takes care to put out fires, the other transports you to 
hospital. There are regions where the two are mostly combined, but in 
other places these are completly separate organizations.


E.g. in Germany they are mostly combined in the larger cities, but 
usually separated in smaller towns. That's related to having 
professional fire fighters and stations that are always manned compared 
to volunteers who have to gather first.



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

Re: [Tagging] How to tag Seveso sites ?

[Jan Michel]

On 08.11.19 11:15, Lionel Giard wrote:
> Seveso sites are all sites identified as source for a "potential major
> industrial hazard"

On 08/11/2019 09:44, Shawn K. Quinn wrote:
> My first guess is it's at least roughly analogous to a Superfund site 
> in the US.


On 08.11.19 12:11, Andy Townsend wrote:

The local regulations in the UK for that are known as COMAH (see  > 
https://www.hse.gov.uk/comah/ ).


This seems like there are varying definitions in different countries, 
but all aim at basically the same thing - potential hazards to the 
environment. How about this scheme?


hazard_class = comah:XYZ
hazard_class = seveso:XYZ


It establishes a common top-level tag and country specific / system 
specific values. This is analogous to e.g. zone:traffic and 
zone:maxspeed used on roads. The 'XYZ' values depend on the 
classification given by the respective scheme.


We could think about adding the country code to the key (like 
hazard_class:US, hazard_class=UK) to separate countries from each other, 
but this doesn't seem necessary.


I wouldn't recommend to add the scheme to the key (as in 
hazard_class:soveso), because this tends to create quite messy tags that 
are difficult to use.



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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Jan Michel]

On 03.11.19 08:19, Martin Koppenhoefer wrote:

Il giorno 2 nov 2019, alle ore 20:37, Clifford Snow  
ha scritto:

I like your proposal but think it needs to clarify the difference between a 
pedestrian lane and a shoulder [1]. In the US, most (many?) states allow 
pedestrians to walk on shoulders if there is no sidewalk/footway, with the 
exception of motorways. How would a mapper know if this is a shoulder or a 
pedestrian lane?


you may not drive on the shoulder but you can drive on the pedestrian lane.


This depends on legislature. In Germany, on normal streets (not on 
motorways) the shoulder is not only for emergency use and pedestrians, 
but also for all slower vehicles. These should drive there to allow 
faster vehicles to overtake them.



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

Re: [Tagging] How to tag pedestrian lanes?

[Jan Michel]

On 21.10.19 13:02, John Willis via Tagging wrote:

We can all imagine a bus lane, a turn lane, a cycle lane, and whatever a "pedestrian 
lane" might be in the road. It's part of the road. It's marked with a (painted) line 
to separate one from the other. The lane feels like part of the road. The green lanes I 
deal with in Japan are clearly part of the road. I don't know how to map them as a lane, 
but it is clearly a lane, and not a sidewalk.


Representing the lane as a lane is quite simple using the established 
lane tagging scheme, e.g. on a oneway road with two vehicle lanes and a 
pedestrian lane to the right:


lanes = 2  (counts only wide lanes for motor_vehicles)
access:lanes = ||no  (prohibit access to the third lane)
foot:lanes = ||designated (allowing foot access to this lane)
width:lanes = 3|3|1.5
colour:lanes = gray|gray|green  (if you like colours...)

These tags can be used to reconstruct the lane structure of the road 
without doubt, but we still have to find a routing engine that is able 
to cope with that...


Jan


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

Re: [Tagging] How to tag pedestrian lanes?

[Jan Michel]

On 20.10.19 20:52, Markus wrote:

On Sun, 20 Oct 2019 at 19:52, Jan Michel  wrote:

I don't see how a 2-3 cm high kerb provides any kind of safety for a
pedestrian.


Not much, but luckily most kerbs (at least those i came across) are
much higher (usually 10 cm and more). They are only lowered at
pedestrian crossings or at driveways. Cars and buses sometimes
accidentally touch kerbs while driving (on narrow roads) and then get
thrown in the other direction. So i'd say that they definitely provide
some safety to pedestrians.


That might be the case for the place where you live. Here is a randomly 
picked street from Frankfurt with what I would call the typical German 
kerb in residential streets:

https://www.mapillary.com/map/im/MB7QKRH0wkXrCicGrK9HpA
(and no, parking on the kerb is not allowed here even though almost all 
cars do it in this street)


They might be a bit higher and more rectangular on major roads, but more 
than 10 cm height is really rare.
Also note that most of the height of the kerb is only because the water 
drain is lower than the road surface.



Jan


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

Re: [Tagging] How to tag pedestrian lanes?

[Jan Michel]

On 20.10.19 12:40, Tobias Zwick wrote:

I have seen this kind of sidewalk that is just a marked lane in Germany as 
well, usually as part of parking lots or larger company grounds.

How about:

sidewalk=right
sidewalk:right:kerb=no
sidewalk:right:surface=asphalt


I also prefer this kind of tagging. I don't see a reason to invent a 
fully new tag for this - it is an area meant just for pedestrians just 
like a sidewalk. In this way, it's fully backwards compatible, only 
additional information is added by the tag mentioning the kerb.


For me, a kerb is not a necessary feature of a sidewalk, e.g. here
https://www.mapillary.com/map/im/Hx17IpF-pZWl6AakpYUc2g
There is no kerb or other barrier at all, but still it's obviously a 
sidewalk.


On 19.10.19 21:44, Markus wrote:
> While a sidewalk provides some safety for
> pedestrians, a pedestrian lanes does not.

I don't see how a 2-3 cm high kerb provides any kind of safety for a 
pedestrian.



On 19.10.19 23:01, Martin Koppenhoefer wrote:

or e.g.sidewalk:right=lane


That would be an option, very much alike the tagging for cycleways - but 
this is a tag that needs to be clearly defined and worked into all the 
existing tools that make use of sidewalks in one way or the other.




Jan


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

Re: [Tagging] Strange tags

[Jan Michel]

On 29.09.19 17:07, Paul Allen wrote:
On Sun, 29 Sep 2019 at 15:52, Valor Naram via Tagging 
> wrote:


Be sure that almost no data user will evaluate these tags


Really?

There are people who are VERY interested in these things.  People who 
want to know where

Munros, Donalds, Grahams, Marilyns, TuMPs, etc. are.


Well... There is no documentation of these tags in the OSM wiki.

ael mentioned that these are well-known terms. I tried several 
translators and dictionaries but didn't find anything.

A Google search only finds the wiki "List of mountains and hills
on the British islands", but not much more related information.

These seem to be very local terms that are not used outside of Scotland 
(British Isles?). In general we oppose such local terms as keys because 
they won't be of any use outside a small area.


Looking at the tag history, most of these were added in a few larger 
edits in 2014 and 2015.


What information do these terms contain exactly? What I understand from 
the Wiki page, the names are determined by three properties: The 
location (to be found from boundary relations), the height (tagged as 
'ele') and the prominence (tagged as 'prominence').


My very personal conclusion / opinion: These tags are undiscussed, 
undocumented, not well-understood outside a small area and useless 
because they can be derived from a few documented, verifiable tags.





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

Re: [Tagging] Tagging meadow orchards

[Jan Michel]

Hi Tobias,

All the options are listed here:
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmeadow_orchard

Current usage stats:

landuse=meadow_orchard  47
landuse=meadow + meadow=meadow_orchard  650
landuse=orchard + orchard=meadow_orchard 2700


Jan


On 18.09.19 16:46, Tobias Zwick wrote:

Hey there

What is the best way to tag meadow orchards?



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

Re: [Tagging] Turn lanes separated by road markings

[Jan Michel]

Hi Markus,

On 06.09.19 21:07, Markus wrote:

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

Do we have a relation for storing the information that the left lane 
continues on [way 
394112487](https://www.openstreetmap.org/way/394112487) and the right 
lane on [way 290130794](https://www.openstreetmap.org/way/290130794)? 
This information is important in order that routers don't announce too 
late (i.e. when the lanes can't be changed anymore) which lane one has 
to take.

We do have a (recently approved) relation type for this: 'connectivity':
https://wiki.openstreetmap.org/wiki/Relation:connectivity

Or is turn:lanes + change:lanes enough? (And what if there were no turn 
lane markings?)
In this case with a simple 2-lane way splitting into 2 1-lane ways I 
would not use this relation - it should be obvious to all routing tools 
how these ways relate to each other. The example looks more complicated 
than it actually is, because some ways are oneways and some are not. For 
routing purposes, the lanes in each direction can be treated separately 
from each other.



Jan


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

Re: [Tagging] Using destination_sign relations for pedestrian navigation

[Jan Michel]

Hi Antoine,

I think your suggestions are all valid, but it seems some make tagging 
and using data more complicated than necessary.



On 05.09.19 09:29, Antoine Riche via Tagging wrote:
In order to improve the user experience, we want to provide walking 
instructions such as "take the exit 'Rue de Londres'" or "Walk through 
the gate labelled 'Northern lines'" rather than "Walk 75 metres then 
turn left". Our problem is that such waypoints may have a different name 
depending on the direction you cross them. The solution we used is to 
create, when there is such an ambiguity, two destination_sign relations 
pointing to the same 'intersection' member, one for each direction with 
the 'from' and 'to' members swapped. Here is an example at Juvisy 
station : the entrance named 'Accès Danton' when walking in 
(https://www.osm.org/relation/9471596) is named 'Quartier Seine' when 
walking out (https://www.osm.org/relation/9471597).
That's correct and how it's done usually. In such a simple case, the 
same information can also be added to the way passing through the 
entrance using the tags 'destination:forward' and 
'destination:backward'. I think this carries all the information you 
need for the routing. The additional information the relation is able to 
handle (location of the sign, colours etc.) are not needed here. Adding 
tags to a (short) way is much less effort and serves the purpose very 
well here. In addition, the 'destination' tag is already used by some 
routing tools.



I wish to amend the Wiki to explain that destination_sign relations can 
also be used for pedestrian and indoor routing, not just at 
"crossroads". Does that require opening a discussion in the discussion 
page, or may I just go ahead ?


A huge amount of these relations are already used on paths like hiking 
trails, so this tagging scheme is definitely not limited to road signs. 
So there is no redefinition needed, maybe the description needs to be 
refined a bit.



Now since the routing engine supports area routing, we need to loosen 
some constraints on the members, that are documented on the wiki and 
enforced by the JOSM validator :
1/ allow areas for the 'from' and 'to' members, as in this example : 
https://www.osm.org/relation/9722912
This seems to be fine - you have to note that many data users (me 
included) are not actually able to handle areas well with respect to 
routing.


2/ allow multiple 'intersection' members, so that multiple doors can be 
referenced by a single relation – example in Gare Montparnasse : 
https://www.osm.org/relation/9823029
This looks fine to me - but the destinations should be tagged using 
'destination' and not using 'name' - that would be the name of the sign 
(which is unlikely to exist).


3/ allow multiple 'to' members, so that the same relation can point to 
both a line and an area, and cover linear and area routing (no example 
but I could create one).
In my opinion, the area should not be included here. The 'to' member of 
the relation is not meant to be the final destination, but just a way or 
node you need to pass through to get to your destination. That would be 
a node directly after the 'intersection'. Having both makes it difficult 
for the data user to find which one is the correct one in the current 
context. The decision might not always be as simple as 'area' vs. 'way'.



FYI, I'm working a bit on displaying destination signs, mostly in the 
context of hiking guideposts, but yours can be displayed as well, e.g.

http://osm.janmichel.eu/destinationsign/example/index.htm#zoom=18=48.993567=2.2349=6079938675
This is currently very much "work in progress" and far from being 
finalized, but you might find it helpful.




Are there objections to this proposal ? Do you recommend to open this 
subject on the Discussion page or is it best discussing it on this list ?


Regards,
Antoine.



Jan


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