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

[Matthew Woehlke]

On 20/12/2020 08.54, ipswichmapper--- via Tagging wrote:
- What should be considered a crossing? If it is unmarked, is it a 
crossing at all? (Should all intersections be tagged as "unmarked 
crossings"? Are places with traffic islands (no kerbs) where people 
frequently cross considered as crossings even though they have no 
marking & no kerbs?)


FWIW, I would say a crossing is somewhere there is a clear expectation 
that people will cross the road. For example, where a sidewalk connects 
to the curb on either side of the road but there are no markings on the 
pavement would be an unmarked crossing. I've seen these in both aerial 
imagery and in person.


To respond to Paul's point, I would tend to think of "marking" as 
referring to markings *on the road pavement*, not just on the sidewalk.


--
Matthew

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

Re: [Tagging] surface=rock

[Matthew Woehlke]

On 21/11/2020 15.07, Joseph Eisenberg wrote:

My understanding about this is that there is a difference between British
English usage and American usage - especially in the western USA.

The English seem to have an idea that "rock" is for mostly solid, 
immobile "bedrock", while a "stone" is a mobile, separate piece of 
mineral which you might pick up if you are strong enough, or at least

move with a piece of heavy machinery. [...] But American English and
perhaps other dialects do not always maintain this distinction, in my
experience.

"I picked up one of the rocks from my stone driveway."

"Look at all these stones I pulled out of the river; sure is rocky in 
there!"


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Matthew Woehlke]

On 26/10/2020 15.19, Jeroen Hoek wrote:

On 26-10-2020 19:31, Matthew Woehlke wrote:

Alternatively, clients might look at the sort of highway running
through a parking area. A highway=tertiary is probably "street-side
parking", while a highway=service, service=parking_aisle probably is
not.


That's not a bad thought, but it would require connecting the
street-side parking area to the highway (e.g., by extending the area to
the middle of the carriage way), which goes against the principle of
mapping what is there.


If parking is on both sides of the street, the parking area already 
crosses the street, and even if it doesn't, logically the parking area 
*does* connect to the street. I disagree with the argument that mapping 
thus is somehow "wrong", and indeed, I usually map parking that way.


The problem with the parking area potentially being misleading (which 
anyway is an issue of the consumer not considering how the adjacent 
highway infringes on the parking area) can be solved by also mapping the 
spaces.



I don't think renderers tend to have this information available in
any case.
Perhaps, but at that point we're tagging for the renderer. I was 
thinking of other clients (e.g. routers).


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - parking=street_side

[Matthew Woehlke]

On 25/10/2020 03.58, Jeroen Hoek wrote:

Our proposal facilitates this: renderers can render street-side parking
however they wish, because the tag tells them it is street-side parking.


Alternatively, clients might look at the sort of highway running through 
a parking area. A highway=tertiary is probably "street-side parking", 
while a highway=service, service=parking_aisle probably is not.


That said, I'm not adamantly opposed to the proposal, having encountered 
situations myself where such a tag would have made how to map this sort 
of thing much more obvious.


--
Matthew

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

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

[Matthew Woehlke]

On 20/10/2020 16.34, Branko Kokanovic wrote:

There are lot of parking lots on amenities (shopping malls...), where
parking is free for customers, but only if you park for less than
some specified time amount (let's say 2-3h), imposed by that amenity.
After that period, you have to pay[1]. It is widespread where I live,
but I would suspect this is not limited to my country only.
FWIW, I believe this is common at many US airports. The first hour 
(sometimes only 15 minutes) is free, e.g. if you are just dropping 
someone off or picking someone up.



To cover how this works, in case you didn't had joy of experience to
use this - you usually press machine to get ticket upon entrance (or
human hand it to you) and ramp opens to enter. When you exit, you
present ticket to machine/human and lift gate/ramp opens if you
stayed for less than specified amount of time. It will not open if
time limit (of how long you stayed parked) is reached and in that
case, you have to go back and pay first to some specific place.


Basically the same where I've seen, except the payment kiosk is right 
next to the gate. Pull up to the gate; if you don't owe money, it opens; 
if you do, pay at the gate and then it opens.


...although I think I've seen the sort you describe as well. "Pay at the 
gate" seems typical for airports in my (admittedly limited) experience; 
the others have been, yeah, city parking garages.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - Artificial

[Matthew Woehlke]

On 21/10/2020 00.57, Robert Delmenico wrote:

'her generic man' has been fixed - it was a typo.

now reads:
"confirmed that when people read or hear the generic version of 'man',
people form mental pictures of males"


Citation needed, especially as you imply one but don't (AFAICT?) supply 
a link to it. I'd be especially curious to know whether there is an 
observable difference in people's mental image of "men", when used in a 
sense to refer to humans generically, and e.g. "people".


Also:


The word 'Man' in the Old English sense 'mann' had the primary meaning of "adult 
male human"


Citation needed, particularly as the other thread contains a statement 
which directly contradicts this.


--
Matthew

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

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

[Matthew Woehlke]

On 21/10/2020 09.34, Tobias Zwick wrote:

You seem to defend that OSM should be used as a tool to change
language, for politically motivated reasons in this case.


Indeed; we should not forget that the ultimate motivation here is *very 
much* political. (Note: as I stated elsewhere, that may not be the OP's 
motivation, but that of the forces manipulating the OP.)


OTOH, there is unfortunately a political aspect to *not* making the 
change... because the group that wants a change can't tolerate the 
status quo.


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.


Likewise.

--
Matthew

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Matthew Woehlke]

On 20/10/2020 15.22, Justin Tracey wrote:

On 2020-10-20 12:13 p.m., Matthew Woehlke wrote:

On 19/10/2020 16.01, Justin Tracey wrote:

It's the same reason we want
discourse on lists like this one to be friendly and amicable: it should
be obvious to anyone outside looking in that contributing and
participating in OSM is *enjoyable*, and they should feel welcome
joining in.


...and the irony is that most of what the SJW agenda accomplishes is to
polarize and inflame the issues, having the exact *opposite* effect as
encouraging harmony and inclusiveness (not to mention the hypocrisy of
being inimically opposed to "conservatives").


I have no idea what "the SJW agenda" is, but it doesn't seem
relevant to the discussion anyway.


https://en.wikipedia.org/wiki/Social_justice_warrior

If you don't see the relevance, I'm afraid I can't help you. The topic 
under discussion is a prime facet of said agenda.



If core aspects of the tagging schema give hints at a bias
towards a particular segment of the population (in this case,
English-speaking men)


So, clearly, we need to change the language of OSM tags to loglan. Oh,
wait, that would *still* be biased.


Correct. All the more reason to discuss how these biases manifest! :)


I don't mind discussing whether or not bias is present. I *do* mind 
someone else assigning a bias to a group when no such bias exists.



I'm not sure what you're talking about, but you seem to have an axe to
grind [...]


True.


[...] with a strawman that hasn't come up in this discussion. Nobody
said anything about "intolerance", there is no vilifying here, and
nobody is "forcing" any opinions on anyone.


Less true. This started as someone / some group deciding that our use of 
a term that has been historically and widely recognized as 
gender-neutral is biased.


Please note I'm not singling out the OP. In fact, I rather get the 
impression he's just innocently exploring an idea that has been forced 
on him. My objection isn't to this discussion as such, but to the groups 
that ultimately caused us to be having it.


Ultimately, given the technical arguments against change, it's hard for 
me to take a stance on the proposal *without* at least considering the 
underlying reasons why such things come up in the first place. If I just 
ignore those aspects, the obvious answer is that the proposal is 
expensive and pointless... but ignoring SJWs is dangerous. (Again, 
ironically; those people employ the exact same sorts of tactics they 
vilify their opponents for using.)


Anyway, most of why I brought it up was in reply to "contributing and 
participating in OSM is *enjoyable*, and [anyone wishing to do so] 
should feel welcome joining in." I wanted to express my agreement with 
the goal, but *dis*agreement with the means of accomplishing that goal.


--
Matthew

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Matthew Woehlke]

On 19/10/2020 16.01, Justin Tracey wrote:

It's the same reason we want
discourse on lists like this one to be friendly and amicable: it should
be obvious to anyone outside looking in that contributing and
participating in OSM is *enjoyable*, and they should feel welcome
joining in.


...and the irony is that most of what the SJW agenda accomplishes is to 
polarize and inflame the issues, having the exact *opposite* effect as 
encouraging harmony and inclusiveness (not to mention the hypocrisy of 
being inimically opposed to "conservatives").



If core aspects of the tagging schema give hints at a bias
towards a particular segment of the population (in this case,
English-speaking men)


So, clearly, we need to change the language of OSM tags to loglan. Oh, 
wait, that would *still* be biased.



The idea that you can make everyone happy is a delusion (source: John 
Lydgate (disputed)). All we're seeing right now is that the SJW crowd 
are making the most noise. The real issue is groups — *ANY* groups — 
trying to force their ideology down other's throats and decide what 
opinions are "allowed" and what aren't.


What needs to stop isn't "intolerance" (the SJW agenda isn't about 
eliminating intolerance — quite the opposite! — but about replacing one 
flavor with another), it's the inability to agree to disagree. Groups 
should feel welcoming even to people with different opinions, rather 
than vilifying anyone who disagrees with the group.



--
Matthew

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

Re: [Tagging] Proposal to change key:man_made to key:human_made

[Matthew Woehlke]

On 19/10/2020 18.46, Robert Delmenico wrote:

'Not really, and "man_made" does not mean that it was made by males.'


Yes it does. Why would society also use women-made?


Because someone with a PC stick up their  decided to declare 
that "man made" meant "made by men" rather than "made by males" as used 
to be the case.



Besides, the correct solution is clearly to restore the original meaning 
of "man" to be gender neutral and to (re)introduce something else to 
mean "an adult male".



--
Matthew

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

Re: [Tagging] Feature Proposal - Voting - Takeaway drink shops

[Matthew Woehlke]

On 05/10/2020 10.39, Joseph Eisenberg wrote:

The page was edited by the author to clarify that the new proposed tag is
amenity=drinks

"A place [which] sells bubble tea, milk tea, milk, juice and other similar
beverages."

I don't think that we should have coffee shops, bubble tea (boba/tapioca),
juice bars and shops that sell smoothies all under the same tag. A smoothie
is hardly similar to a hot coffee, no?


Just like we shouldn't have places that sell pizza, or hamburgers, or 
fried rice under the same tag, right?


Oh, wait...

IMHO there's enough confusion already between amenity=cafe, 
amenity=restaurant, amenity=bar and amenity=fast_food. (Olive Garden has 
a bar; is it amenity=bar? Panera is both fast and somewhat but not 
entirely cafe-like, is it amenity=fast_food or amenity=cafe or 
amenity=restaurant?)


We don't need to make things *worse*; that's why we have cuisine=*.

--
Matthew

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

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

[Matthew Woehlke]

On 02/10/2020 14.27, stevea wrote:

Wieland, I don't have good answers to offer to you for your other
questions.  However, I would say (as others have) that
"direct_marketing" absolutely IS "confusing," I go so far as to say
"incorrect" in these circumstances.  The term "direct_marketing" is
used in various dialects of English around the world as meaning
something wholly different than your proposed usage here.


To that end, perhaps something along the lines of "ad_hoc" would be less 
confusing...


--
Matthew

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

Re: [Tagging] admin, please remove this user from the list

[Matthew Woehlke]

On 23/09/2020 04.52, Martin Koppenhoefer wrote:

It's been some weeks now that I get this kind of reply for every message
that I write to tagging. Can an admin please remove the address
jim...@hey.com from the list recipients? Thank you.


Same here; I sent a message to tagging-owner@OSM some while back, but 
apparently that had no effect. I wonder if anyone even monitors that 
address?


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - (DEPRECATED building=funeral hall)

[Matthew Woehlke]

On 18/09/2020 02.46, Mateusz Konieczny via Tagging wrote:

building=church is building constructed as a church that now can
be a place of worship, warehouse, unused or something else but
retained building structure typical to a church

amenity=place_of_worship is a place where regular worship is conducted
- it may be in a church, in open area, in former fish market, in building 
constructed
as a warehouse


Question: is 
https://www.google.com/maps/@42.7408471,-73.7805254,132a,35y,69.19h,53.87t/data=!3m1!1e3 
a building=church? AFAIK it was constructed as a "church" (as a place of 
worship, anyway), but if you took down the signage and started to use it 
for another purpose, there would be no evidence that it ever used to be 
a place of worship; the construction *style* is absolutely *not* what is 
typically associated with a "church".


Compare with 
https://www.google.com/maps/@42.6822058,-73.840315,35a,35y,225.94h,69.88t/data=!3m1!1e3, 
which still looks almost entirely generic from above, but at least has 
*some* features of a "traditional church".



Not sure whatever there are building where their structure makes them
recognizable as funeral halls, but in case where such building exist
correct tagging is building=funeral_hall (potentially also 
amenity=funerall_hall)


Possibly something like 
https://www.google.com/maps/@43.4139398,-84.0322268,53a,35y,89.44h,48.46t/data=!3m1!1e3 
...?


--
Matthew

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Matthew Woehlke]

On 17/09/2020 15.50, Shawn K. Quinn wrote:

On 9/17/20 11:30, Matthew Woehlke wrote:

*Maybe* if you get lucky and have a very clear shadow at the right
angle, but if you try to tell me you can identify
https://www.openstreetmap.org/node/7695704414 (n.b. a yield sign)
from a shadow in aerial imagery, I am going to be deeply suspicious
;-).


Are you sure you didn't mean node 42164543 or something west of it? That
one, I'd need to survey or see street-level imagery to be confident
enough to map it. The shadow, if present, is overlaid by another in the
area. Nodes 6393986190 and 6393985684 do have the "shark's teeth" line
used with yield signs (which I did add just now).


Ah, I think I see what happened... iD really wants me to tag the node as 
something, and I was just seeing "yield" at the top of its suggestion 
list. I think I didn't notice because every other node I as looking at 
just showed up as a "point", apparently because they belonged to more 
than one way.


Also, I was trying to figure out why an apparently unnecessary node was 
there, which probably helped mislead me into thinking it was tagged. I'm 
pretty sure I'd intended to split between crossing and just sidewalk 
there, as discussed earlier in this thread (also why I was looking at 
that particular spot in the first place) and botched it. (Fixed, now.)


--
Matthew

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Matthew Woehlke]

On 17/09/2020 13.44, Tod Fitch wrote:

On Sep 17, 2020, at 9:30 AM, Matthew Woehlke wrote:
On 17/09/2020 10.07, Shawn K. Quinn wrote:

On 9/17/20 08:15, Matthew Woehlke wrote:

It's also atrocious because it can *only* be verified by survey. As
much as we prefer surveys, the reality is that a lot of mapping
happens just from aerials, where crossings (both marked and, in some
cases, unmarked) can be seen, but signals cannot.

I have mapped many traffic signals (and, for that matter, stop and yield
signs) based on shadows visible on the satellite photos. If you look
carefully enough (Bing and Mapbox Satellite at least), they are there.
(Local knowledge helps too in some cases.)


