Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg  > wrote:
> 
> If you are mapping an area, as in this case, just use a closed way or 
> multipolygon.

How would a closed way (area polygon) denote “top” and “Bottom”? 

if embankments can be easily expressed as a single simple polygon, how data 
users infer “top” and "bottom” from that is beyond me. 

That is the issue: I don’t understand how a polygon would represent that, and I 
think those two different pieces of mapping need to be explicitly tagged. 

Perhaps it is because while I have 3000+ edits, I rarely use relations or other 
complex mapping data structures, nor understand exactly what data consumers can 
infer from data vs what they need explicitly tagged to be useful (as I am not a 
data user) - but I assume that “top” and "Bottom” are difficult to infer, as 
slope data needs to be explicitly tagged to ways. 

I thought that the way (man_made=embankment [top]) + a polygon to represent the 
bank (area:man_made=embankment) would, together, represent the top and the area 
of the embankment, allowing inference of the direction of the slope. Perhaps an 
additional line for “bottom” would be necessary too. 

Two embankments would represent the slopes of the levee, while the 
man_made=dyke way would represent the path of the protection structure as a 
whole, as the embankments (particularly the outer one) are not continuous - but 
the levee (as a complete structure) is continuous. 


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer  
> wrote:
> 
> I agree we should have a way to map both limits, upper and lower, for all 
> kind of similar features, e.g. embankments, slopes, and similar.


> On Nov 11, 2019, at 7:40 PM, Volker Schmidt  wrote:
> 
> I have stood in front of these large levees that prevent big rivers from 
> flooding the surrounding country side many times her in Italy and did not 
> find a suitable tagging for both the top and the bottom border lines of the 
> object.



I think it is pretty easy to make a  “lower bounds” way or area (or both) that 
compliments the existing man_made=embankment way.  

To me, the problem is levees. After having mapped many KM of levees 
(incorrectly), it is really really nice having the two pairs of embankments 
make up the two halves of the levee, because it is easier and more flexible to 
map the two slopes (which widen and narrow, split & merge, and disappear for 
short sections), rather than trying to assume that the man_made=dyke centerline 
way accurately shows the the “top” of the levee. the top varies by width from 
something easily represented by way to something 50m wide in some places (as 
linked to earlier). The =dyke way should represent the inner-most extent of the 
high point of the levee (if it has a weird bulge in the top). 

I made 2 sections of mapping examples on a simple section of levee along the 
Tone River that has a levee breach repair station on top, so the levee is wider 
here than normal. (for a short time).  


a man_made=dyke (on the cycle path) with:


- two pairs of embankment lines   ( man_made=embankment + 
man_made=embankment_lower ) with a regular grass polygon sandwiched between it.


- Two regular embankment lines along the top with an area:man_made=embankment 
polygon representing the slope (also tagged with grass). 

https://www.openstreetmap.org/edit#map=17/35.9/139.89482 
 


Do you need a relation on them? 

Any suggestions on improvements? 

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

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

[Martin Koppenhoefer]

sent from a phone

> On 11. Nov 2019, at 23:02, Markus  wrote:
> 
> Another difference is the width: in Switzerland, pedestrian lanes are
> about 1.5 m wide and shoulders about 4.5 m. But in my opinion their
> different purpose is reason enough to use different tags.


+1, these are lanes, they are part of the carriageway, the shoulder is not.

Cheers Martin 

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

sent from a phone

> On 11. Nov 2019, at 14:38, Paul Allen  wrote:
> 
> For better or worse, shop=cafe is documented as selling beverages AND light 
> meals, and this
> is how it is understood in British English.


from the description, light meals aren’t a hard requirement, or it could be 
seen as satisfied by selling cakes (or ice cream cups in the case of cuisine 
=ice_cream):
„ This includes coffee-shops and tea shops selling perhaps tea, coffee and 
cakes through to bistros selling meals with alcoholic drinks.“

IMHO bistros should get their own tag, or at least specific subtag, but that’s 
a different story.

Cheers Martin 

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

sent from a phone

> On 11. Nov 2019, at 14:38, Paul Allen  wrote:
> 
> I think these are important distinctions: consume on the premises or off
> the premises.  They are different operating models and customers have 
> different
> expectations.


indeed, and you can buy alcohol in a lot of different places, like ice cream. I 
agree despite all the differences, one could also find a lot of similarities. 
E.g.  there is quality alcohol like good wine, or microbreweries, and there is 
industrial mass production. And nobody questions we have a lot of different 
tags for places where you can buy alcohol, because apart from the kind of 
alcohol people are aware that different settings merit different tags. A pub is 
different to a bar, although they might seem the same to an alien: a place 
where you stay to drink alcohol with your friends and strangers.

Cheers Martin 





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

Re: [Tagging] Proposed features, toll (3/5)

[marc marc]

Le 11.11.19 à 23:13, Herbert Allmeier a écrit :
> Country tags: There is no worldwide toll system.

the same apply for parking : no the same-for-all-parking exist
but we still avoid using a country code to said that all parking in this 
country use somethink specific to this country.
the same apply with opening hours : we don't add country code to spécify 
that's it's this country timecode

>   NOTE: All comments attached to this mail WILL NOT BE PROCESSED!
> 
> so nice ! all not-processed comments may result in a vote=no or worse in 
> difficulties of use in the future because a detected problem has not 
> been solved
> 
> If a person  
> does not want to be involved in the discussion there is nothing I can do

if somebody reply, you can read the reply :)

> what would be a better place if not the talk page
> that is directly linked from the voting page?

you may link tagging archive if you want.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposed features, toll (1/5)

[Warin]

On 12/11/19 09:06, Herbert Allmeier wrote:

Hello tagging list!
I agreed to move conversations from this list to the wiki and back so 
that the discussion can keep going here.

