Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

> Alex noted that he found that the "lane" value might have a different
> meaning already. I'll look into that and come up with an alternative.

I did this now, I looked for in which situations ...

parking:lane:*:parallel = lane
parking:lane:*:parallel = on_lane
parking:lane:*:parallel = in_lane

... were used. The tag (and the parking lane tag in general, anyway) is 
used only very few times in relation to the number of streets. It is 
still quite new. Together, less than 1% of all parallel parking lanes 
are tagged like that.
But for what it's worth, "on_lane" is the most popular of the above 
(probably because of its consistency with "on_street" and "on_kerb") and 
most of the times were used to describe situations like this:


https://www.google.de/maps/@49.0056633,8.4349157,120m/data=!3m1!1e3

So, parking is on the street itself (not on kerb, not street side) but 
has its own marked lane.


In any case, whatever if someone used "street_side" as a value for the 
parallel parking lane or "on_lane", "on_kerb", "lay_by" or 
"painted_area_only", its all the same as in that it does define an own 
dedicated space for parking cars as opposed to "on_street" and 
"half_on_kerb".


And in the end, what will give the most precision in measuring the 
drivable space (criteria #2) is to look at the width or est_width tag. 
No need to let the lanes tag duplicate this information but less precise.
If the lanes tag was used for that, then it would become eventually 
obsolete because it wouldn't carry any original information that cannot 
be recorded more precisely and less subjectively with another tag. On 
the other hand, data consumers attempting a visualization (criteria #1) 
need the information how many lanes are tagged.
So, I am going ahead an will add these two words to the documentation of 
the lanes key.


Cheers
Tobias

On 20/11/2020 14:03, Tobias Zwick wrote:

You stated how you would tag that, which I'd summarize as

 > Any parking on the street surface is subtracted from the lanes as the
 > lanes-tag first and foremost indicates the number of usable lanes, not
 > the number of marked lanes

Ok, so apparently there is no consensus on that if there are marked 
lanes, it's always the marked lanes that first and foremost should be 
counted.


But let's not fall in the trap that everybody states how he tags it and 
in the end we can agree that we cannot agree. We have a problem to 
solve, let's identify it and find a solution together. I'd say, the core 
of it is:


How to tag if usable lanes deviate from marked lanes?


And the solution we are aiming at should fulfill at least these criteria:

1. that the street layout can be interpreted correctly and completely
    (for data visualization, f.e. JOSM lanes plugin, abstreet, renderers
     ...)
2. that the effective usable width of the street for car traffic can be
    ascertained (for routers)

---

The criteria above were already in my head when I wrote the second half 
of my intial post: When do usable lanes deviate from marked lanes?
-> When there are cars not parking in an own dedicated parking lane but 
just at one side of the street. Hence, this example:


https://westnordost.de/misc/parallel_parking_lane.png

If these situations are tagged like this...

(1)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = lane

(2)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = on_street

..., both criteria are fulfilled, given the definition for lanes is:
"if marked, number of marked lanes. Dedicated and marked parking lanes 
don't count" (adding "dedicated and marked" to wiki definition).


For visualization, the lanes tag can then be directly used. Routers will 
want to additionally look at the parking lanes tag to see whether the 
effectively usable road is being narrowed by parking lanes with 
on_street or half_on_kerb and subtract that from the usable width.


I further suggested this solution because of its separation of concerns: 
Lanes is then just the marked lanes, no need to factor in possible 
parking lanes into that one tag and estimate whether the parking cars 
subtract enough of lane space to decrease it by one.


So, the definition of parking lanes go into the parking:lane tag, 
including where it is located. Well, and that's already how it is done, 
so that's not a real change.


The change here would be to find a tag the describes "parking lane is on 
street surface but has its own space/lane". Alex noted that he found 
that the "lane" value might have a different meaning already. I'll look 
into that and come up with an alternative.


Tobias

On 20/11/2020 09:16, Mateusz Konieczny via Tagging wrote:
I would describe https://westnordost.de/misc/2or1lanes.jpg 
<https://westno

Re: [Tagging] surface=rock

[Tobias Zwick]

> rock „pieces“ would be tagged as „stone“ I guess?

Not so sure about that, then it would be surface=stones, (note the 
plural) wouldn't it?


---

There is a huge discussion on the #tagging channel on OSM slack (85+ 
replies) where all those "rocky" surface are being discussed.


Here are some statements from this discussion, also on the difference 
between "surface=rock" and "surface=stone". Most from Brian Sperlongano 
and Elliott Plack:


- Rock implies a rough naturalness

- Steps made of large (single-piece) hewn stone columns would be called 
'stone steps'


- Bare [rock] implies the lack of rubble on top

- Scree is specially loose

- Personally I think bare_rock and stone are synonyms here, unless 
someone thinks there's a difference.


- bare_rock has 569 usages, rock has 2759 usages and stone has 6402 
usages, scree has 319 usages, rocky has 1400 uses


---

For Germans, I'd say stone roughly translates to "Stein" while rock 
translates to "Fels". To summarize the above:


rock = rough natural stone, could be loose stones too
stone = smooth stone / bare rock, could be hewn
bare_rock = probably similar to stone, definitely no loose stones
scree = surface like (large) gravel, natural
rocky = scree is rocky, piles of differently sized rocks are rocky

Tobias

On 21/11/2020 09:57, Martin Koppenhoefer wrote:



sent from a phone


On 20. Nov 2020, at 23:22, Mateusz Konieczny via Tagging 
 wrote:

Both for exposed natural rock and steps/footways made of rock pieces?



rock „pieces“ would be tagged as „stone“ I guess?


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] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

You stated how you would tag that, which I'd summarize as

> Any parking on the street surface is subtracted from the lanes as the
> lanes-tag first and foremost indicates the number of usable lanes, not
> the number of marked lanes

Ok, so apparently there is no consensus on that if there are marked 
lanes, it's always the marked lanes that first and foremost should be 
counted.


But let's not fall in the trap that everybody states how he tags it and 
in the end we can agree that we cannot agree. We have a problem to 
solve, let's identify it and find a solution together. I'd say, the core 
of it is:


How to tag if usable lanes deviate from marked lanes?


And the solution we are aiming at should fulfill at least these criteria:

1. that the street layout can be interpreted correctly and completely
   (for data visualization, f.e. JOSM lanes plugin, abstreet, renderers
...)
2. that the effective usable width of the street for car traffic can be
   ascertained (for routers)

---

The criteria above were already in my head when I wrote the second half 
of my intial post: When do usable lanes deviate from marked lanes?
-> When there are cars not parking in an own dedicated parking lane but 
just at one side of the street. Hence, this example:


https://westnordost.de/misc/parallel_parking_lane.png

If these situations are tagged like this...

(1)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = lane

(2)
lanes = 2
parking:lane:right = parallel
parking:lane:right:parallel = on_street

..., both criteria are fulfilled, given the definition for lanes is:
"if marked, number of marked lanes. Dedicated and marked parking lanes 
don't count" (adding "dedicated and marked" to wiki definition).


For visualization, the lanes tag can then be directly used. Routers will 
want to additionally look at the parking lanes tag to see whether the 
effectively usable road is being narrowed by parking lanes with 
on_street or half_on_kerb and subtract that from the usable width.


I further suggested this solution because of its separation of concerns: 
Lanes is then just the marked lanes, no need to factor in possible 
parking lanes into that one tag and estimate whether the parking cars 
subtract enough of lane space to decrease it by one.


So, the definition of parking lanes go into the parking:lane tag, 
including where it is located. Well, and that's already how it is done, 
so that's not a real change.


The change here would be to find a tag the describes "parking lane is on 
street surface but has its own space/lane". Alex noted that he found 
that the "lane" value might have a different meaning already. I'll look 
into that and come up with an alternative.


Tobias

On 20/11/2020 09:16, Mateusz Konieczny via Tagging wrote:
I would describe https://westnordost.de/misc/2or1lanes.jpg 
 as road

with
- one lane driveable by full-size vehicles
- one parking lane

And tag it as:
lanes=1
parking:lane:both=parallel (judging from what is visible about left side)

Additional detail that I am generally not tagging may specify
for example:

parking:lane:right:parallel=on_street
parking:lane:left:parallel=on_kerb (judging from what is visible on photo)

Tagging whatever parking lane has just allowed parking that fully block it
or is it explicitly marked as parking lane can go into new tag (if not
covered by an existing tagging).

For example I would consider
https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg 


as lanes=1, not lanes=3

-

This gets trickier with:

- illegal parking that nevertheless is accepted, widespread and typical, 
de facto changing

number of available lanes

For example street that in theory is lanes=2 but due to how people park 
and lack of need for two lanes,
it is de facto lanes=1 (cars driving over marked centerline as 
theoretical lanes are blocked

by cars)

- lane that switches between parking lane and driveable lane depending on
hour/day (lanes:conditional solves this)

- lane that switches between parking lane and driveable lane depending on
how many people park there

Nov 19, 2020, 15:17 by o...@westnordost.de:

Hello all

First of all, in the past, we have explored many edge cases for the
lanes-tag in various discussions and I am happy that for the most
part, it seems to be quite well defined by now. However, there is
one edge case which is not uncommon at all but still unclear or
awkward to tag. Look at this:

https://westnordost.de/misc/2or1lanes.jpg

It is a residential road marked clearly for 2 lanes, so it seems
obvious to tag it with lanes=2. But on the other hand, you'll notice
that there are parking cars on the right side that effectively
render the right lane

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

For the smart (the white car), the same rules apply as if it was 
overtaking the parked cars, it may only pass once the other side is free.


The signs on the right say "no stopping", arrow to the left means "no 
stopping starts here", arrow to the right means "...and ends here". They 
are just there temporarily, there is some construction or something like 
that.


Maybe it is difficult to see in the perspective the photo was taken, but 
actually none of the parking cars is parking there illegaly. At the 
sections where stopping is forbidden, there are no parking cars.


Tobias

On 19/11/2020 23:22, Graeme Fitzpatrick wrote:




On Fri, 20 Nov 2020 at 00:22, Tobias Zwick <mailto:o...@westnordost.de>> wrote:



https://westnordost.de/misc/2or1lanes.jpg
<https://westnordost.de/misc/2or1lanes.jpg>

It is a residential road marked clearly for 2 lanes, so it seems
obvious
to tag it with lanes=2. But on the other hand, you'll notice that there
are parking cars on the right side that effectively render the right
lane unusable.


So what happens when somebody wants to drive the other way - & by the 
direction those parked cars are facing, they must?


Also, what do the signs mean above the parked cars - Red X & white 
left-pointing arrow on a blue background? Anything relevant to parking?


Thanks

Graeme


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



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

Re: [Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

Okay, but the data consumer won't know how you reached that decision (to 
count it or not). So whoever attempts a visualization of the data will 
have no idea whether to put the parking lane next to the rest of the 
street or put it "on top" (see

https://westnordost.de/misc/parallel_parking_lane.png )

This is not only an issue with visualization, also routers will want to 
know if parking cars effectively reduce the usable width of the road by 
the width of a car, or not.


This is why I initially stated that I see the need to distinguish these 
cases.


On 19/11/2020 23:17, Andrew Harvey wrote:
The way I understood the tagging guidelines was that if there was nobody 
parked there, could you drive along the lane as usual. If you can't then 
I wouldn't include it as lanes=* and only tag it as parking:lane. If you 
can drive along it when vacant, but you can still legally park there 
then I'd include it as lanes=* and also tag parking:lane.


It's common that during peak hour the lane is used by traffic, but 
off-peak it's available for parking.


On Fri, 20 Nov 2020 at 01:22, Tobias Zwick <mailto:o...@westnordost.de>> wrote:


Hello all

First of all, in the past, we have explored many edge cases for the
lanes-tag in various discussions and I am happy that for the most part,
it seems to be quite well defined by now. However, there is one edge
case which is not uncommon at all but still unclear or awkward to tag.
Look at this:

https://westnordost.de/misc/2or1lanes.jpg
<https://westnordost.de/misc/2or1lanes.jpg>

It is a residential road marked clearly for 2 lanes, so it seems
obvious
to tag it with lanes=2. But on the other hand, you'll notice that there
are parking cars on the right side that effectively render the right
lane unusable. These parking cars would (currently) be tagged I
believe as

parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

  > And the following lanes should be excluded:
  > [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the
road has marked lanes, the number of marked lanes should be tagged, on
the other hand, there are these kind of "parking lanes" which do not
have their own space marked as a parking lane but simply absorb the
space assigned to normal car traffic. In OSM tagging, these are also
"parking:lane"s as far as I know.

We need to dissolve this ambiguity by defining a way how to distinguish
between these two cases:

https://westnordost.de/misc/parallel_parking_lane.png
<https://westnordost.de/misc/parallel_parking_lane.png>
(1) a dedicated parallel parking lane. This lane should not count as a
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant
for the lane count.

My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking
lane tagging out and about and its documentation could also state their
point of view here. According to the wiki edit history, looks like at
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.
What do you think?

There is also at least one data consumer I know about that is using
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet
<https://github.com/dabreegster/abstreet> it would be good to know how
they interpret and visualize the data.

Cheers
Tobias

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


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



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

[Tagging] lanes - is "parking allowed" a parking lane?

[Tobias Zwick]

Hello all

First of all, in the past, we have explored many edge cases for the 
lanes-tag in various discussions and I am happy that for the most part, 
it seems to be quite well defined by now. However, there is one edge 
case which is not uncommon at all but still unclear or awkward to tag. 
Look at this:


https://westnordost.de/misc/2or1lanes.jpg

It is a residential road marked clearly for 2 lanes, so it seems obvious 
to tag it with lanes=2. But on the other hand, you'll notice that there 
are parking cars on the right side that effectively render the right 
lane unusable. These parking cars would (currently) be tagged I believe as


parking:lane:right=parallel
parking:lane:right:parallel=on_street

And the wiki states

> And the following lanes should be excluded:
> [...] Parking lanes [...]

So here is an ambiguity in the documentation. On the one hand, if the 
road has marked lanes, the number of marked lanes should be tagged, on 
the other hand, there are these kind of "parking lanes" which do not 
have their own space marked as a parking lane but simply absorb the 
space assigned to normal car traffic. In OSM tagging, these are also 
"parking:lane"s as far as I know.


We need to dissolve this ambiguity by defining a way how to distinguish 
between these two cases:


https://westnordost.de/misc/parallel_parking_lane.png
(1) a dedicated parallel parking lane. This lane should not count as a 
lane in the lanes-tag.
(2) (parallel) parking is allowed (and used). This should be irrelevant 
for the lane count.


My suggestion would be
(1) parking:lane:*:parallel = lane
(2) parking:lane:*:parallel = on_street

Maybe especially those who recently involved themselves with parking 
lane tagging out and about and its documentation could also state their 
point of view here. According to the wiki edit history, looks like at 
least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were active.

What do you think?

There is also at least one data consumer I know about that is using 
parking lane information and displays it visually,
https://github.com/dabreegster/abstreet it would be good to know how 
they interpret and visualize the data.


Cheers
Tobias

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

Re: [Tagging] OSM changes the world | Re: Feature Proposal - RFC - Artificial

[Tobias Zwick]

The purpose of OSM is to **map** the world.

If this brings about positive change such as the things you mentioned 
(any many more), that's good and that is the reason why many people 
contribute to such a free wiki world map.
This is a huge difference to your statement! You seem to defend that OSM 
should be used as a tool to change language, for politically motivated 
reasons in this case.


OSM is as much about change as science, FOSS or wikipedia is about 
change. Who would trust wikipedia as a reliable source if their mission 
was to "bring about (political) change"?


In my book, furthering political or social ideologies does not even fall 
remotely under the mission of OSM. I dearly hope it stays this way.


Tobias

On 21/10/2020 09:49, Rory McCann wrote:

On Wed, 21 Oct 2020, at 6:25 AM, Mateusz Konieczny via Tagging wrote:

(4) I would prefer to not use OSM as a tool
to change language, especially if done at
cost of making more complicated for
mappers. AFAIK term "man made" and it's
meaning remains standard and is well
understood


The purpose of OSM is to change the world. We're trying to create a map of the 
world, build by enthusiastic local people and to give it away to everyone for 
free. We're trying to produce a geo commons for every person. It's too late to 
say that OSM shouldn't change anything in the world. 🙂

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



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

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

[Tobias Zwick]

>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. 

I don't think this is true anymore. Did you try out "Measure" or any other 
ARCore/ARKit-based measuring app? Example:

https://m.youtube.com/watch?v=qz0YJ0s4JLM

Am 20. September 2020 00:01:00 MESZ schrieb Volker Schmidt :
>Some thoughts that trouble me...
>
>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. I guess that most width
>values in the database are reality estimates (I don't think that this
>is an
>unjustified extrapolation from my own mapping - 99.9% of my width
>tagging
>based on estimates). Estimates are relatively easy for narrow roads if
>you
>have street-level photographs. They become much more unreliable for
>wider
>roads. I solve this by using only lanes count for wider roads. Precise
>width measurements are difficult to impossible, but fortunately they
>are
>also less important than the lanes count for the end user.
>
>The discussion about including/excluding sidepaths/sidewalks becomes
>also
>irrelevant if we were only to use the lanes count as that counts only
>motor
>traffic lanes.
>
>Would also overcome another aspect of the width definition: If we use
>width
>for the entire road, i.e motor-traffic lanes, shoulders, sidewalks,
>cycle
>lanes/tracks/paths, tree rows between foot and cycleway, ... we do in
>the
>end not know enough about the the actual widths of the different
>component
>"lanes".
>
>Width values are useful and easy to estimate from street-level
>photographs
>for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m
>precision.
>
>We need in any case a good system for regrouping parallel ways that
>belong
>to the same street.
>A relation seems to me the better option, but in any case, whatever
>approach we pick now, we will face an nearly impossible amount of
>retrofitting work. Anything we do on this from now will not make the
>problem go away with the existing stock of data.
>
>Volker
>
>
>
>
>
>
>
>
>
>Virus-free.
>www.avast.com
>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>On Fri, 18 Sep 2020 at 22:35, Tobias Knerr  wrote:
>
>> On 17.09.20 02:35, Taskar Center wrote:
>> > This is yet another example why "sticking" the sidewalks onto the
>> > highway (as a tag) rather than mapping them as separate ways is
>> > appearing to be less and less practical. Please see our sidewalk
>schema
>> > proposal
>> >
>
>> > from several years ago.
>>
>> Your sidewalk proposal unfortunately doesn't really address the
>crucial
>> shortcoming of separately mapped sidewalks: The lack of a reliable
>> mechanism for figuring out which section of road a given sidewalk way
>> belongs to.
>>
>> I agree that we should be able to give sidewalks their own geometry,
>but
>> we _also_ need the relationship between sidewalk and road. So far,
>all
>> the proposals attempting to support the former end up sacrificing the
>> latter.
>>
>> There have been some promising discussions recently around the
>> sidepath_of idea, but that's still just brainstorming. Until a
>practical
>> solution is found and actually used in the database, sidewalk mapping
>> will remain a choice between two options that are broken in different
>ways.
>>
>> As for the main issue of the thread: I would welcome a clear
>definition
>> for the meaning of width. In my own mapping and when writing the
>> relevant code in OSM2World, I have counted sidewalks etc. as part of
>the
>> road's width if they are mapped as tags on the main way. But I would
>of
>> course change that if there finally was a documented and widely
>> agreed-upon recommendation. I don't care so much which one it is -
>but
>> we need one.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

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

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

[Tobias Zwick]

Absolutely high time! Thank you for bringing this up.

I was under the impression that the wiki already defined it like 2). 1) 
is not practical because parking lanes can be informal or can change 
quickly, 3) is also not practical because sidewalks + additional 
greenery/space between road and sidewalk can vary a lot.


I plan to soon implement a "What is the width of this road" quest in 
StreetComplete where the user can measure the width of the road using 
his or her smartphone (similar to the app Measure from Google [1]). The 
app will need to instruct the user very clearly what should be measured.


The instruction "curb to curb" is pretty clear. However, there is one 
more problem to solve, what about if there are no curbs? For example, 
track-like roads that just consist of either one strip of asphalt 
surface or are not paved at all? I see two possible definitions:


1. Width of the paved surface (if paved)
2. Usable width of the road

1 has the advantage that there is no room for interpretation, but falls 
short of what to do with unpaved roads. 2 leaves some room for 
interpretation but also covers cases where the usable width of the road 
is much different from the width of the paved part of the road.


Tobias

[1] https://play.google.com/store/apps/details?id=com.google.tango.measure

On 14.09.20 20:34, Supaplex wrote:


Hey all,

again and again there are discussions about which parts of a street 
(sidewalks and cycle paths, parking lanes, carriageway) should be 
considered when determining the width of a street. There does not seem 
to be a consensus and therefore information on street widths is 
difficult to interpret or is not even mapped. The following variants 
are common/are discussed:


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

I tend to option 2):
- The width can be clearly defined and measured
- The width of the actual carriageway can be determined by using 
"parking:lane" scheme correctly (or alternatively/supplementarily by 
specifying the width of parking lanes). "width:carriageway" (or 
"width:lanes", if there are marked lanes) also could be used to map 
this width directly.
- The width of roadside paths can optionally be specified with 
"sidewalk:width" etc.


Wouldn't it be time to document a recommendation in the Wiki to reduce 
further ambiguities? Which variant is the most recommendable? Anyway, 
the width of a street is a significant value to evaluate its 
suitability or safety for certain modes of transport or to determine 
the speed that can be expected there.


Thanks for your comments,
Alex


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

Re: [Tagging] tagging drinking water of uncleaer official (signed) status

[Tobias Zwick]

The discussion went astray a bit, partly because I think it was not 
clear why Mateusz proposed to use the 
drinking_water:legal=yes/no/unknown at all, if there is already the tag 
drinking_water=yes/no.


Let me illustrate with some examples. So, these two cases are clear:

 * 1. There is a sign that says you can drink it or it is otherwise
   clear that you can (drinking fountain constructed by muncipality) ->
   drinking_water=yes

 * 2. There is a sign that forbids it or warns that it is contaminated
   -> drinking_water=no

But what about these?

 * 3. There is no sign at all and no clear indication whether it is
   drinkable or not. Water that comes out of a mountain might be
   polluted with toxic substances, especially if it is close to an
   (old) mine.

 * 4. There is a sign that simply says "no drinking water" but it is
   clear from the circumstances that it is. Don't have a good example
   right now, maybe because of insurance, or nearby shop wants to sell
   bottled water.