*Traffic* lights I can buy. I am more suspicious of the claim that 
you can tell whether they have pedestrian crossing signals or not, 
or that you can reliably identify other signage based solely on 
outline. *Maybe* if you get lucky and have a very clear shadow at 
the right angle, but if you try to tell me you can identify 
https://www.openstreetmap.org/node/7695704414 (n.b. a yield sign) 
from a shadow in aerial imagery, I am going to be deeply suspicious

;-).


Not from the signs or shadows of the signs, but in my area the 
pavement markings can often tell you if it is a stop or yield. Some 
times it is easy (“STOP” or “YIELD” painted on the pavement). But it

seems that newer road work uses a different style limit line for a
stop versus yield.


Ah, that's fair; I was under the impression we were talking about 
*signs*. Possibly because most of the yields I see are to yield to other 
*vehicles*, not pedestrians. (I *have* seen "yield to pedestrians", now 
that I think about it, but not sure I've ever seen *lane markings* where 
it's clear that what you are supposed to yield for is pedestrians. Other 
than crosswalks, anyway. Which... makes me wonder if 
"crossing=uncontrolled" is even correct; even more reason to not use 
that! My understanding was "uncontrolled" meant by traffic signals, but 
now I'm not so sure.)


I've tagged some yields based on lane markings myself, e.g. 
https://www.openstreetmap.org/node/7714853074.



Back to the original topic: I am not really sure what, if any, the
US version of a “zebra" crossing is versus a “marked” crossing. So I
usually just tag as “marked” as that seems to be the more generic
item.


Likewise. Even the wiki notes that this is unclear "outside the UK" (as 
I previously observed).



The crossing you linked to *might* be an example of a US “zebra”
crossing. Can anyone verify that for me. Also, there are no tags on
the intersection node itself. Should there be? I have assumed that
there should so that vehicle based navigation would have the
information needed to advise the driver of particular type of
crossing ahead.


As I understand it, yes, and I've tagged that in other places (e.g. the 
above example). I actually have no idea why that node is marked as a 
yield; I don't think there's actually a yield there, but I'm hesitant to 
just delete it (even though apparently I'm the one that added it). 
Unfortunately I can't go survey it right now. (Have to try to remember 
to do that when/if I ever make it back to that Cracker Barrel :-).)


--
Matthew

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Matthew Woehlke]

On 17/09/2020 10.07, Shawn K. Quinn wrote:

On 9/17/20 08:15, Matthew Woehlke wrote:

It's also atrocious because it can *only* be verified by survey. As
much as we prefer surveys, the reality is that a lot of mapping
happens just from aerials, where crossings (both marked and, in some
cases, unmarked) can be seen, but signals cannot.


I have mapped many traffic signals (and, for that matter, stop and yield
signs) based on shadows visible on the satellite photos. If you look
carefully enough (Bing and Mapbox Satellite at least), they are there.
(Local knowledge helps too in some cases.)


*Traffic* lights I can buy. I am more suspicious of the claim that you 
can tell whether they have pedestrian crossing signals or not, or that 
you can reliably identify other signage based solely on outline. *Maybe* 
if you get lucky and have a very clear shadow at the right angle, but if 
you try to tell me you can identify 
https://www.openstreetmap.org/node/7695704414 (n.b. a yield sign) from a 
shadow in aerial imagery, I am going to be deeply suspicious ;-).


--
Matthew

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Matthew Woehlke]

On 16/09/2020 20.40, Taskar Center wrote:

crossing has been a very poor tag because it seems to be the kitchen
sink for all the questions pertaining to crossings... Many of the
attributes that get values in "crossing" are potentially overlapping
and not mutually exclusive, causing a lot of confusion and poorly
tagged crossings. Nevertheless, specifying crossings is very
important because it's a highly contested street region.

The crossing tag has held many values that may overlap, and we should
once and for all split out all these different tags so we can be
mapping what we mean and mean what we map. Questions we should be
answering when mapping a crossing: 1) How is this shared space
controlled? A crossing is a high risk environment where traversal is
shared between cars and pedestrians (they are of unequal footing). So
the type of 'control' and 'right of way' in that space is important
to specify. 'uncontrolled' is a very bad tag in this direction
because it has an actual legal, non-intuitive meaning and many
mappers mistakenly think a crossing that has no traffic signal is
uncontrolled- so that's a really bad tag. crossing_control= ?


It's also atrocious because it can *only* be verified by survey. As much 
as we prefer surveys, the reality is that a lot of mapping happens just 
from aerials, where crossings (both marked and, in some cases, unmarked) 
can be seen, but signals cannot. As someone who's generated a fair 
number of "uncontrolled" crossings because that was the only "blessed" 
tag, I would much prefer separating the presence or absence of features 
that can be verified in an aerial (marked, unmarked, striped, island, 
...) from whether or not signals are present.



3) How can a pedestrian call up the signal and how can they sense
whose right of way is currently allowed? Is there a call button? Does
it chirp, speak out,  vibrate?


Id' be careful with this one; I've read that those buttons are often 
placebos. I suppose if we're just mapping whether a button is present or 
not, that's okay, but just because there *is* a button doesn't 
necessarily mean it has to be pressed.


--
Matthew

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

Re: [Tagging] Best practices regarding implied tags

[Matthew Woehlke]

On 16/09/2020 18.32, Paul Johnson wrote:

No, it's not wrong to add implied tags explicitly.  It's actually
encouraged in some cases where the implicit tag is not consumable by
automated system (such as the "none" default for turn:lanes tends to be
ambiguous between "you can't turn from this lane" and "you can't use this
lane" and "there's an implicit but unspecified implication that isn't
painted on the ground")


Pedantic: wouldn't "you can't turn from this lane" be correctly 
specified as turn:lanes=through? As I understand turn:lanes, "none" 
would be "you can't use this lane". (Also pedantically speaking, a blank 
value would mean there are no specific markings. I think the only 
ambiguity here is that it's unclear if the tag is simply missing — in 
which case the truth on the ground could be *anything* — or if there are 
no markings. Sort of like how a missing oneway could mean oneway=no, or 
could mean oneway but not tagged.)


(Incidentally, I tend to add oneway=no whenever possible... or at least 
I did in iD, which made it easy. I can't recall now how well I've been 
keeping that up with JOSM.)


--
Matthew

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

Re: [Tagging] Addition of highway=emergency_bay and priority_road=yes to Map Features?

[Matthew Woehlke]

On 16/09/2020 17.07, Graeme Fitzpatrick wrote:

On Wed, 16 Sep 2020 at 18:00, Martin Koppenhoefer wrote:

emergency bays are quite common in Italy and Germany when there isn’t an
emergency lane.


Quite common on major highways out here as well.


I'm not sure if I'd call them "common", but they occur in the US also. 
(I would guess they're more common on freeways with longer distances 
between exits; I seem to mainly notice them on long trips, and not so 
much around cities.)


--
Matthew

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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[Matthew Woehlke]

On 16/09/2020 05.57, Martin Koppenhoefer wrote:

I noticed that crossing=zebra tag usage is drastically shrinking while the
very generic crossing=marked, which was quite unpopular before (2013-2018
below 6000 uses) now went through the roof and is leading the tagstats with
more than 1 million uses. What do you think about it, shouldn't we be
encouraging people to use more specific tags like crossing=zebra or
crossing=traffic_signals instead?


My understanding is that crossing=zebra is deprecated in favor of 
crossing=uncontrolled / crossing=traffic_signals. In particular, my 
understanding is that they are synonymous for (almost¹) all practical 
purposes. (Also, that crossing=marked is not desired either...)


Please explain how crossing=marked is "very generic" and what value 
crossing=zebra adds.


Additionally, crossing=zebra is not an approved tag (according to the 
wiki), and "It is not always clear what the intended meaning is when 
used outside of the UK". This doesn't seem like a tag we should be 
encouraging.


(Feel free to disagree with the above, but in that case, the correct 
solution is to a) seek approval for the tag and b) clarify the 
documentation.)


(¹ Pedantically, I suppose you could argue that crossing=zebra refers to 
a specific *form* of marking, i.e. repeated white stripes, while the 
approved crossing=uncontrolled could include crossings marked only by 
two parallel white lines. However, I would question the value added by 
mapping that distinction.)


--
Matthew

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

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

[Matthew Woehlke]

On 26/08/2020 07.12, pangoSE wrote:

I rest my case. Thanks for the examples. Could you help update the wikipage 
about POIs to reflect this?


By "the wikipage", do you mean 
https://wiki.openstreetmap.org/wiki/Points_of_interest? It isn't 
immediately obvious where this information would be added there. (It 
seems it would at least need a new section, something like "how to add 
addresses to POIs"?)


Or were you thinking of some other page?

--
Matthew

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

Re: [Tagging] Hands Off !, respect my (our) space

[Matthew Woehlke]

On 25/08/2020 06.04, Paul Allen wrote:

On Tue, 25 Aug 2020 at 06:38, Warin wrote:

Off list.


It looks like you accidentally Bcc'd the list.


It looks like Warin tried to send it to "80hnhtv4agou---" without 
noticing that address is a spoofed¹ tagging@OSM. (The reply-to: address 
should have been used instead.) That's an understandable oversight that 
I might have made myself :-). (OTOH, it might mean Warin's mail client 
doesn't honor reply-to...)


(¹ Mind, spoofing 'from' as "so-and-so via LIST " is a 
pretty common practice that should not be taken as malicious. In fact, 
for how often I see it, I wouldn't be surprised if it is default 
behavior in some mail clients.)



This has ABSOLUTELY NOTHING TO DO WITH THE TAGGING LIST.


+10


Yup. talk@OSM, maybe, but really at this point it's just someone ranting 
inappropriately.


--
Matthew

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

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

[Matthew Woehlke]

On 24/08/2020 16.25, pangoSE wrote:

Martin Koppenhoefer skrev: (24 augusti 2020 02:16:27 CEST)

Also useful when the POI is approximately placed (e.g. in a
neighbouring building, happens quite often, at least as long as most
POIs are not yet mapped)


Really? Can you link to an example?  I have never come across a POI
that needed a special address. I would rather map to he entry in the
that case and put the address there.


Just about any strip mall. For example, 42.8625, -73.7831. I can give at 
least three other examples within 1000 *feet*; in a few miles, probably 
a dozen or more.


Mapping stores in such cases practically requires mapping the *insides* 
of the buildings. It's much more typical to drop a POI in about the 
right place (either the middle of the store, or the entrance to the 
store). Yet, these *do* have distinct addresses.


The same can easily happen with multi-unit dwellings.

Also, mailboxes have addresses, but are unlikely to be mapped as ways 
due to their size.


The POI IMO cannot logically have an address itself, its a human 
symbol for designating something of interest within a feature like a 
building, park or whatever.


...or its a somewhat abstracted representation of a building because no 
one has yet made the effort to map the building more precisely. BTW, 
it's not that unusual for detached houses to be mapped as POIs, 
especially when addresses are imported from GIS data that gives them 
only as points. Yes, in an ideal world everything of this nature would 
be mapped as a way, but that isn't always practical.



When the Swedish geosurvey sometime soon release all public adresses
for free we will have to merge them all with the buildings where
possible.
...And what will you do if there is no building, and it isn't obvious 
how to add one (e.g. strip malls)? Not import that address at all?



thinking about it postal addresses follows land plots and legal boundaries and 
not POIs.


Actually, AFAIK this is only partly true. Yes, the address "123 Cherry 
Lane" follows a plot, but I'm not aware of anything preventing me from 
erecting three structures on that plot and designating them "unit 1", 
"unit 3.14" and "unit gamma". This would be unusual on a residential 
plot, but not at all (well, sans my intentionally bizarre numbering) for 
a commercial building.


--
Matthew

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

Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

[Matthew Woehlke]

On 24/08/2020 00.47, Jonathon Rossi wrote:

On Mon, Aug 24, 2020 at 2:22 PM Andrew Harvey wrote:

On Mon, 24 Aug 2020 at 14:05, Jonathon Rossi wrote:

Andrew, how do you specify a polygon, always wanted to do that but I
thought OSMCha only supports a bbox?


[...] So at the top you should see a map with a button in the top right.
Click that button and trace your polygon on the map.


Thanks. I've always read the text next to the map ("Filter changesets whose
bbox intersect with a location boundary.") as meaning the map helps you
define a bbox. i.e. it wouldn't keep and filter using the polygon, just
uses it to work out a bbox to contain the polygon. Is that text misleading?


Does it really only use the changeset bounding box? That's good as a 
first-pass culling test, but I would be somewhat annoyed if my ROI is 
"Chicago, IL" and I get notified because someone changed Kansas City, MO 
and Detroit, MI in the same changeset without changing anything near 
Chicago.


--
Matthew

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

Re: [Tagging] oneway=yes on motorways

[Matthew Woehlke]

On 14/08/2020 17.57, António Madeira via Tagging wrote:

In this

section, I suggest changing the text:
"These ways should all point direction of travel and be tagged with
oneway=yes."

to

"These ways should all point direction of travel and imply oneway=yes
(like junction=roundabout), therefore the oneway tag is redundant and
should be avoided."


FWIW, I am also in favor of preferring explicit tagging; oneway={yes,no} 
says that someone paid enough attention to intentionally annotate the 
way thusly. An implicit tag is impossible to tell apart from an 
oversight. IMHO we should never, *ever* discourage adding explicit tags 
even if they are "superfluous".


(I even wish Osmose wouldn't complain about oneway=yes on roundabouts...)

--
Matthew

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

Re: [Tagging] bridge:name and tunnel:name

[Matthew Woehlke]

On 13/08/2020 08.10, dktue wrote:
the wiki states since more than eight years that there's a debate about 
wether one should tag "tunnel:name" or "name". [1]


Is there any new opinion in the community on this topic that has not 
been documented in the wiki?


How is the tunnel tagged? If it's a highway that happens to be going 
through a tunnel (e.g. https://www.openstreetmap.org/way/361906432) I 
would expect that `name` is the name of the *road*, hence if the tunnel 
also has a name, it would need to be tagged in some other manner (e.g. 
tunnel:name).


Note that my example *does* have the street name in `name`.

If the tunnel is somehow tagged separately from the highway, then I 
could see that using `name` as the name of the tunnel. Of course, if the 
*road itself* is known by the same name as the tunnel, then it would 
also make sense to use `name`.


--
Matthew

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

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

[Matthew Woehlke]

On 08/08/2020 19.12, Graeme Fitzpatrick wrote:

On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke wrote:

We already have capacity and capacity=disabled, what's the problem with
adding more capacity:*?


But what number do we show for "capacity"?


IIUC, all of them. So...


I started wondering about this after one of the carparks you mentioned in
Quantico recently showed capacity 15, with 11 car spaces + 4 motorbike
spaces. Should that be =15, or =11 + 4?


...15. Rationale: existing capacity:* spaces are not usable unless you 
meet the criteria, but are (AFAIUI) included in capacity. The 
description in JOSM is explicitly "capacity (overall)". On the wiki, it 
is "the number of vehicles a facility holds". Both imply total capacity, 
including spots that aren't usable to many vehicles. It seems clear that 
the intent is that "general" capacity is the overall capacity less any 
capacity:*.


It's possible that some software will need to adapt (though I question 
how critical it is to know capacity, since no software can know how many 
spaces are already occupied), but it's also possible such software is 
already not honoring other, existing capacity:* tags.



So, do we have a shopping centre parking lot with capacity=100, or should
we have capacity:"vehicle"=60; capacity:motorbike=10; capacity:disabled=10;
capacity:prams***=6; capacity:ev_charging=4;
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5


Hmm, "loading" would be good for curbside pick-up, though now we're into 
the discussion of whether a space for standing-only is actually a 
"parking" space :-). As for the main thrust of your question, see above.



***=prams - I'm not sure if they're yet a thing in OSM?, but that's
carparks marked as reserved for parents with prams eg
https://www.google.com.au/maps/@-28.0997524,153.4253639,3a,64.7y,77.23h,72.17t/data=!3m6!1e1!3m4!1s3e6IiMfvLC7DrZq1RA4TUA!2e0!7i16384!8i8192


Yeah, that might make sense. I'm not sure if it's better to go ahead and 
add that, or if we should treat each type as a separate proposal. (I'd 
almost be tempted to yank "compact" again and resubmit it as a follow-up.)


--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 18.08, Martin Koppenhoefer wrote:

On 7. Aug 2020, at 15:47, Matthew Woehlke wrote:
However, it sounds like you have this backwards; you are using
amenity=parking_space to map lots and amenity=parking to map
individual spaces. There appears to be a modest amount of such
backwards mapping, and it isn't localized to one area.


it was really just a slip


Okay, but then I don't understand the (original) objection? We already 
have capacity and capacity=disabled, what's the problem with adding more 
capacity:*? (Note that these apply to amenity=parking, *not* to 
amenity=parking_space. There is capacity, and *just* capacity — no 
capacity:*, and none is being proposed — on amenity=parking_space, 
although personally I question whether there should be...)


Is it just unclear that the proposed capacity:* apply to amenity=parking?


It was always clear that parking_space was for a single parking space
and the back then already well established “parking” was for a bigger
site with multiple spaces.


Well, perhaps it is clear to you and I, but I found a number of 
amenity=parking_space with capacity > 1 and no associated 
amenity=parking. *Someone* is using it wrong :-).