I hope that it works that I stack all replys behind each other.
If it does not work, don't hesitate to help me out by telling me what 
I am doing wrong ;-)

I am quite new to the system and do not know a whole lot




1) The 'proposal' page should be the proposal .. not a string of 
'discussions'. Any discussions there should really be on the discussion 
page behind the proposal or on the tagging list. There is no requirement 
to copy then back and forth between the two.


2) the messages on the tagging list should be 'threaded' .. do not 
create a new thread (usually by 'writing' a new email) but 'threaded' 
(use the 'reply' on your email thing).



What is your proposal??? There is nothing to say what it is.

Read
https://wiki.openstreetmap.org/wiki/Proposal_process
Examine a past proposal to see how it goes ..
e.g. 
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic


-
toll already exists. I assume your thinking of the method of payment?
Consider https://wiki.openstreetmap.org/wiki/Key:payment#Road_toll




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

[Tagging] Proposed features, toll (5/5)

[Herbert Allmeier]

Copied from https://wiki.openstreetmap.org/wiki/Proposed_features/toll/mailing_list#4

 



	May 8 18:43:00 UTC 2019, Paul Allen:


Only one person (that we know of) wants the new scheme. Others, like myself, haven't mapped a toll, may never map a toll, and comment on the proposal in order to try to improve it even though they may never use it. Because we all benefit from a rational mapping scheme and all suffer from a badly-conceived one.

Question: which of those people should be prepared to do the most work by dealing with a method of communication they do not prefer? Those who didn't see a need for the change in the first place or the person wanting the change?


	I don't know anybody who is specialised in mapping toll. If there is, the person is very much invited to join the conversation. I think the mailing list only knows of one person because that one is actually that one who bothered to share the discussion on the mailing list. All ideas are welcome and should be shared.
	However, if OSM suffers map detail that other routing tools already provide, OSM will fall behind in map quality. The place of discussion should not effect the map's quality.
	--TBKMrt (talk) 13:18, 11 August 2019 (UTC)



If you want you can reply here or on the talk page directly. If you decide to reply here bare with me, I will move it as soon as possible.

 

Just a small note at the end: Personally I am only interested in on topic discussion if you want to discuss anything off topic please use the mail or usertalk page of that user. Thank you for your understanding and your contributions!



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

[Tagging] Proposed features, toll (4/5)

[Herbert Allmeier via Tagging]

Copied from https://wiki.openstreetmap.org/wiki/Proposed_features/toll/mailing_list#3

 



	May 10 22:23:13 UTC 2019, Warin:


No need to separate countries.

toll:type... NO. the values of time and distance indicate the fee paid will be related to those quantities ... the time one? The slower you go do you pay more or less compared to the faster vehicle???

toll:assessment=time/distance  but not toll:type!

And of course if these comment are ignore I will vote against... Bye.


	Different countries have different toll systems. Right now you can only say if you do or do not want to use any toll raods at all. If you have paied the toll for all motorways for the whole year in your home country, you may want to use the motorway when you go on vaccation. And if you don't want pay the toll in the country you go on vacation you have to seperate them in a way that is reliable. So it would make sence even for the boolean we have right now.
	time and distance are variable placeholders. I'm fine with them. If someone thinks that there is a better word for said toll systems they are welcome to share them. Unfortunately, noone did so far. toll:type was already renamed to toll:measure (other suggestions are also welcome)
	Everybody is free to vote for whatever they feel is the best and for whatever reason they think is the most important. If people don't want to discuss a topic on a page that is meant to host discussions that is fine to me.
	--TBKMrt (talk) 13:01, 11 August 2019 (UTC)


 


 
If you want you can reply here or on the talk page directly. If you decide to reply here bare with me, I will move it as soon as possible.


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

[Tagging] Proposed features, toll (3/5)

[Herbert Allmeier]

Copied from https://wiki.openstreetmap.org/wiki/Proposed_features/toll/mailing_list#2

 



	May 8 15:45:29 UTC 2019, marc marc:


- I see no need to specify that a country's roads are in that country.
- I have always considered strange a vignette is considered as a toll. - the toll detail would better be added on the highest entity containing the type of toll concerned (e.g. on the Swiss relationship for the Swiss vignette or on a Brittany relationship to say that there is no payment in Brittany) rather than duplicate the same information many times. - if you want to add details of the fee, use the fee key - to inform if it is with a ticket or rfid, used a dedicated key, especially since in France, both are possible on the same routes. it also allow to use this key for other feature (like paking fee) - type in toll:type is a no meaning key. it's better to use a key with a "self-meaning" (like calculation_basis) but from your examples, it seems that all vignettes are based on a duration, so what's the added value to duplicate vignette with time ? and to say that the payment of a tunnel is based on distance seems wrong (it's a fixed price for the tunnel, you can't paid less or more than the fixed price for a kind of vehicule) - toll:type=time gives me the impression that the payment is made according to the time you use the road (if you drive fast, you pay less than the one who drives slowly). out of the description speaks of a subscription for a certain duration. it is not intuitive. again a lot of roads have one-shoot and subscription payement.


	Country tags: There is no worldwide toll system. There is not even an EU-wide system. So if you want to use toll roads in Germany, but not in Poland you need a way to tag the roads or you can not select them with a routing tool.
	If you have to pay to use a road it is a toll. That it's a different type of toll is collected in toll:measure where you can use time (pay once for set ammount of days/weeks/years) or distance (pay per use). The system used differs not only from country to country, but also for different for types of vehicles in the same country (eg. regular cars and hgv)
	We can also use different keys with different tags for them. I want to avoid using 5 different keys for an information where two keys are enough. I was waiting for suggestions or discussion input, but I didn't really get any.
	toll:type is already renamed to toll:measure
	there are more options for time other than the vingnette so different combinations are possible. distance is just something that came up in previous discussions. if the majority wants something like per-use I would be fine with that. It's again that I'm missing constructive input. both are just to seperate roads that you pay once and can use as much as you like or you have to pay everytime you drive on them.
	--TBKMrt (talk) 12:50, 11 August 2019 (UTC)


 NOTE: All comments attached to this mail WILL NOT BE PROCESSED!