In case 3, where a surveyor cannot with certainty determine if it should 
be drinking_water=yes or no (without trying it himself and waiting if he 
becomes ill or not, which can't be expected of the surveyor). So in this 
case, he would need to leave drinking_water untagged. But what he can 
with certainty record is that there is no official information about it 
whatsoever. This is useful because people searching for drinkable water 
would certainly prefer water sources where it is positive that it is 
drinkable. drinking_water=unknown or drinking_water:signed=no would 
solve this, but there is also case 4.


In case 4, the official information would deviate from the actual 
situation on-site, which could warrant to record these two informations 
separately when necessary.



Cheers
Tobias

On 06.09.20 15:14, Mateusz Konieczny via Tagging wrote:

We have drinking_water:legal=yes for water that is officially drinkable,
we have drinking_water:legal=no for water signed as not drinkable.

Do we have tag for water sources (amenity=drinking_water, 
drinking_water=yes)
that are neither officially or signably drinkable nor with "not 
drinkable sign"?


drinking_water:signed=no ?

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

[Tagging] StreetComplete: summary of re-survey quests and how they will be tagged

[Tobias Zwick]

Hi there,

for your information, here is a summary of all re-survey enabled quests
with intervals, element selection and notes what will be tagged now:

https://github.com/westnordost/StreetComplete/issues/1998#issuecomment-677825912

Cheers
Tobias


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

Re: [Tagging] StreetComplete: no re-survey for speed limits

[Tobias Zwick]

I am not sure what is the message of your statement. Is this just a
general opinion regarding speed limits or is this somehow referring to
the explanation I linked in the thread starter?

If the latter, and you think after all it would be possible to implement
such a re-survey for speed limits without stirring conflict, I'd be
happy to hear your suggestions on how to solve each of the 7 issues
mentioned in the explanation.

For anyone reading here but not inclined to read that long explanation
(which very much originitated from the concrete problems observed when
trying to implement it), I can try to give a shorter and more pointed
summary of the main issues why I can't implement it in StreetComplete.

Cheers
Tobias

On 20/08/2020 01:27, Martin Koppenhoefer wrote:
> I feel that the actual tags for implicit limits are less important than the 
> accuracy of the information. From surveys, in different countries (but 
> clearly random samples and no systematic research), it’s not super rare to 
> find implicit limits tagged where there are (lower) signed speed limits on 
> the ground. Resurvey would make sense, retagging the same with different tags 
> much less so.
> 
> 
> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] StreetComplete: no re-survey for speed limits

[Tobias Zwick]

Hey guys,

I just wanted to inform you that unfortunately, StreetComplete will not
offer a re-survey for speed limits in the upcoming "Map Maintenance with
StreetComplete" feature but probably never anyway.

Short explanation: It is impossible to implement a re-survey without
creating conflict with tagging practices, because there are many
competing ones, each locally established, but none globally. Also, none
of the current tagging practices for implicit speed limits are actually
eligible to be used globally.

Long explanation is here:
https://github.com/westnordost/StreetComplete/issues/1998#issuecomment-676787192

I post this to the tagging mailing list, as the reason for this is
really just an issue with the tagging scheme. For obvious reasons, I can
not take the initiative in solving this issue, I would just like that
more people are made aware of it.

Cheers
Tobias


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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

Two more types came to my mind:

1. Courtyard area (Дворовая территория)


Another type of service road that is currently probably not tagged with
any subtag came to my mind right now: Something like a multi-use
courtyard area bounded by buildings around the perimeter with
playgrounds, recreation and green spaces, driveways etc. It may
additionally be tagged with living_street=yes.

I recently read up on the default speed limits (if no sign is posted) of
the Russian road regulations. It mentioned "20 km/h in courtyard areas"
(Дворовая территория). I asked about what can be understood by that in
the Russian forum:
https://forum.openstreetmap.org/viewtopic.php?id=70178

I have no clear picture of it, maybe someone from Russia can post an
example Google StreetView picture or something.
But if the description given in the Russian forum fits, then these
service roads would be neither alley, nor driveway, nor parking.

2. Medieval alleys (Gasse) / South-East-Asian very-small residentials


Usually and/or in English, service=alley is defined as a road that
provides access to the rear or back of a building or home, alternatively
as a narrow road between properties.

However, (at least) in the German Wiki, it is also documented as a "very
small medieval (residential) road, often broad enough for a car but no
space for sidewalks or parking", see the pictures in
https://wiki.openstreetmap.org/wiki/DE:Tag:service%3Dalley

Whether the wiki entry there is in the wrong or not is quite irrelevant
at this point because it has been documented like that a long time, so
many such roads will be tagged like that and we are dealing with a
status quo.

When looking at the map internationally, one can see that oftentimes for
very small residential roads, the highway=service tag is used (sometimes
with service=alley, sometimes not), sometimes highway=living_street
(even though it is documented that living street should only be used if
it is explicitly signed) and sometimes highway=residential.

Example of such a very small residential in Thailand:
https://goo.gl/maps/aSNb38BNiqDJ3t8Q7 where one can't be sure whether it
is tagged as highway=service, highway=living_street or highway=residential.

Which tag is used and which tag should be used is somewhat subject to
continued disagreement amongst mappers, I consider it an open problem.

So if we are about to define the subtags for highway=service through and
through, then we come to the point where we'd need to decide if this is
a legitimate usage of the highway=service tag and if not, what should be
used instead.

Tobias

On 02/08/2020 02:40, David Dean wrote:
> Hi everyone,
> 
> I'm interested in proposing and/or documenting existing tagging
> approaches of the wiki to ensure that all highway=service ways can have
> a service=? associated tag. Having done, so I'm planning on
> resurrecting https://github.com/westnordost/StreetComplete/issues/808 to
> help people get all service roads appropriately tagged in their area.
> 
> At the moment, service=? can be (according to the wiki
> at https://wiki.openstreetmap.org/wiki/Key:service):
> 
> * service=parking_aisle
> * service=driveway
> * service=alley
> * service=emergency_access
> * service=drive-through
> 
> But service roads are also used for the 'main ways on a parking lot',
> and there is also an indication of access to multiple businesses (like
> in an industrial estate etc), and it looks like the documented way is to
> not to provide a service=? tag in this case.
> 
> This seems problematic to me from a map maintenance purpose, as how do
> we know if a highway=service just hasn't had a service=? tag applied
> yet, or if it is one of the exceptions that does not get a service=? tag
> (and which one is it?)
> 
> I would like to try to understand the highway=service usages that don't
> have a current documented service=? tag and either propose an
> appropriate tag or find examples of existing tagging to document.
> 
> At this stage I think appropriate tagging for some of the missing
> service=? tagging indicated in the documentation would be:
> 
> service=parking -> main way in a parking lot, for connecting
> service=parking_isles (used almost 2K times
> already: https://taginfo.openstreetmap.org/keys/service#values)
> 
> service=driveway -> also used for access to multiple businesses
> (like in an industrial estate, etc)
> 
> service=driveway/drive-through -> Service way for access to a fuel
> station
> 
> 
> Are there any other main understood uses of no service=? tag that would
> need an appropriate service=? tag to fill this gap?
> 
> Once I've got some good starting feedback from this forum, I plan on
> revising 
> https://wiki.openstreetmap.org/wiki/Proposed_features/service%3Dparking to
> include any new appropriate service=? (not just service=parking) tagging
> and start the formal RFC process.
> 
> Thanks for your fe

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

> For the second type of highway=service with no service tagging, what
> about using service=access? 

The issue with this is that basically this is the definition of
highway=service already without any extra tags: It provides access to
something. Be it the rear/side of buildings (alley), the garage of a
house (driveway), the fuel dispensers on a filling station
(drive-through) or to the individual parking spaces on a parking
(parking_aisle).

Maybe service=property_access would be a little more clear. Of course,
strictly speaking, pretty much all the above are also "properties". Is
there a word in English that would describe more accurately those kind
of hmm, bigger properties, like industrial and commercial parks,
hospital grounds etc etc (as mentioned in an earlier post)?

Cheers
Tobias


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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

service=parking_access also sounds most clear to me.

On the other hand, service=parking is already used almost 2000 times so
documenting that as "main access road in a parking" would just be
documenting the status quo, no proposal necessary, which is certainly
easier.

IF after research one can actually conclude that service=parking is
really used for that purpose and not for all kinds of roads in parking
that should actually be parking_aisles. So before reaching a conclusion,
I'd strongly suggest to first analyse a bit what really is the status
quo with service=parking.

Cheers
Tobias

On 03/08/2020 11:25, Martin Koppenhoefer wrote:
> Am Mo., 3. Aug. 2020 um 11:06 Uhr schrieb Tom Pfeifer
> mailto:t.pfei...@computer.org>>:
> 
> Possibilities discussed were:
> 
> service=parking_access
> service=main
> service=access
> service=major
> 
> 
> 
> apart "access", all of these seem better than "parking". My preference
> would go to the more neutral "main" or "major"
> 
> Cheers
> Martin
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

>  - Roads through cemeteries
>  - Roads through campgrounds
>  - Roads through schools
>  - Roads through universities
>  - Roads through hotels
>  - Roads through museums
>  - Roads through prisons
>  - Roads through military areas
>  - Roads through airports
>  - Roads through retirement homes
>  - Roads through resorts
>  - Roads through reservoirs (sometimes over dams)
>  - Roads through ski areas
>  - Roads that serve privately-owned inholdings surrounded by public land
>  - Maintenance roads in parks
>  - Private semi-residential roads that serve multiple driveways
>  - Non-public roads though industrial areas

Good list!

So what all these have in common is that they are not public roads not
intended for through-traffic. They are all on private/public properties.
So maybe they could be summarized under service=property, with a
description like "roads on (private) large properties, such as on
hospital grounds, cemeteries, camping grounds, industrial or commercial
areas"

Another kind of service road that comes to my mind would be just a piece
of paved way that is broad enough for a car somewhere in the nowhere
(countryside, forest) that does not obviously belong to any property but
also does not lead to any house or parking area. It is not tagged as a
highway=path because it is broad enough for cars and it is not tagged as
highway=track because oftentimes such tracks that are well paved and not
obviously for agricultural/forestry usage are simply tagged that way.
So in other words, it is "just" a service road but a subtype is unknown,
much like a subtype is often unknown for highway=footway ("It is just a
way!").

Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Zwick]

> I think it would help with community acceptance of a potentially large
> number of meta tags if you're somewhat frugal when it comes to adding
> new ones. [...]
> 
> In practice, this could mean ...
> 
> * ... not adding key:check_date when the key is first added, or when the
> value is changed as opposed to confirmed. (But update check_date tags
> that already exist on the object, of course.)
> * ... only using check_date where regular re-survey is plausible and
> useful. This ties in with your observations on re-check intervals. For
> example, there should be an opening_hours:check_date, but probably no
> building:levels:check_date.
I think the same. Basically, I only brought this up as a question
directed at the mailing list at all because in the linked github issue
[1] someone argued for always adding a check_date.

He makes some good points [1], also regarding the reliability of the
"timestamp" (last date changed) attribute of an element. But so far, the
voices here on the mailing list were mostly arguing for frugal use of
such meta-tags, so if no other voices that make a conclusive point for
being less frugal with such meta tags come up, I will take the measures
that you mentioned.

[1] https://github.com/westnordost/StreetComplete/issues/1836


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Zwick]

> adding check timestamps as string tags for every single tag seems a lot of 
> bloat. One tag per object for me would be acceptable because it is indeed a 
> valuable information when something was last verified and no changes were 
> necessary.

Definitely it has the potential for that. And as Mateusz noted in
another branch, check_date tags themselves could become out-of-date if
successive editors do not update the tag together with the tag it refers to.

On the other hand, at least at this time I do not see the danger of this
[=every single tag is accompanied by a meta-tag] happening, neither
through individual usage of such meta tags nor by being set by
StreetComplete automatically because only a small fraction of tags are
likely to change in a timeframe of some years or below. In other words,
only for a small fraction of tags it makes sense to attach a check_date
to. A good example of things that change more frequently would be
smoothness or opening hours.

For example one surveyor may check on-site the smoothness and surface of
a road, but not check if the width is still correct because he doesn't
have anything with him to measure it. Also, he doesn't want to check if
the speed limit is still correct because that would require him to go up
the road at least until the next big intersection to find a speed limit
sign (or not). He may also not want to check whether all(?!) the bus
routes are still correct. Generally, some information tagged on an
element is also not verifiable on-site.
What this example should illustrate is that it is illusory to assume
that a mapper is both able and willing to check everything at once for a
certain element.

(Basically, StreetComplete is founded on the idea that surveyors don't
have to tag and check "everything" at once for any given element but
add/update the information bit by bit.)

---

On the topic of map maintenance, there is another information that is
currently missing (from the API) which would be helpful to maintain an
up-to-date map. It is a bit off topic because this topic is mostly about
StreetComplete / on-site map maintenance but I would like to still touch
on it shortly:

If the date + *source* of the last change made on (the geometry of an)
element was readily available, through the API or another meta-tag
(source=bing, anyone? ;-) ), this would help to identify areas that
should be updated because a new more current and/or detailed source
became available.
In Hamburg, we are lucky that the public authority provides us with
really detailed up-to-date satellite imagery that are far beyond bing
but there is no easy way to see which buildings and road geometries have
still been mapped on the basis of bing and which are already using the
better source.
So in a nutshell, the topic of how to find things based on old sources
is also very relevant for remote mappers.

Cheers
Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Zwick]

Thanks!

> Secondly, I think having to evaluate the history is a challenge. But do
> you have to? 

No, I don't have to, thanks to such tags as check_date. But then again,
check_date, survey:date etc. only came to be invented because API
support was missing. It would be better to have somthing like that in
the API itself. I would welcome it.

> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).

Interesting approach, but what tag do you use for that? It sounds like
you use check_date for that, but check_date is documented as "The tag is
intended to document the last date, when an object as a whole or
specific tags of the object were checked and verified".

Cheers
Tobias


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Zwick]

> It is completely possible to add this functionality to the API in a
> backwards compatible fashion, at the cost of a long per tag in the
> current table (assuming that we don't need the information for historic
> object versions, so at a reasonable cost space wise. There are a couple
> of semantic issues that need to be considered but definitely not rocket
> science. Where the big effort is likely adapting the internal tools
> (database dumps etc), cgi-map and in the end migrating the database.
> 
> If I can find some time over the next months I might prototype this, but
> if somebody can do it earlier pls be my guest.

I am happy that through this topic, the topic of API support for
recording and getting the last checked date gained traction (again).

We,... well, we probably could, but we shouldn't always rely on tags
like check_date etc.. As Mateusz Konieczny rightfully noted in another
branch, meta-tags as opposed to API support has the potential to become
out of date if successive editors forget to update the check_date tag
when they update the object or tag it is referring to.

So, all the more I say it is pretty awesome that you plan to conceive a
plan for this. Whatever comes out of it, in any case thank you for
taking an initiative, Simon!
Such a feature would also open up much more room for comprehensive
analyzing and QA tools focussed on map maintenance, a topic that is or
at least is becoming more and more important in my opinion. The
endorsements there were so far for the map maintenance in StreetComplete
indicate that the topic has become to take precedence in the minds of
many mappers, also of those usually not that involved in discussions in
the established channels.

Regarding changes to the API, it would then probably look like this?


  


Thinking a little bit about it, it would not be a 1:1 replacement of
some_tag:check_date=2019-09-04 because check_date is usually used for
when something has been checked on-site (survey). A timestamp on a tag
just records "a" change. That could have been a mechanical edit, like
for example the recent change of http:// urls to https:// urls where
possible. Though I guess this would be good enough, it may be worth a
thought whether to also include the source field of the linked changeset
in the tag xml.

I reckon a difficulty for implementing something like this would be the
issue of "touching" elements in order to update their timestamp. I think
this may be possible already with the current API, but what is really
missing would be the possibility to "touch" certain tags only - only the
tags that one checked but didn't change because there was no change
required.

Cheers
Tobias


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

[Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Zwick]

Hello everyone

As you may or may not know, my microgrant proposal "Map maintenance with
StreetComplete" [1] was selected to be funded by the OSMF. So, I am
happy to have the oppurtunity to invest the time  extending the app,
hoping that it will help to keep the map up-to-date and unburden people
and communities invested in that topic.

I am pitching this here because there are three details on which I would
like to hear your input. Two of these are about tagging.

But first, how will it work?


So, what StreetComplete will do is to scan the map for whether certain
properties (tags) of map features haven't been surveyed for a certain
time. If this is the case, users will be prompted to answer the question
for that property again. For example, if the app ascertained that the
smoothness of a road hasn't been changed for 5 years, it would ask users
again about the smoothness of the road.

Challenges
--

Now, you might imagine that this is not so straightforward to implement,
and you would be right, for several reasons:

Firstly, the OSM API has no notion about when a particular property of
an element has last been changed, only for when the whole element has
last been changed. But elements are changed all the time for various
reasons. Roads for example tend to be changed especially often, splitted
up to accomodate bus routes, turn restrictions, when detailing
intersections, etc.

Secondly, there is only the date of the last change, but that doesn't
mean that is the date of the last survey. Even though that would be the
information we are interested in: when has the element last been checked
on-site?

Thirdly, the OSM API does not offer users to record solely that they
checked something and that it is still up to date. Any new record in OSM
must always come with a tagging change.

Solutions
-

In the absence of direct API support, fortunately the community came up
with a solution: Add the check_date tag to the element that has been
checked on a survey - or with the namespace if it concerns only a
certain tag of a map feature.

This works well and is actually already used by Streetcomplete in the
"Is this construction site finished?"-quest:
If the element as a whole hasn't been changed for 6 months *or* the
check_date key is present and its value is older than 6 months, the
quest is eligible to be asked again. When the user answers the question,
the check_date is set to current date.

Your input
==

Now here is where I would like your input:

1. Use check_date:smoothness or smoothness:check_date?
--
check_date with a namespace isn't used all that often yet, both variants
are used and thus there is no real winner yet. What variant do you
prefer and why? And most importantly, which variant would be most
consistent with existing tagging practices?

2. Always record check_date or avoid tagging it where not absolutely
necessary?
---
If something is resurveyed and it is acknowledged that nothing changed,
it is absolutely necessary to tag check_date. If something changed, it
is not strictly necessary because that the element changed as a whole is
itself also recorded.
But as already mentioned, elements can and do change all the time. One
can not assume that if an element has been changed that it has been
checked on-site. And even if one could, maybe not all the things were
checked but for example only the bus route relation, or maybe only the
presence of a sidewalk, or someone made the way a little more detailed etc.

The topic whether StreetComplete should only tag the minimum of what is
necessary to ensure functionality or always tag check_date (at least for
properties that are eligible for re-survey) was already subject to
discussion in the issue tracker here:
https://github.com/westnordost/StreetComplete/issues/1836

Maybe it is obvious that my opinion is that StreetComplete should always
tag check_date as it also adds valuable information for other surveyors
that do not use StreetComplete. Nevertheless, in the GitHub ticket
linked above, I played a bit of a devils advocate for the other point of
view - for being frugal with such meta-tags.

So, I'd like to collect what are the advantages and drawabacks of adding
check_date to all the tags surveyed on-site, with your help.

3. At what intervals should questions be asked?
---
Certain properties can be expected to usually not change in tangible
amount of time. For example, properties such as the structure of a
bridge, the levels and roof shape of buildings, street names and
housenumbers don't or change so infrequently that it is not worth
sending users every once in a blue moon to re-check the data. Others
will change more frequently, such as the smoothness of roads and ways or
anything related to businesses as they close and other shops open in

Re: [Tagging] Discourage use of landuse=churchyard?

[Tobias Zwick]

It could be useful to check (at random) how the tag is currently used - as 
synonym for graveyard, or for religious or both, at times (-> tag is ambiguos) 
and put that info in the wiki as well.

If it's both as you suspect, it's a very good reason to point to the other tags 
instead.

Tobias 

Am 23. Dezember 2019 06:27:55 MEZ schrieb Joseph Eisenberg 
:
>The tag landuse=churchyard has been used several thousand times, but
>amenity=graveyard is over 10 times more common, and landuse=religious
>is 4 times more common.
>
>I would recommend discouraging use of this tag, because the wiki
>definition contradicts the plain-English meaning of churchyard, which
>is usually a graveyard (cemetry) or burial ground next to a church.
>
>The wiki page for landuse=churchyard claims "Used to map the area
>surrounding a christian church or chapel, particularly when this does
>not contain a graveyard" - this conflicts with the common English
>definition of the value.
>
>Cambridge Dictionary (UK):
>"an area of land around a church, where dead bodies are buried "
>
>Merriam-Webster (US):
>"a yard that belongs to a church and is often used as a burial ground."
>
>To avoid ambiguity, mappers can use the two well-accepted tags
>landuse=religious + religion=christian
>OR
>amenity=graveyard + religion=christian, depending on the situation.
>
>I would like to update the wiki page for landuse=churchyard to suggest
>not using the tag and changing to one of the other two tags +
>religion=christian instead.
>
>- Joseph Eisenberg
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Tagging of bicycle anti-features

[Tobias Zwick]

We know how to tag certain bicycle features such as the "advanced stop line" [1]

It would be interesting to tag also anti-features. Most commonly, a cycleway 
that just ends  without merging it back onto the street. Currently, such a 
situation would be tagged the same as a track that is merged correctly onto the 
road. This situation is especially hindering if combined with cars parking 
closely to each other on the sides of the road.

How could this be tagged, for cycleways mapped on the road-way? Any suggestions 
how a tag for this could be named?

Greetings
Tobias

[1] https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl

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

Re: [Tagging] How to tag pedestrian lanes?

[Tobias Zwick]

Shoulders are a common feature on many roads. And the tagging for this is 
already established. Maybe a different way to tag kerb-less sidewalks thus 
would then be 

shoulder=right
shoulder:right:access=foot
(or access no and ...:foot=designated?)
shoulder:right:width=1

Though, in regards of software support,  I  my earlier suggestion is better, as 
no modification on existing software is necessary to understand that a sidewalk 
without kerb is still for pedestrians and used the same as a sidewalk, 
regardless of whether in (Oxford) English, one may or may not call this thing 
"sidewalk".

 (Existing) software will treat shoulders primarily as a feature relevant for 
cars.

Tobias 

On October 21, 2019 9:40:03 AM GMT+02:00, Joseph Eisenberg 
 wrote:
>“Sidewalk” is North American English, but it’s used because the
>British term is “pavement”, which is confusing due to its dual
>meaning. As a North American I would expect it to be separated from
>the road by a curb (kerb) or a strip of grass.
>
>Oxford dictionaries definition, Pavement:
>"1. British A raised paved or asphalted path for pedestrians at the
>side of a road.
>- ‘he fell and hit his head on the pavement’
>- North American term:   sidewalk"
>https://www.lexico.com/en/definition/pavement
>
>Wikipedia claims:
>"... normally separated from the vehicular section by a curb. There
>may also be a median strip or road verge (a strip of vegetation..."
>https://en.wikipedia.org/wiki/Sidewalk
>
>These definitions fit my impression, as an American, that a "sidewalk"
>is a separate feature, not part of the same paved road surface as the
>main lanes of the highway.
>
>If there's just a painted line, we would normally call the space
>between the line and the edge of the asphalt "the shoulder" of the
>road in a rural area, or it can also be a "bike lane" if it's wide
>enough and there are certain markings.
>
>So I'm in favor of a new key like pedestrian_lane=right/left/both,
>rather than calling these a type of sidewalk
>
>- Joseph Eisenberg
>
>On Mon, Oct 21, 2019 at 3:51 PM Mateusz Konieczny
> wrote:
>>
>> 20 Oct 2019, 19:08 by selfishseaho...@gmail.com:
>>>
>>> On Sun, 20 Oct 2019 at 12:42, Tobias Zwick 
>wrote:
>>>>
>>>>
>>>> How about:
>>>>
>>>> sidewalk=right
>>>> sidewalk:right:kerb=no
>>>
>>>
>>> I dislike using these tags for pedestrian lanes for the following
>>> reasons (sorry if i repeat myself):
>>>
>>> * It doesn't make sense: if it doesn't have a kerb (or any other
>>> physical barrier) it isn't a sidewalk.
>>
>> I am curious about opinion of a native speaker
>> of British English.
>>
>> Are you maybe one?
>>
>> (Sorry for poor phrasing here,
>> I tried to make it less aggressive and failed)
>>>
>>> * Blind people are able to make out a sidewalk, but not a pedestrian
>lane.
>>
>> No one argues against tagging this info.
>> We only disagree how it should be tagged.
>>>
>>> * It's misleading: Data users may not know the tag
>>> sidewalk:right:kerb=no and thus may make wrong assumptions. For
>>> example, a navigation application may guide a pedestrian along a
>route
>>> with only pedestrian lanes instead of safer route with sidewalks.
>>
>> And with a new incompatible tag
>> routing software may guide along
>> road without even such lane, instead of
>> using route where at least pedestrian
>> lanes are present.
>>
>> In both cases routing software would
>> benefit from an upgrade.
>>>
>>>
>>> * pedestrian_lane= is simpler for mappers and data
>users.
>>
>> Depends on whatever you consider
>> it as a low quality sidewalk or
>> a separate feature.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>On 10/21/19, Martin Koppenhoefer  wrote:
>>
>>
>> sent from a phone
>>
>>> On 21. Oct 2019, at 08:51, Mateusz Konieczny
>
>>> wrote:
>>>
>>> I am curious about opinion of a native speaker
>>> of British English.
>>
>>
>> while I am not, I’m pretty sure the British term is pavement, not
>sidewalk
>> (for the kerb separated way, no idea about the marking separated way)
>>
>> We had deliberately chosen the word sidewalk for OpenStreetMap
>tagging
>> because of the ambiguity of ”pavement “
>>
>> Cheers Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] How to tag pedestrian lanes?

[Tobias Zwick]

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 

The most important thing is to tag whether there is a sidewalk or not. 
Regardless of whether it has a keen or not.

According to taginfo, sidewalk:right:kerb is already used a few times:
https://taginfo.openstreetmap.org/keys/sidewalk%3Aright%3Akerb#overview

Tobias 

On October 20, 2019 8:39:14 AM GMT+02:00, John Willis via Tagging 
 wrote:
>
>
>> On Oct 20, 2019, at 4:44 AM, Markus 
>wrote:
>> 
>> However i think that a sidewalk requires a physical separation to the
>> roadway
>
>
>I agree with you, and I tag all separated standard sidewalks as
>“sidewalks” (iD preset).
>
>however, there are a lot of narrow roads in Japan where the side of the
>road (between the white lane border line and the barrier wall along the
>road) is painted with a (thin) green stripe, and is considered a
>pedestrian path - usually around schools where children walk. The
>infrastructure in the area is very old, and they cannot widen the roads
>to be safer, so they paint the green line on to remind drivers to be
>safe and keep the pedestrians on one side. this is only around schools
>with narrow roads. New roads all have separated sidewalks, so no
>painted area is necessary. 
>
>I tag the green line as a highway=path and add a note=* to the way. 
>
>One example I have seen is much larger, and is a new “lane” created by
>converting a 2-way road to 1-way and giving the margin to pedestrians. 
>https://www.openstreetmap.org/way/667338935
>.
>
>I do not think this is ideal, but it does properly map the marking and
>the routing that should be used for pedestrians. usually many roads in
>the area are narrow, and the designated way is best. 
>
>If some method is standardized, I will correct my mapping. 
>
>Note: these are not the blue cycle-lanes or cycle arrows in the road
>found on many narrow high traffic roads. 
>
>
>Javbw

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

Re: [Tagging] Guard booth building type

[Tobias Zwick]

How about porters_lodge, it's more general. It would cover the small building 
at the entrance of outdoor pools where you buy the tickets, same for other 
outdoor venues, the booth at the entrance of company/factory grounds, the guard 
booth at the entrance of gated communities etc.

Not sure if this word is common in English, I just looked up the translation of 
the German word for that.

Tobias 

On October 7, 2019 3:38:17 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Mo., 7. Okt. 2019 um 09:09 Uhr schrieb Mateusz Konieczny <
>matkoni...@tutanota.com>:
>
>> What would be the best tagging for guard booth minibuildings?
>>
>> I think that building=guard_booth would be the best one for objects
>> constructed
>> as guard booth.
>>
>
>
>I agree on the selection of building for the key, but the word "guard"
>may
>be too restrictive or misleading. There are many similar structures
>used
>for similar purposes, e.g. staffed by a "porter" or "gate keeper" or
>"janitor" (?) (someone who opens for example a lift gate), which would
>not
>be covered by this term. In my area there are also many similar
>structures
>placed mainly at big crossings, which are sometimes staffed by
>policemen
>(I'm not completely sure if they can control the traffic lights, but I
>guess not, because when chaotic situations occur they step out of the
>enclosement, put the whistle and in the mouth and regulate the traffic
>in
>person). The latter have a writing on them "municipal police", I would
>not
>consider them guard houses (although they look the same), these are
>typically airconditioned and will be locked when they leave.
>
>There's also a not so well known key (but still has more than 1000 uses
>as
>of now) to be added as a property to barriers:
>https://wiki.openstreetmap.org/wiki/Key:barrier:personnel
>(it is physically a different feature, but functionally very similar).
>
>And there's a proposal for extending surveillance which has a
>(functionally) similar property:
>https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_tags_for_Key:Surveillance#Guard
>
>Looking at taginfo, I also found security_guard=no/yes (no is by far
>more
>used)
>https://taginfo.openstreetmap.org/keys/security_guard
>
>and guarded=yes/nighttime/yes/daytime/...
>https://taginfo.openstreetmap.org/keys/guarded
>
>both of these are currently around 250 uses globally, and far from
>reaching
>"supervised=*" (200K uses)
>
>I wonder if the tag would also be suitable for "temporary" structures
>like
>tents, which may not always be as temporary as they look. For example
>there
>are such tents set up in Rome since the government decided to put armed
>forces in front of embassies, and this is a situation that goes on for
>many
>years, one example can be seen here in the background on the right:
>https://www.mapillary.com/app/?lat=41.87225687537841&lng=12.496776313017108&z=17&pKey=2L3AoKjXelz-CEG5Z4JBQg&focus=photo&x=0.5120040767123977&y=0.5725924352245725&zoom=0
>
>Cheers,
>Martin

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Tobias Zwick]