There are also a bunch of parking_space=* on *buildings*, which 
similarly seems like poor tagging. (I guess the intent is to say "the 
parking *associated with* this facility is X, but I really don't care 
for that vs. actually mapping the parking.)


--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 13.11, Tobias Knerr wrote:

On 06.08.20 22:52, Matthew Woehlke wrote:

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


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

Could you add a short definition of "compact"? I can guess that it's
supposed to mean parking spaces for compact cars, but the first Google
result for me is some parking system for trucks at motorways. Better to
avoid the ambiguity.


Done; thanks! (BTW, "compact cars" probably gives better results. I used 
https://www.google.com/search?q=parking+for+compact+cars=isch as an 
"example" on the proposal page.)


To Jan's point, that sounds like a documentation issue, or possibly a 
need for parking_space=oversized. I think "normal" should mean "normal 
*for that region*", and similarly, "compact" should means *for that 
region*. Of course, the real rule of thumb is whether the space is 
marked "compact only" (and/or is clearly smaller than its neighbors).


Is it worth essentially writing the wiki page for parking_space=compact 
so that it's clear *exactly* what we're voting on, or can we vote on the 
general idea and hash out the precise wording after?



Also, I guess we need to decide if we need to be able to map something
that fits more than one class, like a takeaway parking spot reserved for
users with disabilities.


Although I have yet to see such a thing, that doesn't make your point 
invalid.



If so, we could consider a solution something like
parking_space:takeaway=yes, or a clearly defined meaning for 
semicolon-separated values.
I would normally assume that semicolon-separated values are union ("or") 
rather than intersection ("and"). Maybe your example should be 
parking_space=takeway+disabled (note the '+' rather than ';')? Given I 
don't know of extant examples, however, I'm just as happy to punt on it 
for now.


--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 14.39, Philip Barnes wrote:

I am not 100% sure but McDonalds that have a drive through have special
spaces where you are told to wait if your order is taking a long time
to clear the queue. Is that what this means?


"No", because those are not *parking* spaces as was previously 
discussed. (Um... not sure where, possibly in one of the threads linked 
in the proposal.) OTOH *I* wouldn't be adverse to overloading it with 
that meaning, but technically speaking such spaces are not *parking* 
spaces, because you are not supposed to park in them. (Note the 
difference between "parking", "standing" and "stopping". You are 
supposed to *stop* in them, but not *park*.)



We also have loading bays where you can stop for a few minutes to
collect things you have bought and cannot carry to the car park, there
is no specific time limit here but you are expected to not be far away.
Again is that what this means.


That is explicitly "standing". Previous comments apply.

Again, the *intended* use is for *parking* spaces (park, go inside, 
collect a to-go order, possibly *order* a to-go order and wait for it to 
be made... but don't sit down and eat at the restaurant). However *I* 
would not object to using it for any sort of parking/standing/stopping 
space where you are expected to not be long (and the space is 
specifically signed with something like "loading only") but there is not 
a specific time limit. Others might object, however. (Probably on the 
basis that this is not "parking", on which point they *are* technically 
correct.)


--
Matthew

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

Re: [Tagging] Electric scooter parking

[Matthew Woehlke]

On 07/08/2020 11.55, Jan Michel wrote:

Note that we also lack a proper way to tag parking lots for trucks.


This sounds like a good candidate for expanding capacity:* / 
parking_space=*, at least in the case of mixed-use lots. In general, I 
agree it would be good to have a better way to tag parking areas for 
specific vehicle types.


BTW, how are hitching rails (i.e. "horse parking") mapped? ;-)

--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 10.09, Jez Nicholson wrote:

I saw parking_space=takeaway riding on the coattails of the original
postis this not a waiting time restriction? Does it merit its own
value?


That's not how I would interpret it. Stuff like "15 minute parking" also 
exists; "takeaway" parking (which would usually be called "carry-out" in 
the US) is a *purpose* restriction, and there is not *technically* a 
time restriction attached. (I'm pretty sure that if your order took an 
unusually long time for some reason, you would not get towed, as you 
might in a "15 minute" space.)


My main argument (well, aside from "they're a thing") is that if I can't 
map them, how am I supposed to map a lot that has such spaces? They 
aren't normal spaces and definitely shouldn't be mapped that way, but 
then, am I supposed to subtract them from 'capacity'? How do I map them 
so that armchair mappers don't see my "error" and "correct" it?



Perhaps I'm against it because we don't AFAIK have these in the UK?


I can't speak to that :-). They are assuredly real in the US; several 
restaurants in my area have parking/standing spaces that are either 
carry-out only or pickup only. (Almost all Red Robin's AFAIK have some, 
I suspect many/all Chili's have some, and pretty sure I've seen them 
associated with other restaurants as well.)


--
Matthew

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

Re: [Tagging] Electric scooter parking

[Matthew Woehlke]

On 07/08/2020 04.27, Mateusz Konieczny via Tagging wrote:

Electric scooter parkings started to appear in Poland.

https://commons.wikimedia.org/wiki/File:ParkingHulajn%C3%B3g.jpg
https://commons.wikimedia.org/wiki/File:Parking_Hulajnogi.jpg

(text on traffic sign is "electric scooters")

How it should be tagged?

amenity=small_electric_vehicle_parking ?

amenity=electric_scooter_parking ?


IMHO, something along those lines. Your examples appear to be very much 
in line with amenity=motorcycle_parking or amenity=bicycle_parking.



amenity=parking + vehicle=no + small_electric_vehicle=yes
or
amenity=parking + vehicle=no + electric_scooter=yes
seems like a terrible idea to me


To the extent these are not part of a parking lot that includes parking 
for other vehicles, I would agree.


--
Matthew

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

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

[Matthew Woehlke]

On 06/08/2020 19.42, Martin Koppenhoefer wrote:

amenity=parking  is defined for single parking spaces, adding
capacity to what seems to be a subtag, would create confusion


Okay... yike. I think I see the problem here (after doing some digging 
into extant usage).


The problem is *you have this backwards*, and possibly (I didn't dig 
into authorship to be able to say for certain) aren't the only one.


To quote the *approved* documentation:

"Use amenity=parking_space to map a single parking space on a parking 
lot. Mapping parking spaces is an addition, not a replacement, to 
mapping a whole parking lot with amenity=parking."


However, it sounds like you have this backwards; you are using 
amenity=parking_space to map lots and amenity=parking to map individual 
spaces. There appears to be a modest amount of such backwards mapping, 
and it isn't localized to one area.


Such tagging is, however (at least according to both the voted-upon 
usage and AFAIK most if not all existing editors and renderers), wrong.


If I reread your message with that context, however, then your objection 
makes sense *in that context*. If, however, you alter your understanding 
to reflect the *prescribed* usage of amenity=parking and 
amenity=parking_space, I think you will find your objection disappears.


Hope that helps!

--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 09.06, Paul Allen wrote:

On Fri, 7 Aug 2020 at 13:53, Matthew Woehlke wrote:

Well, yes, voting "no" is probably not useful, but this is also the
least "interesting" bit of the proposal. The purpose here would be just
to bless the tag with "status=approved" rather than "status=de-facto".


But it wasn't approved by a formal vote.  If you mark it status=approved
then it ought to be possible to find the vote that approved it.


Ahem:

"The purpose [of including parking_space=disabled as an element of the 
proposal] would be [so that, if the proposal passes, we can] bless the 
tag with 'status=approved' rather than 'status=de-facto'."


Was some part of that unclear?

The proposal under discussion in this thread *would be* the 
aforementioned approval vote.


--
Matthew

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

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

[Matthew Woehlke]

On 07/08/2020 08.23, Alessandro Sarretta wrote:

Dear Matthew,

On 06/08/20 22:52, Matthew Woehlke wrote:
Please see 
https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking.


To summarize: I am proposing the following:

- To codify / make official the de-facto parking_space=disabled 


I've always had some doubts in using parking_space=disabled.

When I had to map parking spaces specifically designed for disabled 
people (i.e. only disabled people can park there), I've used 
disabled=designated, because it defines (or that is my interpretation) 
an access condition and it applies it to disabled people.


While parking_space=disabled seems to be more generic.

But if the default use of parking_space=disables means exactly that only 
disabled people can park there, I'm ok to use it (and change my edits), 
but in this case an explicit description in this sense is required in 
the wiki page.


See? This is *why* we need a page! Thank you for bringing up this 
excellent point!


For me, I always look at parking_space=X and capacity:X as being 
related. I didn't also propose e.g. parking_space=parent because I can't 
recall ever encountering such a thing, but arguably that should be added 
also.


That said... now I'm on the fence. FWIW, the amenity=parking page 
mentions parking_space=disabled as being supported by at least one 
renderer, while one has to do quite some digging for how to use 
access:*. Clearly we *do* need to improve the documentation here! Also, 
it's less obvious how one would apply access restrictions for e.g. 
charging, compact.


(If I'm using overpass correctly, it looks like there are ~1k instances 
of amenity=parking_space *also* tagged with access:disabled. That's 
clearly much less popular than parking_space=disabled. Do you know if 
any renderers use access:disabled to affect the rendering of 
amenity=parking_space?)


--
Matthew

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

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

[Matthew Woehlke]

On 06/08/2020 19.42, Martin Koppenhoefer wrote:

On 6. Aug 2020, at 22:54, Matthew Woehlke wrote:
- To codify / make official the de-facto parking_space=disabled


that’s almost 22k uses, it is already established and voting yes or no will not 
change it


Well, yes, voting "no" is probably not useful, but this is also the 
least "interesting" bit of the proposal. The purpose here would be just 
to bless the tag with "status=approved" rather than "status=de-facto".



- To allow mapping motorcycle parking as part of a unified parking
lot, by introducing parking_space=motorcycle and
capacity:motorcycle


amenity=parking  is defined for single parking spaces, adding capacity to what 
seems to be a subtag, would create confusion


Huh? There is clearly some miscommunication happening here.

The capacity and capacity:* tags apply to amenity=parking, which is used 
to map entire *lots*. Capacity is clearly meaningful in this context.


Individual parking *spaces* are not supposed to be tagged 
amenity=parking, they are supposed to be tagged amenity=parking_space.


I fail to see the confusion. Maybe you were misreading the proposal? (I 
am not at this time proposing capacity or capacity:* tags for 
amenity=parking_space. That tag *can* have a capacity¹, but it's 
arguable whether it *should*, or whether it's preferable to not map 
multi-capacity spaces.)


(¹ ...and iD thinks it should have capacity=1, while JOSM disagrees. 
I've been tagging them thusly, but that's arguably an iD bug that should 
be fixed, in which case I'd happily go back and nuke all my capacity=1.)


--
Matthew

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

[Tagging] Feature Proposal - RFC - more parking types

[Matthew Woehlke]

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


To summarize: I am proposing the following:

- To codify / make official the de-facto parking_space=disabled
- To allow mapping motorcycle parking as part of a unified parking lot, 
by introducing parking_space=motorcycle and capacity:motorcycle

- To add the additional parking space types 'compact' and 'takeaway'

See https://www.openstreetmap.org/way/830096097 for an example of 
parking_space=motorcycle being used in anger. See also 
https://www.openstreetmap.org/?mlat=38.51676=-77.29554 (open in an 
editor and check the Mapbox imagery) for another, even better example of 
where splitting what most people would almost surely call a single lot 
into separate amenity=parking and amenity=motorcycle_parking would be 
silly. The same lot also has an example of a space that is obviously 
compact-cars-only (by virtue of being not quite 15' long, vs. a more 
typical 18'+).


See https://goo.gl/maps/ePTDv7U4LnieFoor7 for an example of takeaway 
parking.


Question: should we also overload parking_space=takeaway for "parking" 
spaces reserved for curbside pickup? Should we also add a different type 
for those? Or should we simply not map those, or map them in some manner 
totally different from how parking spaces are mapped?


--
Matthew

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

[Matthew Woehlke]

On 03/08/2020 19.56, Graeme Fitzpatrick wrote:

On Tue, 4 Aug 2020 at 01:10, Matthew Woehlke wrote:

Parking lot access roads are a common example; I don't really feel that
these are "driveways", but I also prefer to reserve "parking_aisle" for
ways that actually *have* parking spaces along them.


Main through road across the front of the shopping centre, with
parking_aisles opening off it, put with a dozen or so specialised parking
spaces (disabled, ambulance, reserved, electric vehicle charging) on it -
does that change it from "access" to another parking aisle?


Maybe. It's possible I'd tag that as a parking_aisle. The point was more 
though that I wouldn't use parking_aisle for something that *doesn't* 
have parking spaces.



service=driveway/drive-through -> Service way for access to a fuel station

IMHO, a drive-through is a very specific type of way which involves a
service window. *Maybe* you could argue for that in case of a
full-service fuel station, but I wouldn't use it otherwise. (Note:
"drive through" implies that the vehicle will engage in stopping but no
standing or parking.)