so nice ! all not-processed comments may result in a vote=no or worse in difficulties of use in the future because a detected problem has not been solved


	TThis is an open and unhidden discussion in a section of the wiki where discussion is meant to happen. Everybody is free to join and contribute to the discussion as much as they like. If a person who is going to vote (on a sidepage of the discussion page) does not want to be involved in the discussion there is nothing I can do about that. If a person wants to vote no (or yes) for whatever reason it is the person's decision alone. Everybody is free and welcome to join this discussion and raise their concerns and share ideas and thoughts. However, a serious discussion that is meant to have an effective output, needs a point where all comments are collected - and what would be a better place if not the talk page that is directly linked from the voting page?
	--TBKMrt (talk) 12:50, 11 August 2019 (UTC)



 
If you want you can reply here or on the talk page directly. If you decide to reply here bare with me, I will move it as soon as possible.


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

[Tagging] Proposed features, toll (2/5)

[Herbert Allmeier]

Copied from https://wiki.openstreetmap.org/wiki/Proposed_features/toll/mailing_list#1

 



	May 8 14:50:34 UTC 2019, Mateusz Konieczny:


> I would like to hear your thoughts and comments here: > https://wiki.openstreetmap.org/wiki/Proposed_features/toll >


I see no good reason to turn simple boolean tag (toll=yes/ toll=no are 98,98% of all values[1]) into something highly complicated. It would work better as a new tag

Also, what is the point of tagging that road located in Italy is an Italian toll road?

[1] https://taginfo.openstreetmap.org/keys/toll#values 


	I don't see it as complicated. It's not like maxspeed where you enter a number, but it's not nearly as complicated as other already accepted forms of tagging. Moreover the documentation is already very detailed, provides a lot of examples and guides you through step by step. So if you have a hard time using the tag, you can use copy & paste.
	Why we need something more detailed than yes/no is also very easy to explain. Just imagine maxspeed as boolean. You can say if there is a maximum speed on that road or not, but how fast are you allowed to drive? Same here. There are so many different types of toll systems that a boolean just doesn't cut it here. The greater idea behind this to provide more detailed data for better routing options (eg. you want to use the motorway which you already paied for, but don't want to use roads with extra toll)
	On new tags. If you use toll=yes and toll:SUBKEY=TAG to describe the road you can go with toll=TAG as well. But if you have an idea that you think is better than this example, don't hesitate to hare it.
	Italian roads: Simply because there is no worldwide toll system. There is not even an EU-wide system. So if you want to use toll roads in Ggermany, but not in Poland you need a way to tag the roads or you can not select them.
	--TBKMrt (talk) 12:19, 11 August 2019 (UTC)


>  NOTE: All comments attached to this mail WILL NOT BE PROCESSED! Only comments on the wiki page will be answered and worked on!


It is your choice but it means that you are likely to miss some comments, and encounter them as explanation of "no" votes.


	Productive comments should be pulled into consideration now.
	--TBKMrt (talk) 12:19, 11 August 2019 (UTC)


 

If you want you can reply here or on the talk page directly. If you decide to reply here bare with me, I will move it as soon as possible.


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

[Tagging] Proposed features, toll (1/5)

[Herbert Allmeier]

Hello tagging list!

I agreed to move conversations from this list to the wiki and back so that the discussion can keep going here.

 

I hope that it works that I stack all replys behind each other.

If it does not work, don't hesitate to help me out by telling me what I am doing wrong ;-)

I am quite new to the system and do not know a whole lot

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

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

[Markus]

Hi Nick,