Milestones are not necessarily located at the true distance of A to B. Not sure 
why this is the case, but I know that this is true for at least Thailand. 

On 01/10/2019 21:10, Paul Allen wrote:
> On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre  > wrote:
> 
> The addresses that utilize ‘Km’ as part of the actual address are always 
> related to a specific 'highway:milestone’ on that particular highway. For 
> instance, the address for the Hilton Guatemala Vista Real Hotel in Guatemala 
> - as it appears on their official website: 
> [https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html]
>  - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City, 01015’. What 
> this means is the location is 500 meters from where the 'highway:milestone=9’ 
> on that particular ‘CA-1 East’ highway...
> 
> 
> I think we're close to hitting the record for how misleading a tag name can 
> be.
> 
> This is a proposal for a tag addr:milestone to allow us to specify a distance 
> in kilometres
> (not miles), of a house (not a milestone) and the nearest milestone isn't a 
> stone but a sign.
> If the locals call the road markers (marked in kilometres and which are not 
> stones)
> milestones then there is some slight justification for addr:milestone.  But 
> only slight,
> because the address doesn't give the nearest "milestone" but a distance along 
> a road.
> 
> If I understand you correctly, this is actually a distance along a particular 
> highway.  A distance
> from where, exactly?  A highway has two ends, and there may be a milestone 
> (that is neither
> a stone, nor marked in miles) 9km from each end.  I assume that since the 
> address
> is in Guatemala City, that would be what is used for addr:city; I also assume 
> that since
> the street is CA-1 East, that would be what is used for addr:street.  
> Therefore the only
> other thing required would be addr:distance to specify the distance from 
> addr:city
> along addr:street.
> 
> Unless the locals call road markers "milestones" and think of the "9.5km" in 
> terms of
> milestones, addr:milestone is a horrific misnomer and addr:distance better.
> 
> -- 
> Paul
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] Tagging meadow orchards

[Tobias Zwick]

Hey there

What is the best way to tag meadow orchards?

Most orchards are plantations with monocultures of one kind of tree, usually 
planted in rows and pruned to have a short trunk for easier picking.

There is another type of orchard, in German "Streuobstwiese", in English I 
think "meadow orchard" or "meadow with fruit trees". This orchard has many 
different types of fruit trees scattered all over the meadow. The trees are 
usually not pruned. The meadow serves multiple purposes: As a meadow and as an 
orchard.
(Nowadays) meadow orchards are less common, because they are less accessible to 
machines for hay harvest and less convenient to harvest the fruit.

Show the meadow orchard be 

a) an own tag, like landuse=meadow_orchard?

b) a subtag of landuse=orchard? Maybe orchard=meadow/plantation?

c) or should the "meadow orchard" be a landuse=meadow with every single fruit 
tree added separately? (Well, I suppose it could in any case, but that's quite 
a micromapping solution)

What do you think?

Tobias

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

Re: [Tagging] oneway street with two combined foot-cycle lanes

[Tobias Zwick]

Hi Volker 

The full tagging here would be:

oneway = yes 
oneway:bicycle = no  <- oneway not for bicyclists
sidewalk = both  <- there is a sidewalk on both sides
cycleway = track...which is also a cycleway and
cycleway:segregated = no...not segregated 

Because the unsegregated foot+cycleway is really slim, it'd be useful to also 
record the width of the sidewalk/cycleway in

cycleway:width = X

Greetings
Tobias


On 16/09/2019 21:29, Volker Schmidt wrote:
> How to tag a
> oneway street with a combined foot-cycle lanes on either side with oneway 
> restrictions for bicycles.
> To understand my description you need to look at the photo:
> 
> http://www.mapillary.com/map/im/ndVXZQlQxoTi_678lWXc9A/photo
> 
> 
> Thanks in advance
> 
> Volker
> 
> 
> 
>  Virus-free. www.avast.com 
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] lanes = 0

[Tobias Zwick]

Also, the mention of that lanes key (should) only be used to denote the number 
of MARKED lanes was added in 2017 after a short discussion in the German forum 
about the same topic.

However, in this topic here on the ML, arguments were brought forth that made 
us get to a different conclusion (the one documented in the wiki, see recent 
change history) which is why I consider the decision reached in 2017 (to only 
include marked lanes) obsolete.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

Re: [Tagging] lanes = 0

[Tobias Zwick]

This topic again? We had this just a few weeks back and we actually reached to 
a conclusion that lanes=0 should NOT be used to denote that there are no marked 
lanes.

I believe I also documented that conclusion on the wiki, prompting here for 
review.

Tobias 

On July 30, 2019 1:19:32 PM GMT+02:00, Martin Koppenhoefer 
 wrote:
>Am Di., 30. Juli 2019 um 12:32 Uhr schrieb Jérôme Seigneuret <
>jerome.seigneu...@gmail.com>:
>
>> Please don't use lanes=0. That don't make sense!
>>
>
>
>if lanes is about the total amount of marked "2-tracked-vehicle"-lanes
>(as
>it is according to my understanding), then lanes=0 means no marked
>lanes.
>
>Cheers,
>Martin

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

Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

[Tobias Zwick]

Sounds to me that those pages were incorrectly deleted. Only because someone 
can tag the abandonedness of a single tag of a feature, doesn't mean that the 
tag that applies to the whole feature is deprecated.

Actually, sine best practice is to map each feature as an own element (unless 
maybe both features encompass the whole element, i.e. a building), the plain 
non-namespace tag would probably be used in the vast majority of cases.

Even in cases where two or more features encompass the whole object, I can't 
really think of a use case where the namespacing made sense: For example a 
disused hotel in a stately building may be mapped on one element, but then, 
wouldn't the whole building not also be diused?

Tobias 

On July 29, 2019 8:23:42 AM GMT+02:00, Joseph Eisenberg 
 wrote:
>I was going to fix the status of abandoned=yes which is currently
>incorrectly listed as "obsolete". I thought it was probably
>deprecated, since the wiki page was deleted when Key:abandoned:*
>(namespaced) was made in 2015, but it's still used 40,000 times.
>
>The key disused (mainly disused=yes) is also used 60,000 times, even
>though the situation is the same: no wiki page, and the Key:disused:
>page suggests it is deprecated.
>
>Should these two be added to deprecated features, or should I recreate
>the deleted pages and change the status to something other than
>obsolete/deprecated?
>
>I see that there was just a mention added that landuse=quarry plus
>disused=yes might be more sensible than disused:landuse=quarry.
>
>Joseph
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] New page "Approval status" for "de facto", "in use", "approved" etc

[Tobias Zwick]

One or several wiki edits should stand at the end of every tagging discussion, 
to document the conclusions made.

Tobias 

On July 29, 2019 8:37:25 AM GMT+02:00, Warin <61sundow...@gmail.com> wrote:
>Err .. sent to tagging list, so response here. Not to worry, a little
>more chatter.
>(Should there be a wiki edit list? Or would 'we' all then have to join
>that well as the tagging list? Anyone not want to be part of the
>discussions on wiki edits possibly of relevance to tagging? )
>
>On 29/07/19 16:13, Joseph Eisenberg wrote:
>
>> (Not sent to tagging list)
>>
>> I think the idea was that a tree with a proper name is an important /
>> landmark tree?
>>
>> Perhaps you crazy Europeans name your special trees, eg King George's
>Oak?
>>
>> The other suggestion was to use "landmark=yes" but this key is also
>> not recommended. Someone needs to check how denotation=cluster is
>> actually used now days.
>
>Correct. I looked it up.  :)
>
>The key denotation is meant for special trees .. see
>https://wiki.openstreetmap.org/wiki/Key:denotation
>
>So I have changed the wiki again . to simply direct 'special tree'
>tagging to that page.
>https://wiki.openstreetmap.org/wiki/Tag:denotation%3Dcluster
>
>If people want to mention names .. the denotation page would be the
>better place for it.
>
>>
>> Joseph
>>
>> On 7/29/19, Warin <61sundow...@gmail.com> wrote:
>>> On 29/07/19 15:26, Joseph Eisenberg wrote:
 I've edited the page:

 1) I reworded some of the helpful changes that Mateusz Konieczny
>just
 made, for better English style.

 2) I've removed the implication that de facto / approved are
 "recommended" and that "deprecated" / "discardable" etc. are "not
 recommended".

 I also removed the suggestion that "de facto" tags are supported by
 rendering / routing / editing software - while this is usually
>true,
 it isn't what determines if a tag is given "de facto" status.

 3) I removed "obsolete" status from the list with
>deprecated/discouraged.

 However, I now think I figured out what this status is supposed to
 mean: it's supposed to be used for tags that were deprecated, but
>now
 no longer even appear in the database, so the wiki page is only for
 historical information.

 Do we really need a special status for this, or should is it ok if
>I
 retag the 6 tags with this status to "deprecated"?


>https://wiki.openstreetmap.org/wiki/Category:Tag_descriptions_with_status_%22obsolete%22

 - Tag:abandoned=yes - recommended replacement abandoned:*=* - used
>34,000
 times
 - Tag:amenity=Kneippbecken - approved replacement is
 amenity=kneipp_water_cure - used 0 times
 - Tag:man_made=power_hydro / Tag:man_made=power_nuclear /
 Tag:man_made=power_wind - use  power=generator, generator:source=*
 instead - used a couple of times only.
 - Tag:denotation=cluster - for special trees. Recommend to use
>name=*
 instead with natural=tree. Had been down to 0 uses at one point,
>but
 now there are a few hundred?
>>> Gah! use name=* for something other than the name? No. Use the
>description
>>> key for that.
>>> Edited wiki to remove this suggestion.
>>>
 So only amenity=Kneippbecken and man_made=power_* really fit the
 "obsolete" status, though there are a number of tags currently with
 "deprecated" that are also no longer found in the database.

>>> Once something has been 'depreciated' but now has little to no
>presence then
>>> 'obsolete' is a good status for it.
>>>
>>>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] shop=window(s) incorrectly deprecated in favor of craft=window_construction ?

[Tobias Zwick]

I always thought that there is no norm for standard sizes of windows, so every 
window is made to measure. (And in case of a larger construction project, then 
1000s of windows are made with the same measure)
Is this not true after all?

Tobias 

On July 9, 2019 4:54:59 PM GMT+02:00, ael via Tagging 
 wrote:
>On Tue, Jul 09, 2019 at 04:03:35PM +0200, Martin Koppenhoefer wrote:
>> 
>> like in only selling, not fitting/mounting them? Not offering to
>replace the glass, etc.? Can you go there to buy a window, and take it
>away, or will you order a window or maybe the whole facade which will
>then be produced and delivered to you? 
>> 
>> While a shop like this may exist, I must admit I have never seen it.
>Can you refer to a real example?
>
>Several in my area in UK. 
>
>ael
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

Ok, it seems that "unladen" is somewhat favoured here on the list because it is 
more precise, more common and conforms with the wording in the (UK) legislation.

I'll change the one mention in the wiki of "maxemptyweight" to 
"maxunladenweight".

Cheers
Tobias

On 06/07/2019 14:17, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 6. Jul 2019, at 12:53, Tobias Zwick  wrote:
>>
>> So "unladen" is the word used in UK legislation? Do you have a link?
>> Even if "unladen" is most commonly used in UK, I still find "empty" better 
>> because it is easier to understand what it means for non native speakers 
>> (simpler word).
> 
> 
> to me unladen seems more specific (I am not a native speaker of course), 
> empty could mean more things (seats removed? No gasoline in the tank?) 
> although I agree unladen also leaves it open whether it is with petrol or 
> without.
> 
> Ciao, 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] lit=yes/no threshold

[Tobias Zwick]

> I am trying to make lit=yes/no definition more precise

I think that your suggestions would make the definition actually less precise 
because they add a fair level of subjectiveness: "necessary to bring your own 
light"

The least subjective definition is to map the physical presence of street 
lanterns on the way, not the light they emit. (This definition (though) would 
mean that a footway close to a lit street would be mapped as unlit as long as 
it does not have own lanterns.)

Tobias 

On July 6, 2019 12:24:18 PM GMT+02:00, Mateusz Konieczny 
 wrote:
>Some cases of lit=yes are clear (direct lighting of street/footway by
>lamps)
>
>Some cases of lit=no are clear (no lighting whatsoever)
>
>But in cities there is also often strong or weak ambient light, for
>example:
>
>- carriageway is directly lit with so powerful light that spillover
>light
>makes footway well lit - clearly lit=yes
>
>- spillover light is quite dim but enough to comfortably walk - also
>lit=yes
>
>- there is some ambient light, but not enough to walk without own
>source of light - lit=no
>
>- there is an ambient light, one can carefully walk, but only slowly,
>people with poor eyesight needs their own source of light - lit=no (?)
>
>Overall, I am considering adding to
>https://wiki.openstreetmap.org/wiki/Key:lit
>
>recommendation to consider "is it necessary to bring your own light
>source to see it properly"
>as recommended threshold for footways/paths.
>
>Any problems with that or ideas for a better threshold between lit=yes
>and lit=no?
>
>disclaimer: I am trying to make lit=yes/no definition more precise as
>part of my grant
>https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.

Are you absolutely sure about this?

I am pretty sure myself that hgv are defined differently: as goods vehicles 
with a "gross vehicle weight rating" (gvwr), a.k.a. "gross vehicle mass" (gvm) 
or plainly said maximum laden weight above 3.5t

...  and also documented it this way on the Key:hgv page

Tobias