No, driveway/-through is good for a fuel station, as well as anywhere else
that you don't get out of your car to be served eg take-away, car wash,
bottle shop (liquor store)


"Anywhere else that you don't get out of your car to be served" is 
effectively what I proposed, but (at least in the US, nearly all) fuel 
stations do *not* meet that criteria.


--
Matthew

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

[Matthew Woehlke]

On 01/08/2020 20.40, David Dean wrote:

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


As someone who has recently tagged a number of ways thusly, I have to 
strongly agree that there needs to (continue to) be a way to mark such 
roads. It's also often unclear if an otherwise undesignated road with 
provides access to, or navigation of, a larger area (consider a mall 
perimeter road as an example), should be a "driveway".


*If* we need a tag (on which note, I'll point at Jason's list), what 
about something as simple as "service=access"? (IOW, Martin's line of 
thinking, except lose the confusing "collector".)


That said, service=main might be a good choice.


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.


You might start by taking a look at all such routes in Quantico, VA (as 
any such were probably tagged by me).


Parking lot access roads are a common example; I don't really feel that 
these are "driveways", but I also prefer to reserve "parking_aisle" for 
ways that actually *have* parking spaces along them.


Of course, Jason's list is quite good; this is more along the lines of 
if you want to go look at some *extant* examples where the lack of 
service= is known to be intentional.



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


As noted by others, I would strongly prefer parking_access.


service=parking_isles (used almost 2K times already:
https://taginfo.openstreetmap.org/keys/service#values)


What is a parking *isle*? I wonder how many of these are typos for 
"aisle"...



service=driveway -> also used for access to multiple businesses (like in an
industrial estate, etc)


*Maybe*, but this seems like an excessive stretch of what most people 
would consider a "driveway".


OTOH, my suggested service=access could be seen to overlap with 
driveway. Maybe it would be better to provide that while also narrowing 
the definition of "driveway"?



service=driveway/drive-through -> Service way for access to a fuel station


IMHO, a drive-through is a very specific type of way which involves a 
service window. *Maybe* you could argue for that in case of a 
full-service fuel station, but I wouldn't use it otherwise. (Note: 
"drive through" implies that the vehicle will engage in stopping but no 
standing or parking.)


--
Matthew

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

Re: [Tagging] addr:street for routes

[Matthew Woehlke]

On 31/07/2020 15.39, Martin Koppenhoefer wrote:

the authority for names are the local people. I would bet that some
of them would refer to this particular road as State Highway 214 if
they should name it in a formal way. NY 214 is a ref, no doubt, and
is fine to have, but so is State Highway


...and then there is, for example, 
https://www.openstreetmap.org/way/5640056. According to OSM, this is 
"Clifton Park Blvd¹", but I don't think I've ever called it anything 
other than "146".


(¹ ...except not abbreviated, but I'm lazy.)

--
Matthew

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

Re: [Tagging] addr:street for routes

[Matthew Woehlke]

On 31/07/2020 14.02, Kevin Kenny wrote:

The `addr:street` should match what goes on the address label that a
delivery driver will be reading.

Ordinarily, that's the signed name of the street, if the street has a
name.  Rural New York has many streets that will have a `ref=* noname=yes`
- because their highway number is their only name.  In this case, I use the
postal address spelt out, so a building or address point will
have `addr:housenumber=1234 addr:street="'State Route 214"` or
`addr=housenumber=1234 addr:street="County Route 23C"`

That practice gives some validation engines heartburn - they warn that
`addr:street` shows a name that does not belong to a nearby way.


That sounds suspiciously like a solvable problem. (I mean, that the 
validation tools could be improved to handle this situation properly.)


Granted, there may need to be some gymnastics to know that e.g. "State 
Route (\w+)" matches ref="[A-Z]+ \1", but even so...


--
Matthew

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

Re: [Tagging] How to map "piers" on land?

[Matthew Woehlke]

On 29/07/2020 10.57, Jarek Piórkowski wrote:

On Wed, 29 Jul 2020 at 09:47, Matthew Woehlke  wrote:

So... back to my *other* question: how should a raised wooden platform
on land be tagged? For example:

https://www.pitztal.com/sites/default/files/styles/adaptive/public/thumb_5101_lightbox.jpeg
https://upload.wikimedia.org/wikipedia/commons/e/e2/Laguna_Mountains%2C_California%2C_observation_area_2015.jpg


There is bridge=boardwalk
https://wiki.openstreetmap.org/wiki/Tag:bridge%3Dboardwalk which would
seem to match at least the second image to me.

The first is a bit of a stretch since it's not exactly a far walk, but
seems to be related closely enough? I'd probably mark it as a short
bridge way with a viewpoint at end node, or a bridge area with the
viewpoint tag on the entire area (highway=pedestrian + area=yes +
bridge=boardwalk + tourism=viewpoint?) and a bench node in the middle.


The connecting platforms *might*, in some cases, be bridges. The 
terminal platforms aren't bridges by any reasonable definition *I* know. 
For one, they don't *go* anywhere.


Do we really not have a way to tag *platforms*?


--
Matthew

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

Re: [Tagging] How to map "piers" on land?

[Matthew Woehlke]

On 28/07/2020 16.09, Paul Allen wrote:

On Tue, 28 Jul 2020 at 20:44, Matthew Woehlke wrote:

Please see https://www.openstreetmap.org/way/651244930. This is a pier
with a platform on land that extends into the water. Carto cuts off the
part that is on land.


There is no part of a pier on land.  Not according to the wiki: "A pier is
a raised
walkway over water..."


Really?

Let's look at some pictures:

https://mediaassets.ksby.com/cordillera-network/wp-content/uploads/sites/2/2019/04/26205653/PierToday-e1556337486552.jpg
https://cloudfront-us-east-1.images.arcpublishing.com/raycom/X3EB5BF765G5TFHPOBGNDEJIJQ.jpg
https://arc-anglerfish-arc2-prod-pmn.s3.amazonaws.com/public/AY3CHTOCXNDWDHJJD2A73ICBF4.jpg
https://www.fishanywhere.com/wp-content/uploads/2019/08/crystal-coast17-229.jpg

What you are saying (okay, maybe what the wiki is saying) is that all of 
these magically cease to be piers at the coastline and become... what?


I don't think most people share that view.

BTW, Wikipedia defines a pier as "a raised structure that rises above a 
body of water *and usually juts out from its shore*" (emphasis added). I 
would expect that most people would interpret the "pier" in the above 
images as being the entire contiguous surface from the end in the water 
until either a) where the support framework ceases, or at least b) the 
narrower section ends at a wider deck.


I have to agree with others; the wiki is wrong. (And I think carto is 
also wrong about the render order; military areas certainly can have 
piers, so rendering in a way which makes them impossible to see is 
unhelpul.)


On 28/07/2020 18.23, Paul Allen wrote:
> Or maybe I've seen floating piers. :)

Even floating piers may have sections on land:

https://cdn.shopify.com/s/files/1/0056/4376/3801/products/10x8_Aluminum-Framed_Floating_Dock_with_Pond_King_Sport_Mini_Pontoon_Boat_grande.jpeg
https://chesapeakedock.com/app/uploads/2020/02/garido-floating-pier-1.jpg
https://i.pinimg.com/736x/e0/c5/0a/e0c50a27ceaf9b3ef12a54f6571284ff.jpg
https://cdn.shopify.com/s/files/1/0056/4376/3801/products/8x8-8ft-walkway_grande.jpg
https://www.goldenboatlifts.com/wp-content/uploads/2017/10/IMG_0092.jpg

...unless you insist on separately modeling the connecting section as a 
bridge. (Which I will concede is feasible in *some* cases. Even in my 
example, if I knew how to tag the on-land part, but less so in the 
examples given above in this message.)


(On a related note, this makes me think we should have pier type tags...)

So... back to my *other* question: how should a raised wooden platform 
on land be tagged? For example:


https://www.pitztal.com/sites/default/files/styles/adaptive/public/thumb_5101_lightbox.jpeg
https://upload.wikimedia.org/wikipedia/commons/e/e2/Laguna_Mountains%2C_California%2C_observation_area_2015.jpg

--
Matthew

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

[Tagging] How to map "piers" on land?

[Matthew Woehlke]

Please see https://www.openstreetmap.org/way/651244930. This is a pier 
with a platform on land that extends into the water. Carto cuts off the 
part that is on land.


Is this a carto bug or should the part that is on land be tagged 
differently? (I wonder about the current behavior, because pier 
structures almost never end exactly at the waterline...)


For that matter, how would something like this (a wood-surfaced raised 
observation deck) in the middle of a grass field be tagged? I've seen 
such things in some parks.


--
Matthew

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

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Matthew Woehlke]

On 28/07/2020 03.15, Martin Koppenhoefer wrote:

Never use the driveway tag on public ways


Uh... IIUC, "public" driveways are just fine. A driveway is a minor 
service road leading to a residential *or business* property. I've 
tagged plenty of things that aren't really "roads" (entrances to parking 
lots, especially) as service=driveway.


...OTOH they probably aren't technically *public* roads, even though 
there are generally open to the public.


For example: https://www.openstreetmap.org/way/378672974.

--
Matthew

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

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

[Matthew Woehlke]

On 27/07/2020 17.59, Mateusz Konieczny via Tagging wrote:

Jul 27, 2020, 21:55 by r...@senecass.com:

I assume if the highway has no name, it'd be highway=service, but if
it has a county name, like "Lost Gulch Road" too, wouldn't it then be
highway=residential? Is there a difference if it's vacation cabins, or
seasonal or full-time houses ?


Maybe "named therefore residential, service otherwise" makes
sense in your region, but in some places (for example Poland)
there are named service roads and unnamed residential roads.


If the road leads to houses, residential probably makes sense. The 
reason I want to chime in here, though, is that *in general* I agree 
with this last comment. TIGER seems to label everything that isn't 
primary/secondary/tertiary as "residential", but per the wiki, 
residential is supposed to only be used for roads that are, well 
*residential*, i.e. are leading to or fronted by *residences*.


Personally, when I see stuff like 
https://www.openstreetmap.org/way/734188025, I re-tag it highway=service 
or highway=unclassified. That road (apparently¹) has a name, but it's 
clearly *not* a residential road; it's the access road to a strip mall.


(¹ Seeing as https://www.openstreetmap.org/way/50738336 is apparently 
"also" Southside Drive, I would question the name on way 734188025, but 
I can't get there right now to do a survey. However, that's sort of 
beside the point.)


TL;DR: I assume that Rob had an unstated "if it leads to residences" in 
there, and probably should have stated it, because the rest of the 
assertion is only valid *with* that assumption.


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 25/07/2020 16.40, Allroads wrote:

The earlier mentioned,
bicycle=leave
This is for me, leave the bicycle behind at the sign.
More native English speakers can give a comment on that?


I don't know that I would guess that's what that means...

(Strictly from a "what's most reasonable, ignoring fixup effort" 
standpoint, I'd be strongly in favor of "no really means no; don't use 
that if you really mean bicycle=dismount".)



So, now we need also a hard yes. That you must bring a bicycle with you.


This conversation started as "what the heck does bicycle=dismount 
foot=no mean?"... we could use that, or maybe to be more clear, 
foot=with_bicycle.


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 25/07/2020 14.26, Jo wrote:

In Antwerpen there is a bus that you can only take, as a cyclist, so
accompanied by a bicycle. It's a subsidised service of the harbour, free
for its users (commuters). The bus replaces a ferry and goes through a
tunnel, prohibited for cyclists riding a bicycle.


***SEE!!*** This is why I don't make assumptions! :-D

--
Matthew

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

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

[Matthew Woehlke]

On 25/07/2020 07.06, Andy Townsend wrote:
Why do people in OSM map anything?  I can't see any reason why I'd want 
to add urban buildings, or comprehensive address data, or a whole bunch 
of other things that people think are _really important_.



How are addresses _not_ important? If I'm trying to find 123 Cherry 
Lane, I really, really appreciate if that entity actually exists in OSM.


I guess I don't know what you mean by "comprehensive".

As for buildings, I know you meant that as a rhetorical question, but I 
have a fascinating perspective I hope you'll forgive me if I share. I'm 
working on traffic simulation, and one of the problems is creating 
realistic waypoints. To do this, I either have to specify start and stop 
points manually (a huge amount of work that is of no benefit outside a 
particular simulation), or make educated guesses based on knowing where 
things like offices and houses are. I also need to guesstimate *how 
many* people will leave a particular house, or travel to a particular 
office. If buildings are present and fully tagged as to their purpose, I 
can not only decide what category they should be in, I can also use 
their square footage to estimate their occupancy.


See? Urban buildings are *useful* to me! :-)

Someone else recently posted that having the buildings *and their 
material composition* tagged is useful for planning purposes for folks 
going around trying to kill malaria-carrying mosquitoes.


(Yes, that means I may need to model the buildings, but at least all 
that work makes the map better and might be useful to someone else.)


For me, it's probably power lines that seem useless, but someone else 
probably has a use case where having those mapped is really helpful. 
(Maybe someone planning to buy a house wants to know, without having to 
drive there, if there are high-voltage power lines nearby?)


--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 25/07/2020 03.34, Martin Koppenhoefer wrote:

On 24. Jul 2020, at 16:18, Matthew Woehlke  wrote:

if there is no name, what makes a parking space logically one lot?


Consisting of one contiguous surface? Clearly associated with the same building?


but it’s clearly distinct things: a motorcycle parking and a parking for 
automobiles...


What is "clear" to you is not "clear" to everyone. I look at those and I 
see *one* parking lot.


By your logic, we should also carve out disabled parking, PEV parking, 
carry-out parking, etc. from all parking lots.


IM(NSH)O, that's dumb. *Especially* if parking spaces are mapped.

--
Matthew

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

[Tagging] TRAVEL_DIR (and other fields) in shapefile?

[Matthew Woehlke]

This might be somewhat OT, but it's OSM-related, so...

I have a shapefile I obtained from a county's GIS¹. In addition to road 
names (sometimes) and speed limits (yay!), there is an attribute 
TRAVEL_DIR, which seems to have the possible values (at least) 1, 2 and 
3. Does anyone know what this field means? (I was hoping there might be 
some indication what roads are one-way, but I have not been able to 
determine a definite relation.)


For that matter, is there other useful information I might be able to 
extract? (For example, I wonder what TYPE_CODE means...)


I'm sort-of hoping these might be using some US standard system and not 
something the county made up. There seem to be some indications of that 
from trying to search the internet for information, but I was unable to 
find any sort of legend.


