Re: [Tagging] Using destination_sign relations for pedestrian navigation

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

Re: [Tagging] Turn lanes separated by road markings

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 

Re: [Tagging] Tagging meadow orchards

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:

Re: [Tagging] Strange tags

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] How to tag Seveso sites ?

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

[Tagging] Feature Proposal - RFC - Small electric vehicles

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

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

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:

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

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

Re: [Tagging] How to tag pedestrian lanes?

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

Re: [Tagging] How to tag pedestrian lanes?

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

Re: [Tagging] How to tag pedestrian lanes?

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

Re: [Tagging] Barrier=berm

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

Re: [Tagging] What access key for cargo bike ?

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

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

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

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

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

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

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:

Re: [Tagging] Public refrigerators

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

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

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

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

? 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>> wr

Re: [Tagging] Doorzone bicycle lanes

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

[Tagging] Feature Proposal - RFC - electric_bicycle and speed_pedelec

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

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

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

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

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

[Tagging] Feature Proposal - Voting - electric_bicycle and speed_pedelec

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

Re: [Tagging] Doorzone bicycle lanes

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

Re: [Tagging] Doorzone bicycle lanes

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.

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

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

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

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

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

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

Re: [Tagging] Network-tag needs extension

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] Electric scooter parking

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

Re: [Tagging] Electric scooter parking

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

Re: [Tagging] Electric scooter parking

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

Re: [Tagging] Electric scooter parking

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

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

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,

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

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

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

". 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:

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

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

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

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,

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

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

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

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

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

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

Re: [Tagging] Mapping bicycle-only turn lanes

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

Re: [Tagging] Mapping bicycle-only turn lanes

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

Re: [Tagging] Mapping bicycle-only turn lanes

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 t

Re: [Tagging] Mapping bicycle-only turn lanes

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

Re: [Tagging] Feature Proposal - Voting - electrcity=*

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,

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

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

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

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

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

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.

Re: [Tagging] Parking fee only after some time period

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.

Re: [Tagging] Mapping bicycle-only turn lanes

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