On July 6, 2019 1:38:34 PM GMT+02:00, Philip Barnes  
wrote:
>
>
>On Saturday, 6 July 2019, Warin wrote:
>> On 06/07/19 19:46, Colin Smale wrote:
>> >
>> > On 2019-07-06 10:48, Warin wrote:
>> >
>> >> On 06/07/19 18:16, Colin Smale wrote:
>> >>>
>> >>> On 2019-07-06 05:03, Warin wrote:
>> >>>
>> >>> On 05/07/19 19:33, Mateusz Konieczny wrote:
>> >>>
>> >>> 3 Jul 2019, 12:52 by o...@westnordost.de:
>> >>>
>> >>> 1.1 At the examples: for max empty weight, I propose
>the
>> >>> key maxemptyweight. It suggests itself.
>> >>>
>> >>> Added, with link back to this post
>> >>>
>> >>>
>> >>> Here that would be called "maximum Tare weight". In the UK? 
>> >>>
>> >>> Probably "maximum unladen weight." "Tare" does exist as a word,
>and 
>> >>> is frequently used in logistics (empty weight of containers etc)
>but 
>> >>> AFAIK not in the context of traffic regulations.
>> >>>
>> >>
>> >> Possibly not where you are.. but
>> >>
>> >> "registrable light motor vehicle means a motor vehicle that is 
>> >> registrable and has a tare mass that is not greater than 2,794 
>> >> kilograms."
>> >>
>> >> From
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>> >>
>> >> And also in other traffic legislation in Australia...
>> >>
>> >> In the UK?
>> >>
>> >> "(h)the manner in which the tare weight of road vehicles, or of
>road 
>> >> vehicles of any particular class or description is to be
>determined. "
>> >> from https://www.legislation.gov.uk/ukpga/1985/72
>> >>
>> >>
>> > That is not a traffic regulation, that's about metrology. And by
>the 
>> > way, I am speaking as a Brit, so native speaker and somewhat 
>> > conversant with the laws and legal system. As I said, the word
>"tare" 
>> > does exist, and is used in certain specific contexts. But in 
>> > connection with road vehicles, everybody in the UK speaks of
>Unladen 
>> > Weight.
>> >
>> > https://www.gov.uk/vehicle-weights-explained
>> >
>> 
>> Ok.
>> Here trucks have small signs on there side, they state the tare
>weight 
>> and gvw. I think these are used to confirm the vehicle is not
>overloaded 
>> when inspected (we have both mobile and stationary testing).
>> Also tare is used to specify the maximum tare weight of a trailer
>that 
>> inexperienced drivers can use, and that is a road regulation. It may 
>> also be used for other things.
>> A fairly common term here.
>> 
>> -
>> Further nit picking..
>> The "Unladen weight" is usually done without fuel but in all other
>ways 
>> ready for the road -i.e. includes spare tyre/s, tools, battery,
>coolant, 
>> oil etc etc. ???
>> I think some manufactures sales brochures quote figures without some
>of 
>> these to make it appear that they have greater load carrying
>capabilities.
>> Again this may vary from place to place around the world.
>> 
>> 
>> I would be happy with "unladen weight" rather than "empty weight".
>> As for "maximum" .. I would use "limit" similar to the use of "speed 
>> limit". So it would become "unladen weight limit".
>> 
>> I don't think I have ever seen a sign limiting the unladen weight ..
>it 
>> is always a limit on the total weight that the structure is rated
>for.
>> So I don't think there is much point in discussing it? At least not
>from 
>> my limited knowledge.
>>
>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.
>
>It has nothing to do with structures, it is to prevent heavy goods
>vehicles taking short cuts through residential areas.
>
>It only apples to goods vehicles, as you need buses to have access.
>
>Phil (trigpoint)

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

So "unladen" is the word used in UK legislation? Do you have a link?
Even if "unladen" is most commonly used in UK, I still find "empty" better 
because it is easier to understand what it means for non native speakers 
(simpler word).

In the US, "empty" seems to be most commonly used, as it is also written on the 
signs while at the same time, the word is not exclusively known/used in the US 
- unlike mall, freeway, etc.

"maxbogieweight" caused confusion earlier and was misunderstood as synonymous 
to "maxaxleload" recently. "maxemptyweight" I think does not need documentation 
to clarify what it stands for, "maxunladenweight" might.

In the end, UK naming should usually win, but maybe "empty vehicle weight" does 
not sound so exotic to British ears?

Tobias

On July 6, 2019 11:46:33 AM GMT+02:00, Colin Smale  
wrote:
>On 2019-07-06 10:48, Warin wrote:
>
>> On 06/07/19 18:16, Colin Smale wrote: 
>> 
>> On 2019-07-06 05:03, Warin wrote: 
>> On 05/07/19 19:33, Mateusz Konieczny wrote: 
>> 3 Jul 2019, 12:52 by o...@westnordost.de: 
>> 1.1 At the examples: for max empty weight, I propose the key
>maxemptyweight. It suggests itself. 
>> Added, with link back to this post
>
>Here that would be called "maximum Tare weight". In the UK? 
>
>Probably "maximum unladen weight." "Tare" does exist as a word, and is
>frequently used in logistics (empty weight of containers etc) but AFAIK
>not in the context of traffic regulations. 
>Possibly not where you are.. but 
>
>"registrable light motor vehicle means a motor vehicle that is
>registrable and has a tare mass that is not greater than 2,794
>kilograms." 
>
>From  
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>
>And also in other traffic legislation in Australia... 
>
>In the UK?
>
>"(h)the manner in which the tare weight of road vehicles, or of road
>vehicles of any particular class or description is to be determined. "
>from https://www.legislation.gov.uk/ukpga/1985/72 
>
>That is not a traffic regulation, that's about metrology. And by the
>way, I am speaking as a Brit, so native speaker and somewhat conversant
>with the laws and legal system. As I said, the word "tare" does exist,
>and is used in certain specific contexts. But in connection with road
>vehicles, everybody in the UK speaks of Unladen Weight. 
>
>https://www.gov.uk/vehicle-weights-explained

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

Reviewed it. That is some impressive work, thank you for this!

A few remarks:

1. Maxweight

1.1 At the examples: for max empty weight, I propose the key maxemptyweight. It 
suggests itself.

1.2 At the examples: Conditionals should maybe better be catch-all, so i.e. 
axles>=3 instead of axles=3

2. Maxweightrating:

2.1 At the examples, Poland: This sign is actually an access restriction for 
all HGVs: hgv=no. By definition in EU laws and most other countries, a heavy 
goods vehicle is a goods vehicle with a GVWR of 3.5t and above. See the wiki 
page for Key:hgv for a longer explanation.

3. Maxaxleload mentions that weight in USA must always be given in short tons 
while the maxweight article also mentions pounds. Same with the article about 
maxbogieweight.

4. Maxbogieweight in Romania: I'd say a tri-axle is still a bogie.

Tobias 🌴


On July 3, 2019 9:43:12 AM GMT+01:00, Mateusz Konieczny 
 wrote:
>There were recently significant changes at OSM Wiki page about
>maxweight tag
>and related tags. Review is welcomed.
>
>See
>https://wiki.openstreetmap.org/wiki/Key:maxweight
> - major changes
>included fixing mistakes
>in examples, adding additional examples, reformatting, documenting how
>object without max weight
>sign may be tagged
>
>https://wiki.openstreetmap.org/wiki/Key:maxweightrating
> - page itself
>is quite new. Recent changes
>included reformatting and new examples
>
>https://wiki.openstreetmap.org/wiki/Key:maxaxleload
> - smaller
>changes, but for completeness:
>fixing mistake and additional examples
>
>Again, review is welcomed!

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

Re: [Tagging] New sections added to "Good Practice" page?

[Tobias Zwick]

Maybe mobile-but-usually-stationary (or with a fixed schedule) amenities and 
shops could get an extra tag to denote that property. For example mobile=yes or 
something.
POIs with this tag set could be resurveyed more often than others.

Tobias 

On July 1, 2019 11:15:32 AM GMT+01:00, Paul Allen  wrote:
>On Mon, 1 Jul 2019 at 09:49, Martin Koppenhoefer
>
>wrote:
>
>>
>> For example there are boats used as restaurants, they could move, but
>they
>> don’t (in some instances at least).
>
>
>Got one of those near me.  I've mapped it.
>
>
>> Or mobile fruit or ice cream vendors, which may be there only during
>the
>> daytime, but will be there every day.
>>
>
>Or mobile food vendors who have a fixed spot but take the trailer home
>at
>night.  Got two of those
>near me, and I've mapped them.  There used to be three, but one of them
>upgraded from a
>mobile vehicle to a building.
>
>Or a mobile butcher serving small communities and visits each community
>on
>a fixed day of the
>week at a fixed time.  Got one of those near me, but I've not mapped it
>(can't find his schedule).
>
>Or mobile banks.  Got several of those near me.  They're in each
>village
>for a couple of hours one
>day a week.
>
>Or mobile libraries.  Similar deal to the mobile banks.
>
>Or a ticket office for boat trips.  It's a trailer in a fixed location
>and
>remains there overnight but
>is only present during the tourist season.  Got one of those near me.
>
>Generally it doesn’t seem a good idea to add stuff to the „good
>practice“
>> page at this stage, without consulting with the wider community
>before.
>>
>
>I've altered the "good practice" page to state that it should not be
>changed without consulting
>the wider community.  Joking.

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

Re: [Tagging] paid ferry - fee or toll tag

[Tobias Zwick]

Colin Smale, this is a very wise thing to say. I think this is often a missing 
element in tagging discussions.

Is there a tagging suggestion guidelines page on the wiki? If yes, this is 
definitely one point that should be added. And if not,  maybe we (people on the 
mailing list) should create one: Not too set up rules, but just to get everyone 
on the same page regarding what a good tag design is.

On June 22, 2019 11:03:31 AM GMT+02:00, Colin Smale  
wrote:
>On 2019-06-22 10:38, bkil wrote:
>
>> If we step back a bit from our dictionaries, fee=* as a concept is
>> isomorphic to toll=* (and fare) in this context.
>
>Only insofar as they indicate that the user has to pay. "Toll" has a
>distinct meaning, in the UK at least, that it is (and needs to be)
>sanctioned by law. 
>
>> As all of them could
>> be understood by native speakers and fee=* covers a more general
>> category, it is clearly the better choice. If we consider our data
>> users, non-native speakers and learning curve, the less terms we use
>> in our vocabulary, the better.
>
>"As simple as possible, but not simpler". Attributed to Albert
>Einstein,
>and a philosophy I wholeheartedly embrace. If it is required to be able
>to make the distinction between a charge levied based on a legal
>sanction, and a charge simply levied by the owner because they feel
>like
>it, then the subtle difference between "toll" and the other words is
>significant. If we all agree that the distinction is not to be
>represented in OSM, then this discussion is moot - call it something
>neutral like payment, fee, charge, whatever. This process is called
>data
>modelling; the modelling aspect comes from the fact that you have to
>make compromises, and you have to choose which compromises to make
>according to what is important to you. Otherwise you are just
>replicating reality at full scale, which defeats the point of
>modelling.
>
>
>As this is OSM, it only takes one person to want to make this
>distinction to unchain interminable discussions... 
>
>> On Thu, Jun 20, 2019 at 11:20 AM Paul Allen 
>wrote:
>> On Thu, 20 Jun 2019 at 01:33, Warin <61sundow...@gmail.com> wrote:
>> The Oxford Dictionary says
>> 
>> Toll : A charge payable to use a bridge or road.
>> 
>> Yep.  Also, in the UK, carries legal implications.  Legislation is
>required to require tolls on a
>> public highway.
>> 
>> Fee : A payment made to a professional person or to a professional or
>public body in exchange for advice or services.
>> 
>> That's how I'd use it.  Of course, ferries provide a ferry service,
>so fee could be used.  But I'd go
>> with something else: fare.  We don't talk of rail tolls or rail fees,
>we talk of rail fares.  We don't talk
>> of air tolls or air fees, we talk of air fares.  From OED online:
>"The money paid for a journey on
>> public transport."
>> 
>> --
>> Paul
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] lanes = 0

[Tobias Zwick]

Okay, to wrap this up, I added this title in the wiki and referenced back to 
this discussion, advising to not use lanes=0/1.5/none to signify no lane 
markings but instead use something like lane_markings=no.

https://wiki.openstreetmap.org/wiki/Key:lanes#No_lane_markings

---

Additionally, I noted that after a similar discussion about lanes=1.5 in the 
German forum in 2017, the wiki page was changed to stress that the lanes-key is 
for *marked* traffic lanes. The change was announced on the Talk page and the 
German forum discussion linked there.

I did not change the formulation back but only added the outcome of this 
discussion to that topic on the Talk page because I do not feel legitimated to 
do that as the 2017 wiki change was also done only after discussion in the 
community, same as now:
https://wiki.openstreetmap.org/wiki/Talk:Key:lanes#No_centerline_-_one_or_two_lanes.3F

[1] https://forum.openstreetmap.org/viewtopic.php?pid=627975#p627975

On 15/06/2019 18:55, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 15. Jun 2019, at 01:10, Joseph Eisenberg  
>> wrote:
>>
>> This requirement is fine for Europe, but the presence of lane markings
>> is not reliable in all of the world.
>>
>> In developing countries, such as here in Indonesia, the presence of
>> painted lane markings is inconsistent. Often cheap pain is used
>> instead of more durable thermoplastic, so the markings only last a
>> year. After that the road still functions the same, even though the
>> markings are no longer visible.
>>
>> There are also sections of primary or trunk road that are at least 6
>> or 7 meters wide and freshly painted, but have not yet been marked and
>> may not be for a number of years. I tag these as lanes=2 because the
>> road is clearly wide enough for two lanes.
>>
>> And here in town the main road was recently marked with 2 lanes in
>> each direction, but before it already functioned as 4 lanes because
>> the width was sufficient.
>>
>> While tagging the width is useful, I believe tagging the presence of
>> "de facto" lanes is reasonable in developing countries and places
>> where painted lane markings are not frequently used.
> 
> 
> 
> This description is a perfect fit for the situation in central Italy as well, 
> not having marked lanes can happen on 2+2 roads for years and for many 
> kilometers. Often there are lane markings for some part of the road while 
> they are missing on others. Generally they are aiming at having lanes, but it 
> isn’t pursued with high priority ;-)
> I can understand the argument that lanes have to be painted in order to be 
> there, but it isn’t the reality I am observing.
> 
> We shouldn’t dismiss lane_markings=no as it can solve both cases: no lanes 
> marked but lanes=n is set, and no lanes tag set (confirmation the tag wasn’t 
> forgotten).
> 
> 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=cannabis including medical cannabis

[Tobias Zwick]

Wouldn't medical cannabis be sold in pharmacies?

On 14/06/2019 18:26, Jmapb wrote:
> An accepted answer to a recent question on help.openstreetmap.org (
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> ) suggested expanding the definition of shop=cannabis to include
> dispensaries for medical cannabis.
> 
> This makes sense to me, and the original discussion (
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> ) doesn't really give any clear reason for excluding medical cannabis
> shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> are proposed and not disputed.)
> 
> I'm inclined to go ahead and edit the shop=cannabis wiki page (also take
> out some of the verbiage... the history in Colorado is interesting but
> not really relevant to the map) but I'd first like to fish for
> objections. (Agreement also welcome!)
> 
> Thanks, Jason
> 
> 
> ___
> 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] lanes = 0

[Tobias Zwick via Tagging]

Ok so to recap. All fairly weak reasons (except 2) here, but let's find the 
best tag:

1. Allroads did not favour nolanes=yes because it is a double negative