(¹ https://gisdata-pwcgov.opendata.arcgis.com/datasets/roads)

--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 10.52, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:26, Matthew Woehlke wrote:

Yeah, I don't know what "floating" means there.


You don't?  It even explained it in the video.  Or the description.
Somewhere.
The parking spaces are detached from the sidewalk because there's a
bicycle lane between the two.


Ah, yes, it's in the description (which I didn't read :P).


It's pretty typical of what I'm dealing with in Quantico, though. We
seem to have come to an agreement to map this as a "lot".


It's how I'd handle the one in the video.  But that's just me, bringing my
own cultural assumptions and idiosyncrasies with me.  And I'm
very idiosyncratic.


That's okay, I've decided I can very much live with that idiosyncrasy 
:-). (Did I mention that it's much easier to map lots than use 
parking:lane? ;-) ...that's rhetorical, BTW.)


--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 24/07/2020 10.44, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:20, Matthew Woehlke wrote:

For example, https://www.openstreetmap.org/way/828934579 and
https://www.openstreetmap.org/way/828934591, or (even better)
https://www.openstreetmap.org/way/828934580 and
https://www.openstreetmap.org/way/828934583. To wit, in both cases,
dividing the "separate lots" from each other requires drawing an
absolutely arbitrary line on the pavement.


That second pair of examples.  Ugh!

I think I'd try mapping them as a single parking lot and add parking
spaces.  Even though we don't currently have a way of tagging
motorcycle spaces, the relative sizes would give a clue.


Yeah, I'm probably going to rework it that way... and I am very 
seriously thinking about proposing capacity:motorcycle (and 
capacity:carry_out!) and parking_space={motorcycle,carry_out}.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 10.18, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:00, Matthew Woehlke wrote:

On 24/07/2020 08.19, Paul Allen wrote:

The image in the wiki for parking lanes matches
what I expect of it.  As in this situation near me:
https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
of the road are double yellow lines, which mean "no parking
or waiting at any time" (but there are exceptions) and on
the left is a single yellow line which means "parking and
waiting permitted some of the time" (though there are
exceptions and provisions and it gets complicated).  The
left is a parking lane, as I understand it.  There are no
parking spaces marked.


AFAIK there is nothing exactly like that in the US. People do park on
streets (note 5th, 4th and 3rd Avenues, as previously mentioned), and
there is sometimes signage regulating this.


Sounds like the same thing,  Near enough.  Especially if some streets
have signs saying "no parking at any time."


Right; I didn't mean "we don't have on-street parking", I meant we don't 
mark it like that.


Relatedly: I would call that "on-street parking". To me, a "parking 
lane" is actually more like the NYC video I linked, i.e. a space that is 
dedicated to *parking* and not intended to be used by through traffic. 
This is probably a large part of the confusion, as it seems that what 
OSM calls a "parking lane" is what I would call "on-street parking", and 
what I call a "parking lane", OSM considers a parking lot.



BTW, this is what NYC apparently considers a "parking lane":
https://www.youtube.com/watch?v=RJv4oleZAhQ


That's a "floating parking lane," according to the video.


Yeah, I don't know what "floating" means there.


Looks to me like a parking lot adjoining a road at one side and
adjoining a cycle lane at the other.  I say this because of what is
visible at the left of that "floating parking lane" - an obstacle.
Even with no vehicles parked there, through traffic would be
obstructed.  Difficult to be sure, from the video, though.  I'm glad
I don't have anything like that around here, otherwise I'd have to
figure out how to map it.


It's pretty typical of what I'm dealing with in Quantico, though. We 
seem to have come to an agreement to map this as a "lot".



That said, I think the US definition may be "a lane which is for
parking, rather than through traffic, and which may be intermittently
present" (e.g. the above video). However, I am much *less* convinced
that it is useful to model them that way, at least in the current state
of things.


Was there through traffic in the parking lane itself in the above video?


I can state with some confidence that there isn't *intended* to be. 
Again, I think we've agreed to treat that as a "lot". (Which I believe 
is what I was trying to say, admittedly very badly, with the above.)


--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 24/07/2020 02.19, Martin Koppenhoefer wrote:

On 23. Jul 2020, at 21:31, Matthew Woehlke  wrote:
...and what if we're mapping spaces? I'm not sure I'm on board with
dividing things which are logically "one parking lot"


if there is no name, what makes a parking space logically one lot?


Consisting of one contiguous surface? Clearly associated with the same 
building?


For example, https://www.openstreetmap.org/way/828934579 and 
https://www.openstreetmap.org/way/828934591, or (even better) 
https://www.openstreetmap.org/way/828934580 and 
https://www.openstreetmap.org/way/828934583. To wit, in both cases, 
dividing the "separate lots" from each other requires drawing an 
absolutely arbitrary line on the pavement.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 04.29, Mateusz Konieczny via Tagging wrote:

Jul 23, 2020, 20:42 by mwoehlke.fl...@gmail.com:

I'm trying to tag a whole bunch of side-of-road parking, and I have two 
questions.

First, what is the correct way to tag marked parking spaces? There
is parking:lane:*=marked which would seem to apply, but then it
isn't clear how to indicate the direction (parallel vs. diagonal
vs. perpendicular)?


Depending on their direction? Can you link photos of case that is unclear for 
you?


Diagonal vs. perpendicular vs. parallel is clear. What I mean is it s 
unclear how to tag e.g. marked, diagonal parking.


...or am I overthinking this? =marked;diagonal?


  It's also not entirely clear when I am or am not supposed to use 'marked'...


"There are only some parking spaces available that are individually marked."
so it seems to be used for example in case where there is a single parking 
space,
20m of no parking then other parking space (possibly in other direction),
tree, parking space, 10m of no parking, 3 parking spaces and so on.


This makes me wonder if 'marked' shouldn't even be a type, and maybe 
there should be an 'intermittent' tag instead.



Second, at what point does "on street parking" become a parking lot?

There are examples of the first *all* over Quantico (at least the "downtown" 
part). For examples of the second, consider:

  https://www.openstreetmap.org/way/829371448
  https://www.openstreetmap.org/way/829371451
  https://www.openstreetmap.org/way/826561586

I am particularly struggling to decide what to do at places such as:

  38.52057/-77.29185
  38.52181/-77.29611
  38.52125/-77.29711


Can you link some photos?


Use your favorite satellite imagery. For example, use 
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 and pull 
something up (the MapBox for this area is very high resolution).


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 08.19, Paul Allen wrote:

On Fri, 24 Jul 2020 at 00:06, Matthew Woehlke wrote:

Currently, I have the non-parallel spots marked as a lot. To my mind,
parallel parking and on-street parking are nearly synonymous.


I'm not entirely clear what you mean by those terms as you're
American.


That's okay; that makes two of us ;-).


The image in the wiki for parking lanes matches
what I expect of it.  As in this situation near me:
https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
of the road are double yellow lines, which mean "no parking
or waiting at any time" (but there are exceptions) and on
the left is a single yellow line which means "parking and
waiting permitted some of the time" (though there are
exceptions and provisions and it gets complicated).  The
left is a parking lane, as I understand it.  There are no
parking spaces marked.


AFAIK there is nothing exactly like that in the US. People do park on 
streets (note 5th, 4th and 3rd Avenues, as previously mentioned), and 
there is sometimes signage regulating this.


Actually, this might answer one of my prior questions; is =marked 
supposed to be used for stretches that alternate between parking allowed 
and parking forbidden?


BTW, this is what NYC apparently considers a "parking lane":
https://www.youtube.com/watch?v=RJv4oleZAhQ

Based on this discussion, it seems to me that that is *not* a "parking 
lane" as OSM uses it.


That said, I think the US definition may be "a lane which is for 
parking, rather than through traffic, and which may be intermittently 
present" (e.g. the above video). However, I am much *less* convinced 
that it is useful to model them that way, at least in the current state 
of things.



Well, there's an easy solution to that; map the spaces, also ;-)


Yeah, but the spaces don't render.  Oh wow!  I just checked one of your
later examples and parking spaces now render.  I'd given up on hoping that
they would render.  Doesn't fix the example I'm thinking of, though - it's
clearly a pregnant bulge that is for parking, but no spaces are marked.


Ah, yes, that would be an issue. Not sure what was with the not 
rendering, unless you happened to look at it soon enough after I 
uploaded the changes. There does seem to be a variable delay between the 
database changing and the rendered tiles being regenerated.



it's normal for a parking lot area to include at least parts of the
aisles.


In one sense it's correct.  At a level of highway modelling we don't do and
may never do.  In terms of what gets rendered (where the renderer draws
roads on a layer above parking lots), it's perfectly comprehensible.  Since
we don't have a better way of representing what's there, I ignored the
objection.


Agreed; if the road was mapped also as an area, it would make sense.


...and to be honest, another argument for modeling as lots is that the
parking_lane tagging is rather more obtuse...


There is that.  Which is why I tend not to bother with it.  Especially as it
means surveying and finding out the restrictions on times.


Meh, I'm happy to omit the restrictions :-).

--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 23/07/2020 17.30, Mike Thompson wrote:

On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke wrote:

...but then your horse is a passenger in a vehicle. Otherwise that would
be like saying a human can't ride in a vehicle if foot=no.


Exactly, foot=no doesn't mean that feet are not allowed, it means that
using a mode of transportation that primarily uses feet  ("foot
travel"/walking/running/hiking) isn't allowed.
bicycle=no is consistent with this, it doesn't mean that bicycles are
prohibited, it means that a mode of transportation, (bicycle riding) is
prohibited.
horse=no is apparently a  little different as you point out.  It seems to
refer not just to a mode of transportation, but to the possession of the
animal in general.


I disagree. In both cases, what is prohibited is the horse/bicycle 
touching the ground.


Based on that, you could argue that bicycle=no means you can *carry*, 
but not *walk* (push) your bicycle. I would be *tentatively* sympathetic 
to such an argument... depending on how obnoxious it is for you to be 
dragging around a bicycle. For something like a foldable, or if is 
dismantled enough to not be a large, ungainly object, then I would lean 
toward that being okay (which is where we get into prohibited=bicycle or 
whatever spelling).



It is similar to dog=no. dog=no doesn't refer to
whether you can use a dog as a mode of transportation, it means you can't
possess a dog at all on the given way (even if you carry it).


*This* is where things become inconsistent :-). Although, as we've 
noted, in some instances you *can* carry your dog.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 23/07/2020 17.26, Paul Allen wrote:

On Thu, 23 Jul 2020 at 21:00, Matthew Woehlke wrote:

Interesting. By that criteria, I would think that
https://www.openstreetmap.org/way/826561593 has on-street parking,


Tough call.  In isolation it looks like a parking lane, but it has markings
for car parking.  On-street parking (at least where I am) doesn't usually
have that.  However, when I switch to Virginia imagery (much clearer)
I see the parking extends around the corner.


The Virginia Ortho isn't bad, and I sometimes use it as a secondary 
reference, but MapBox is even better. (That doesn't seem to be the case 
everywhere; in some places, MapBox is apparently quite bad, but for much 
of the US east coast it seems to be the highest-resolution imagery 
available. NAIP is the *newest*, but it's lower resolution than many 
other sources.)



From the geometry, I'd say that was a parking lot.


Currently, I have the non-parallel spots marked as a lot. To my mind, 
parallel parking and on-street parking are nearly synonymous. That said, 
I can see your argument, especially if I look at JOSM's lane rendering 
as a gauge for whether normal traffic flow would be occluded by parked 
vehicles. In that sense, there are a lot of folks parking on e.g. 3rd 
and 4th Avenues (where there are additionally not marked spaces) that I 
would definitely call "on street parking". (I'm also not at all inclined 
to tag that.)