Please excuse my late reply. :(

On Wed, 6 Nov 2019 at 00:53, Nick Bolten  wrote:
>
> ## Similarities to shoulders and an opportunity to figure out how to tag them.
>
> Would it be fair to say that the only differences between this feature and a 
> shoulder are (A) it has paint designating where pedestrians should go and (B) 
> it has some right-of-way implications? Because it's often the only pedestrian 
> option in rural areas near me, I'd appreciate having a way to tag shoulders 
> and then enhancing them with a subtag. e.g., something like 
> shoulder=left/right/both + shoulder:right=pedestrian_lane.

Another difference is the width: in Switzerland, pedestrian lanes are
about 1.5 m wide and shoulders about 4.5 m. But in my opinion their
different purpose is reason enough to use different tags. Besides,
cycle lanes already have a separate tag. (Even though cyclists are
also allowed to use shoulders in the USA afaik.) And finally,
shoulder:right=pedestrian_lane doesn't make much sense semantically.

> ## Challenges of mapping pedestrian paths as street attributes
>
> As proposed, this tag would apply to streets. I understand the appeal - it's 
> a minimal change from current maps and the feature is basically just paint on 
> a street - but I think there are also some potential risks to describing the 
> pedestrian path this way that would be valuable to discuss. Examples:
>
> (1) Intersections, particularly ones with marked crossings. 
> sidewalk=left/right/no/both has difficulties with this as well. Put yourself 
> in the shoes of someone trying to analyze the paths a pedestrian could take 
> using this tag to determine that there is a path using pedestrian lanes and a 
> crosswalk. There is a street way (way 1) with pedestrian_lane=right that 
> continues through an intersection. There is a crosswalk tagged as 
> highway=crossing, crossing=uncontrolled on another way that shares a node 
> with another street way (way 2). How do you proceed and associate these path 
> data so that you can reliably say that a pedestrian path exists that uses 
> that crosswalk? I believe it will require some fairly nerdy graph analysis I 
> think it could be a significant hurdle for using this data.

You mean a situation like this?:

https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg

I add a sidewalk=both tag to the road section up to the crosswalk,
then sidewalk=no to the rest of the road that doesn't have a sidewalk.
This may look a bit strange in this example, but usually the sidewalks
are more curved at crossroads, like for example here:

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

(The "Stadt Bern 10cm/25cm (2012)" imagery has the highest resolution
at this place.)

I suggest the same mapping for pedestrian lanes.

> (2) Transitions to other pedestrian paths, such as sidewalks. Pedestrian 
> lanes are sometimes used as a means to have a "temporary" sidewalk-like 
> feature, pending some future construction of actual sidewalks. There will be 
> sidewalks that are half-built, then transition into a pedestrian lane. How do 
> we tag that situation, given a separately-mapped sidewalk?

I would simply connect the sidewalk way with the road where the
sidewalk ends (and map a barrier=kerb + kerb=* node) and add
pedestrian_lane=* to the road starting from where the pedestrian lane
begins.

> With the above issues in mind, what would you think about allowing 
> highway=footway, footway=pedestrian_lane as a possibly redundant tagging 
> option?

Consider this example:

https://www.openstreetmap.org/#map=19/46.99149/7.45448

There is a pedestrian lane along the the south-eastern part of the
road Reichenbachstrasse. On the opposite side there are public steps
as well as many (currently unmapped) driveways and private footpaths.
Mapping the pedestrian lane as a separate way would either make it
disconnected from the steps, driveways and footpaths on the opposite
side of the road or you would need to add many highway=footway
connections from the pedestrian lane to the steps, driveways and
footpaths, which would make the map very confusing.

Therefore i strongly advise against mapping pedestrian lanes as separate ways.

By the way, the same problem occurs with sidewalks mapped as separate ways.

> ## Usefulness / data consumption
>
> Knowing where pedestrian lanes are would be very useful, in my opinion, but 
> the devil is always in the details. Do you have any examples of how this data 
> could be consumed downstream? Not saying there always has to be a data 
> consumer, but the exercise could reveal advantages between different 
> approaches.

I'm not a programmer and therefore don't have concrete plans to use
this data, but i imagine (and hope) that pedestrian routers could use
this data to prioritise roads with pedestrian lanes and to tell blind
people on which side of the road they should walk.

> ## Other sources
>
> A potentially helpful resource during these international comparisons: 
> https:/

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Mon, 11 Nov 2019 at 11:55, Mateusz Konieczny  wrote:
>
> Is there some consistent difference how
> this two tags are actually used?

Unfortunately i can't answer your question (too little
amenity=ice_cream and no shop=ice_cream around where i live), but i
just discovered that 349, that's 15.2%, of all 2,293 shop=ice_cream
also have an amenity=ice_cream tag.

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

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

[Colin Smale]

On 2019-11-11 09:47, Martin Koppenhoefer wrote:

> Am Mo., 11. Nov. 2019 um 09:37 Uhr schrieb 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.
> 
> you're right, sorry, seems I'm living for too long time away from Germany now 
> to have a good idea about the current situation. In many (most?) countries, 
> there isn't a mofa class at all, and you may not even need a driving license 
> for the bigger 50ccm class. For example there is no EU-vehicle class for 
> Mofas, it's a German specialty: 
> https://de.wikipedia.org/wiki/EG-Fahrzeugklasse#Klasse_L

And Dutch (snorfiets/bromfiets), and Belgian (klasse A/klasse B)... More
widespread than you think...___
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

[Paul Johnson]

On Mon, Nov 11, 2019 at 2:41 AM Martin Koppenhoefer 
wrote:

> Am Mo., 11. Nov. 2019 um 09:28 Uhr schrieb Jan Michel  >:
>
>> 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.
>>
>
>
> 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).
>

Be aware that it's pretty typical in North America for pedelecs to be
considered as motor vehicles and excluded from bicycle facilities as such
when using their motor.  We have the Chinese pump-and-dump rental trash
scooter model to thank for this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 15:22 Uhr schrieb Dave F via Tagging <
tagging@openstreetmap.org>:

> On 10/11/2019 16:53, Greg Troxel wrote:
> >
> > So I agree these tags should be kept separate.
>
> I'm struggling to comprehend how a question I deliberately kept simple
> at just one sentence long can cause so much misinterpretation.
>
>

maybe your question was too simple / brief and led to people
misinterpreting what you actually asked. It seemed you were questioning
that fire stations and ambulance stations should get different tags, and
this may not have seemed completely off, as fire stations indeed often
provide ambulance emergency services as well.

If your question was intended like "why are fire station under the amenity
key and ambulance stations under the emergency key?", the answer would have
probably been that for many years, some people have been running around
telling the others "amenity" was (almost) full and we should spread the
tags under different keys (it was a not so rare notion for years, although
it is now some time that somebody has written amenity was "overcrowded", so
there is hope this fud is overcome).



> >   As for emergency= and
> > amenity=, that's a historical artifact and doesn't matter.
>
> That just makes it historically wrong. Being incorrect for a long time
> isn't a reason not to fix it. Having two different keys to describe
> entities which come under the heading 'emergency services' is confusing
> to experienced OSMers let alone newbies.
>