2. lanes=no is not so good because there are people who estimate the lanes 
value if no markings are present (see ael's message). Adding "no" as a possible 
value that is to be applied when no visual markings are present would make a 
portion of the currently tagged lanes-tags wrong and thus would be a 
redefinition of the lanes key.

3. lane_marking=no has of the proposed tags the least semantic similarity to 
the lanes tag but on the other hand is used a few times already and is safe for 
the "_" instead of the ":" what Warin suggested

4. lanes:mark...=no would maybe imply that lanes=X must be tagged as well?

On 13/06/2019 15:15, Tobias Zwick wrote:
>> I think a tag to say "lane:marking=no" could be better for that situation???
> 
> 1. or lanes:marked=no? (mark_ed_ instead of mark_ing_)
> 
> Would be (more) consistent with the naming of opening_hours:signed, 
> collection_times:signed, (1k-2k usages each)
> 
> 2. or nolanes=yes?
> 
> Would be consistent with noname=yes, noaddress=yes, ...
> 
> 3. or lane_marking=no? I found this on taginfo, it has 90 usages. Personally, 
> I like either 1 or 2 better though.
> 
> Point 1 and your (Warin's) suggestion have the advantage that it semantically 
> refers to the lanes-key. Though on the other hand, would that imply that 
> lanes=X should always be tagged if lanes:marked=no is tagged?
> 
> Cheers
> Tobias
> 
> ___
> 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] lanes = 0

[Tobias Zwick]

> I think a tag to say "lane:marking=no" could be better for that situation???

1. or lanes:marked=no? (mark_ed_ instead of mark_ing_)

Would be (more) consistent with the naming of opening_hours:signed, 
collection_times:signed, (1k-2k usages each)

2. or nolanes=yes?

Would be consistent with noname=yes, noaddress=yes, ...

3. or lane_marking=no? I found this on taginfo, it has 90 usages. Personally, I 
like either 1 or 2 better though.

Point 1 and your (Warin's) suggestion have the advantage that it semantically 
refers to the lanes-key. Though on the other hand, would that imply that 
lanes=X should always be tagged if lanes:marked=no is tagged?

Cheers
Tobias

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

Re: [Tagging] lanes = 0

[Tobias Zwick]

> Here, legally, if there are no lane makings then it is considered to have one 
> lane in either direction.

I am kind of a fan of lanes=0, denoting that there are no marked lanes. Here is 
why:

a. if a road with no lane marking is tagged as lanes=2, this situation cannot 
be distinguished from a road with 2 lanes
b. if a road with no lane marking is tagged as lanes=1, this situation cannot 
be distinguished from a road with 1 marked lane (a oneway road?)

So, in both these cases, the tagging is not explicit.

But it is important to be able to make the distinction. Some reasons:

1. Verifiability: Clearly, "on the ground", a road with 2 lanes looks different 
from a road with no lanes. A famous example for even a very broad road that has 
no lanes is Place Charles-de-Gaulle in Paris [1]

2. Legal implications: As far as I know, there are legal implications for roads 
with no lanes. Depends on the country of course, two examples that come to my 
mind:

  2.1 In Germany, (afaik) it has implications when passing obstacles. If there 
are marked lanes, you can only cross into the other lane when it is free, while 
if there are no marked lanes, whoever reaches the obstacle first may pass 
first, independent on whose "side" it is

  2.2 In China, the default speed limit if nothing is signed in towns is 50 
km/h but on urban roads without a center line, it's 30 km/h [2]

3. Fuzzy/Implicit implications: Software may want to treat roads with unmarked 
lanes differently from ones that are marked. A few examples:

  3.1 StreetComplete may want to ask surveyors to measure a road width in 
meters only for unmarked roads because they are likely very thin and the 
traffic throughput is not clear through the lane count 

  3.2 router software may want to slightly prefer roads with lanes>=2 over 
unmarked roads and/or calculate a virtual lane count from the given width, if 
any - especially if the maxspeed-tag is missing

  3.3 map rendering software may want to render roads as they appear in 
reality. F4Map already does this rudimentary [3]

---

Now, my argumentation is in favour of making a distinction between unmarked and 
marked but not explicitly for lanes=0. I wouldn't mind or even slightly favor a 
tag like nolanes=yes or similar - this would be even more explicit. But since 
this does not exist (yet), lanes=0 would do as well in my opinion because it 
also reads as "zero (=no) lanes".

Cheers
Tobias

[1] see 
https://www.google.de/maps/@48.8734657,2.2942766,3a,75y,117.5h,85.1t/data=!3m7!1e1!3m5!1s4ofE9aRZMKKfWiiB2SiOrQ!2e0!6s%2F%2Fgeo1.ggpht.com%2Fcbk%3Fpanoid%3D4ofE9aRZMKKfWiiB2SiOrQ%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D166.38968%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192

[2] see https://wiki.openstreetmap.org/wiki/Default_speed_limits

[3] see https://demo.f4map.com/#lat=53.5832254&lon=9.9338489&zoom=19


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

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

[Tobias Zwick]

Sorry in hindsight I should have left out the last paragraph, please ignore it. 
I would rather not discuss concrete suggestions for software but collect ideas 
for certain modes of communications that may make constructive communication 
happen more.

On 25/05/2019 02:28, Tobias Zwick wrote:
> 
> 1. Thesis: Mailing lists (and to a lesser degree, classical forums) promote a 
> culture of dissent. This is because if people just agree, they tend towards 
> not answering at all on these mediums because they do not want to litter the 
> conversation when they don't have something own to say. So, as someone posing 
> a topic that does not develop into a long thread (like this one), you never 
> know if it was due to that nobody is interested, or if everyone is like "ok 
> sounds good".
> Now, what we actually want to achieve when starting a discussion on the 
> mailing list or forums to get so some kind of result with which all or most 
> people are actually fine with, to a consent. 
> 
> 1.1 A Solution: In real life, if you agree but have nothing more to say, you 
> simply show that by nodding or clapping. While, if you don't, you voice this 
> and state your reasons. So, I think simply a 👌 "sounds good" button, aka 👍 
> "like" (facebook) or 👏 "clap" (medium.com) will make a big difference. (Did 
> you know that a "thanks" button was introduced in our wiki recently? Use it!) 
> This will make it much easier also for people who usually just lurk on the 
> mailing list and don't feel they want to actively participate in the 
> discussion to give the people who write some feedback.
> 
> 2. Get more "normies" on board. I think it can only be good for the overall 
> communication culture to get more people on board. 
> 
> 2.1 Linked from the main page. Was already mentioned before in this thread 
> somewhere - the communication medium should be linked directly from the 
> openstreetmap.org start page to get more people on board. See for example 
> https://kotlinlang.org/community/ on how it could look like
> 
> 2.2. OAuth. Users should simply be able to use their openstreetmap login, no 
> further registration required.
> 
> 3. Moderation and Edits.
> 
> 3.1 Edit: Every now and then, people derail verbally, it happens. We are all 
> humans. So, to be able to edit your post after you realized that you 
> shouldn't have said something inflammatory, abusive or stupid, is important.
> 
> 3.2 Report: And sometimes, a person will just not cool down and fail to see 
> that he is being abusive, then this needs to be moderated in order to keep 
> the discussion factual. An abusive comment on the mailing list will stay 
> forever, while one on a well moderated medium will only be seen by those that 
> see it before it is reported. Having an abusive comment just stay there, even 
> if it is rebuked, broadcasts a nasty odor and poisons the discussion. This is 
> the "toxicity" that pops up time and again here. Don't underestimate 
> emotions. Just remember how this discussion here started ( 
> https://lists.openstreetmap.org/pipermail/tagging/2019-May/045501.html ). So, 
> my conclusion, *good* moderation is most important really.
> 
> 3.3 Moderation: Sometimes discussions go off topic or branch off. Especially 
> if using a threaded forum or a mailing list. Then, it should be possible to 
> put those branches into own threads.
> 
> 3.x All three are not possible on a mailing list, but at least in the forum.
> 
> All those points I mentioned are nothing new or outrageous. Any modern 
> conversation software will have all of this.
> 
> For example F-Droid (Android OpenSource Software Repository) and Kotlin 
> (modern programming language) both use Discourse. Could this be an option to 
> replace both the mailing lists and the forums? https://www.discourse.org/
> 
> I am talking about replace here, because one part of the problem is, is that 
> the community is so scattered ("filter bubbles").
> On 25/05/2019 01:43, Tobias Zwick wrote:
>>> Sometimes, it goes the other way - the good way. There's consensus, or if 
>>> disagreement, the different options are offered constructively. You can see 
>>> that happen pretty often. How do we make that happen more?
>>
>> The discussion pretty quickly drifted from considering technical solutions 
>> to behaviors, toxicity, cultural differences etc. etc., I have read this a 
>> thousand times. I don't see how this brings us forward.
>>
>> But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
>> positive, and talk about ideas.
>> We can't change the people, but we can change the c

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

[Tobias Zwick]

1. Thesis: Mailing lists (and to a lesser degree, classical forums) promote a 
culture of dissent. This is because if people just agree, they tend towards not 
answering at all on these mediums because they do not want to litter the 
conversation when they don't have something own to say. So, as someone posing a 
topic that does not develop into a long thread (like this one), you never know 
if it was due to that nobody is interested, or if everyone is like "ok sounds 
good".
Now, what we actually want to achieve when starting a discussion on the mailing 
list or forums to get so some kind of result with which all or most people are 
actually fine with, to a consent. 

1.1 A Solution: In real life, if you agree but have nothing more to say, you 
simply show that by nodding or clapping. While, if you don't, you voice this 
and state your reasons. So, I think simply a 👌 "sounds good" button, aka 👍 
"like" (facebook) or 👏 "clap" (medium.com) will make a big difference. (Did you 
know that a "thanks" button was introduced in our wiki recently? Use it!) This 
will make it much easier also for people who usually just lurk on the mailing 
list and don't feel they want to actively participate in the discussion to give 
the people who write some feedback.

2. Get more "normies" on board. I think it can only be good for the overall 
communication culture to get more people on board. 

2.1 Linked from the main page. Was already mentioned before in this thread 
somewhere - the communication medium should be linked directly from the 
openstreetmap.org start page to get more people on board. See for example 
https://kotlinlang.org/community/ on how it could look like

2.2. OAuth. Users should simply be able to use their openstreetmap login, no 
further registration required.

3. Moderation and Edits.

3.1 Edit: Every now and then, people derail verbally, it happens. We are all 
humans. So, to be able to edit your post after you realized that you shouldn't 
have said something inflammatory, abusive or stupid, is important.

3.2 Report: And sometimes, a person will just not cool down and fail to see 
that he is being abusive, then this needs to be moderated in order to keep the 
discussion factual. An abusive comment on the mailing list will stay forever, 
while one on a well moderated medium will only be seen by those that see it 
before it is reported. Having an abusive comment just stay there, even if it is 
rebuked, broadcasts a nasty odor and poisons the discussion. This is the 
"toxicity" that pops up time and again here. Don't underestimate emotions. Just 
remember how this discussion here started ( 
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045501.html ). So, 
my conclusion, *good* moderation is most important really.

3.3 Moderation: Sometimes discussions go off topic or branch off. Especially if 
using a threaded forum or a mailing list. Then, it should be possible to put 
those branches into own threads.

3.x All three are not possible on a mailing list, but at least in the forum.

All those points I mentioned are nothing new or outrageous. Any modern 
conversation software will have all of this.

For example F-Droid (Android OpenSource Software Repository) and Kotlin (modern 
programming language) both use Discourse. Could this be an option to replace 
both the mailing lists and the forums? https://www.discourse.org/

I am talking about replace here, because one part of the problem is, is that 
the community is so scattered ("filter bubbles").
On 25/05/2019 01:43, Tobias Zwick wrote:
>> Sometimes, it goes the other way - the good way. There's consensus, or if 
>> disagreement, the different options are offered constructively. You can see 
>> that happen pretty often. How do we make that happen more?
> 
> The discussion pretty quickly drifted from considering technical solutions to 
> behaviors, toxicity, cultural differences etc. etc., I have read this a 
> thousand times. I don't see how this brings us forward.
> 
> But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
> positive, and talk about ideas.
> We can't change the people, but we can change the communication medium which 
> can have a very big effect.
> 
> I would like to brainstorm what features of a desired communication medium 
> would have a positive impact on the discussion culture, and also on the 
> ability of us, to find something like a consensus.
> 
> Please, everyone, feel invited in this branch of this thread to give some 
> input. I have some ideas myself so I will start with that, but in the next 
> message. :-)
> 
> Tobias
> 
> On 25/05/2019 00:47, Nick Bolten wrote:
>>> What I'd suggest is that (much as I suggested before) everyone tries to 
>>> understand how points

Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

[Tobias Zwick]

> Sometimes, it goes the other way - the good way. There's consensus, or if 
> disagreement, the different options are offered constructively. You can see 
> that happen pretty often. How do we make that happen more?

The discussion pretty quickly drifted from considering technical solutions to 
behaviors, toxicity, cultural differences etc. etc., I have read this a 
thousand times. I don't see how this brings us forward.

But I was waiting for a cue like this. Thank you for that, Nick. Let's be 
positive, and talk about ideas.
We can't change the people, but we can change the communication medium which 
can have a very big effect.

I would like to brainstorm what features of a desired communication medium 
would have a positive impact on the discussion culture, and also on the ability 
of us, to find something like a consensus.

Please, everyone, feel invited in this branch of this thread to give some 
input. I have some ideas myself so I will start with that, but in the next 
message. :-)

Tobias

On 25/05/2019 00:47, Nick Bolten wrote:
>> What I'd suggest is that (much as I suggested before) everyone tries to 
>> understand how points of view can be misunderstood and how conversations 
> can go downhill, when each side believes that there is malice on the other.  
> This thread is actually a pretty good example of it ...
> 
> Yes, of course. It's important to ask questions and assume the best, when 
> possible.
> 
> Sometimes, the insults are as subtle as a sledgehammer. It's not 
> miscommunication, it's a free-for-all, and it turns away new users. I've seen 
> it happen in real time.
> 
>> The initial "OSM needs an alternative for community tagging discussions" 
>> message in the other thread said a number of things that surely were not 
>> intended as 
> personal attacks but were directed at a place with which people felt a sense 
> of community, and therefore _were_ interpreted as direct personal attacks.  
> I'd suggest everyone asks themselves "If I write this, how will it be 
> interpreted?  How will it make other people feel?".
> 
> This point is well-taken. I should have contextualized my points so that it 
> was clear that I'm objecting to a particular atmosphere and want it to 
> improve. I do believe there are fundamental problems with the mailing list 
> format that contribute to that atmosphere.
> 
>> The next thing that I'd suggest is when someone has said something out of 
>> order (or that seems at first glance to be out of order) to wait a 
> bit before replying.  An initial retort will be be unlikely to contain the 
> clearest thought out response.  If you've managed to get into an argument 
> with someone and the other person behaves in a particularly childish way, you 
> can rely on someone else to tell them that what they are saying is silly (as 
> happened in this thread when Clifford Snow intervened).
> 
> Of course, but this won't help new users asking questions. They will still 
> have a negative experience. This is still (in theory) a volunteer-driven 
> effort, so that really matters. They can (and do) just leave. You can see 
> that the main dev of the most popular editor has already given up on these 
> lists for very similar reasons. That's why this is relevant: that's a 
> surprisingly reasonable response, so how can we fix it? How can we interface 
> properly and decrease alienation?
> 
> Finally, while it is surely helpful when certain behavior is called out as 
> unacceptable, and it's appreciated, it doesn't happen nearly often enough to 
> establish a minimum sense of decorum.
> 
>> Finally, (and this is one for British politicians as well) if it feels like 
>> everyone's ganging up on you and no-one seems to agree, stop, take 
> a step back and try and draw a thread between what "everyone" seems to be 
> saying.
> 
> Oh, I think "ganging up" is fine so long as it's civil. That would be 
> something like consensus - sounds great! 
> 
> I may not be making my point about disagreement clear. I love disagreement: 
> it's healthy, it's productive, there's no other way to get consensus. New 
> users should be met with it, when appropriate. We should all have robust 
> discussions about differing views to establish the meaning of tags.
> 
> However, it's hard to see how "establish the meaning of tags" is served when 
> there are 3, 4, 5, 6, etc absolutist, often insulting, yet also incompatible, 
> opinions offered. That forces the visitor into this position: ignore at least 
> N - 1 of those people and either give up or plod along hoping that those 
> positions can be, in some way, taken back. I'm not simply talking about 
> proposals: if you ask, "how do I tag this?" and are in that situation, you'll 
> come away thinking that nobody knows the answer, but some people will be very 
> annoyed if you try to do it your way.
> 
> Sometimes, it goes the other way - the good way. There's consensus, or if 
> disagreement, the different options are offered constructively. You can

Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

[Tobias Zwick]

These are some valid points, and I also have some input to that, but are you 
sure you want to discuss this on the tagging ML? The talk ML might be a better 
spot for this, this topic has already strayed quite far from the original 
topic. (And maybe start the topic on a more positive prospect instead of with a 
rant ;-)

Tobias

On 23/05/2019 21:58, Nick Bolten wrote:
>> Yes, it would be great. There is plenty of negative emotion on both sides 
>> and it would be great to reverse this (for example title that I used was 
>> frankly stupid what I realized after sending the message).
> 
> OSM needs an alternative for community tagging discussions outside of these 
> mailing lists. Ones that people will actually use and that have a reasonable, 
> community-oriented code of conduct. I have talked to 10X more people about my 
> `crossing` proposals outside of this mailing list (in-person, personal 
> emails, slack, etc.) and the differences could not be more stark:
> 
> # My experiences with OSMers in other contexts:
> - Very friendly, all focused on making maps better, highly motivated to 
> donate their time to help others via the map.
> - Disagreements are pleasant. Both sides acknowledge the other point of view 
> and usually come around to a compromise.
> - There is interest in knowing more: lots of questions back and forth.
> - Objections are qualified and polite.
> - 10s-100s of people giving feedback on a single idea.
> 
> # My experience with this mailing list:
> - Quick to exasperate.
> - You will be assumed to be coming to the table in bad faith.
> - You will probably be insulted at some point, potentially sworn at.
> - The same 8 or so people respond to posts out of a community of tens of 
> thousands of people, companies, non-profits, etc.
> - The odd situation of absolute certainty in completely incompatible opinions 
> from those that do respond.
> - Difficult for people to discover. How do we know that the opinions shared 
> here are in any way representative of the community, given that so few 
> discover + participate in it?
> - Difficult to filter for relevance. Have to set up email filters and/or 
> specialized search queries.
> - Zero real synchronization with OSM editors, the only way people add data to 
> the map. Blame doled out everywhere, but very little in the way of 
> collaboration, no real venue for doing so (see previous bullet points).
> 
> Focusing on the idea of being an "arbiter", does that sound like a good way 
> to figure out which tags are good/acceptable?
> 
> When I was mentoring a group of students a few years ago, several were 
> offended by the condescending and insulting responses they received on this 
> mailing list, all because they suggested making a coherent way of combining 
> existing tags into a pedestrian schema and doing a carefully-vetted import. 
> The import was so carefully-vetted that we later realized it wasn't even 
> really an import, but this didn't stop there being several insulting 
> accusations from several long-term OSMers on these lists. Those students were 
> motivated by helping other people and spent literal months attempting to 
> gather enough information from underspecified tagging standards and would 
> have been put off the community entirely if it weren't for the project's 
> momentum and much more productive and friendly interactions with local 
> OSMers. I think it's probably a good thing that it's so hard to even know 
> that there is a mailing list, as users have a negative experience.
> 
> To boot, there are technical problems solved by virtually every other 
> messaging system:
> - Difficult to discover.
> - Virtually impossible for new users to join recent discussions - they need 
> to have subscribed to the list first.
> - Discovering old discussions is difficult, requires some nerdy prowess.
> - Terrible security practices. Passwords sent in plain text over email. No 
> encryption. I was almost put off the mailing list entirely when I saw this. 
> Completely unacceptable.
> 
> Gripes aside, I have a suggestion: move these discussions to a real forum 
> system, properly organized around regional/topic-specific/tagging 
> discussions. It could be a revamped https://forum.openstreetmap.org/ or 
> something fancier and slack-like (like riot chat). Have actual moderators and 
> code of conduct. The current mode of communication is systematically flawed.
> 
> On Thu, May 23, 2019 at 12:06 PM Mateusz Konieczny  > wrote:
> 
> 23 May 2019, 18:32 by o...@westnordost.de :
> 
> reverse this development.
> 
> Yes, it would be great. There is plenty of negative emotion on both sides 
> and it
> would be great to reverse this (for example title that I used was frankly 
> stupid
> what I realized after sending the message).
> 
> I had to rewrite this last paragraph several times, but, well, I hope 
> this does not come across the wrong way...
>  

Re: [Tagging] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

I'd say so. 

On 23/05/2019 19:03, Nick Bolten wrote:
> So would it be fair to say that a linear *=platform implies foot=yes and can 
> be tagged with reasonable tags for a footway such as width, incline, surface, 
> tactile paving, etc?
> 
> On Thu, May 23, 2019, 9:46 AM Tobias Zwick  <mailto:o...@westnordost.de>> wrote:
> 
> "Redundant" is perhaps not the best way to describe the problem. I'd go 
> about this like this:
> 
> A "highway=footway" is a footway, a "public_transport=platform" is a bus 
> stop (platform). These are simply two different things. They *share* certain 
> properties, for example, they are accessible both by pedestrians, but that 
> does not make a bus stop platform a footway.
> Giving an extreme example: Paved brownfields and parking lots are not 
> footways. But following the argument of the iD developers, they probably 
> should.
> 
> Tobias
> 
> On 23/05/2019 18:26, Nick Bolten wrote:
> > I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> >
> > Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> >
> > On Thu, May 23, 2019, 12:49 AM Markus  <mailto:selfishseaho...@gmail.com> <mailto:selfishseaho...@gmail.com 
> <mailto:selfishseaho...@gmail.com>>> wrote:
> >
> >     I agree that adding highway=footway to platforms is not only
> >     redundant, but (as pointed out by Michael) is bad because platforms
> >     often have different access restrictions than highway=footway. iD's
> >     validation rule should be removed.
> >
> >     Regards
> >
> >     Markus
> >
> >     ___
> >     Tagging mailing list
> >     Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> 
> <mailto: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 <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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

"Redundant" is perhaps not the best way to describe the problem. I'd go about 
this like this:

A "highway=footway" is a footway, a "public_transport=platform" is a bus stop 
(platform). These are simply two different things. They *share* certain 
properties, for example, they are accessible both by pedestrians, but that does 
not make a bus stop platform a footway.
Giving an extreme example: Paved brownfields and parking lots are not footways. 
But following the argument of the iD developers, they probably should.

Tobias

On 23/05/2019 18:26, Nick Bolten wrote:
> I'm confused, because these two statements seem incompatible. If it's 
> redundant, how can it also have a conflict like different address 
> restrictions? I'd like to know how, as a data consumer, I should reliably 
> interpret existing platforms without the tag added by iD.
> 
> Taking a step back, can anyone name an instance where a linear transit 
> platform is not a footway?
> 
> On Thu, May 23, 2019, 12:49 AM Markus  > wrote:
> 
> I agree that adding highway=footway to platforms is not only
> redundant, but (as pointed out by Michael) is bad because platforms
> often have different access restrictions than highway=footway. iD's
> validation rule should be removed.
> 
> Regards
> 
> Markus
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] ID is not a king and final arbiter of OSM (was: iD adding highway=footway to all railway/public_transport=platform ways and relations)

[Tobias Zwick]

I simply have the feeling that we are heading straight for an escalation course 
here. I already see it looming that some day the plug might be pulled on iD 
(being hosted on openstreetmap.org) and I really really don't want this to 
happen, lest even to think about it makes me sick.

Undoubtedly, the developers behavior is not helping there. I have the 
impression that they have almost given up on the OSM community. But this 
doesn't come out of nowhere.  I think it is important to understand their side 
of the story if we were to reverse this development.

I had to rewrite this last paragraph several times, but, well, I hope this does 
not come across the wrong way...
it can certainly not continue like this, so ... why not interview him, honestly 
and with open outcome, how should the collaboration and communication in OSM 
happen in the future from his point of view? Would he rather feel relieved or 
rather feel betrayed if the gatekeeping (~deployment) is done by other people? 
Does he really feel alienated (because I assumed it) from the community and if 
yes, why? And most importantly, what would it take to reverse this? 

Tobias

On 23/05/2019 17:15, Mateusz Konieczny wrote:
> Though repeated attempts by @bhousel and @quincylvania to declare themselves 
> as
> final arbiters of OSM tagging and dismissing everybody else is certainly not 
> helping.
> 
> That is really not going to work, and it is a pity because plenty of work 
> done of him is really great
> but it is tainted by ignoring arguments of critics. No one is right all the 
> time.
> 
> To directly quote part of
> https://github.com/openstreetmap/iD/issues/6409#issuecomment-495231649
> 
> "Some things that don't really factor at all into our decision:
> 
>     how long a tag with implicit semantics has been in use
>     how many softwares (renderers / routers or whatever) already support the 
> implicit rule
>     how frequently the tag is used
>     what a handful of people on a mostly dormant mailing list think
>     what one person has written on the osm wiki
>     how many downvotes you encourage people to put on our issue list
>     what they are saying about us in the weekly osm tabloid"
> 
> So someone is dismissing what everybody else thinks and at the same time 
> expects everybody
> to accept his own opinions?
> 
> Some ideas from tagging mailing list and OSM wiki (even after limiting to 
> popular ones
> or "approved") are pointless/harmful but that is not a valid reason to simply 
> ignore all of them.
> 
> 23 May 2019, 10:16 by o...@westnordost.de:
> 
> I like your wording. It is a burden. He also takes all the complaints for 
> bugs and when iD steps on someone's shoes. This is a very stressful position 
> to be in.
> 
> 
> 
> ___
> 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] iD adding highway=footway to all railway/public_transport=platform ways and relations

[Tobias Zwick]

I like your wording. It is a burden. He also takes all the complaints for bugs 
and when iD steps on someone's shoes. This is a very stressful position to be 
in.

Am 23. Mai 2019 09:38:06 MESZ schrieb Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> On 23. May 2019, at 09:21, Mateusz Konieczny
> wrote:
>> 
>> I think that main difference between JOSM validation (that is not
>causing repeated complaints, 
>> at least on this mailing list) and iD validation is that JOSM devs
>have no trouble 
>> with reverting or fixing changes that are not actually wanted (or are
>better on judging what 
>> is wanted by community).
>
>
>a big difference is that in Josm there is a team, where different
>opinions can be discussed, while in iD it is Bryan who has the whole
>burden on his shoulders to decide alone about raised issues.
>
>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] Extremely complicated conditional values

[Tobias Zwick]

Even shorter, because if there are conflicting rules in the conditional, the 
last one is taken, says the wiki. (Not sure if this is really implemented in 
applications that work with that data though):

maxspeed:advisory:conditional=37 mph @ (weight>=6 lbs);26 mph @ 
(weight>=65000 lbs);22 mph @ (weight>=7 lbs);18 mph @ (weight>=75000 lbs 
AND weight<=8)

Notes:
- I'd always specify units as they are used on the sign for better 
confirmability
- to be precise, I guess you'd need to add "AND axles>=5" in every conditional 

Tobias

Am 25. April 2019 10:34:21 MESZ schrieb Johnparis :
>I suppose, given that they all have the same tag, that the values would
>need to be concatenated with semicolons:
>
>
>maxspeed:advisory:conditional=18 @ (weight>=37.5);22 @ (weight>=35 AND
>weight<37.5);26 @ (weight>=32.5 AND weight<35);37 @ (weight>=30 AND
>weight<32.5)
>
>On Thu, Apr 25, 2019 at 10:28 AM Johnparis  wrote:
>
>> I'd try something similar to this example:
>>
>> access:conditional=destination @ (weight>5.5)
>>
>> So in your case you would have
>>
>> maxspeed:advisory:conditional=18 @ (weight>=37.5)
>> maxspeed:advisory:conditional=22 @ (weight>=35 AND weight<37.5)
>> maxspeed:advisory:conditional=26 @ (weight>=32.5 AND weight<35)
>> maxspeed:advisory:conditional=37 @ (weight>=30 AND weight<32.5)
>>
>> (... the standard for weight being short tons in the USA...)
>>
>> John
>>
>>
>> On Thu, Apr 25, 2019 at 4:36 AM Paul Johnson 
>wrote:
>>
>>> Is there a condition value calculator that can help me come up with
>sane
>>> tagging for this?
>>>
>>> https://openstreetcam.org/details/955279/18672/track-info
>>>
>>> This is a chart of advised speeds in MPH for HGVs on a motorway in
>Oregon
>>> based on weight in pounds.  I'm at a complete loss of how to tag for
>this
>>> save for conditional values but I am banging my head on coming up
>anything
>>> cogent reading through
>>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions short
>of maxspeed:advisory:hgv=18
>>> mph (which technically fits the most stringent value but a little
>>> hamfisted given that sign).
>>>
>>> Can I get a hint on this?
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>

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

Re: [Tagging] Intermittently unprotected cycle track

[Tobias Zwick]

Hi Richard

I'd tag this situation with cycleway=track/lane/shared_lane on the road itself. 
I don't see the namespacing as an issue here.

The rule of thumb I (we?) use to decide whether a cycleway shall better be 
tagged as a separate way is to look if the cycleway is segregated from the road 
by more than a curb, such as scrub or a tree row. In other words, so that 
bicyclists can not simply cross onto the street at any point without a 
dedicated crossing.

Tobias 