but would you argue that all of Potomac Avenue
(https://www.openstreetmap.org/way/686513005


From the fact that parking spaces are marked, it's not a parking
lane, in my opinion.


Well it's certainly not a parking *lane*; you clearly are not meant to 
possibly drive through it. I was thinking that the fact the parking 
spaces are arranged so as to not occlude traffic was what was inclining 
me to model it as a "lot".


Really, it's the notion of a parking lot for which the aisle is also a 
main road that's throwing me... Maybe I should look at what's been done 
somewhere like Manhattan...



Actually, I did mean the six spaces on the west side of Broadway. I
recommend looking at e.g.
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 for all of
those, it will be easier to tell what's centered.


That's a parking lot rather than on-street parking.  At least, that's how
I'd map it.  If no cars were parked you couldn't drive along it without
some turns.  If you mapped the highway itself as an area, that
parking would be a pregnant bulge.


Yeah, that line of thinking is similar in effect to asking if it 
occludes normal traffic flow. Different questions, but likely to have 
the same answer.



This is how I handled a similar one:
https://www.openstreetmap.org/?mlat=52.08562=-4.65829#map=19/52.08562/-4.65829

Somebody objected that whilst that looked right when rendered, when
you examined it in the editor it misleadingly implied that you could
park with one end of your car blocking half of the street.
Well, there's an easy solution to that; map the spaces, also ;-). That 
said, I find that attitude slightly asinine; it's normal for a parking 
lot area to include at least parts of the aisles.



I did one car park which attempted to deal with that complaint:
https://www.openstreetmap.org/?mlat=52.10572=-4.37367#map=19/52.10572/-4.37367
but it looks so ugly that I doubt I'll do that again.


Agreed (on the 'looking ugly'). I also tend to line up edges of lots 
along ways (example: https://www.openstreetmap.org/way/826298876). 
However, part of that was from an effort to make the lot only cover the 
area where you can actually park, without disconnecting it from the ways 
that serve it (the aforementioned lot is a good example of my 'older' 
technique). However, now that I am drawing the spaces also (thank you 
gridify!), I'm generally mapping the entire surface, up to some 
semi-arbitrary cutoff representing the entrances. I suppose if the roads 
were also mapped as areas, I would probably connect those rather than 
mapping them as separate driveways, although I'm on the fence there 
also. For example, with https://www.openstreetmap.org/way/826239218 I've 
connected the parking aisle directly to the main road, but in other 
places (e.g. https://www.openstreetmap.org/way/829371430) I've modeled a 
separate driveway first.


Anyway, your example would be much more sane if the entire road had a 
mapped area, rather than just the little piece by the parking lot.



In the end, do what works for you and hope nobody else who comes across it
thinks it so egregiously wrong that they change it.  At least not until
you've finished your project.


As long as they don't *remove* information, I don't mind people 
fiddling. That said, I'm not going to hold my breath, there doesn't seem 
to have been much activity on the base until I started working on it.


...and to be honest, another argument for modeling as lots is that the 
parking_lane tagging is rather more obtuse...


Anyw

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 23/07/2020 16.16, Mike Thompson wrote:

Perhaps it is unfortunate that for modes of transportation we picked
nouns rather than verbs (e.g. foot vs. walking), but that is what it
is by long tradition.  A similar thing applies to horse=no.  There
are roads (some of the US Interstates) where you can not ride your
horse, but you can load your horse into a trailer, hook the trailer
up to your truck, and drive with your horse on those same roads.


...but then your horse is a passenger in a vehicle. Otherwise that would 
be like saying a human can't ride in a vehicle if foot=no. Besides, 
those restrictions are generally because slow-moving traffic is a 
hazard; in a trailer, your horse (camel, elephant, ...) is no longer 
slow-moving.


For similar reasons, I would assume that a way that allows vehicles but 
not pushed bicycles allows a bicycle *in* a vehicle.


FWIW, I'm sympathetic to the "no means no" camp and just declaring that 
if you really meant "dismount", *fix it*.


I don't think bicycle=no and horse=no should mean something different. 
If horse=no means "no horses allowed", not "horses allowed as long as no 
one is riding them" (which I would expect to be the case), then 
bicycle=no should mean the same thing with "bicycle" substituted for 
"horse". And in both cases, we're talking about the horse/bicycle being 
*directly* on the way, not being inside a vehicle.


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 23/07/2020 15.34, Jmapb wrote:

As I see it, having bicycle=no imply permission to push a dismounted
bicycle violates the principle of least surprise because it's
inconsistent with other *=no access tags. I wouldn't presume I could
push my car along a motor_vehicle=no way,


While I would generally agree, I *have* seen someone "dismount" their 
car¹ and drag it along sidewalks. Mind, they also drove it onto an 
elevator and into a library², so...


(OTOH, they may have had permission to do this; "someone" *was* Jeremy 
Clarkson... If you saw it, you knew this thread wasn't going to be 
"complete" until it got mentioned ;-). Yes, you *can* "dismount" and 
push/pull a road-legal petrol vehicle. Depending on the vehicle.)


(¹ https://en.wikipedia.org/wiki/Peel_P50)

(² ...or was that the "P45"? I forget...)


or dismount my horse and lead it along a horse=no way.


Definitely.

--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 23/07/2020 15.20, Paul Allen wrote:

On Thu, 23 Jul 2020 at 19:43, Matthew Woehlke 
wrote:


I'm trying to tag a whole bunch of side-of-road parking, and I have two
questions.

First, what is the correct way to tag marked parking spaces? There is
parking:lane:*=marked which would seem to apply, but then it isn't clear
how to indicate the direction (parallel vs. diagonal vs. perpendicular)?
It's also not entirely clear when I am or am not supposed to use
'marked'...



In a parking lot, amenity=parking_space.  It doesn't render on standard
carto, so you may not feel it worth the effort.  If it's not obvious from
the dimensions (parallel vs perpendicular should be) people will
see when they get there.  You've given the capacity but can't
map how many spaces are currently free - some things have to be
left to inspection.


Second, at what point does "on street parking" become a parking lot?


When it's not part of the street.


Interesting. By that criteria, I would think that 
https://www.openstreetmap.org/way/826561593 has on-street parking, but 
would you argue that all of Potomac Avenue 
(https://www.openstreetmap.org/way/686513005 and 
https://www.openstreetmap.org/way/20453853 *is* or *is not* on-street 
parking? What about https://www.openstreetmap.org/way/686513006?



I am particularly struggling to decide what to do at places such as:

38.52057/-77.29185
38.52181/-77.29611
38.52125/-77.29711


Pretend they don't exist.  Map something else instead.


Alas, my end goal isn't just to map for the sake of mapping, but to have 
a map that is usable for another project :-). Right now, having as much 
parking mapped as possible is relevant to that objective.



That first one is tricky.  I assume you're talking about the
ordinary parking lot with the off-street parking adjoining rather
than the separate 6-place parking next to the building.
Actually, I did mean the six spaces on the west side of Broadway. I 
recommend looking at e.g. 
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 for all of 
those, it will be easier to tell what's centered.


That said...


I'd map it as a large parking lot (as you have) and then the
side-of-street but as a separate off-street parking of the type you
did for https://www.openstreetmap.org/way/829371451 then combine the
two in a multipolygon.
...I was wondering about this also, so thanks for the thoughts! To be 
clear, you are suggesting to *not* use parking_lane stuff for this?



Actually, that#s three separate bits of off-street-parking because they're
interrupted by the access roads into the larger parking area.


Meh, parking aisles and even driveways pass through lots all the time, I 
think modeling them as three separate lots may be overkill :-).


--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 22/07/2020 20.49, Warin wrote:

You asked for 'better' without defining what better means to you.
To me it is 'better' to know where these things are (requires more work 
by the mapper) rather than that they are somewhere inside some area 
(requires less work by the mapper).


Disabled parking to me is 'better' mapped as a separate thing, as is 
truck parking etc.


While a motorcycle may legal park where a car parking space is the same 
cannot be said of a motorcycle parking space given  the usual sized of 
the things.


Tags may be available for those who cannot be bothered with the detail, 
similar observations may be made for surface=paved vs surface=concrete etc.


...and what if we're mapping spaces? I'm not sure I'm on board with 
dividing things which are logically "one parking lot" into multiple 
areas for... questionable benefit at that point. (If the spaces are also 
mapped, the "where is the parking for X?" doesn't hold.)


I think I want parking:capacity:motorcycle, and, while we're on the 
subject, parking:capacity:carry_out :-).


(And also parking_space=motorcycle and parking_space=carry_out, naturally.)

--
Matthew

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

[Tagging] Two side-of-road parking questions

[Matthew Woehlke]

I'm trying to tag a whole bunch of side-of-road parking, and I have two 
questions.


First, what is the correct way to tag marked parking spaces? There is 
parking:lane:*=marked which would seem to apply, but then it isn't clear 
how to indicate the direction (parallel vs. diagonal vs. perpendicular)? 
It's also not entirely clear when I am or am not supposed to use 'marked'...


Second, at what point does "on street parking" become a parking lot?

There are examples of the first *all* over Quantico (at least the 
"downtown" part). For examples of the second, consider:


  https://www.openstreetmap.org/way/829371448
  https://www.openstreetmap.org/way/829371451
  https://www.openstreetmap.org/way/826561586

I am particularly struggling to decide what to do at places such as:

  38.52057/-77.29185
  38.52181/-77.29611
  38.52125/-77.29711

(There are likely more examples...)

--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 23/07/2020 12.09, bkil wrote:

Alright, I didn't know you were only asking for the entertainment
value, but then I accept your challenge.


I wasn't asking for entertainment. I was asking because, while 
*logically* it seems like such a combination doesn't make sense, the 
refrain around here seems to be "don't assume".



Actually I could indeed think of a place where you are only allowed to
be present in case you are pushing a bicycle. Imagine a bicycle
adventure park that only contains bicycle roads. Let's say that the
terms of service declares that visitors must not leave their bikes
unattended (i.e., no parking).

Now let's pretend that there's a small bridge in the middle of the
park that includes a small stretch of stairs that has bicycle pushing
rails (or substitute with just a single wooden bridge in a bad shape
that has a bunch of long cracks that could easily lock your wheels if
you ride over it - true story, we had a bridge just like that). A sign
would be posted here that disallows bicycle riders from accessing it,
but pushing through would be possible.

How could you be walking on to this bridge if you were not in
possession of a bicycle in the first place?


Interesting. I suppose the question becomes, if there were such a way, 
would you tag it foot=no + bicycle=dismount?


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 23/07/2020 09.59, Philip Barnes wrote:

On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
I'm trying (and failing) to imagine a road/path/whatever that you 
are allowed to walk on *iff* you are pushing a bicycle (or moped

or...). Do you know of any examples?


I cannot think of many roads where you can walk but not cycle, other
than pedestrianised streets in town centres but you can walk on lots of
footpaths where you can push a bicycle. Some are too long and totally
unsuitable.

A few of examples from my local big town
https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
https://www.openstreetmap.org/way/23896048

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

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


All of those examples appear to allow regular pedestrians (foot=yes), 
which is common. I am asking if there are any places where walking is 
allowed *only* if you are pushing a bicycle, i.e. "no bicycle, no 
access". IOW, where your joke about dogs isn't a joke.


(OT: Airline transponders may be IFF — note the capitalization — 
although I wonder about that because I always think of IFF as more a 
military thing. I'm not sure if civilian transponders are really meant 
to *identify friend or foe*, or if they're more just "transponders".)


On 23/07/2020 09.59, bkil wrote:

For example, bicycle=dismount should be understood that bicycle
access is only allowed if a rider dismounts. However, if we had to
write bicycle=dismount + foot=no, then the meaning basically becomes:
neither riding your bicycle nor walking is allowed here, which is
quite the opposite compared to what bicycle=dismount would mean if it
were placed alone on the POI. Hence the correct way to tag this
should be bicycle=no + foot=no.


Right, that's what I was suggesting, because the only plausible 
interpretation I can come up with for foot=no + bicycle=dismount is that 
you may traverse the way [on foot] iff you are pushing a bicycle. The 
question was, does that ever actually happen? I'm not *quite* willing to 
rule it out...


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Matthew Woehlke]

On 22/07/2020 19.05, bkil wrote:

But also consider that it wouldn't make sense to tag a motorway as
foot=no + bicycle=dismount (+ moped=dismount + mofa=dismount +
auto_rickshaw=no + agricultural=no), because the combination of tags would
create a completely new meaning, and that is not a preferred tagging
practice in OSM.

I.e., bicycle=dismount means that you can proceed after you dismount,
however if a certain combination of other tags are also present (foot=no),
a data user would need to ignore this, making this more confusing than
necessary (bicycle=no).


I'm trying (and failing) to imagine a road/path/whatever that you are 
allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do 
you know of any examples?


--
Matthew

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

[Tagging] Feature Proposal - RFC - sport:four_square

[Matthew Woehlke]

When creating https://www.openstreetmap.org/way/828950465, I wasn't sure 
how to tag it... it's a somewhat generic paved lot for recreation, but 
it *does* have markings for four square, which is not unusual for such 
areas.


We do not have an "official" tag for that, although even so there are 
almost 400 extant uses (some sport=four_square, many fewer 
sport=foursquare).


Shall we make this an official value?

https://wiki.openstreetmap.org/wiki/Proposed_features/sport%3Dfour_square

--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 22/07/2020 16.32, Martin Koppenhoefer wrote:

Am Mi., 22. Juli 2020 um 21:11 Uhr schrieb Matthew Woehlke:

Right now the only option seems to be to model the lot as two separate
entities, one which excludes the motorcycle spaces, and one which is
*only* the motorcycle spaces which could be amenity=motorcycle_parking.
Is this really the best way?


I am usually doing it like this (separate entities), it also seems most
useful for drivers / riders, because each group can see where are their
parking lots.


So... I'm not sure I agree with that. Maybe it's different in !US, but 
in the US, motorcycles can (generally) park in any car parking space. If 
we're going to use that argument, why do we have capacity:disabled, or 
indeed capacity:*, rather than modeling those spaces as separate lots?


--
Matthew

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

[Tagging] Tagging motorcycle parking

[Matthew Woehlke]

I've seen some parking lots that have spaces specifically for 
motorcycles (i.e. that are not large enough for cars), although the lot 
as a whole is mixed-use. Is there no "direct" way to tag this (something 
like capacity:motorcycle)?


Right now the only option seems to be to model the lot as two separate 
entities, one which excludes the motorcycle spaces, and one which is 
*only* the motorcycle spaces which could be amenity=motorcycle_parking. 
Is this really the best way?


--
Matthew

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

Re: [Tagging] Waterway equivalent of noexit=yes?

[Matthew Woehlke]

On 22/07/2020 11.25, Tod Fitch wrote:

Digression: The wiki page for natural=sinkhole [3] says that it is a
tagging error to use natural=sink_hole. When I look at taginfo I see
nearly 2000 occurances of natural=sink_hole and none for
natural=sinkhole [4]. I guess the write of the wiki page disagreed
with the spelling of the most used spelling of the tag value.


I am fairly confident that "sinkhole" is the correct American spelling, 
and "sink hole" is discouraged; my guess is that's what the author was 
thinking.


That said, OSM apparently uses en_GB spelling, and "sink hole" *does* 
seem to have use in the UK (but it seems "sinkhole" does also).


FWIW, Wikipedia (https://en.wikipedia.org/wiki/Sinkhole) only lists 
"sink-hole" as an alternative, although Wiktionary does have "sink hole".


Interestingly, the etymology is given as 'from sinkehole, sinkeholl', 
suggesting that "sink hole" is a neologism and "sinkhole" is more 
historically accurate.


--
Matthew

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

[Tagging] How to tag minor commercial roads?

[Matthew Woehlke]

I'm wondering what, if anything, I should do with 
https://www.openstreetmap.org/way/351516889. It doesn't seem to meet the 
definition of a highway=residential, but I'm not convinced it is a lowly 
highway=service, either, but I also can't easily demonstrate it is 
highway=tertiary.


How should I classify this?

--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 15/07/2020 17.10, Martin Koppenhoefer wrote:

On 15. Jul 2020, at 16:17, Matthew Woehlke wrote:

Do you mean having that on both the relation and the areas?

>
yes, you should have it only on the relation 


If I remove it from the areas, however, at least iD no longer thinks 
they are parking lots.



Generally I would agree with Paul, maxstay of a few minutes isn’t actually a 
„parking“


I think you and I must have different definitions of "parking".

- Did you shut off the engine?
- Did you engage the parking brake?
- Did you exit and lock the vehicle?
- Are your hazard flashers *not* on?

If the answer to any of the above is 'yes', you may be "parked". If the 
answer to *all* of the above is 'yes', you are almost surely parked.


Note that there is nothing in that list about how *long* you expect to 
be away.


If you stop at a rest area, expecting to only run in and use the 
facilities and then leave again (so, less than ten minutes), do you say 
your vehicle is "parked" when you walk away from it?


For that matter, the signs themselves even say "15 minute *parking*" or 
"*parking* for to-go only" (emphasis added).


As Paul notes, these are spots where you are allowed to "park" and go 
inside to get your food. I'm inclined to agree with that distinction. (I 
might add to that "...for non-emergency purposes". A shoulder on a 
highway isn't "parking" even though you may need to leave your vehicle 
to go get help if your car breaks down.)


FWIW, 
https://www.myparkingsign.com/MPS/No-Parking-No-Standing-No-Stopping.aspx 
roughly defines "parking" as "leaving the vehicle unattended". That 
said, legal definitions can and do vary.


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 15/07/2020 05.43, Paul Allen wrote:

On Wed, 15 Jul 2020 at 08:35, Martin Koppenhoefer wrote:

there is the "maxstay" tag which can be used with a value like 5 or 15
minutes.
https://taginfo.openstreetmap.org/keys/maxstay#values


That works semantically, but the rendering is (on many cartos) misleading.
If it looks like a car park on the map, people assume it's a car park.  Few
will go to the trouble of querying the tags to find there's a max stay.


...which is IMHO dumb, because time-limited parking is extremely common 
in some instances (especially metered parking in cities). Granted, the 
maximum stay is usually hours, not minutes. OTOH...



The label would help avoid confusion but to me it doesn't feel like a
car park as I understand the term.
...15-minute parking for a store in which you usually don't spend a lot 
of time doesn't really make it "not parking" either.


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 15/07/2020 03.33, Martin Koppenhoefer wrote:

Also you should not have 2 objects amenity=parking which cover the same
area (regardless of additional tags).


Do you mean having that on both the relation and the areas?


Am Mi., 15. Juli 2020 um 01:40 Uhr schrieb Paul Allen :

Even so, is a multipolygon giving any information that couldn't be had
by separate parking areas with the appropriate operator tag?


+1, this is what I would choose, no relation at all. It is also what you
can probably argue for "on the ground": two parkings operated by the same
business, not one parking spread over 2 areas.


Okay, I'm curious now, how would you treat 
https://www.openstreetmap.org/way/117565094 and 
https://www.openstreetmap.org/way/117565096. IMO those are both part of 
"the same lot", split across a road, or at least they are parking for 
the same place (SPAC). For that matter, I think most people would 
consider my original example, or certainly Delmonico’s next door (west) 
as a single lot.



(BTW, is there any accepted way to tag a 'carry-out only' space?)


there is the "maxstay" tag which can be used with a value like 5 or 15
minutes.
https://taginfo.openstreetmap.org/keys/maxstay#values


Yes, but a) there is no explicit time limit (maxstay=carry-out?), and b) 
how do you apply that to only some spaces?