actually, both do not come only under "emergency services", for examples
most ambulances are not operated in emergency mode (but to transport ill
people from one hospital to another, or similar), and fire brigades also
have a significant amount of other work, at least in some places, e.g.
evaluating building applications (e.g. in Germany public buildings and
those accessible to the public and generally buildings with many people in
them, like high rise buildings).
Also, if "emergency" features should be those that are relevant in an
emergency, while ambulance stations and fire stations are relevant for
organizing emergency response, they are typically not important for people
that are hit by an emergency: neither would you have to go to a fire
station if your house is on fire, nor would you go to an ambulance station
if you need emergency treatment. They are not comparable to emergency
departments or similar.

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

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

[Mateusz Konieczny]

11 Nov 2019, 16:05 by marc_marc_...@hotmail.com:

> Le 11.11.19 à 15:44, Joseph Eisenberg a écrit :
>
>> decide which tags under `emergency=` should be treated as polygons
>> when mapped as closed ways
>>
>
> is this information not already present on the wiki pages? for example
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dambulance_station
> onArea=yes
>
It is, but code of OSM Carto is at 
https://github.com/gravitystorm/openstreetmap-carto/
and AFAIK relevant polygon code is mostly in
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
file with some prepared not deployed code at
https://github.com/gravitystorm/openstreetmap-carto/blob/schema_changes/openstreetmap-carto.lua
(schema changed branch).

OSM Carto developers are using OSM Wiki and other documentation but
OSM Wiki is not a runnable code that can be directly used to make map.
Or even something that can be used without verification.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[marc marc]

Le 11.11.19 à 15:44, Joseph Eisenberg a écrit :
> decide which tags under `emergency=` should be treated as polygons
> when mapped as closed ways

is this information not already present on the wiki pages? for example
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dambulance_station
onArea=yes

Of course, osm-carto need to convert/parse those infos
and maybe some values doesn't have it yet.

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

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

[Joseph Eisenberg]

DaveF, reloading the database could be done more often, but it does
take time and server resources, and everyone is a volunteer. People
can help by donating money to the OSMF to help run the servers, or
donating time to help improve the openstreetmap.org website
infrastructure.

At Openstreetmap-carto there are over 400 open issues
(https://github.com/gravitystorm/openstreetmap-carto/issues), and a
particular request is more likely to happen if a contributor
volunteers to do the work. In this case the first step would be to
decide which tags under `emergency=` should be treated as polygons
when mapped as closed ways, and then submitting a PR (pull request) to
add these for the next database reload, which might happen soon, if
enough people are interested in making it happen.

- Joseph Eisenberg

On 11/11/19, Dave F via Tagging  wrote:
> On 11/11/2019 02:20, Joseph Eisenberg wrote:
>> If this is about Openstreetmap-carto, there is now an open issue:
>> https://github.com/gravitystorm/openstreetmap-carto/issues/3968 - note
>> that rendering area features in the "emergency=" key, like this, would
>> require reloading the database on the openstreetmap.org servers.
>
>
> it wasn't about rendering really, it was just the illogical use of keys
> making it more awkward for all database users.
>
> I gave up on referring to anything relating to OSM-carto issues for
> precisely the reason you highlight - to render
> emergency=ambulance_station It requires a database reload which is only
> performed "*every few years*". #Ridiculous
>
>
> DaveF
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

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

[Paul Allen]

On Mon, 11 Nov 2019 at 14:22, Dave F via Tagging 
wrote:

>
> As emergency=ambulance_station appears to be a later invention, was
> there a valid reason fire_station did follow suit?
>

Presumably because the icon looks like a firepit.  Or maybe an eternal
flame.  Or maybe
a flammable chemical site.  So everyone goes there to sit around the
firepit.  Or admire
the eternal flame.  Or wait to see the chemical site explode.  So it's an
amenity.

Joking aside, the carto people appear to have a fixed rule of "no
synonyms."  A very good rule
in many situations as we don't want more than one way of mapping the exact
same thing.
However, it seems problematic in cases like this where there is broad
agreement that we
should replace amenity=fire_station with emergency=fire_station and that
the 1:1
correspondence means it could even be considered for an automated edit.  It
would
seem that TEMPORARILY allowing a synonym in this case would be a sensible
thing
to do.  Render both until editors have made the change and most occurrences
in the
db have been updated, then only render emergency=fire_station.

There are other cases where a policy of temporarily allowing synonyms in
order to
rationalizing tagging would be useful: landuse=grass vs landcover=grass
comes to mind.

As things stand, though, emergency=fire_station doesn't render and (without
a change in
policy by carto) will never render, so mappers won't use it, so you'll just
have to live with
the confusion.  And the further confusion from the icon being completely
misleading.

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

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

[Dave F via Tagging]

On 11/11/2019 02:20, Joseph Eisenberg wrote:

If this is about Openstreetmap-carto, there is now an open issue:
https://github.com/gravitystorm/openstreetmap-carto/issues/3968 - note
that rendering area features in the "emergency=" key, like this, would
require reloading the database on the openstreetmap.org servers.



it wasn't about rendering really, it was just the illogical use of keys 
making it more awkward for all database users.


I gave up on referring to anything relating to OSM-carto issues for 
precisely the reason you highlight - to render 
emergency=ambulance_station It requires a database reload which is only 
performed "*every few years*". #Ridiculous



DaveF

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

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

[Dave F via Tagging]

On 10/11/2019 16:53, Greg Troxel wrote:


So I agree these tags should be kept separate.


I'm struggling to comprehend how a question I deliberately kept simple 
at just one sentence long can cause so much misinterpretation.



  As for emergency= and
amenity=, that's a historical artifact and doesn't matter.


That just makes it historically wrong. Being incorrect for a long time 
isn't a reason not to fix it. Having two different keys to describe 
entities which come under the heading 'emergency services' is confusing 
to experienced OSMers let alone newbies.


As emergency=ambulance_station appears to be a later invention, was 
there a valid reason fire_station did follow suit?