Am 27. März 2019 11:31:18 MEZ schrieb Richard Fairhurst :
>Hi all,
>
>Let me introduce you to one of London's better cycleways:
>
>https://www.openstreetmap.org/#map=19/51.53397/-0.00715
>https://cycle.travel/map?lat=51.5254&lon=-0.0335&zoom=17
>
>You might look at this and think "that doesn't look like 'better' to
>me, 
>it's full of 45-degree bends". And based on OSM you would of course be 
>right.
>
>In reality it isn't full of 45-degree bends. It's a continuous straight
>
>route. But although it's mostly protected (i.e. concrete barrier 
>separating it from the car lanes), the protection gives out at
>junctions 
>and crossings, so turning traffic can cross. Here's an example 
>(apologies for Google link):
>
>https://goo.gl/maps/rFHNHdCxMCp
>
>Currently, it's mapped in OSM as a highway=cycleway for the segregated 
>bits, and then it rejoins the highway=primary road (with cycleway=lane)
>
>where the barrier gives out.
>
>This is correctish in terms of tagging but not in terms of geometry.
>The 
>current mapping implies 45-degree turns which the cyclist doesn't have 
>to take - they just continue straight on. Breaking geometry to enable 
>tagging is bad in itself, misleading on renderings, and unsurprisingly 
>confuses the heck out of routers.
>
>How should we represent this?
>
>My gut feeling is that it would be better to map it as a continuous 
>highway=cycleway but with 'protected=no' for the bits where the
>concrete 
>divider isn't there.
>
>Another alternative might include deleting the cycleway completely and 
>just using cycleway=track on the car road, but this seems suboptimal as
>
>you can't then easily apply tagging that applies distinctly to the 
>cycleway (surface, route relation membership, etc.) without lots of 
>namespacing.
>
>Or we could just go with highway=cycleway and no additional tagging, on
>
>the basis that 'unprotected' is implied by the pedestrian-crossing tags
>
>and the junction geometry - i.e. obviously there's no protection there 
>because we have a junction which cars can turn across.
>
>Any preferences?
>
>cheers
>Richard
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Is there any use of shop=general/general_store not covered by shop=convenience/supermarket/country_store?

[Tobias Zwick]

Well, there is a long wp article about it with a clear description for a start.

From that I understand, general stores are tiny department stores - i.e. a 
hyper market is to a convenience store as a department store is to a general 
store.

As it is about what they are selling, not where they can probably be found, 
"general" certainly seems like a better fit than "country"... If country_- and 
general_store are even supposed and understood by mappers as being the same 
thing.

Am 25. März 2019 14:45:41 MEZ schrieb Mateusz Konieczny 
:
>Is there any reason for shop=general and shop=general_store to keep
>existing?
>
>It seems that all cases are covered by better defined and named
>shop=convenience shop=supermarket shop=country_store

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Tobias Zwick]

Missed the earlier discussion.

I also always regarded cycleway=opposite, opposite_track, opposite_lane, 
opposite_share_busway etc. as the old deprecated method and oneway:bicycle=no + 
normal cycleway tag as the one that superceded it.

Same with cycleway:right=dual_lane/dual_track being superceded by or at least 
synonymous to cycleway:right=lane+cyleway:right:oneway=no.

Tobias 

Am 15. März 2019 01:35:51 MEZ schrieb Hubert87 :
>I also regard
>
>"cycleway:left=lane"
>"cycleway:left:oneway=-1"
>
>as the currently preferred method and have been mapping/tagging like 
>this for a while now.
>
>Just my two cents
>
>Hubert87
>
>
>Am 15.03.2019 um 00:12 schrieb althio:
>> Discussed: maybe there
>>
>https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
>> Decided : I don't know
>>
>>> Cmuelle introduces rather complex combinations of tags such as
>cycleway:left=lane + cycleway:left:oneway=-1, that should in his view
>be used instead of cycleway:left=opposite_lane.  Does anyone on this
>list know whether this change has been discussed anywhere, and where
>and when it has been decided that cycleway=opposite_lane is a "legacy
>tag" ? If so please point me at some references.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] shop=clothes vs shop=fashion

[Tobias Zwick]

Hmm, basically all kiosk type shops around my area are big enough to be entered 
- but only sell newspaper, magazines, cigarettes, drinks and snacks.  But *not* 
any of toilet paper, shampoo, cornflakes, yogurt, bread (so, daily needs) iirc

I think what they sell is a more useful differenciation than whether you can 
enter or not.

Am 6. März 2019 16:33:19 MEZ schrieb Mateusz Konieczny 
:
>Yes, shop is not becoming shop=kiosk just becomes you are unable to
>enter inside.
>
>Shop selling only clothes is still shop=clothes even if it is so small
>that you are unable 
>to enter inside.
>
>Shop selling only cars is still shop=car even if it is so small that
>you are unable 
>to enter inside.
>
>In some funny cases kiosk-type shops (sells drinks, newspapers,
>magazines, snacks, 
>cigarettes and the like) may be big enough that you can enter (for
>example at train 
>stations).
>
>
>Mar 6, 2019, 4:23 PM by o...@westnordost.de:
>
>> kiosk and convenience is supposed to be the same? I always used it
>like
>>
>> - convenience: small supermarket that is usually too small to have
>shopping carts but still also sells things of daily need (shampoo,
>toilet paper, milk, cornflakes, bread and spread,...). The typical
>7-Eleven store (doesn't exist in Germany btw)
>>
>> - kiosk: very small store that usually only sells drinks, newspapers,
>magazines, snacks, cigarettes and the like. Sometimes even so small
>that you can't go inside but buy things through the window
>>
>> Tobias
>>
>> Am 6. März 2019 16:06:25 MEZ schrieb Jean-Marc Liotier <>
>j...@liotier.org > >:
>> >On Wed, March 6, 2019 3:58 pm, Enock Seth Nyamador wrote:
>>
 Jean-Marc I agree with about shop=boutique much used in West
>Africa.

>> >The
>>
 reason being that the shops have boutique attached to their names.

>> >Indeed. In Dakar and Bamako, when you need to buy a Fanta, tu vas à
>la
>> >boutique... So I can't really blame contributors for using the word
>> >that
>> >sound most natural to them.
>>
>>>
>>>
>> >Depending on how big the shop is, solutions would be shop=kiosk
>(after
>> >years of pushing we are beginning to see that one adopted) and
>> >shop=convenience (which is not used enough)
>>
>>>
>>>
>> >___
>> >Tagging mailing list
>> >> Tagging@openstreetmap.org 
>> >> https://lists.openstreetmap.org/listinfo/tagging
>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>
>>

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

Re: [Tagging] shop=clothes vs shop=fashion

[Tobias Zwick]

kiosk and convenience is supposed to be the same? I always used it like

- convenience: small supermarket that is usually too small to have shopping 
carts but still also sells things of daily need (shampoo, toilet paper, milk, 
cornflakes, bread and spread,...). The typical 7-Eleven store (doesn't exist in 
Germany btw)

- kiosk: very small store that usually only sells drinks, newspapers, 
magazines, snacks, cigarettes and the like. Sometimes even so small that you 
can't go inside but buy things through the window

Tobias

Am 6. März 2019 16:06:25 MEZ schrieb Jean-Marc Liotier :
>On Wed, March 6, 2019 3:58 pm, Enock Seth Nyamador wrote:
>> Jean-Marc I agree with about shop=boutique much used in West Africa.
>The
>> reason being that the shops have boutique attached to their names.
>
>Indeed. In Dakar and Bamako, when you need to buy a Fanta, tu vas à la
>boutique... So I can't really blame contributors for using the word
>that
>sound most natural to them.
>
>Depending on how big the shop is, solutions would be shop=kiosk (after
>years of pushing we are beginning to see that one adopted) and
>shop=convenience (which is not used enough)
>
>
>___
>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 is a conscription number (addr:conscriptionnumber)?

[Tobias Zwick]

Thank you for the documentation. I read it, and it is clear to me.

Maybe it'd be good to further stress out how housenumber relates to
conscription- and streetnumber by giving an example:

  addr:streetnumber + addr:street = addr:housenumber + addr:street

  addr:conscriptionnumber + addr:place = addr:housenumber + addr:place

Conscriptionnumber explicitly refers to the place, streetnumber
explicitly refers to the street. And only in places where both numbers
exist alongside each other, it is necessary to use these tags.

Anyway, one important point I want to make is that there are many more
places than only in Czechia and Slovakia where the housenumbers relate
to the place, not the street, because streets in small(er) villages
often have no name, at least to my experience in South East Asia but I
bet this is somewhat universal.



Provisional numbers are a different type of conscription numbers
assigned to temporary, recreational buildings (etc). See § 31 zákona
128/2000 Sb [1] for Czech Republic.

Tobias

[1] https://zakonyprolidi.cz/cs/2000-128#f2024753

On 03/03/2019 08:28, Mateusz Konieczny wrote:
> I attempted to de describe conscription numbers
> at https://wiki.openstreetmap.org/wiki/Key:addr:conscriptionnumber
> - mostly using automatically translated texts.
> 
> Can someone look at this and check whatever what I added is correct
> and more or less clear?
> 
> Also, has anybody got any idea how addr:provisionalnumber and
> addr:housenumber tags differ in meaning?
> 
> ( https://wiki.openstreetmap.org/wiki/Key:addr:provisionalnumber )
> 
> ___
> 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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Because this is about foot=no, not handcart=no

On February 17, 2019 11:23:46 PM GMT+01:00, Martin Koppenhoefer 
 wrote:
>
>
>sent from a phone
>
>> On 17. Feb 2019, at 22:39, Tobias Zwick  wrote:
>> 
>> No, that tag is correct. It is not allowed to walk in the tunnel,
>> because the tunnel is still part of the street Tunisstraße, which has
>a
>> sidewalk. See StVO §25 (1)
>> https://www.gesetze-im-internet.de/stvo_2013/__25.html
>
>
>Why are you ignoring StVO p.25(2)?
>
>(2) Wer zu Fuß geht und Fahrzeuge oder sperrige Gegenstände mitführt,
>muss die Fahrbahn benutzen, wenn auf dem Gehweg oder auf dem
>Seitenstreifen andere zu Fuß Gehende erheblich behindert würden. 
>
>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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

>> Pedestrians can take the level footpaths/sidewalks instead taking the
>> underpass:
>> https://www.openstreetmap.org/way/6187386#map=18/50.94224/6.95277.
>> There is no signage forbidding foot traffic.
>> (https://www.google.de/maps/@50.978,6.9530483,3a,60y,190.35h,87.27t/data=!3m6!1e1!3m4!1sQMNheDoeod1aqNAV9jAkzQ!2e0!7i13312!8i6656)
>>
> 
> For that example you should use another tag & not misappropriate.

No, that tag is correct. It is not allowed to walk in the tunnel,
because the tunnel is still part of the street Tunisstraße, which has a
sidewalk. See StVO §25 (1)
https://www.gesetze-im-internet.de/stvo_2013/__25.html

I expect similar laws to be in place for other countries.

Tobias

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

Re: [Tagging] start_date variants

[Tobias Zwick]

Sounds solid and already used quite a bit.

But wait, is it start_date:somekey or somekey:start_date?

Tobias 

On February 15, 2019 11:03:01 AM GMT+01:00, "Stephan Bösch-Plepelits" 
 wrote:
>Hi!
>
>I have some thoughts in the start_date tag, as I find it a bit too
>vague -
>meaning start of what?
>
>Example: There is this museum, which openened in 2011, but the building
>is
>much older, it was built in 1725:
>https://www.openstreetmap.org/relation/1937535
>
>An option would be to prefix start_date with the key of the indicating
>tag,
>e.g. amenity:start_date would describe the start_date of the current
>amenity. So, non-prefixed start_date would apply to all other tags.
>
>This seems to be quite popular anyway, but I don't know if this ever
>has
>been agreed upon - at least it's not documented as such:
>https://taginfo.openstreetmap.org/search?q=start_date
>
>For the museum, which I mentioned before, I used the following tags:
>- start_date=2011
>- building:start_date=1725
>
>Other remarks:
>
>It would also be interesting to be able to tag the start of
>construction -
>often construction starts many years before the building is finshed:
>Airport BER in Berlin, Germany or La Sagrada Familia in Barcelona,
>Spain
>are famous examples. How to tag this? Maybe: construction:start_date?
>
>Any thougths on this?
>
>greetings,
>   Stephan
>
>PS: OpenStreetBrowser has a category which shows building:start_date
>resp.
>start_date:
>https://www.openstreetbrowser.org/#categories=buildings-start_date
>
>PS: I even found, that people translate 'start_date' by using a
>language
>suffix (e.g. start_date:fr, start_date:ja):
>- https://taginfo.openstreetmap.org/keys/start_date%3Afr#values
>- https://taginfo.openstreetmap.org/keys/start_date%3Aja#values
>I wrote a node module which can translate start_date values (English,
>German, French available). Pull requests welcome!
>https://github.com/plepe/openstreetmap-date-format

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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Okay, right, this is a good point. I am not a native speaker and translated the 
German word "zugänglich" (literally: enterable) to English and wasn't aware of 
the ambiguous/broad meaning in the context of accessibility.

So I'll negate the wording to specifically ask for it being forbidden.

Furthermore, I mentioned it already, I am primarily after tagging explicitly  
situations like road sections within large intersections, overpasses, 
underpasses, inner segregated lanes of large streets, connecting/linking road 
way section that are in reality simply part of the street area and so forth.
I am not interested to add foot=X to any rural road etc.

So, while a tag to denote that a road is rural does not exist (yet), I could 
filter out uninteresting roads using tell-tale tags.

So, I could further filter out roads with..

- lit != yes (so, also if lit is not set) to exclude most of the 
rural/undeveloped roads. For UK, it is not even tell-tale

- motorway, motorroad anyway

- any but paved roads

- perhaps even only oneway roads?? (asking for input here) Because the cases I 
mentioned are in the majority oneway-lanes

- perhaps also only ask for a sidewalk in the first place if the road is tagged 
as lit=yes? Asking for input.

Tobias

On February 15, 2019 1:59:25 AM GMT+01:00, Kevin Kenny 
 wrote:
>On Thu, Feb 14, 2019 at 7:26 PM Tobias Zwick 
>wrote:
>>
>> Is this now about the word "legal" or about the negation of the
>question? What difference does the latter make? Also, doesn't
>"probited" imply "legally" in common understanding?
>>
>> And of course, foot=no is tagged if a road is not accessible by foot.
>
>Many posters in this thread confused 'accessible safely' with
>'accessible lawfully', hence the talking at cross purposes. The former
>may be a judgment call; the latter is ordinarily reasonably
>straightforward to resolve.
>
>This comes partly from the fact that 'accessible' in the US appears
>mostly in phrases such as 'accessible to the disabled', which connotes
>affirmative provision for the group in question.
>
>___
>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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Is this now about the word "legal" or about the negation of the question? What 
difference does the latter make? Also, doesn't "probited" imply "legally" in 
common understanding?

And of course, foot=no is tagged if a road is not accessible by foot.

On February 15, 2019 12:52:16 AM GMT+01:00, Joseph Eisenberg 
 wrote:
>> The question asked is "Is this street accessible for pedestrians
>here?".
>> It doesn't ask for the user's opinion on how safe it is.
>>
>
>I believe this is the wrong question. It should be “Are pedestrians
>legally
>prohibited from walking along this road?”
>
>If so, use foot=no
>
>Foot=yes should only be used for motorways and motorway_link roads,
>bridleways and cycleways.
>
>(and perhaps busways, railways? Though I can’t think of any that would
>allow pedestrian travel)
>
>If the road is tagged expressway=yes then foot=yes might also be
>needed.
>All other classifications of road should be presumed to permit
>pedestrian
>travel.
>
>
>>

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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

> Agreed. I don't see much of a difference between residential and higher
> class roads. I would even argue that around here a sidewalk=no + foot=no
> is even less likely on higher class roads than on residentials.

How so? I have the impression, we (all) have different kinds of road in
mind, when arguing whether or not an explicit foot=yes/no is reasonable
or not.
I have these kind of road (sections) in mind that I already mentioned:
underpasses, tunnels, bridges, but also (large) intersections,
roundabouts, links between roads and any other occurances where in OSM,
multiple ways are drawn even though in reality, it is just one road.
So, what kind of roads do you have in mind?

Tobias

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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

The question asked is "Is this street accessible for pedestrians here?".
It doesn't ask for the user's opinion on how safe it is.

Also:
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042874.html

On 14/02/2019 22:10, Volker Schmidt wrote:
> I am sorry, this is not the correct approach. We have here plenty of
> streets in other categories (unclassified|teritery|secondary|primary)
> without sidewalk  where it is perfectly legal for pedestrians to use the
> road. This does not say whether it's safe to walk on them. If people now
> start putting foot=no because they want to prevent people from walking
> on the these roads because it's unsafe, then we create a nice mess. You
> should map the deviation from the default (foot=no), not confirm a
> default (foot=yes).

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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

No, I didn't. I explained the quest here:
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042860.html

In a nutshell: foot=yes/no is only asked if sidewalk=no is tagged.

As per request on this mailing list, I now changed it so that regardless
of whether sidewalk=no is tagged, it is never asked for service roads,
living streets, pedestrian and residential roads. Here is the code:

https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/quests/foot/AddAccessibleForPedestrians.kt#L12-L18

Tobias

On 14/02/2019 21:14, Tobias Wrede wrote:
> Am 14.02.2019 um 20:50 schrieb Tobias Zwick:
>> Alright, I will change it so that the question whether a road is
>> accessible for pedestrians is never asked for residential roads (and
>> living streets, service roads, pedestrians roads) for v10.1
>>
> I think you lost me. Didn't you explain in the beginning that this quest
> was asked for residentials only anyway? What will remain then?
> 
> You could modify so that the question is asked only for bridges, tunnels
> or where bicycle=no exists and where there is no sidewalk.
> 
> Tobias
> 
> 
> ___
> 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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Alright, I will change it so that the question whether a road is
accessible for pedestrians is never asked for residential roads (and
living streets, service roads, pedestrians roads) for v10.1

Tobias

On 14/02/2019 10:26, Florian Lohoff wrote:
> 
> Hi,
> i am seeing a growing number of changesets setting foot=yes
> on all kinds of roads e.g. residential
> 
> https://www.openstreetmap.org/way/403719315
> 
> Commit message is:
> 
> "Add whether roads are accessible for pedestrians"
> 
> All residentials are accessible to pedestrians so i a bit puzzled
> what this challenge is good for. It just adds redundant tags to
> all roads.
> 
> Flo
> 
> 
> ___
> 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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

I agree that it would make sense to not ask whether a road has a
sidewalk outside of built-up areas because in most cases, it will have
no sidewalks.

Regrettably, whether a road is in a built-up area or outside is not an
information that is recorded in OSM.

Tobias

On 14/02/2019 18:23, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 14. Feb 2019, at 16:05, Rory McCann  wrote:
>>
>> But in Ireland (& I think UK), all public roads except motorways, are 
>> foot=yes. Legally you can walk on the road, even if there is not footpath 
>> ("sidewalk"). I think this adds bloat and quests which will annoy mappers.
> 
> 
> Germany and Italy as well (motorroads and motorways excluded).
> Sooner or later we might add sidewalk=no tags to many roads in the 
> countryside (maybe, so long I wasn’t actually doing it). There may be a 
> fundamental conflict of the StreetComplete project (which encourages to 
> verify everything) and our usually sloppy way of assuming defaults. Problem 
> is with lots of “boring” tags on every object, we’ll loose focus/overview and 
> it might reduce data quality rather than augmenting it. I acknowledge some 
> compromise is already offered by asking only for roads without sidewalks, but 
> it is still too many, if it were only in built-up areas it would be probably 
> acceptable (for Italy or Germany).
> 
> 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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

This is, by the way, a bit of a different topic now, because the thread
was originally about tagging foot=yes on residential, not whether
foot=yes/no is limited to a *legal* access restriction. Anyway:

I doubt access restrictions are used that way in reality.

The absence of keys like the mentioned key walkable(, cycleable,
motorcarable, hgvable etc.) is a clear sign for that, because there are
enough situations where the situation on the ground is clear for a
surveyor but there is no official sign.
Otherwise, the access restriction information would be hardly useful.

There are many different road traffic legislations around the world and
(as I read many of them) I can tell you that there is a lot of variance
in how precisely and how close to reality they are written. And also,
how much the road authority feels the need to sign more or less obvious
road situations.

In some legislations, there is no notion of motorways and motorroads,
but roads like this may nevertheless exist. Does that mean that no roads
may be tagged like this in OSM? No. Does it mean that foot=yes is
implicitly assumed on them? Well, no, because even if that would be the
official legal situation, that would be silly, and I am sure no
policeman with common-sense would listen to this kind of bean counting.

Same with Germany/UK. Some posters mentioned, that on any road without a
sidewalk and without an explicit access restriction for pedestrians,
pedestrians are allowed. Okay, that is new to me, but if this is true,
then this is also a case where the law (massively) diverges from the
actual reality on the ground. I am sure the police would find something
else to charge you with when you take a walk on for example this busy
intersection https://www.openstreetmap.org/way/188015324 , like,
hindrance of traffic. Note that the road authority also did not bother
to put any signs there [*]
(Google Streetview:
https://www.google.de/maps/@53.5483485,10.0055799,3a,73y,176.82h,81.92t/data=!3m6!1e1!3m4!1sBSZx5A6MNVRKd0qN6MIanQ!2e0!7i13312!8i6656
)

Incidentally, that section is also tagged with foot=no.

I have no statistics up my sleeve, but I firmly believe that this is no
exception, because, common sense.

Let's be pragmatic: We don't tag things just because and also do not
live in clouds. So, why do we tag access restrictions at all? -
To be of use for routing and other use cases where it is relevant
whether something is accessible or not, simple as that.
The reason for it being (not) accessible is secondary, because this
information is mostly used for verifiability, but not for the routing
itself. It is the source of the information, like maxspeed:source=sign.

So, to come back to StreetComplete, the app could of course ask the user
instead: "Is this street *legally* accessible for pedestrians here?".
But, I hope I made clear that this is beside the point and asking more
generally is both more concise and meaningful. A surveyor that is
on-site is in the best position judge the situation according to common
sense if no sign is present and if he cannot (i.e. the answer would be
"prrooobably yes, it's not forbidden at least, but perhaps a bit
dangerous"), then he can still leave a note in which he explains the
situation and attaches some photos to it.

Tobias

[*] And exactly these situations were the ones I had in mind when
designing the discussed quest for StreetComplete, by the way.

On 14/02/2019 18:16, JS wrote:
> 
> 
>> The rationale behind collecting this information is, that if a street
>> is
>> explicitly surveyed as having no sidewalk, it is no longer implicated
>> that naturally the street is accessible on foot (foot=yes). Roads
>> explicitly signed as motorroads are not the only roads that are not
>> accessible on foot.
>>
>> And this is an important information for pedestrian routers and maybe a
>> useful information for car routers (because they might want to prefer
>> routes without the sidewalk=no + foot=yes 
> 
> First, thanks for all the effort put into "StreetComplete". I really like the 
> app and frequently use it.
> 
> Concerning the new task, I think the rationale to explicitly map highways 
> that are actually accessible to pedestrians is laudable. But the approach 
> chosen here may be inaccurate as it mixes the legal and the physical 
> realities. The legal situation is already represented by the default OSM 
> setting, considering all highways as "foot=yes" except some like motorways or 
> those explicitly marked as "foot=no".
> 
> Although walking on a street may be allowed, it may however be unpleasant or 
> even unsafe to really do so. But this physical reality should, IMHO, be 
> reflected in a separate (afaik still non-existant) tag, like "walkable=1-3" 
> or so. This could then be taken into account by routers when calculating 
> alternative routes between to points. But that certainly goes beyond this 
> thread.
> 
> I would, in consequence, support the deactivation of the task in its current 
> form.
> 
> _

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

apart from underpasses, bridges also intersections and similar
constructs. They need not be trunk/motorroad.

For example many road segments at Deichtorplatz and inner lanes of
Willi-Brandt-Straße in Hamburg:
https://www.openstreetmap.org/#map=18/53.54762/10.00345

On 14/02/2019 17:03, Philip Barnes wrote:
> 
> 
> On 14 February 2019 15:05:56 GMT, Rory McCann  wrote:
>> I can't find any issue on Github for this feature.
>>
>> But in Ireland (& I think UK), all public roads except motorways, are 
>> foot=yes. Legally you can walk on the road, even if there is not 
>> footpath ("sidewalk"). I think this adds bloat and quests which will 
>> annoy mappers.
> 
> You are correct Rory, in the UK you can normally walk (or cycle) on all non 
> motorways. There are a few exceptions but these will be trunk, never ever 
> residential, and will be associated with underpasses or bridges. 
> 
> Would anyone live somewhere you are legally not allowed to walk to your 
> house? 
> 
> Phil (trigpoint) 
> 
> 
> 
> 
>>
>> On 14/02/2019 10:26, Florian Lohoff wrote:
>>>
>>> Hi,
>>> i am seeing a growing number of changesets setting foot=yes
>>> on all kinds of roads e.g. residential
>>>
>>> https://www.openstreetmap.org/way/403719315
>>>
>>> Commit message is:
>>>
>>> "Add whether roads are accessible for pedestrians"
>>>
>>> All residentials are accessible to pedestrians so i a bit puzzled
>>> what this challenge is good for. It just adds redundant tags to
>>> all roads.
>>>
>>> Flo
>>
>>
>> ___
>> 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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Wrong thread?

Anyway, the quest in StreetComplete only asks for foot=yes/no if the
road is tagged with sidewalk=no.

On 14/02/2019 15:44, Volker Schmidt wrote:
> ... and just to make this even trickier:
> The access tag is (in most cases) about legal access, and not about
> is-it-a-good-idea-to-route-a-pedestrian-along-this-road access.
> That has to be underlined. In my part of the world most roads, even with
> a lot of traffic and without sidewalk are legally open to pedestrians,
> but if they take the road their chance of survival is low.
> Add to the mix that, in my part of the world, almost all roads have no
> sidewalk tag nor separate parallel footways, even if these are present.
> I don't think it's a good idea to add foot=yes to underline what is
> already the default. It would make more sense to tag foot=use_sidepath
> for those cases where there is a sidewalk _and_ pedestrians a legally
> required to use it, and use, obviously, foot=no for those cases where
> there it is against the law to walk on the street (for roads where the
> default is foot=yes)
> 
> 
> On Thu, 14 Feb 2019 at 14:49, Tobias Zwick  <mailto:o...@westnordost.de>> wrote:
> 
> I don't take dismissive and generalizing statements on a project I have
> been putting 3+ years of lifeblood into, invest much of my free time in
> and offer as open source for the betterment of OSM, lightly.
> 
> If you have a concrete constructive suggestion to make, do it,
> otherwise, save your breath.
> 
> Tobias
> 
> On 14/02/2019 11:45, Wiklund Johan wrote:
> > I think that apps adding redundant tags to cover for a tiny number
> of special cases is going to cause more problems than it solves
> (i.e. users misinterpreting the question and adding "private" access
> to all kinds of roads). StreetBloat instead of StreetComplete :)
> >
> > -Original Message-
> > From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com
> <mailto:dieterdre...@gmail.com>]
> > Sent: torsdag 14. februar 2019 10.36
> > To: Tag discussion, strategy and related tools
> mailto:tagging@openstreetmap.org>>
> > Subject: Re: [Tagging] StreetComplete 10 / foot=yes on residential
> >
> >
> >
> > sent from a phone
> >
> >> On 14. Feb 2019, at 10:26, Florian Lohoff  <mailto:f...@zz.de>> wrote:
> >>
> >> All residentials are accessible to pedestrians so i a bit puzzled
> what
> >> this challenge is good for. It just adds redundant tags to all roads.
> >
> >
> > I agree the default is accessibility for everyone on non-motorroad
> roads. There might be residential roads with private access (in the
> occasions I met where access was private I was tending towards
> service, although with general public access I would have called
> them residentials).
> >
> > Cheers, Martin
> > ___
> > 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 <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] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

I don't take dismissive and generalizing statements on a project I have
been putting 3+ years of lifeblood into, invest much of my free time in
and offer as open source for the betterment of OSM, lightly.

If you have a concrete constructive suggestion to make, do it,
otherwise, save your breath.

Tobias

On 14/02/2019 11:45, Wiklund Johan wrote:
> I think that apps adding redundant tags to cover for a tiny number of special 
> cases is going to cause more problems than it solves (i.e. users 
> misinterpreting the question and adding "private" access to all kinds of 
> roads). StreetBloat instead of StreetComplete :)
> 
> -Original Message-
> From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
> Sent: torsdag 14. februar 2019 10.36
> To: Tag discussion, strategy and related tools 
> Subject: Re: [Tagging] StreetComplete 10 / foot=yes on residential
> 
> 
> 
> sent from a phone
> 
>> On 14. Feb 2019, at 10:26, Florian Lohoff  wrote:
>>
>> All residentials are accessible to pedestrians so i a bit puzzled what 
>> this challenge is good for. It just adds redundant tags to all roads.
> 
> 
> I agree the default is accessibility for everyone on non-motorroad roads. 
> There might be residential roads with private access (in the occasions I met 
> where access was private I was tending towards service, although with general 
> public access I would have called them residentials).
> 
> Cheers, Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

With this information given, the question is, whether

  highway=residential + sidewalk=no

implies a

  foot=yes

. And with implies, I mean, that it is considered *duplicate
information* if this is tagged. Note that This is different to an
unspecified information which can with relative certainty be assumed (by
data consumers) to be X. ( See also
https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#Why_does_StreetComplete_often_tag_the_absence_of_features.3F)

I am unsure about this myself, it's certainly not mentioned in the wiki,
but that doesn't have to mean anything.

What do you think?

Tobias

On 14/02/2019 14:25, Tobias Zwick wrote:
> Yes, there is a new quest in v10, which tags foot=yes/no. It is no
> problem to make changes on it, but let me first provide some information
> on it first, so we have a common basis to discuss:
> 
> For any street that has been tagged as having no sidewalk, the
> StreetComplete asks the surveyor:
> 
> "Is this street accessible for pedestrians here?
> 
> This street was tagged as having no sidewalk on either side. So, the
> street is only accessible on foot if people may walk on the street
> itself or there is enough space to walk beside it."
> 
> When the surveyor answers "yes", foot=yes is tagged.
> 
> The rationale behind collecting this information is, that if a street is
> explicitly surveyed as having no sidewalk, it is no longer implicated
> that naturally the street is accessible on foot (foot=yes). Roads
> explicitly signed as motorroads are not the only roads that are not
> accessible on foot.
> 
> And this is an important information for pedestrian routers and maybe a
> useful information for car routers (because they might want to prefer
> routes without the sidewalk=no + foot=yes combination).
> 
> Tobias
> 
> On 14/02/2019 10:26, Florian Lohoff wrote:
>>
>> Hi,
>> i am seeing a growing number of changesets setting foot=yes
>> on all kinds of roads e.g. residential
>>
>> https://www.openstreetmap.org/way/403719315
>>
>> Commit message is:
>>
>> "Add whether roads are accessible for pedestrians"
>>
>> All residentials are accessible to pedestrians so i a bit puzzled
>> what this challenge is good for. It just adds redundant tags to
>> all roads.
>>
>> Flo
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Tobias Zwick]

Yes, there is a new quest in v10, which tags foot=yes/no. It is no
problem to make changes on it, but let me first provide some information
on it first, so we have a common basis to discuss:

For any street that has been tagged as having no sidewalk, the
StreetComplete asks the surveyor:

"Is this street accessible for pedestrians here?

This street was tagged as having no sidewalk on either side. So, the
street is only accessible on foot if people may walk on the street
itself or there is enough space to walk beside it."

When the surveyor answers "yes", foot=yes is tagged.

The rationale behind collecting this information is, that if a street is
explicitly surveyed as having no sidewalk, it is no longer implicated
that naturally the street is accessible on foot (foot=yes). Roads
explicitly signed as motorroads are not the only roads that are not
accessible on foot.

And this is an important information for pedestrian routers and maybe a
useful information for car routers (because they might want to prefer
routes without the sidewalk=no + foot=yes combination).

Tobias

On 14/02/2019 10:26, Florian Lohoff wrote:
> 
> Hi,
> i am seeing a growing number of changesets setting foot=yes
> on all kinds of roads e.g. residential
> 
> https://www.openstreetmap.org/way/403719315
> 
> Commit message is:
> 
> "Add whether roads are accessible for pedestrians"
> 
> All residentials are accessible to pedestrians so i a bit puzzled
> what this challenge is good for. It just adds redundant tags to
> all roads.
> 
> Flo
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

I stumbled upon a real-world example yesterday that may make the attempt
to have the level-tag describe a "global" order (as used in OpenLevelUp,
JOSM etc.) somewhat impractical -  with that level-selector UI element:

So, Hamburg is a really flat city. And even still, the mall "Europa
Passage" ...
https://www.openstreetmap.org/way/214840502#map=17/53.55223/9.99644
... does have two "ground floors". If you enter through the northern
entrance, you are in the lower ground floor (level=0), if you enter
through the southern entrance, you are in the upper ground floor
(level=1). If you walk alongside the mall though (Bergstraße), there is
no (apparent) elevation.

So, imagine there are more indoor-mapped places both around the northern
and the southern end of that mall (there is, partly, but I am sparing
you the details), and as a matter of fact, sprinkled throughout the
entire city centre.
Then, to have a global order of things, the ground floor of all the
buildings South of that mall would need to be tagged with level=1 and
the ground floor of all the buildings North of this mall would need to
be tagged with level=0. In other words, must be relative to the level
order used in this building.

I see two problems with this:

1. Where to stop? How global is this global order? Going further South,
at what point does the level-value for the ground floor revert back to
0? What then if two such places collide? (A mall and a multi-level train
station were mapped separately and they built a tunnel to connect the
two, but they connect on different level=X - or not even a tunnel, let's
say they are just next to each other)

2. It is somewhat confusing for the user (and the mapper) because if you
look at such a map, at for example level=0, you would see an unexpected
split through the city centre where seemingly no building is
indoor-mapped South of that mall ... oh wait, it's all on level=1+.  ???

I, too, hope that the example was understandable.

Tobias

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

[Tagging] weight limit in short tons

[Tobias Zwick]

Hey there, as I was illustrating the
https://wiki.openstreetmap.org/wiki/Key:maxweight
article with some example signs and notes about pitfalls, I noticed that
the wiki says here that the weight *must always* be defined in metric units.

So, I also added a row in the examples table about the short tons to
metric tons conversion.

But now, I am wondering, if the claim "As per Map Features:Units, as of
September 2014 only metric units of weight (metric tonnes or kilograms)
are supported for this tag." is not a mistake.

Because...
1. https://wiki.openstreetmap.org/wiki/Map_Features/Units mentions "st"
(short tons) as a unit
2. there is also "mph" for speed limits
3. it seems that this rule would unnecessarily complicate the mapping in
the United States

Does anyone know anything about (a decision) that the weight may only be
specified in metric? Or was there a misinformed wiki-fiddler at work?

Cheers
Tobias

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

On 22/01/2019 10:47, Lionel Giard wrote:
> So, i'm really in favor of the level=* for a "data user friendly" tag
> (that could correspond to local numbering, but not always) and a special
> tag for the local levels. At this moment i would see a *local level tag
> *like "level:ref=*" or "loc_level=*" (like we have for name and loc_name
> ?) but _*on each object*_, as it would not be realistic to use an
> outline in the cases i present). 
> 
> PS: i hope my example is not too confusing, or badly explained. :-)