Of course, now that I've mentioned it, how do you note that 2 out of 20 
spaces are maxstay=15? (I've seen that...)


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 14/07/2020 19.39, Paul Allen wrote:

On Tue, 14 Jul 2020 at 23:44, Matthew Woehlke wrote:
The multipolygon is just ammenity=parking, but the sub-objects are 
tagged with more information (capacity, in particular). Again, is

that sane, or do I need to do this differently?


Doesn't look sane at present.  You have combined one public parking
area with two private ones.  If they're all private, for use by the
restaurant, mark them all as private.


Oh, right, I keep forgetting about that. They're all notionally "the 
Chili's parking lot", but people use the back lot as overflow parking 
for other nearby locations (e.g. the office building to the immediate 
northeast). I'm sure they'd get annoyed at someone taking their "prime" 
spaces for that purpose, but I haven't observed them caring about folks 
in the far end of the back lot.


Maybe this is an argument for a site, instead?

OTOH, now we can rehash the access=destination discussion given that 
(most of¹) the lot isn't *explicitly* signed "customers only" and yet 
that's obviously the intent.


(¹ I would argue that the 'carry-out only' spaces qualify as 'customers 
only'.)



Even so, is a multipolygon giving any information that couldn't be had
by separate parking areas with the appropriate operator tag?


As I understand it, the operator tag is more of a legal thing (which I 
honestly wonder why or *how* we map) and not so much an "associated with 
such-and-such building" tag. Accordingly, it is clear as mud how I'm 
supposed to apply that tag.



(BTW, is there any accepted way to tag a 'carry-out only' space?)


If you're talking about one (or both) of those parking areas by the
restaurant, then it is (or they are) not really a parking area.


Only specific parking spaces² are carry-out only. The lot as a whole — 
and I would expect most people to consider it *one* lot³ — contains a 
mix of several types of parking spaces, distinguished only by marking 
and/or signage. I think it would be odd to specifically carve out the 
carry-out-only spaces from the rest of the lot.


IMHO there should be a way to tag that a lot contains such spaces.

(² IMHO, any reasonable person is going to consider them parking spaces, 
even if they are implicitly limited to a very short time. On which note, 
'15 minute parking' spaces are also quite common, at least in my area.)


(³ Possibly, as I've drawn it, three lots, or anyway three clearly 
different 'sections' of something which conceptually is a single lot.)


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 14/07/2020 12.05, Peter Elderson wrote:

Just two outers is a regular use of multipolygon.

One parking lot on two sides of a road is perfect for this method.


Okay, since you brought it up... is this¹ an appropriate use of a 
multipolygon?


On the subject of:


it will then get the attributes of the multipolygon.
The multipolygon is just ammenity=parking, but the sub-objects are 
tagged with more information (capacity, in particular). Again, is that 
sane, or do I need to do this differently?


(BTW, is there any accepted way to tag a 'carry-out only' space?)

(¹ https://www.openstreetmap.org/relation/11300044)

--
Matthew

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Matthew Woehlke]

On 10/07/2020 19.45, Shawn K. Quinn wrote:

On 7/10/20 09:04, Matthew Woehlke wrote:

(I would probably use access=permissive for e.g. a mall parking lot,
where it's not strictly public, but where you wouldn't be expected to be
visiting a particular building or organization such that it's much less
clear whether or not you are a "customer".)


You would still most likely be expected to be a customer of some store
within the mall, whether you're just popping into the food court to get
a Big Mac from McDonald's for lunch or you're getting a new flat screen
TV from Macy's (or for that matter, just browsing in Macy's).


True, but at the least, it's much harder to enforce that you aren't just 
parking there and either walking to somewhere else or hitching a ride 
with someone else to some other destination than it would be at a lot 
dedicated to a single building. Overnight parking may well get you 
towed, but I'd be surprised if people don't leave vehicles in mall lots 
during the day that don't actually go to the mall. For that matter, I 
know that some people go to malls just to walk around.



At least in the US, even though malls are nominally public spaces they
are still private property and many of them around here (Houston area)
specifically state certain non-shopping activities that will get you
bounced from the property (usually things like protesting or
unauthorized peddling).


Sure, which is why such lots should be "permissive" and not "public".

--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 10/07/2020 19.51, Graeme Fitzpatrick wrote:

On Sat, 11 Jul 2020 at 04:18, Martin Koppenhoefer wrote:

it is not so relevant for the international mailing list, because these
things tend to work differently in different countries.


Which proves the impossibility of trying to get one term to cover all
possible aspects interchangeably worldwide :-(


Right, which is why I wonder if we shouldn't enumerate the 
possibilities, pick some term in use for each, and use those 
consistently, local conventions be damned. That's approximately what I 
was trying to do. (I used the US terms, but I'm not saying we "should" 
use those.)


On 10/07/2020 14.17, Martin Koppenhoefer wrote:

IMHO this discussion is going offtopic as we generally do not map
ownership.


I don't agree that it's off-topic. While I certainly agree we shouldn't 
map ownership as in "5 West Street is owned by Jacob Smith", I *am* 
arguing that we should map according to lots/deeds. (Personally, I would 
also like to map *lots*, but maybe that's just me.)



If you want to dig deep into american legislation specifics only, it
is not so relevant for the international mailing list, because these
things tend to work differently in different countries.
Last I checked, America isn't the only country that allows private land 
ownership.


Per the above reply to Graeme, the intent of the message to which you 
replied wasn't to enumerate US-specific ownership categories. It was 
meant as an initial attempt to produce a more general list. Yes, it uses 
US categories and terminology *because that's what I know*. I also 
stated that the list is likely incomplete.


Again, I think it would be helpful to have a list of lease/ownership 
types somewhere in order to establish a shared lexicon, so that we can 
point to it and know what is meant by "townhouse" rather than having 
people talk past each other because their definitions differ.


For the purposes of such a list, I would recommend combining what I 
listed as "row house" and "semi-detached". As for what these mean for 
mapping, that is *exactly* what this thread is all about. Right now we 
have clear guidelines for mapping apartments and detached houses, but 
everything "in between" is, as far as I can tell, muddy.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 16.38, Jarek Piórkowski wrote:

On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke wrote:

[problem description elided; see archives]


Yeah that's a problem. But since OSM would have to be changed to add
junction=intersection tags anyway, isn't it better to use the
established method of tagging with one traffic signal per direction at
the stop line, as suggested in the wiki
https://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Tag_all_incoming_ways
?


Yes, and somewhat irrelevant. That's not the only problem that 
junction=intersection solves.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 15.01, Martin Koppenhoefer wrote:

On 10. Jul 2020, at 16:17, Matthew Woehlke  wrote:

My use case isn't the only one that has issues with this sort of
thing; routers can "see" more traffic lights than actually exist
and can (so I hear, anyway) give directions that are potentially
confusing.


this is a different issue though, it depends how the traffic lights
are mapped (the way the junction is represented does have influence
how the traffic lights are mapped, but neither way leads necessarily
to a wrong number of traffic lights).


I have to strongly disagree. Consider an intersection of dual 
carriageways (so, four intersection nodes) where signals are tagged on 
the intersection nodes. Please explain how a tool is supposed to 
determine whether a vehicle passing "straight through" the intersection 
will encounter one or two signals.


Now take that same intersection and plop it into a dense urban area 
where there really *are* four separate intersections and explain how the 
same tool is supposed to know when that's the case.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

For illustrative purposes, I went ahead and tagged 
https://www.openstreetmap.org/way/175473372. (I chose this intersection 
because the way was already split, so the only edit needed was to add 
the tag.)


On 10/07/2020 10.15, Matthew Woehlke wrote:
As some of you may recall, I'm working on a project to do traffic 
simulation with the help of OSM data and SUMO¹.


One of the issues that SUMO has is that the typical method of modeling 
intersections (which I don't propose to change, mostly) results in SUMO 
thinking there are multiple intersections where there should only be 
one. For example, intersections of two dual carriageways produces four 
intersections and makes the turns much sharper than in reality.


My use case isn't the only one that has issues with this sort of thing; 
routers can "see" more traffic lights than actually exist and can (so I 
hear, anyway) give directions that are potentially confusing. 
Intersection modeling is a long-standing issue that has had multiple 
previous proposals.


The major two prior proposals of which I'm aware are to map the 
'footprint' of the intersection as an area, or to create relations to 
map the intersection. Both are difficult, both to model, and for tools 
to parse. The area proposal has potential rendering issues.


I am proposing² a *much* simpler alternative, which is to simply tag the 
portions of a road that are "part of" an intersection (i.e. the 'm', 
'n', 'p', 'q' segments of 
https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with 
junction=intersection. This is straight-forward to model, and I believe 
solves most of the issues for a majority of affected intersections. 
(Exceptions likely exist, but 'perfect' is the enemy of 'good', and 
right now we're at 'bad'.)


Comments would be appreciated!

Also, should I start just doing this for the areas I'm trying to use for 
my project, or is it better to wait for some degree of consensus?


(¹ https://www.eclipse.org/sumo/)

(² https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection) 


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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Matthew Woehlke]

On 10/07/2020 11.25, Paul Allen wrote:

On Fri, 10 Jul 2020 at 15:41, Matthew Woehlke wrote:

On 10/07/2020 09.32, Paul Allen wrote:

On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny wrote:

barren is horrible as it can be easily interpreted as including also
paved surfaces,


Ummm, not really.  Not in British English.  I'd never describe paved
surfaces as barren.  Technically, I suppose they are, but they don't
fit my mental category of barren.


As someone who desperately wishes his gravel driveway *was* barren, I'm
afraid I'm inclined to agree with Mateusz Konieczny :-).


How about the roof of your house?  Unless there's moss growing on it,
is it barren?  The road your house is on, is that barren?


My earthen roof might be barren, yes :-). (Okay, *I* don't have such a 
roof, but some people do!)



The car park in town, is that barren?
If it's well maintained, hopefully it is. If it's crumbling, it might 
not be! My previous residence had a paved driveway that, strictly 
speaking, was not barren.


It's true that such surfaces are often *implied* to be barren, and we 
may not think of typically labeling them as such, but strictly speaking, 
"barrenness" is a property that they *can*, and *don't necessarily* possess.


I think the real reason we don't typically think of roads as "barren" is 
because we think of them as existing at a different level, if that makes 
any sense. We don't think of a field with a large rock in it as "an area 
of bare rock surrounded by meadow", we think of it as "meadow, with a 
[large] rock in it". Roads and rivers are similar. By contrast, I 
*could* easily see describing a sufficient expanse of paved ground as 
"barren".


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 12.57, Tod Fitch wrote:

In the old days the wiki said you could put a highway=stop or
highway=give_way node on a way and the data consumer would determine
the nearest intersection and just do the right thing. I mapped
several thousand, yes thousand, stop signs that way. Later it was
decided that each of those nodes should also have a direction=forward
or direction=backward tag as well. Years later, I am still updating
those highway=stop nodes as the various QA tools nag that I am
responsible for miss tagging them. So I am pretty sensitive to
changing tagging norms on intersections.


That's... interestingly ironic. The problem is you *cannot* correctly 
tag a direction on such entities where assigned to the intersection 
nodes of a dual carriageway. My proposal would not only fix that, it 
would obviate the need for specifying a direction.


Going back to relations, is it even *possible* to correctly tag a 
relation on a way that isn't split at the 'via' node? (How does the 
relation otherwise know to which side of the way it applies?) If the way 
already *must* be split at the 'via' node, I don't think splitting it 
downstream will break the relation unless the editor is dumb as rocks. 
(That is, I think the editor can reliably repair the relation 
automatically.)



With respect to what happens when a way is split near an
intersection, I have been using the “tag all incoming ways” [1]
method for mapping intersections.


Heh... I missed (or had forgotten about) that. Yes, that's what I'm 
doing, also. It solves the signals/signage issue (and likewise makes it 
sometimes unnecessary to add directionality), but not other issues with 
tools not recognizing intersections as single logical entities.



I have seen a few intersections where the limit line (where you would
place the stop sign or traffic light node) exactly on top of a the
transition to a bridge. This leads me to wonder what the semantics of
“direction=forward | backward” or “traffic_signals:direction=forward
| backward” are if the node is at the change of ways, especially if
the ways have different directions.


Broken, I would expect, if the meeting ways don't have the same 
direction :-). (Fortunately, it should be easy for tools to flag this...)


If they're in the _same_ direction, it would apply to the way that is 
"entering" (or "exiting") the node, i.e. it's well defined.


But I think it is a situation that could be come more common if all 
ways are split where they enter an intersection so some thought

should be given to that.


I think I've already done that? One of the proposed semantics is that 
"signals do not apply to a way which is tagged junction=intersection". 
That is, it is well defined to which edge a signal/signage/etc. applies 
*without* needing to specify a direction. (This is implicit, because 
AFAIK signals/signs never apply *inside* of intersections, but to the 
*boundaries* of intersections. Once you're *in* an intersection, the 
intent is that you *get out ASAP*.)


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 12.22, Clifford Snow wrote:

Interesting suggestion. The sumo github page doesn't appear to have any
open issues that involve OSM and intersections that I could find. (I only
looked at intersection issue titles) Has this been reported to the sumo
developers? Sumo documentation does suggest fixing OSM issues but other
than that it seems to indicate that OSM data is suitable for use with their
software.


I haven't reported anything yet, but (obviously?) it is my intention if 
this gains any traction to improve SUMO to automatically merge 
intersections based on this tag. That said, if you watch their 
*tutorial* (it's over an hour long), there is at least one example where 
the presenter shows an instance of this issue, so it *is* known to the 
community. I'm not sure if anyone else has had the idea to specifically 
annotate these in OSM in order to be able to better fix up such 
intersections automatically.


For my specific use case, it's moderately important to be able to 
convert OSM data into SUMO networks in a fully automated and 
deterministic manner.


Another issue, that isn't really OSM's fault, is that SUMO likes to add 
intersections wherever a way is split, even though only two edges come 
together. I don't think OSM needs to change anything there, however, 
except perhaps that it might be desirable to mark nodes where a U-turn 
is specifically legal.



You mention that the duplicate traffic signals are a problem but I don't
understand from your proposal how traffic signals should be tagged in your
proposal. Could you update your proposal to include how they are to be
tagged as part of the intersection.


That's because the proposal isn't proposing to change how signals are 
tagged. Rather, the objective is to make it so that "the existing way" 
("each [intersection] node is tagged as a traffic signal") Just Works™ 
with tools: "signals do not apply to a way which is tagged 
junction=intersection".


*Independently*, I am leaning toward suggesting to tag signals at the 
'stop here' line rather than on the intersection nodes (which also 
solves the signals aspect of the problem in a different manner), but IMO 
that is orthogonal. See e.g. 
https://www.openstreetmap.org/node/7695739446. (Also, if this proposal 
is approved, that change may or may not be necessary or desirable. I 
think the 'stop here' lines should be tagged in *some* manner, but with 
junction=intersection, it may be that a new way to tag 'stop here' lines 
is desired and leaving the signals on the intersection nodes is 
preferred. At that point, we're getting into arguing about tagging where 
the signal *applies* vs. where the actual signal lamp is physically 
located.)


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 11.24, Peter Elderson wrote:

Well, if you do a couple of intersections it's no big deal, but if every
intersection would need this and it breaks relations, no matter whose fault
it is, it is a problem. Then it's not just modeling, but forced repair
work.


Sure, but my point was that I don't think my proposal changes anything 
here, since someone (myself, for example) might already split ways at 
intersections for other reasons.



May be worth it, but I would like to know that at proposal time, not
by discovering all routes and turn restrictions are broken.


That's fair. I'm not actually sure offhand what happens when you split a 
way at or near an intersection, although I would hope that editors can 
update the relations correctly. This is probably more of an issue with 
intersections where turn lanes are separately modeled, and I wonder how 
many of those aren't already split as they would need to be.


That said, I think it makes sense to add a note asking editors to be 
mindful of such things. I'll add some wordage to the proposal.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

On 10/07/2020 10.36, Peter Elderson wrote:

Question: does it break anything? I am thinking about existing relations of
various kinds.


If splitting ways breaks relations, well, a) that's an editor problem, 
and b) I've already been breaking those left and right from splitting 
ways to improve accuracy of lane information.