DaveF

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Paul Allen]

On Mon, 11 Nov 2019 at 09:49, Martin Koppenhoefer 
wrote:

Note I didn't write a bar cannot have seats, I wrote it isn't a strict
> requirement, while it is for pubs I would say.
>

>From my experiences, seats are normally present in both, the difference
between the two
being the types of drinks commonly offered and the prices.  In other
countries it may be
different.  More important is that pubs and bars are places where people
congregate to
consume the products they buy there.


> I don't find the analogy with alcohol very useful, it is a different topic
> and the situation varies even more than for ice cream according to the
> contryspecific situation (and because alcohol is generally considered more
> "drug" than ice cream is, and because religious rules come into play when
> it is about alcohol, etc.).
>

Yes, they are different because of the legal situation.  Which is why I
said the parallels were
not exact.  Where they do match, though, is that you have a shop where you
buy stuff to
take out of the shop and a place where people congregate to consume stuff
they have
bought there.  I think these are important distinctions: consume on the
premises or off
the premises.  They are different operating models and customers have
different
expectations.


> You seem to refer to the British situation, frankly, I do not know what an
> "off-license" is. Germany for example is notably infamous for having very
> lax alcohol regulation (cheap and available everywhere).
>

Pub: place selling alcohol for consumption on the premises.  A place people
congregate
socially to consume the alcohol they buy there.  Usually also permitted to
sell alcohol to
take away.

Supermarket: place selling many different things which may include
alcohol.  If alcohol is
sold it may only be consumed off the premises.  A place people don't (apart
from some of
the idiots in my town) congregate socially.  A place where consumption of
any type of
food or drink on the premises (other than in an in-store cafe, if it has
one) results in ejection.

Off-licence: place selling only alcohol, or alcohol is the primary product
sold.  Alcohol may
only be consumed off the premises.  That is the terms of its LICENCE, that
the alcohol be
consumed OFF the premises, hence "off-licence."

The distinction that I find important is between ice cream made in an
> artisanal fashion (like cakes, pastry) vs. ice cream that is produced
> industrially, and then for the latter maybe the distinction between
> portioned ice cream like here
>

I don't find that an important distinction at all.  A secondary
characteristic at best.  Not one
that distinguishes a shop from an amenity.

My tag for artisanal ice_cream places would be something like "craft=*"
> (meaning the ice cream is made on the premises) and I have also been using
> "restaurant:type:it=gelateria" for them.
>

Craft can be added as a node if the amenity or shop makes the stuff on the
premises.

I don't understand your reasoning here, because I would clearly see these
> (some) kind of ice cream parlours as a subclass of cafe: they have a coffee
> machine, they have table service, they often also sell other stuff that is
> not ice cream (not speaking about "meals" here, but about "drinks").
>

For better or worse, shop=cafe is documented as selling beverages AND light
meals, and this
is how it is understood in British English.


> also this really depends, I would not expect bacon sandwiches to be found
> in a cafe in Germany (could be, but the expectation for me would be table
> service and selling coffee and cakes),
>

 I used "bacon sandwich" as an example of a light meal.  I would expect a
cafe to sell light
meals, even if that is limited to pre-packed sandwiches.  In the UK people
who used a search
facility to look for a cafe would be disappointed if they went and found it
sold only ice cream.
Perhaps when you're in a strange place and want lunch you'd be happy eating
just ice cream
but many people would not.

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Joseph Eisenberg]

> I have not found non-shops tagged as shop=ice_cream, have you?

The example photo on the shop=ice_cream wiki page shows an "ice cream
parlour", which I would not call a shop.

Previously it was claimed that a shop has to be in a building rather
than in a booth, stand or van. However, I don't believe this is true
globally: shop=farm can be used for booths or stands set up next to
the road to sell farm produce in the USA, and previously it was
suggested that I could use either shop=fruit or shop=green_grocer for
stands that sell fruit in Indonesia. Also, there's the tag shop=kiosk
- a kiosk is closer to a booth or stand than to a building.

- Joseph Eisenberg

On 11/11/19, Martin Koppenhoefer  wrote:
> Am Mo., 11. Nov. 2019 um 11:55 Uhr schrieb Mateusz Konieczny <
> matkoni...@tutanota.com>:
>
>> Again, is there some difference
>> in use by general population of mappers?
>>
>> I am not looking for differences in use
>> wanted by specific mappers active here.
>>
>> I am not looking for how
>> "place selling ice cream" may be split into
>> smaller groups.
>>
>> I am not looking
>> for purely theoretical implications
>> of keys shop and amenity.
>>
>> I am not  looking for what would be desirable
>> difference in use.
>>
>> Is there some consistent difference how
>> this two tags are actually used?
>>
>>
>
> I have not found non-shops tagged as shop=ice_cream, have you? How many of
> these would we have to provide in order to be sure it aren't exceptional
> "errors" but standard way of tagging? You can find mistagged objects for
> any kind of object.
>
> FWIW, if we always redefine our tag definitions to the smallest common
> meaning of the "general population of mappers", then discover that we have
> tags that now mean the "exact same thing", we will wipe out all the
> details. Looking at the key definitions to find out that a certain object
> doesn't fit into the general scheme, is not something we should dismiss.
> highway=ice_cream for ice cream vendors along a road isn't a good idea.
> Similarly, shop=* for something that isn't a shop isn't a good idea either.
>
> Cheers
> Martin
>

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 11:55 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

> Again, is there some difference
> in use by general population of mappers?
>
> I am not looking for differences in use
> wanted by specific mappers active here.
>
> I am not looking for how
> "place selling ice cream" may be split into
> smaller groups.
>
> I am not looking
> for purely theoretical implications
> of keys shop and amenity.
>
> I am not  looking for what would be desirable
> difference in use.
>
> Is there some consistent difference how
> this two tags are actually used?
>
>