I understand it. (To recap - ) you are giving a real-life example of
what Roland described: Using the level tag outside of (a single)
building but in a wider scope.
To be able to show on indoor maps what is really on the same level on a
scope that exceeds single buildings, you need to use the level-tag also
in a scope that exceeds single buildings, making it important that the
level indices of (neighbouring) buildings match.

So, basically, your example is like a situation where two malls are
connected by a footbridge, but one mall labels its level there as "UG"
and the other as "M".[1]
If the level tag was allowed to be non-numerical and required to always
follow the building operator's denomination even if they are letters and
not numbers, the information on what buildings (and non-buildings like
footbridges, train stops, tunnels etc.) connect to each other is lost.

This is an interesting point. I agree, this is important information for
an indoor-map.
And from this standpoint, your suggestion to allow "level:ref" on single
shops within one building as a replacement for "level" sounds like a
good solution to accommodate for the points I made.

---

So, though, this means that (already now), the level tag enjoys somewhat
of a dual-usage:
- On the one hand, it should follow the building operator's denomination
  as long as it is numeric, thus, is or comes close to how the level is
  really named "on the ground"
- On the other hand, in a wider context, it is used similarly to the
  layer tag: An arbitrary ("programmer's") value to arrange a Z-order.

I think this dual usage may come back to bite us.

First, I am still in the dark a bit how this affects SIT with S3DB
compatibility, perhaps Tordanik can explain. After all, a clearly
defined global Z-Order of things would be in the best interest of
3d-rendering, but he mentioned that this is not how the level tag was
intended (for SIT).

Second, why can not the layer tag be used to arrange the global z-order
of things?

Regards
Tobias


[1] By the way: The most complex example of such a situation I know is
Pathum Wan (ปทุมวัน) junction in central Bangkok, a multi-level skytrain
station, five different malls and a culture centre connect with each
other with various footbridges. Photos:
http://www.komchadluek.net/photo-gallery/512

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

On 21/01/2019 09:19, PanierAvide wrote:
> Just for your information, there is also this "level:ref" tag which was
> used in various context to solve this problem 

I know of "level:ref". However, on the SIT wiki page, "level:ref" is
documented as a tag for the level-outline tagged with "indoor=level",
not as an alternative to "level" on each individual shop.

So, it is possible to make the connection between the index and the
level denomination, but it is not exactly straightforward. I just wrote
a longer description (of the problem) on another branch:
https://lists.openstreetmap.org/pipermail/tagging/2019-January/042369.html

Regards
Tobias

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

On 20/01/2019 23:39, Tobias Knerr wrote:
> The main challenge I see with your proposal, though, is that the
> levels=* tag on the building would be utterly required to make any sense
> of the order of floors. Without it, applications would have no idea
> whether "M" is above or below "P2", for example. So at the very least,
> adding levels=* should explicitly be documented as mandatory when using
> non-standard levels.

Yes, the levels=* would be mandatory for proper ordering in those cases
where the floor levels are not numerical. For places where it is
numerical, nothing changes. It'd be an extension after all.

Consider: For places where they are not numerical, only
levels="LG,UG,M,1,2" on the building (part) outline is required to allow
tagging shops with a non-numerical level, nothing more.

In the current SIT scheme*, in this case, it is required to add 5
additional outlines, one for each floor (indoor=level), and tag each
with a level-index (level) and floor denomination (level:ref) in order
to create the relation between the level-indices as tagged on each
individual shop and the actual floor denomination.
In other words, to map a mall with non-numerical floor numbers already
requires to use the stuff described under "advanced modelling", and it
is more than one tag, it is 5 times "level" and 5 times "level:ref".

Additionally, one has to tag each shop not with the actual floor
denomination, but with the said level-index referenced in each floor
outline.
In the described case of non-numerical floors, the level-index becomes a
purely virtual ("programmer's") value which only becomes meaningful when
all the data is put together. And apart from making the machine
understand the relation between index and ref, the mapper himself needs
to make the conversion (in his head - .oO("UG is 0", "M is 1", "1 is
2",...)) for every shop he maps as well, which is prone to error,
especially with sporadic contributors.
In a nutshell, mappers and software are expected to know and use the
(advanced) SIT scheme if they "just" want to map on which floor a shop
is located.

I do not want to sound so combative or negative here - to reason for why
a new tag may be useful, I just need to describe the problem. I want us
all to be on the same page.

* as far as I understand it, correct me if I am wrong

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

>> - also the building with "ground_level=G" to define which level is
>>   the ground level. If ground_level is missing, 0 is assumed.
>>
> Do we really need a ground level? I think not. We need connections to
> outside ways and entrances.

Well, all of which I mentioned is optional. But I can come up with two
use cases for wanting to know which level is the ground level:

1. Localization

In an application, it is much nicer to be able to write
"ground floor" (en-GB), "first floor" or "basement floor 2"
than
"level 0", "level M" or, worst, "level -1"

To refer to a "level" may be even less understandable when trying to
translate that into other languages.

But for this to work, it is necessary for the application to know which
level is the ground floor.

2. 3D indoor levels

When displaying the floors of a multi-storey building in 3D on top of
each other, you need to know where on the Z-Axis you have to place it.

Tobias

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

> So from a SIT perspective, the problem isn't that the US (and other
> places) call the ground level "1". It's that the level below that is
> called "-1" rather than "0". You could still make it compatible with
> Simple Indoor Tagging by adding a skipped_levels=0 tag to the building,
> but this tag has only been used five times so far.

skipped_levels is also pretty awkward because one needs to recalculate
the indexed (OSM) level from the real (on the ground) level all the
time. Even worse if the levels are not actually numbers on the ground
but letters or something else (like in that mall in Bangkok).

If SIT (and by consensus in the SotM 2016 indoor session) encourages to
use the level numbering scheme of the building operator, why keep the
"tied to numbers" requirement?

Someone mentioned earlier in a diary discussion a pretty nice
solution[1]. So, in a mall with the levels P2,P1,G,M,1-12,14-99 one
simply tags:

- a shop on level M with "level=M"

- the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
  levels). If levels is missing, a numerical order is assumed

- also the building with "ground_level=G" to define which level is
  the ground level. If ground_level is missing, 0 is assumed.

I find this would have the following advantages while completely
compatible with the current SIT scheme and has no disadvantages (I can
come up with):

1. The correct denomination of the floor is always directly tagged on
   the shop -> much easier for end-user apps to display the correct
   floor for a shop because no special SIT software support is necessary

2. no calculating forth- and back between level "indices" and real names
   for the levels (for neither the software nor the mapper) because this
   effectively eliminates the concept of indices:

   a) thus avoids the whole 0-index-based vs 1-index-based problematic
  that I started this thread with.

   b) thus no workarounds like non_existent_levels necessary

What do you think about this?

[1]
https://www.openstreetmap.org/user/Anton%20Khorev/diary/46933#comment43565

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

On 20/01/2019 18:06, Roland Olbricht wrote:
> we have here in Wuppertal, Germany at least three indoor-tagged
> structures that have street level entrances at multiple levels, making
> "street level" a not-at-all defined concept. In case of the university
> e.g. the main entrance is on level 7, and street level entrances range
> from levels 2 to 10. I am also aware of dozens of buildings across
> Europe with "street level entrance" on multiple levels.

Defining what is the ground level wouldn't be the problem, and it is
necessary for S3DB for building:levels anyway. As far as I remember, it
is "the lowest level that has a (normal) entrance from the street".

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

Re: [Tagging] The actual use of the level tag

[Tobias Zwick]

Maybe. My point though is that the (un)intuitiveness of this definition
will be a constant source of error because as shops close and new shops
open, the data is changing and thus the potential for error remains.
(With incomplete software support.)

Turns out, it is even a problem in countries where the ground floor is
level 0. I was just researching what floor numbering scheme Thailand
follows by looking at mall maps in Bangkok and found that it is common
for malls to have a storey named "M" between "G" and "1"
( https://www.emporium.co.th/directory/ ), making it as mistake-prone as
mapping a mall in the US.

On 20/01/2019 16:16, Tobias Knerr wrote:
> On 20.01.19 14:49, Tobias Zwick wrote:
>> 2. generally, tagging definitions that are not intuitive to use (in a
>> region) will not be used consistently (in that region), leading to
>> ambiguous data.
> 
> I believe the high number of (potential) errors is temporary, resulting
> from the relative lack of software support for indoor mapping. Once
> application support is commonplace, mappers will likely notice that it
> "renders wrong", and fix their data accordingly. Proper editor support
> would be valuable, too, of course.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] The actual use of the level tag

[Tobias Zwick]

Hi there,

In the wiki, the level tag is defined to be a 0-based-index so that
level=0 is the ground floor, i.e. at the street level. In other words, a
two-storey mall with no basement will have shops at level=0 and level=1.

This is intuitive for (at least) Europeans, people from Commonwealth
countries and parts of Asia as this coincides with common language.
However, in at least the USA, Canada, Japan, Korea, China and most
probably more regions, the floor at street level is denominated as the
"1st floor" in common language. In other words, it is a 1-based-index.

To my knowledge, no editor (neither iD nor JOSM) and no user-end
application takes this into account and localizes the level tag to
common language (properly). Instead, it is assumed that everybody knows
about this and adheres to this scheme.

This is why I suspect that despite it being mentioned several times in
the wiki, the level tag is not used the way it was defined in those
regions where the definition of the level tag to be 0-index-based does
not coincide with common language. Deliberately, or unwittingly.

So, I did a little research.

Via overpass, I searched for multi-storey malls in some metropolitan
regions where the first floor is at street level and looked at with
which levels the shops inside were tagged.

Results
===

Region| likely zero-based | likely one-based
--|---|-
Washington, Philadelphia, NY  | 3 |2
Silicon valley, Los Angeles   | 4 |4
Quebec, Montreal, Ottawa  | 6 |0
Moscow|23 |   51
Tokyo |14 |   16
Seoul | 0 |2
Bangkok   | 8 |5
--|---|-

For comparison:
whole Phillipines |23 |4
whole Netherlands |11 |2
Berlin|19 |2

*likely zero-based: there was at least one shop tagged with level=0
*likely one-based: there was no shop tagged with level=0 but shops at at
   least two different other levels