I don't see how it would break the *ability* to model anything, however. 
Given the above, I don't see how it could be meaningfully *harmful*.


--
Matthew

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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Matthew Woehlke]

On 10/07/2020 09.32, Paul Allen wrote:

On Fri, 10 Jul 2020 at 14:10, Mateusz Konieczny wrote:

barren is horrible as it can be easily interpreted as including also paved
surfaces,


Ummm, not really.  Not in British English.  I'd never describe paved 
surfaces as barren.  Technically, I suppose they are, but they don't

fit my mental category of barren.


As someone who desperately wishes his gravel driveway *was* barren, I'm 
afraid I'm inclined to agree with Mateusz Konieczny :-).


--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 09/07/2020 21.51, Warin wrote:

On 9/7/20 12:44 am, Martin Koppenhoefer wrote:
both is possible, each one can own a precise list of apartments, or 
both can own 50% of all apartments.


Here apartments are usually sold separately, each as a title dead.
Other than 100% ownership it would be highly unusual for a  50% 
ownership other than by the entire thing being owned by a firm and an 
individual/firm owning 50% of the 100% owning firm.


FWIW, and while we're at the point of arguing definitions and not how we 
should do things in OSM, a unit that is *sold* is not an "apartment" in 
America.


- Apartment: The larger property, including habitable units, is owned by 
some entity. Units are leased.


- Condominium: The larger property / building exterior is owned by some 
entity. Units are deeded and sold. (Unit owners may in turn lease the 
units they own.) Unit owners typically must pay dues to an association 
which maintains the exterior and grounds. Unit owners are not legally 
responsible for the building exterior or grounds


- Townhouse: Units are deeded and sold. (Unit owners may in turn lease 
the units they own.) Unit owners typically must pay dues to an 
association which maintains the exterior and grounds. However, unit 
owners also own a land parcel which contains their unit and associated 
grounds, and have some degree of legally responsibility for their 
portion of the building and grounds.


- Row house: The parcel grounds and all structures thereon are owned by 
an individual or entity (which may lease the residence or portions 
thereof). Said owners are fully responsible for all building exteriors 
and grounds on their lot. However, the structures may share walls with 
other structures on adjacent parcels.


- Semi-detached house: A set of row houses with exactly two connected 
units. (IMO this is a somewhat stupid distinction likely created by 
realtors for marketing purposes.)


- Detached house: The parcel grounds and all structures thereon are 
owned by an individual or entity (which may lease the residence or 
portions thereof).


Note that the line between a detached house, flats, and apartments can 
get pretty blurry, especially when you start running into things like 
buildings that were constructed as single-family dwellings and have been 
converted into apartments. However, if we ignore the case of converted 
single-family homes, I think we can be non-ambiguous.


Those are the specific, *legal* categories of which I know. We can argue 
about what to call those categories (different locations may assign the 
names differently), but IMHO those are the categories that (at a 
minimum; it's entirely possible there are others I'm not familiar with) 
make sense to model/tag.


--
Matthew

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

[Tagging] Feature Proposal - RFC - junction=intersection

[Matthew Woehlke]

As some of you may recall, I'm working on a project to do traffic 
simulation with the help of OSM data and SUMO¹.


One of the issues that SUMO has is that the typical method of modeling 
intersections (which I don't propose to change, mostly) results in SUMO 
thinking there are multiple intersections where there should only be 
one. For example, intersections of two dual carriageways produces four 
intersections and makes the turns much sharper than in reality.


My use case isn't the only one that has issues with this sort of thing; 
routers can "see" more traffic lights than actually exist and can (so I 
hear, anyway) give directions that are potentially confusing. 
Intersection modeling is a long-standing issue that has had multiple 
previous proposals.


The major two prior proposals of which I'm aware are to map the 
'footprint' of the intersection as an area, or to create relations to 
map the intersection. Both are difficult, both to model, and for tools 
to parse. The area proposal has potential rendering issues.


I am proposing² a *much* simpler alternative, which is to simply tag the 
portions of a road that are "part of" an intersection (i.e. the 'm', 
'n', 'p', 'q' segments of 
https://wiki.openstreetmap.org/wiki/File:Doublejunction.svg) with 
junction=intersection. This is straight-forward to model, and I believe 
solves most of the issues for a majority of affected intersections. 
(Exceptions likely exist, but 'perfect' is the enemy of 'good', and 
right now we're at 'bad'.)


Comments would be appreciated!

Also, should I start just doing this for the areas I'm trying to use for 
my project, or is it better to wait for some degree of consensus?


(¹ https://www.eclipse.org/sumo/)

(² 
https://wiki.openstreetmap.org/wiki/Proposed_features/junction%3Dintersection)


--
Matthew

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Matthew Woehlke]

(Apologies if this double-posts; my mail client is telling me it 
couldn't be sent, but I've known it to lie about that...)


On 09/07/2020 18.57, Mateusz Konieczny via Tagging wrote:

Jul 9, 2020, 23:58 by pla16...@gmail.com:

I take "customers" to mean "non-employees who may access the
facility because of interactions with the controlling organization."  Not
staff.  Private means that nobody but staff (excepting emergency
services, plumbers who have been called in to deal with a problem,
etc.) have access.


Good point, I also used access=customers for churchgoers-only parking lot.


I think this makes sense also. To a previous point, I take 
access=customers to mean someone intending to visit the associated 
location, whether that's a store, a church, a doctor's office, ...


BTW, I've used access=customers for parking lots that aren't 
*explicitly* marked 'customers only', but where I would expect the 
proprietors would nevertheless be annoyed by people just using their 
lots that aren't going to the associated store (or church, or ...) at 
all. Should I not do that? Is there a clear rule for when to use 
access=customers vs. access=permissive?


(I would probably use access=permissive for e.g. a mall parking lot, 
where it's not strictly public, but where you wouldn't be expected to be 
visiting a particular building or organization such that it's much less 
clear whether or not you are a "customer".)


--
Matthew

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

Re: [Tagging] Distinguishing closed office spaces and client service locations?

[Matthew Woehlke]

On 09/07/2020 17.34, Mateusz Konieczny via Tagging wrote:

Jul 9, 2020, 20:38 by pla16...@gmail.com:

Maybe not ideal, but if you're looking for an immediate solution then
access=customers and access=private?


I like it, but it is a bit tricky as I can walk into many offices without being
a customer (though typically it is done as someone wants or
considers being one).


I wonder if we shouldn't discourage this "use case". In my experience, 
while you are correct that corporate offices *do* sometimes get "walk-in 
clients", I think most tend to discourage that sort of thing. Usually an 
office that doesn't have resources dedicated to dealing with walk-ins 
will prefer to set up appointments for a potential customer to visit.



Maybe something along amenity=customer_service?


If a space does actively encourage walk-ins, that might work. Although...


Though access=private seems perfectly fine to mark office as internal
to a company (or covering restricted set of clients).


...I would think that, yes, access=private should probably be used. I 
would expect that even access=private implies it's okay to go there if 
you're invited. (Also, if you're invited, you probably don't need to be 
asking OSM if it's okay to visit.)


As Paul notes, I would also assume that access=private includes service 
workers with a legitimate reason to access the premises; affiliated 
vendors, postal workers, maintenance persons, etc.


p.s. access=designated is *not* a thing; so saith the wiki.

--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 08/07/2020 16.31, Mateusz Konieczny via Tagging wrote:

On 08/07/2020 12.34, Mateusz Konieczny via Tagging wrote:

BTW, is your project including something that can be tested already?


I was referring to "traffic simulation project" mentioned in
https://lists.openstreetmap.org/pipermail/tagging/2020-July/053879.html
and I hoped that it is something both already released and released to public


No, it isn't released yet... maybe soon (in theory we have permission to 
release it as open source, but I want to get confirmation), but it's 
also still in the embryonic stage. So far all I have is a "toy" 
application that uses Valhalla to generate a route given a start and 
stop lat/lon. The eventual goal is to leverage OSM information 
(buildings and their tags, POI's and their tags) to automatically select 
start and stop points in order to generate *lots* of routes, and to then 
feed that into SUMO for kinematic simulation.


Thanks for the interest, though!

--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 08/07/2020 12.34, Mateusz Konieczny via Tagging wrote:

8 Jul 2020, 16:44 by mwoehlke.fl...@gmail.com:

On 08/07/2020 10.36, Martin Koppenhoefer wrote:

On 8. Jul 2020, at 16:24, Matthew Woehlke wrote:
(On which note... knowing that a residence is *also* a shop is potentially 
important!)


look for shop=* rather than building typologies...


And... what, assume anything *not* a shop is a residence?


That was in response to "knowing that a residence is *also* a shop is
potentially important"
Ah, yes, sorry. I only meant that in the "please tag them" sense, not as 
far as any specific "suggestion" *how* to tag such instances. (In that 
sense, I think we're on the same page; tag the building as a house and 
add a shop POI.)



BTW, is your project including something that can be tested already?


I don't understand the question?

--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 08/07/2020 10.36, Martin Koppenhoefer wrote:

On 8. Jul 2020, at 16:24, Matthew Woehlke wrote:
(On which note... knowing that a residence is *also* a shop is potentially 
important!)


look for shop=* rather than building typologies...


And... what, assume anything *not* a shop is a residence? I'm quite 
certain (based on observations of mapping in my area) that will generate 
a bunch of false positives.


I *could* (and may need to, eventually) look at zoning, but I also need 
to be able to estimate habitation density, for which I need to know ­— 
oh, hey, topical! — if a building is apartments, a terrace, or a single 
family dwelling.


--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 08/07/2020 10.32, Matthew Woehlke wrote:

On 08/07/2020 10.21, Chris Hill wrote:
Google's Terms of Use prevent us reusing their Streetview in OSM, see 
section 2d.


"Apart from any license granted to you by Google, your use of the 
content may be acceptable under principles of 'fair use.' Fair use is a 
concept under copyright law in the U.S. that, generally speaking, 
permits you to use a copyrighted work in certain ways without obtaining 
a license from the copyright holder."


This smells a lot like how Red Hat prevents people from cloning them. 
Namely, they can't, because they don't have a legal leg to stand on as 
far as enforcing copyright claims against anyone doing so. What they 
*can* do is revoke the rights to use *their* services.


So, okay, I can see an argument that "copying" makes your use of Google 
maps unauthorized. I still can't see an argument where Google could come 
after OSM.


Moreover, it would be interesting to see a court weigh in on 2b vs. 2d, 
and what exactly constitutes "use". If I look at *content* in Google 
Maps, and then copy that *content* as permitted by 2b, am I "using" Maps 
in a way that 2d prohibits?


It seems pretty clear that if I were to use the Maps *software* to 
create e.g. shapefiles that I then imported into OSM, that would violate 
2d. It's much less clear that merely using Maps to cross-check *facts* 
would fall under 2d rather than 2b.


--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 08/07/2020 10.32, Matthew Woehlke wrote:

On 08/07/2020 10.21, Chris Hill wrote:
Google's Terms of Use prevent us reusing their Streetview in OSM, see 
section 2d.


"Apart from any license granted to you by Google, your use of the 
content may be acceptable under principles of 'fair use.' Fair use is a 
concept under copyright law in the U.S. that, generally speaking, 
permits you to use a copyrighted work in certain ways without obtaining 
a license from the copyright holder."


This smells a lot like how Red Hat prevents people from cloning them. 
Namely, they can't, because they don't have a legal leg to stand on as 
far as enforcing copyright claims against anyone doing so. What they 
*can* do is revoke the rights to use *their* services.


So, okay, I can see an argument that "copying" makes your use of Google 
maps unauthorized. I still can't see an argument where Google could come 
after OSM.


Moreover, it would be interesting to see a court weigh in on 2b vs. 2d, 
and what exactly constitutes "use". If I look at *content* in Google 
Maps, and then copy that *content* as permitted by 2b, am I "using" Maps 
in a way that 2d prohibits?


It seems pretty clear that if I were to use the Maps *software* to 
create e.g. shapefiles that I then imported into OSM, that would violate 
2d. It's much less clear that merely using Maps to cross-check *facts* 
would fall under 2d rather than 2b.


--
Matthew

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

Re: [Tagging] How to map terrace buildings with names

[Matthew Woehlke]

On 07/07/2020 19.21, Paul Allen wrote:

If it was obviously built as a house I'd tag it as building=house because
anything but building=no will render identically in many cartos anyway.


On a somewhat unrelated note, I really, *really* want residences to be 
tagged as such. I'm working on a traffic simulation project, and need to 
know the "function" of a building. Residences act in the simulation very 
differently from shops or other non-residence locations. (On which 
note... knowing that a residence is *also* a shop is potentially important!)


--
Matthew

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