I have not found non-shops tagged as shop=ice_cream, have you? How many of
these would we have to provide in order to be sure it aren't exceptional
"errors" but standard way of tagging? You can find mistagged objects for
any kind of object.

FWIW, if we always redefine our tag definitions to the smallest common
meaning of the "general population of mappers", then discover that we have
tags that now mean the "exact same thing", we will wipe out all the
details. Looking at the key definitions to find out that a certain object
doesn't fit into the general scheme, is not something we should dismiss.
highway=ice_cream for ice cream vendors along a road isn't a good idea.
Similarly, shop=* for something that isn't a shop isn't a good idea either.

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Mateusz Konieczny]

Again, is there some difference
in use by general population of mappers?
I am not looking for differences in use
wanted by specific mappers active here.

I am not looking for how 
"place selling ice cream" may be split into
smaller groups.

I am not looking
for purely theoretical implications
of keys shop and amenity.
 
I am not  looking for what would be desirabledifference in use.

Is there some consistent difference how
this two tags are actually used?

Based on what I encountered there is none.
11 Nov 2019, 11:17 by dieterdre...@gmail.com:

> I would definitely dispute the sentence that was now added to shop=ice_cream: 
> "exact duplicate of amenity=ice_cream", as it describes only a part of what 
> amenity=ice_cream can cover.
>
> Cheers
> Martin
>
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Volker Schmidt]

I have stood in front of these large levees that prevent big rivers from
flooding the surrounding country side many times her in Italy and did not
find a suitable tagging for both the top and the bottom border lines of the
object.

We have a similar problem with extended stairs for which there is a tagging
scheme , which could
be transferred to the levee situation. I am  not an expert in either levees
nor staircase modelling - I only note the similarity of the problems.

On Mon, 11 Nov 2019 at 10:16, Martin Koppenhoefer 
wrote:

> Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <
> tagging@openstreetmap.org>:
>
>> It seems I was (very) confused, possibly by misreading it several
>> different times. I have mapped 40km of levees wrong, with an improper lower
>> bounds line. I’ll have to fix it.
>> I now understand that my embankment lines at the top are the (only)
>> proper way to map the edge of the embankment.
>>
> I am interested in mapping the extent of the levee/embankments with some
>> kind of outer/lower line, either as a single area or as 2 related ways for
>> a levee.
>>
>>
>
> I agree we should have a way to map both limits, upper and lower, for all
> kind of similar features, e.g. embankments, slopes, and similar. A relation
> seems easier to evaluate and explicit, while a spatial query heuristic will
> inevitably fail in some cases (lets not forget that we cannot assume that
> OSM data is complete, having mapped the upper boundary of one embankment
> and the lower of another, in proximity, and not having mapped the other
> upper and lower boundaries, would not be considered an "error", just
> incomplete data).
>
>
>
>
>> it is interesting to me that a levee is a way that marks the
>> “centerline", while the embankment maps the top edge of the slope - yet
>> there is no documented way to map the *area* of the levees nor embankments.
>> my “lower” embankment line (which is apparently very bad mapping) makes the
>> extent of the embankments that make up a levee. while they sound simple,
>> our levees are *covered with* parallel and intersecting roads.
>>
> some levees will have 5 parallel ways on them for different kinds of
>> traffic. similar to man_made=bridge, showing the area used by a bridge is
>> very useful.
>>
>
>
> maybe in case a road cuts through an embankment, you would have to map
> several embankments (upper and lower boundaries) to represent it?
>
> Cheers
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

I would definitely dispute the sentence that was now added to
shop=ice_cream: "exact duplicate of amenity=ice_cream", as it describes
only a part of what amenity=ice_cream can cover.

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 03:19 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> [is there a] "consistent difference between shop=ice_cream and
> amenity=ice_cream in real tagging by mappers", or not?
>
> It does not appear that these tags are consistently used in a
> different way, but rather than some users have typed in "shop="
> instead of the more common key "amenity=".



I would see amenity=ice_cream to be able to cover everything (and more)
that shop=ice_cream can cover, but not the other way round, i.e.
shop=ice_cream seems more specific (=it is not a booth or van). WRT to
amenity=cafe cuisine=ice_cream, I would see amenity=ice_cream to be able to
cover all those as well, but not the other way round, and finally,
Shop=ice_cream would only cover those amenity=cafe cuisine=ice_cream, where
takeaway is also offered (probably almost all of them).

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 01:10 Uhr schrieb Paul Allen :

> On Sun, 10 Nov 2019 at 23:51, Martin Koppenhoefer 
> wrote:
>
>>
>> > On 10. Nov 2019, at 21:57, Paul Allen  wrote:
>> >
>> > I also see a clear parallel between amenity=bar and amenity=ice_cream:
>> go in, sit down
>> > and consume (there may be an option to purchase to take out).
>>
>> I would not see sitting as a requirement for any of these two. It is for
>> a cafe, but for a bar?
>>
>
> In the UK we have pubs/bars.  They are places where you sit, buy drinks,
> and consume them.
>


Note I didn't write a bar cannot have seats, I wrote it isn't a strict
requirement, while it is for pubs I would say.



> We also have off-licences, where you buy alcoholic drinks and take them
> off the premises
> to consume them.  I see parallels to ice cream sales.  A place with tables
> and seats serving
> only (or mainly) ice cream is amenity=ice_cream in the same way a pub is
> amenity=pub.
>


As stated before, I would rather tag the former as amenity=cafe
cuisine=ice_cream to avoid the ambiguity (as amenity=ice_cream can also
mean a booth or van selling ice cream over the counter).