Note that cases where mappers did not add level=0 to shops at street
level because they thought level=0 is the default and should not need to
be specified would be counted as "likely one-based" in above table.

Conclusions
===
Two immediate conclustions can be made:

1. user-end software cannot reliably assume that level=0 is the ground
level in certain regions because the data is not mapped consistently
according to the wiki definition

2. generally, tagging definitions that are not intuitive to use (in a
region) will not be used consistently (in that region), leading to
ambiguous data.

Regards
Tobias

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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

Oh, you are right. I am sorry. So that opening hours tool understands
more than what is defined in the specification.

On 13/10/2018 12:35, Simon Poole wrote:
> 
> 
> Am 13.10.2018 um 00:46 schrieb Tobias Zwick:
>> It is already part of the specification that "Mo-Fr 9-17" is possible.
> 
> Actually it isn't, see
> https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
> 
> I don't think discussing changes to the opening_hours grammar is this
> thread is a sensible thing to do, most of the changes proposed are not
> unambigously parseable and would require us to rely even more on
> heuristics than we do now to make sense of the values. There a small
> number of additions that could make sense and make things easier
> (seasons and some more variable holidays), but they tend to fit in to
> the existing schema.
> 
> Simon
> 
> 
>> Alas, QA tools / the openinghours evaluation tool emit a warning in this
>> case: "Time range without minutes specified. Not very explicit! Please
>> use this syntax instead "9:00-17:00"."
>> Not sure why that is not seen as explicit.
>>
>> On 12/10/2018 22:29, bkil wrote:
>>> That looks like a nice improvement.
>>>
>>> Additionally, I've always wondered why we need to enter :00 after
>>> every hour and zero pad the hours? The shops themselves usually post
>>> the opening hours as 9-17 - why can't we use this human friendly
>>> abbreviation? I don't feel that it would be that much harder to parse.
>>> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
>>> unambiguous (though, the latter looks a bit uglier at first).
>>>
>>> I think this would greatly improve readability, make data entry faster
>>> and less error prone and shorten the field all at the same time.
>>>
>>> Is this fit for a proposal?
>>>
>>> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>>> On 10/11/18 11:47 PM, Jmapb wrote:
>>>>> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>>>>>
>>>>>> Hey there!
>>>>>>
>>>>>> So, a user of StreetComplete came across the following complicated
>>>>>> opening hours for a shop (prettified):
>>>>>>
>>>>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>>>>> Jun-Sep: Su 10:00-12:00;
>>>>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>>>>>> Nov-Mar: Sa 10:00-12:00;
>>>>>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>>>>>> Apr-May: Sa 10:00-12:30;
>>>>>> Apr-May: Su 10:00-12:00;
>>>>>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>>>>> Oct: Sa 10:00-12:30;
>>>>>> Oct: Su 10:00-12:00
>>>>>>
>>>>>> Unfortunately, this does not fit into the opening_hours value, as this
>>>>>> is limited to 255 characters. What can we do?
>>>> Hey :)
>>>>
>>>> I would say your best bet is to try to shorten the opening_hours values 
>>>> using
>>>> every little trick that the syntax has to offer, for example you can join 
>>>> the
>>>> month ranges which is enough to bring you under 255 characters.
>>>>
>>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>>>> Nov-Mar: Sa 10:00-12:00;
>>>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>>> Apr-May,Oct: Sa 10:00-12:30;
>>>> Apr-May,Jun-Oct: Su 10:00-12:00
>>>>
>>>> You can then use the "value to compare to the first value:" feature of
>>>> https://openingh.ypid.de/evaluation_tool/ to check that you still 
>>>> preserved the
>>>> original meaning.
>>>>
>>>> I don’t have much to add in case you can not bring the value under 255 
>>>> only that
>>>> I also don’t know any software which would handle that. I guess having the
>>>> special cases in an additional tag and `opening_hours` fully valid would 
>>>> be best
>>>> then.
>>>>
>>>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
>>>> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
>>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
>>>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>>>>
>>>> This won’t work. I had an idea for doing that but this is not supported 
>>>> yet:
>>>> https://github.com/opening-hours/opening_hours.js#todo
>>>>
>>>> --
>>>> Live long and prosper
>>>> Robin `ypid` Schneider -- https://me.ypid.de/
>>>>
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

It is already part of the specification that "Mo-Fr 9-17" is possible.
Alas, QA tools / the openinghours evaluation tool emit a warning in this
case: "Time range without minutes specified. Not very explicit! Please
use this syntax instead "9:00-17:00"."
Not sure why that is not seen as explicit.

On 12/10/2018 22:29, bkil wrote:
> That looks like a nice improvement.
> 
> Additionally, I've always wondered why we need to enter :00 after
> every hour and zero pad the hours? The shops themselves usually post
> the opening hours as 9-17 - why can't we use this human friendly
> abbreviation? I don't feel that it would be that much harder to parse.
> (9-17h would also work for me) 9-17:30 and 9:30-17 are still
> unambiguous (though, the latter looks a bit uglier at first).
> 
> I think this would greatly improve readability, make data entry faster
> and less error prone and shorten the field all at the same time.
> 
> Is this fit for a proposal?
> 
> On Fri, Oct 12, 2018 at 12:04 AM Robin Schneider  wrote:
>>
>> On 10/11/18 11:47 PM, Jmapb wrote:
>>> On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>>>
>>>> Hey there!
>>>>
>>>> So, a user of StreetComplete came across the following complicated
>>>> opening hours for a shop (prettified):
>>>>
>>>> Jun-Sep: Mo-Sa 10:00-18:00;
>>>> Jun-Sep: Su 10:00-12:00;
>>>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>>>> Nov-Mar: Sa 10:00-12:00;
>>>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>>>> Apr-May: Sa 10:00-12:30;
>>>> Apr-May: Su 10:00-12:00;
>>>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>>>> Oct: Sa 10:00-12:30;
>>>> Oct: Su 10:00-12:00
>>>>
>>>> Unfortunately, this does not fit into the opening_hours value, as this
>>>> is limited to 255 characters. What can we do?
>>
>> Hey :)
>>
>> I would say your best bet is to try to shorten the opening_hours values using
>> every little trick that the syntax has to offer, for example you can join the
>> month ranges which is enough to bring you under 255 characters.
>>
>> Jun-Sep: Mo-Sa 10:00-18:00;
>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00,15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;
>> Apr-May,Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>> Apr-May,Oct: Sa 10:00-12:30;
>> Apr-May,Jun-Oct: Su 10:00-12:00
>>
>> You can then use the "value to compare to the first value:" feature of
>> https://openingh.ypid.de/evaluation_tool/ to check that you still preserved 
>> the
>> original meaning.
>>
>> I don’t have much to add in case you can not bring the value under 255 only 
>> that
>> I also don’t know any software which would handle that. I guess having the
>> special cases in an additional tag and `opening_hours` fully valid would be 
>> best
>> then.
>>
>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar:
>> Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr
>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr
>> 10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>>
>> This won’t work. I had an idea for doing that but this is not supported yet:
>> https://github.com/opening-hours/opening_hours.js#todo
>>
>> --
>> Live long and prosper
>> Robin `ypid` Schneider -- https://me.ypid.de/
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] Opening hours too long for OSM

[Tobias Zwick]

Regarding the general workaround of defining some common tag extension
scheme, the idea sounds good at first, but I think this cannot be the
solution after all.
Because, let's not fool ourselves, the application support for an
extension syntax will be almost non-existent. Just look at the support
for things like shop=books;stationery. Also, all QA-Tools will complain
about opening_hours or any other tag normally containing structured data
that is split along several keys to be wrong.

I think this can only be solved effectively centrally, and since Simon
mentioned an earlier ticket in openstreetmap-website, I opened a ticket
to request this:

https://github.com/openstreetmap/openstreetmap-website/issues/2025

On 11/10/2018 23:21, Tobias Zwick wrote:
> Hey there!
> 
> So, a user of StreetComplete came across the following complicated
> opening hours for a shop (prettified):
> 
> Jun-Sep: Mo-Sa 10:00-18:00;
> Jun-Sep: Su 10:00-12:00;
> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;
> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
> Apr-May: Sa 10:00-12:30;
> Apr-May: Su 10:00-12:00;
> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
> Oct: Sa 10:00-12:30;
> Oct: Su 10:00-12:00
> 
> Unfortunately, this does not fit into the opening_hours value, as this
> is limited to 255 characters. What can we do?
> 
> Is there any generic way to treat an overflowing tag? Perhaps use a
> second key to store the rest, something like (in this case)
> 
> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00;Jun-Sep: Su
> 10:00-12:00;Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
> Nov-Mar: Sa 10:00-12:00;Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;Apr-May:
> Sa 10:00-12:30;Apr-May: Su 10:00-12:00;Oct: Mo-Fr
> 10:00-12:30,15:00-18:00;Oct: Sa 10
> opening_hours_1=:00-12:30;Oct: Su 10:00-12:00
> 
> ?
> 
> Greetings
> Tobias
> 
> ___
> 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] Opening hours too long for OSM

[Tobias Zwick]

>Do we really need to re-declare the month ranges each time? I would 
>think that
>
>   opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar: 
>Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
>...would work just as well. Seems to pass muster at 
>openingh.openstreetmap.de and it's a svelte 251 chars.

Unfortunately, that does not work. According to the specs, every rule must 
specify its own months range. If you don't, that rule applies throughout the 
whole year. E.g.

Jun: Mo-Sa 10:00-18:00; Sun 10:00-12:00

is interpreted as "open Mo-Sa 10-18 o'clock in June, always open on Sunday 
10-12 o'clock".

Tobias 

Am 11. Oktober 2018 23:47:06 MESZ schrieb Jmapb :
>On 10/11/2018 5:21 PM, Tobias Zwick wrote:
>
>> Hey there!
>>
>> So, a user of StreetComplete came across the following complicated
>> opening hours for a shop (prettified):
>>
>> Jun-Sep: Mo-Sa 10:00-18:00;
>> Jun-Sep: Su 10:00-12:00;
>> Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;
>> Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
>> Apr-May: Sa 10:00-12:30;
>> Apr-May: Su 10:00-12:00;
>> Oct: Mo-Fr 10:00-12:30,15:00-18:00;
>> Oct: Sa 10:00-12:30;
>> Oct: Su 10:00-12:00
>>
>> Unfortunately, this does not fit into the opening_hours value, as
>this
>> is limited to 255 characters. What can we do?
>>
>> Is there any generic way to treat an overflowing tag? Perhaps use a
>> second key to store the rest, something like (in this case)
>>
>> opening_hours=Jun-Sep: Mo-Sa 10:00-18:00;Jun-Sep: Su
>> 10:00-12:00;Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
>> Nov-Mar: Sa 10:00-12:00;Apr-May: Mo-Fr
>10:00-12:30,15:00-18:00;Apr-May:
>> Sa 10:00-12:30;Apr-May: Su 10:00-12:00;Oct: Mo-Fr
>> 10:00-12:30,15:00-18:00;Oct: Sa 10
>> opening_hours_1=:00-12:30;Oct: Su 10:00-12:00
>>
>> ?
>>
>> Greetings
>> Tobias
>>
>
>Do we really need to re-declare the month ranges each time? I would 
>think that
>
>   opening_hours=Jun-Sep: Mo-Sa 10:00-18:00; Su10:00-12:00; Nov-Mar: 
>Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00; Sa 10:00-12:00; Apr-May: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30; Su 10:00-12:00; Oct: Mo-Fr 
>10:00-12:30,15:00-18:00; Sa 10:00-12:30;Oct: Su 10:00-12:00
>
>...would work just as well. Seems to pass muster at 
>openingh.openstreetmap.de and it's a svelte 251 chars.
>
>This doesn't answer the real question of course, because certainly 
>longer values are possible, especially when exceptions for holidays etc
>
>are tacked on. Lengthening the field would be great, but failing that I
>
>suppose opening_hours_1 is an ok stopgap, though it's unlikely there's 
>any end-user software that will look for it. One thing I'd recommend, 
>though, is not to end truncate the value mid-clause. In your example, 
>I'd probably put all of October in opening_hours_1 so that the standard
>
>opening_hours tag is correct and parseable on its own.
>
>J
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Opening hours too long for OSM

[Tobias Zwick]

Hey there!

So, a user of StreetComplete came across the following complicated
opening hours for a shop (prettified):

Jun-Sep: Mo-Sa 10:00-18:00;
Jun-Sep: Su 10:00-12:00;
Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
Nov-Mar: Sa 10:00-12:00;
Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
Apr-May: Sa 10:00-12:30;
Apr-May: Su 10:00-12:00;
Oct: Mo-Fr 10:00-12:30,15:00-18:00;
Oct: Sa 10:00-12:30;
Oct: Su 10:00-12:00

Unfortunately, this does not fit into the opening_hours value, as this
is limited to 255 characters. What can we do?

Is there any generic way to treat an overflowing tag? Perhaps use a
second key to store the rest, something like (in this case)

opening_hours=Jun-Sep: Mo-Sa 10:00-18:00;Jun-Sep: Su
10:00-12:00;Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
Nov-Mar: Sa 10:00-12:00;Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;Apr-May:
Sa 10:00-12:30;Apr-May: Su 10:00-12:00;Oct: Mo-Fr
10:00-12:30,15:00-18:00;Oct: Sa 10
opening_hours_1=:00-12:30;Oct: Su 10:00-12:00

?

Greetings
Tobias

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

Re: [Tagging] Arboretum - how to tag?

[Tobias Zwick]

Well, an Arboretum is a "botanical tree garden", is it not? So why not
leisure=garden (+ maybe additional tags, see wiki article)?

On 10/10/2018 11:47, Warin wrote:
> Hi
> 
> I have an arboretum, Way: Arboretum (628753725), that is part of a
> nature reserve and within a tree covered area. I assume that there is
> more than one species of tree.
> 
> How to correctly tag it?
> 
> At the moment it has
> 
> landuse=yes (what brought it to my attention)
> 
> name=Arboretum
> 
> Clearly both these tags are incorrect.
> I have confirmed that it is anarboretum so at least that bit is true.  
> 
> ___
> 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] Map a divide?

[Tobias Zwick]

The definition in the wiki is a bit contradictory, in my opinion. On the one 
side, it states the thing about that the arrows should point away from the 
saddle point towards the peaks, like steps or a oneway street, on the other 
side it describes a ridge to connect several peaks and saddle points. Tagging 
the whole ridge as one way would be impossible if you followed that "arrow 
points upward" rule.

There is also no mention of that rule in the original approved proposal. 
Looking at the history of the article, that rule was added in January 2018, 
following a short, well "discussion" about how a ridge could be rendered.
The change made amounts to a incompatible, as your enquiry shows, redefinition 
of the ridge tag because one cannot anymore correctly tag a whole ridge as one 
way.

We have two options to go from here:
1. Revert that definition change, continue to allow tagging ridges as one way  
spanning over several peaks
2. Leave the wiki definition as it is currently and you tag "name=Catskill 
Divide" on every of the multiple natural=ridge ways you'd have to create along 
the whole way

I'd favour the first option because 
1. Redefinition of an existing tag is a no go
2. The reason why the definition was changed was to make it easier to render a 
ridge in a certain suggested way. Don't know if it is even rendered this way 
now (on osm-carto), but in any case this'd be tagging for the renderer, as the 
information where the ridge goes up and where it goes down is already present 
in the peak/saddle nodes

Cheers 
Tobias 

Am 4. Oktober 2018 16:46:19 MESZ schrieb Kevin Kenny :
>In some maps that I render, I want to show the divide between a couple
>of major river basins. (I have a good DEM for the area in question and
>can derive the line readily.)
>
>In light of the recent thread on topographic prominence, I wonder if
>this is sufficiently interesting information at least to push it to
>OSM. (If not, that's fine, I have a PostGIS database and a bucket of
>shapefiles and know what to do.)
>
>If it is sufficiently interesting, the question then arises: how to
>map/tag it?
>
>'natural=ridge' comes to mind, and the divide in question has a local
>name. (The 'Catskill Divide' separates the basins of the Hudson and
>Delaware Rivers.) This approach appears to run into problems, as I
>read the Wiki. I see:
>
>> The way should connect saddle points and peaks, and the arrows should
>point upwards.
>
>That may be all right for a ridge ascending the flank of a single
>mountain, but what I'm talking about is the spine of a range, with the
>ridge traversing dozens of named peaks. Even with a single mountain,
>if there are false summits, the arrows on a single way cannot point
>upward all the time! (And the wiki is clear that the
>
>Do I misread, and should the reading instead simply be that the
>arrowhead should be higher than the arrow tail? In that case, I could
>break the divide into two ways, with a common endpoint at the highest
>summit in the range.
>
>Consider this a low-priority item. I have (or will have - there is a
>bit of debugging yet) the data. I know how to render them. I'm happy
>enough with a shapefile or a private PostGIS table if others aren't
>interested.
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

[Tobias Zwick]

> the building=* tag helps define the rough purpose fo the building - but not 
> the exact purpose. The pin or other tags on the building do that. And that 
> building looks like it wants to sell food to tourists.  ^_^

Yes, true. Though I rather had something like building=gastronomic in mind, not 
building=restaurant.

Am 25. September 2018 02:54:02 MESZ schrieb John Willis :
>
>
>
>> On Sep 25, 2018, at 2:15 AM, Tobias Zwick  wrote:
>> 
>> I find it kind of unfitting to tag those as building=retail because
>the
>> kind of building is almost like a residential one (or like a hotel).
>
>the buildings look like a hotel (or was perhaps a hotel in the past) -
>but if it is just a restaurant now, then it is building=retail. 
>
>If it is a place where you can rent a private room to sleep, it is a
>building=hotel with a commercial landuse, a pin for the hotel, and
>another pin for the restaurant  (the lobby restaurant in hotels is
>usually a separate mappable place, as it’s purpose, operating hours,
>and access to the general public is different than the hotel itself. 
>
>there are all kinds of amenities - pubs, restaurants, bed&breakfasts,
>Ryokans, fast food shops, etc,  But if they take up the entire
>building, almost all of them would fall into building=retail or
>building=hotel.  you are tagging the purpose of the building - not it’s
>design, except in the rarest of cases. 
>
>the building=* tag helps define the rough purpose fo the building - but
>not the exact purpose. The pin or other tags on the building do that.
>And that building looks like it wants to sell food to tourists.  ^_^
>
>I understand the “rest stop” nature of the building - there are similar
>buildings in Japan, some larger complexes registered as official “road
>stations” often using the nickname "Oasis” with the government, and
>others that are merely private businesses that provide a place to sit
>and relax and enjoy a coffee - but mapping the small  private
>businesses that do this as anything other than a “cafe” or “restaurant”
>or “convenience store” is very very difficult without some larger
>complex with a larger landuse with more amenities. 
>
>http://www.nanmoku.ne.jp/modules/oasis/index.php?content_id=4/
><http://www.nanmoku.ne.jp/modules/oasis/index.php?content_id=4/>
>
>an official “Road station” on a very narrow road in the mountains. 
>
>http://michinoeki-shimonita.com <http://michinoeki-shimonita.com/>
>
>A pretty large road station down in the valley. 
>
>they are a collection of several shops and amenities - not a single
>building with a single purpose. 
>
>Javbw

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

[Tobias Zwick]

What about buildings like these though? (de: "Gasthof" / "Gaststätte" -
"guest yard" = tavern / "guest place" = restaurant)

https://noew.infomaxnet.de/data/imxplatformj/images/301_gasthof_fink_bad_erlach_1.jpg
http://www.norbert-maas.com/foto/800_tetzelstein-8889.jpg
https://www.harzinfo.de/fileadmin/Mediendatenbank/Bilder/Orte/Sankt_Andreasberg/Rinderstall.jpg
https://images.1000ps.net/images/motorradhotels/hotel_866_1.jpg

I find it kind of unfitting to tag those as building=retail because the
kind of building is almost like a residential one (or like a hotel).

Tobias

On 24/09/2018 05:37, Eugene Alvin Villar wrote:
> On Mon, Sep 24, 2018, 7:52 AM Martin Koppenhoefer,
> mailto:dieterdre...@gmail.com>> wrote:
> 
> I’ve recently used building=fast_food_restaurant
> but it is not used very often yet.
> 
> 
> Can you care to explain why building=retail is not enough detail? I
> would think that a combination of building=retail + amenity=fast_food
> (whether on the same polygon or on separate polygon + interior node) is
> already sufficient.
> 
> 
> 
> ___
> 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] JOSM error for a bus lane conditional

[Tobias Zwick]

Looks fine to me. Perhaps open an issue in the JOSM bugtracker?

On 23/09/2018 07:43, Warin wrote:
> Hi,
> 
> 
> There is a past entry of
> 
> lanes:bus:conditional=1 @ (Mo-Fr 06:00-10:00,15:00-19:00)
> 
> 
> That JOSM says is incorrect. There is a declared 2 lanes there on the way.
> 
> What is wrong with that tagging? One lane for buses between 6 to 10 and
> 15 to 19 hundred hours.
> 
> 
> 
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

Oh, I think you found an error in the default speed limits document. I
will go through the table from A to Z within the next few days or even
today to correct this at places where the gross vehicle weight is meant
instead of the actual weight. I guess then

  maxspeed:conditional=xx @ (weight > yy)

would be actual weight (de: "Gewicht") and

  maxspeed:conditional=xx @ (maxweight > yy)

would be max gross weight (de: "zulässiges Gesamtgewicht")?

The latter is not documented in the wiki. I would add it to the
conditional-documentation if everyone here thinks that "maxweight" is
the best conditional name to denote "max gross weight".

Tobias

On 22/09/2018 23:52, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 22. Sep 2018, at 23:48, Tobias Zwick  wrote:
>>
>> What do you mean, what is the difference?
>>
>> maxspeed:conditional=xx @ (weight > yy) would be the former or the latter?
> 
> 
> in German: zulässiges Gesamtgewicht vs. Gewicht
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] How to tag a building constructed for a gastronomic purposes?

[Tobias Zwick]

Hey there

Do you have suggestions what would be the appropriate building value for
a building constructed for gastronomic purposes only, such as a
restaurant/café/fast food/food courts etc?

In context of Europe, I am thinking of:
- inns/taverns (eating only) (de: "Gasthof"), for example in forests,
national parks or other touristic areas, or that typical one inn in a
village
- the fast food place around the corner (de: "Imbiss")
- restaurants and stalls at rest stops
- motorway restaurants, food courts
- staple food buildings (McDonalds etc)

Tobias

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