> A place selling only (or mainly) ice cream to be consumed off the premises
> is
> shop=ice_cream in the same way that an off-licence is shop=alcohol.  Pubs
> are usually
> licenced for off sales (take out) too and many ice cream parlours will do
> takeaways of
> some sort: we have a key for that.
>


I don't find the analogy with alcohol very useful, it is a different topic
and the situation varies even more than for ice cream according to the
contryspecific situation (and because alcohol is generally considered more
"drug" than ice cream is, and because religious rules come into play when
it is about alcohol, etc.). You seem to refer to the British situation,
frankly, I do not know what an "off-license" is. Germany for example is
notably infamous for having very lax alcohol regulation (cheap and
available everywhere).

The distinction that I find important is between ice cream made in an
artisanal fashion (like cakes, pastry) vs. ice cream that is produced
industrially, and then for the latter maybe the distinction between
portioned ice cream like here
https://asset-eu.unileversolutions.com/content/dam/unilever/magnum/united_kingdom/general_image/magnumcannes_themonologue_59sec_2048x851px_5b8_5d-1630529-jpg.jpg.ulenscale.2048x960.jpg.ulenscale.420x236.jpg
and those in "family containers" (i.e. big containers with more than one
"serving unit", without a cone or stick). Actually I haven't bothered so
far to tag places selling ice cream in large scale containers (because they
are less interesting on the go and in general, you would assume to be able
to buy industrial ice cream in any supermarket, and you would hardly find
any supermarket selling artisanal ice cream, at least around here).

My tag for artisanal ice_cream places would be something like "craft=*"
(meaning the ice cream is made on the premises) and I have also been using
"restaurant:type:it=gelateria" for them.

As ice cream may be of particular interest, I have also started adding
sells:ice_cream=yes to places which sell a lot of other stuff and also ice
cream (e.g. news agents and other kiosks, cafes, convenience shops,
bakeries, ticket offices, petrol stations, video stores, etc.)


I don't think amenity=cafe + cuisine=ice_cream is a good fit unless there
> are other
> cuisines, so that you can have a light meal, in which case it's a cafe not
> an ice cream
> parlour.
>


I don't understand your reasoning here, because I would clearly see these
(some) kind of ice cream parlours as a subclass of cafe: they have a coffee
machine, they have table service, they often also sell other stuff that is
not ice cream (not speaking about "meals" here, but about "drinks"). The
ice cream cups are prepared (like other meals). Thinking of places like
these: https://www.san-marco-eiscafe.de/
(look at the pictures to understand the difference between a simple cone
and an ice cream arrangement with sauces and fruit). They are typical for
areas in Germany with Italian migration, but aren't actually in central
Italy (have not found one in Rome).





> However well it might fit OSM syntax and semantics, mentally I don't class
> an ice cream parlour in the same category as a cafe.
>


it really depends on the kind of ice cream parlour. Maybe you simply don't
have the San Marco-alike in Britain?



> I'd be upset if I went to
> something represented by a cafe icon on a map only to find it was an ice
> cream
> parlour and didn't serve bacon sandwiches.  YMMV.
>


also this really depends, I would not expect bacon sandwiches to be found
in a cafe in Germany (could be, but the expectation for me would be table
service and selling coffee and cakes), but this is depends on the local
culture. I hope we all agree, despite using British English terms for our
tags, we will not reduce the possibilities of what can be tagged, to the
British "cu

Re: [Tagging] Additional detail of Levee mapping via embankments

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <
tagging@openstreetmap.org>:

> It seems I was (very) confused, possibly by misreading it several
> different times. I have mapped 40km of levees wrong, with an improper lower
> bounds line. I’ll have to fix it.
> I now understand that my embankment lines at the top are the (only) proper
> way to map the edge of the embankment.
>
I am interested in mapping the extent of the levee/embankments with some
> kind of outer/lower line, either as a single area or as 2 related ways for
> a levee.
>
>

I agree we should have a way to map both limits, upper and lower, for all
kind of similar features, e.g. embankments, slopes, and similar. A relation
seems easier to evaluate and explicit, while a spatial query heuristic will
inevitably fail in some cases (lets not forget that we cannot assume that
OSM data is complete, having mapped the upper boundary of one embankment
and the lower of another, in proximity, and not having mapped the other
upper and lower boundaries, would not be considered an "error", just
incomplete data).




> it is interesting to me that a levee is a way that marks the “centerline",
> while the embankment maps the top edge of the slope - yet there is no
> documented way to map the *area* of the levees nor embankments. my “lower”
> embankment line (which is apparently very bad mapping) makes the extent of
> the embankments that make up a levee. while they sound simple, our levees
> are *covered with* parallel and intersecting roads.
>
some levees will have 5 parallel ways on them for different kinds of
> traffic. similar to man_made=bridge, showing the area used by a bridge is
> very useful.
>


maybe in case a road cuts through an embankment, you would have to map
several embankments (upper and lower boundaries) to represent it?

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

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

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 09:37 Uhr schrieb 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.



you're right, sorry, seems I'm living for too long time away from Germany
now to have a good idea about the current situation. In many (most?)
countries, there isn't a mofa class at all, and you may not even need a
driving license for the bigger 50ccm class. For example there is no
EU-vehicle class for Mofas, it's a German specialty:
https://de.wikipedia.org/wiki/EG-Fahrzeugklasse#Klasse_L

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

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

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 09:28 Uhr schrieb Jan Michel :

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


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).


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


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. There's to keep in mind that there may be
different restrictions or permissions not only according to traffic law but
also according to other regulations or more generally based on the context
(private rules on private ground), e.g. vehicles with combustion motors
might be disallowed in some indoor spaces (exhaust fumes, noise etc.) while
electrial may be allowed.



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


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.

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