Re: [Tagging] Route names being applied to tracks/paths

[Jmapb]

On 12/30/2022 2:22 AM, stevea wrote:

I agree with Mateusz here:  whether to tag a way after the name of a route which includes 
it (if it didn't have a name=* tag beforehand) isn't a "one size fits all" 
situation.  It's difficult to describe what the right thing to do is in all cases.


I've also generally avoided doing it on bridges, lest the trail name be 
mistaken for a bridge name. (I know bridge:name=* exists but plenty of 
mappers still use name=*.)


J


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

Re: [Tagging] Route names being applied to tracks/paths

[Jmapb]

On 12/29/2022 10:13 AM, Zeke Farwell wrote:
Yes, the way name tag should be the most local trail name. However, 
sometimes there is no local trail name and the long distance route 
name is the only name.  In this case putting the long distance route 
name on the ways also makes sense.


I've been doing some mapping on the Appalachian Trail lately and this 
appears to be the common practice, although the AT is dominant enough 
that constituent trails sometimes lose their local names over time.


Some mappers will take it a little too far and tag sections of sidewalk 
and driveway that the AT follows with name=Appalachian Trail (or even 
name=Appalachian National Scenic Trail... IMO this is an official_name, 
and probably only belongs on the route superrelation.)


It's common to see ref=AT as well, which is fine on trails (even locally 
named ones) and perhaps ok on the sidewalks, but adding it to a 
vehicular road seems iffy.


Jason



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

Re: [Tagging] building=entrance

[Jmapb]

On 12/12/2022 2:28 PM, Martin Koppenhoefer wrote:
Following a JOSM discussion I wanted to ask here, if someone else is 
using building=entrance to tag entrance buildings.


It is a term that seems well introduced and understandable, so there 
is not much hindering people from using it, just that there was the 
bad practice to use the same tag on nodes for what is now done with 
the "entrance" key.

sorry, missed the link https://josm.openstreetmap.de/ticket/22570

any comments on the tag? Someone else using it for buildings?


Two thoughts offhand:

1) I feel pretty strongly that any value of building=* should refer to a 
type of building. To me, building=entrance would sound like an attempt 
at tagging something similar to building=gatehouse.


2) building=* on a node is just fine; we don't always have sufficient 
aerial imagery or other data to discern an acceptable footprint. (That's 
on a freestanding node of course; building=* on a node that's part of 
another building's perimeter would be a problem.)


Cheers, J


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

Re: [Tagging] care services

[Jmapb]

On 11/18/2022 5:07 PM, Graeme Fitzpatrick wrote:


On Sat, 19 Nov 2022 at 05:58, Jmapb  wrote:

I think office=home_aide might be good.
("home_care" sounds like it's the home that's being cared for.)


How about =home_assistance?


Hey, that's not bad!

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

Re: [Tagging] care services

[Jmapb]

On 11/17/2022 2:23 PM, Minh Nguyen wrote:

Vào lúc 10:51 2022-11-17, Philip Barnes đã viết:

On Thu, 2022-11-17 at 19:21 +0100, Georges Dutreix wrote:


Le 17/11/2022 à 18:52, Philip Barnes a écrit :

I have used office=home_care for a care company.


I found as well amenity=personal_service used 110 times
Would be "amenity" better than "office" for this case ?


Personal services and Care are not really the same thing.

Care could probably fit into heathcare.


I've mapped the office of a home care provider (just a desk) as 
healthcare=home_care, but something in office=* would make sense too.


https://www.openstreetmap.org/node/8710988857

I've been using amenity=social_facility + 
social_facility=ambulatory_care for so-called "home health agencies", 
based on the wiki pages 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dsocial_facility and 
https://wiki.openstreetmap.org/wiki/Tag:social_facility%3Dambulatory_care 
, but I've never really grooved to that tag. From the page history, I 
see that J Eisenberg asked us to "consider office=* instead" in 2020, 
with no value specified. I think office=home_aide might be good. 
("home_care" sounds like it's the home that's being cared for.) Could 
also go under the healthcare tag.


J


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

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Jmapb]

On 11/6/2022 6:18 PM, Graeme Fitzpatrick wrote:



I definitely agree that it should be emergency=, rather than amenity=. 
I must also admit to a slight personal preference for =marine_rescue 
:-), but the vast majority of usage is in the UK & Western Europe, 
where =lifeboat seems to be the most popular, so I'm happy to go along 
with that.


I'll see if there's any other comments before starting a full RFC


"Lifeboat" is an ambiguous term  -- it even has a disambiguation page on 
Wikipedia  which lists 
https://en.wikipedia.org/wiki/Lifeboat_(shipboard) ahead of 
https://en.wikipedia.org/wiki/Lifeboat_(rescue) .


Favoring emergency=marine_rescue seems sensible to me.

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

Re: [Tagging] sport=shooting_range vs sport=shooting + leisure=pitch

[Jmapb]

On 12/19/2020 5:16 PM, Martin Koppenhoefer wrote:

I agree with this, there’s a lot of abuse for “pitch”, and these are
not arguments for continuing the line, it’s never too late to learn
from past errors ;-)

leisure=shooting_range might make sense? There are also 4000
military=range (is this about shooting? bombing? )


I've been using leisure=sports_centre + sport=shooting for these,
possibly combined with a building tag for an indoor range. Makes more
sense to me to giving them a top-level leisure tag unlike all other sports.

The value "shooting_range" is currently in use for the "hazard" key,
though, and is part of the hazard=* proposal which is currently being
voted in with flying colors. (
https://wiki.openstreetmap.org/wiki/Proposed_features/hazard )

J


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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Jmapb]

On 12/14/2020 3:11 PM, Paul Allen wrote:


I'd expect a motel to be set up to handle very short duration (one or two
day) at very short notice (turn up and ask for a room) and to offer
meals unless there are diners/restaurants nearby...



Take a look at https://www.canllefaes.com/
 and note the
requirement that occupancy start/end on a Saturday,
that the cottages have kitchens, etc., and tell me if
that fits into your model of a motel with distributed
cabins.


No indeed it does not. I would be uncomfortable using the tourism=motel
tag on any establishment with a minimum week stay, kitchens or no. Even
a 2-night minimum at a motel would wrinkle my brow.

For Canllefaes, I'd be happy enough with leisure=resort.

(By the way, I would generally *not* expect a motel to offer food beyond
coffee and packaged snacks, though many of them share a parking lot with
a restaurant or fast food.)

J

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

Re: [Tagging] How to tag entire group of rentable holiday cottages?

[Jmapb]

I've been using tourism=motel for these, if there are no other features
that would tip them into leisure=resort.

At least In the rural USA, there's a continuum between motels that have
an array of rentable rooms in one or two buildings and those where each
room is an individual cabin, or sometimes half of a duplex cabin. It's
common to see motels offering both styles of accommodation.

Jason


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

Re: [Tagging] edit war related to tagging of a bus-only major road

[Jmapb]

On 12/9/2020 9:36 AM, Michael Tsang wrote:


Des Voeux Road Central is considered one of the most important roads
in the area which I
tagged it as highway=secondary, however another editor has repeatedly
changed
it to highway=service on the fact that that road is closed to motor
vehicles
except buses


Hi Michael, my understanding is that this type of access restriction has
no bearing on the correct value of the highway tag. That doesn't mean
that a bus-only road can't be 'highway=service', but my armchair opinion
is that this one deserves a higher classification,
'highway=unclassified' at minimum. Obviously a local consensus would be
best.

As far as the access tags go, from your description I imagined
'access=private' plus 'bus=yes', and 'foot=yes' if there's sidewalk that
isn't mapped separately. The segment you linked to (
https://www.openstreetmap.org/way/242113655 ) has tags that are a bit
more complicated; no doubt they make sense in context. It's worth
noting, though, that it currently allows bicycle traffic.

Here's a photo showing the bus-only segment and signed restrictions --
https://www.mapillary.com/app/?pKey=V6xCvni7pFMnBkHoXfZcIw&focus=photo&lat=22.2806400619&lng=114.16016743519445&z=17&x=0.5090835219500857&y=0.5090768471784388

Jason




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

[Tagging] Crossing tagged on both way and node (was: What does bicycle=no on a node means?)

[Jmapb via Tagging]

On 10/13/2020 6:30 PM, Kevin Kenny wrote:

On Tue, Oct 13, 2020, 17:41 Volker Schmidt mailto:vosc...@gmail.com>> wrote:

I changed the crossing to the way we do it in many parts of
Europe, i.e. a crossing node _and_ a crossing way. This was
described as an option on the highway=crossing wiki page until it
was changed on 07:52, 3 October 2020by user Emvee
 by addng the
diagram and its description.
If you don't like it, please change it back - I used it in place
of a longish explanation.


Both of those are better, thanks! The routers that I use for testing
seem to be aware of crossings without crossing nodes, so I too often
forget to tag them.


I've always been surprised to see a footway=crossing/cycleway=crossing
way with the intersection node tagged as highway=crossing. There's only
a single physical crossing, so this seems contra to the
one-feature-one-element rule.

A highway=crossing node makes sense in an area without mapped
footways/cycleways. But if the crossing ways are mapped, routing
software will need to examine the intersection node and scan the
properties of all highways intersecting there. It seems to make tagging
the node itself redundant.

Are there really routers that require the node be tagged as well?

Jason

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

Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

[Jmapb via Tagging]

On 9/4/2020 6:24 PM, Mateusz Konieczny via Tagging wrote:

Sep 4, 2020, 18:19 by tagging@openstreetmap.org:

node and discovered the shelter_type=rock_shelter subtag, but the
map in
question didn't render it any differently. Revisiting the site in fair
weather, I found a tiny crack under a ledge that *might* have kept a
child dry. It was very satisfying to delete that node.

This seems to be a clear case of incorrect tagging of something that\
has not actually existed.

natural=rock_shelter and any other tagging of rock shelter would be
equally
incorrect


Assuming that I located the correct crack, it was undoubtedly a case of
overzealous tagging. The problem I see is that the definition of rock
shelter is subjective enough that this sort of tagging will happen from
time to time. Some mappers will stretch the definition because they just
love adding features. And since rock shelters are currently a subtag of
amenity=shelter, people looking for amenity=shelter -- with the possibly
live-saving properties that implies -- will be misled.

Tagging a rock shelter any other way -- natural=rock_shelter,
amenity=rock_shelter, whatever -- and we're no longer bound to
fulfilling the existing expectations of the parent tag.

Jason

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

Re: [Tagging] Link to stream of webcam

[Jmapb via Tagging]

On 9/4/2020 3:45 PM, Paul Allen wrote:

A surveillance cam isn't a "contact" and contact:* is STILL a stupid
idea.

Oh, and what's wrong with url=*?  Especially as the wiki page endorses it.


Nb, the link to the "Surveillance under Surveillance" project that you
quoted doesn't mention the url=* tag.


https://sunders.uber.space/ (with info pop ups, even with a live image
if URL provided  in
the data)


The "URL provided" link points at the contact:* page, so presumably
whoever wrote that was assuming that the live image URLs should be
tagged  under the contact namespace. I agree that it's bizarre tagging
practice, but I understand how it happened, since that's where almost
all URLs more specific than "url" or "website" have found a home, and
many of those are predominately used to publish info rather than to
receive communication.

Taginfo doesn't break down the common tag combinations for
surveillance:type=camera, but here's my attempted tally using overpass:
 website 1485
 contact:webcam 1146
 url 204
 contact:website 115
 url:webcam 29
 webcam 17

Note that there's some overlap as some cameras have more than one of
these tags (sometimes with different values.) And there may be some
variations that I missed.

Simple website=* is the most popular, but often it points to things
other than a camera feed, most commonly the site of the person or
institution that runs the camera. Often it holds the URL of a top-level
view of many cameras while contact:webcam holds the direct URL to the
camera in question.

My favorite of these is url:webcam. But contact:webcam is hundreds of
times more popular.

What's wrong with just url=*? To quote the url=* wiki page, "/it is
advised not to use this tag when more specific alternatives are
available./" Like website=*, it doesn't specify that it's a camera feed,
so it might be used for other purposes. And in fact I happened to see a
couple of nodes using url=* for picture *of* the camera, rather than
pictures taken by the camera.

https://www.openstreetmap.org/node/4163745929
https://www.openstreetmap.org/node/5979627352

Jason

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

Re: [Tagging] Link to stream of webcam

[Jmapb via Tagging]

On 9/4/2020 2:10 PM, Martin Koppenhoefer wrote:

Am Fr., 4. Sept. 2020 um 19:03 Uhr schrieb Jmapb via Tagging
mailto:tagging@openstreetmap.org>>:

On 9/4/2020 11:34 AM, Jmapb via Tagging wrote:
> The "See also" section of that page seems to suggest the
undocumented
> tag `contact:webcam` for this purpose.

(Mea culpa, contact:webcam is indeed documented on the contact page.)



according to the "contact" webpage it is a tag for tagging "contacts".
Is a live stream of a camera a "contact"?


In a loose sense, perhaps, you are "contacting" the webcam by requesting
that URL... but it's a stretch.

If I were proposing a tag, I'd probably say `camera:url` or
`webcam:url`. But `contact:webcam` is documented and in popular use all
over the world.

J


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

Re: [Tagging] Link to stream of webcam

[Jmapb via Tagging]

On 9/4/2020 11:34 AM, Jmapb via Tagging wrote:

The "See also" section of that page seems to suggest the undocumented
tag `contact:webcam` for this purpose.


(Mea culpa, contact:webcam is indeed documented on the contact page.)


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

Re: [Tagging] Feature Proposal - RFC - Tag:shelter_type=rock_shelter

[Jmapb via Tagging]

On 9/3/2020 11:51 PM, Andrew Harvey wrote:

I've created a proposal to formalise shelter_type=rock_shelter, while
currently in-use, there is disagreement within the community on if
this tag should be used and features are commonly mis-tagged.

So I'm hoping with this proposal and voting we can come to some
consensus around it's use.

I'll leave it open for two weeks for comments then move to voting.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shelter_type%3Drock_shelter


Thanks for your work on this Andrew.

I agree that a shallow rock overhang that can be used for ad hoc shelter
is not the same as a cave. But I'm strongly in favor of
discouraging/deprecating shelter_type=rock_shelter.

I'm a bit strident about this because I've been personally "betrayed"
using an OSM-derived hiking map, expecting to arrive at a shelter in
poor weather and finding nothing. Back in civilization, I examined the
node and discovered the shelter_type=rock_shelter subtag, but the map in
question didn't render it any differently. Revisiting the site in fair
weather, I found a tiny crack under a ledge that *might* have kept a
child dry. It was very satisfying to delete that node.

Obviously the map rendering can be improved, but it's against the
general anti-troll-tagging practices to have a subtag that undoes the
essential properties of the main tag. Because of the ambiguity as to
what constitutes a viable rock shelter, I think
shelter_type=rock_shelter falls into this category.

I'd suggest natural=rock_shelter as a replacement tag.

(For that matter, I think shelter_type=sun_shelter is a troll tag as
well. I'd suggest man_made=sun_shade.)

Jason

PS - I'll be hiking in two weeks so feel free to vote in my name by proxy!



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

Re: [Tagging] Link to stream of webcam

[Jmapb via Tagging]

On 9/4/2020 11:08 AM, dktue wrote:

Hi,

I'd like to tag the link to the (current) JPEG-image of a webcam, but
the wiki doesn't state how to do so [1].

Any suggestions how to tag this?

Cheers,
dktue

[1] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance


The "See also" section of that page seems to suggest the undocumented
tag `contact:webcam` for this purpose. (This should probably be moved to
"Tags to use in combination".) It's in pretty wide use according to
Taginfo (1817 uses.)

Here are some in the wild:

https://www.openstreetmap.org/node/305956624
https://www.openstreetmap.org/node/2989816818
https://www.openstreetmap.org/node/5852641220

The second one links directly to a .mjpg stream. I did find some linking
directly to .jpg urls but none that were currently functional.

Jason


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

Re: [Tagging] addr:street for routes

[Jmapb]

On 8/3/2020 4:36 PM, Paul Johnson wrote:



On Mon, Aug 3, 2020, 15:29 Jmapb mailto:jm...@gmx.com>> wrote:


...Regardless, if this general approach is considered valid and
workable, then I'd like to propose the following answer to my original
question:

  * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
  * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name
tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the
value of
the way's `ref` tag, which should match the name of the route
relation.


Name is only the name, so most route relations wouldn't have a name.


Fair enough. The ones around me have names, but it looks like plenty of
them get by with just ref and network.

So...

  * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
  * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the value of
the way's `ref` tag, which should correspond to a route relation that
includes the way.



Since the number of different variations on how one might address
something when the street name is on a numbered route, seems like it's
on the data consumer to fuzzy match appropriately to match an
imperfect hit.


I don't disagree, but I don't mind tagging more if it helps a bit.

J

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

Re: [Tagging] addr:street for routes

[Jmapb]

On 8/3/2020 6:07 AM, Sarah Hoffmann wrote:


There is some fuzzy matching, you can expect to work, for example
abbreviations like street -> st or even New York -> NY. But going from
ref=NY-214 to 'State Highway 214' is already a long stretch that requires
special local knowledge.


Understood. And this is a little out of scope for the tagging list but I
suspect this kind of long-stretch fuzzy matching for numbered routes
will be necessary to return decent search results for a large portion of
the rural USA -- and I'd guess similar problems will be found in other
countries.

At least for the New York State routes, Google, Apple, Microsoft, and
HERE seem to get this right. I don't know of any OSM-centric maps that
do, and I'm not savvy enough to know which are using Nominatim and which
aren't.

(Offhand, AI seems like overkill for this! The variations are pretty
formulaic.)


Note that 'on the ground' doesn't always mean that there needs to be a
physical sign. I consider an envelope (of a letter) as much on the ground
as a street name you get by asking the inhabitants what they call the
street they live on. If you want to express these nuances you can always
use the different variants of name (offical_name, local_name, old_name, ...).
So, yes, in your situation I'd leave out the name tag, add the ref and
a couple of *_name tags that contain the names used in the addresses or
between locals.


The inhabitants call it all of the above. Usually they'll just say "214"
(pronounced "two-fourteen.") I'm not inclined to rifle through people's
mail, but I assure you that every variation *except* the bare "214" will
be written on envelopes and will be delivered. (Assuming the USPS
survives the current attempt at extermination.)


Nominatim's algorithm currently is to match addr:street with any name or
ref tag on a highway (including service, footway, path, etc.) It allows a
little bit of fuzziness but ideally you use exactly the same spelling. If
nothing is found, it simply uses the nearest street.

There is another solution, if you really don't like the requirement of
exactly matching names: associatedStreet relations. They do take precedence
over the matching as explained above. Using those relations you can
use a different addr:street name.

Disclaimer: I have a deep dislike of associatedStreet relations and consequently
they suffer from a bit of neglect in Nominatim. :)


Yes, I've been trying to avoid mentioning associatedStreet! I'm
comfortable creating and maintaining these relations as a last resort,
but heck they're annoying. We'd prefer a solution that would allow a
casual mapper to add or fix addresses along a route.

For now I've had a go with verbose explicit tagging using  _name tags as
you've suggested (ignoring JOSM's "alternative name without name" warnings):

ref=NY 214
official_name=State Route 214
alt_name=Route 214;Highway 214;State Highway 214;New
York 214;New York State Route 214

I've used the USPS-rectified format for the `official_name`, which isn't
exactly right (`postal_name` might be a better tag) but seems close enough.

It's unclear to me how useful it is to cram in all those
semicolon-separated values under `alt_name`. Since this update,
Nominatim is now giving decent (one block away) results for "58 State
Route 214, Phoenicia NY" but nothing for "58 State Highway 214,
Phoenicia NY" so maybe I just have to pick a single `alt_name` and maybe
throw in a `local_name`? (Must confess, this sort of shoehorning starts
to feel a little odd.)

...Regardless, if this general approach is considered valid and
workable, then I'd like to propose the following answer to my original
question:

 * Q) How should `addr:street` be tagged for an address along an
unnamed way which is part of a numbered road-type route relation?
 * A) Check the way for alternative name tags. The official postal
version of the street name may be tagged as `official_name`; if so
that's a good value for `addr:street`. If the way has other name tags --
such as `alt_name`, `local_name`, `old_name`, or a language-specific
name -- those values may be used. It's also possible to use the value of
the way's `ref` tag, which should match the name of the route relation.

Thanks all for your thoughtful replies, and let me know if this seems sane.
Jason


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

[Jmapb]

On 8/1/2020 8:40 PM, David Dean wrote:

Hi everyone,

I'm interested in proposing and/or documenting existing tagging
approaches of the wiki to ensure that all highway=service ways can
have a service=? associated tag.


Hi David -- My feeling is that often highway=service, without a
service=* tag, is a useful and valid tagging practice.

The basic rule I follow is that any road that is not part of the general
public road network but is more established than a track should be
highway=service. (There are exceptions of course -- privately operated
residential, unclassified, tertiary etc -- but that's the basic rule.)
If that road isn't obviously a driveway, alley, drive-through, or
parking aisle then I'm usually fine to omit the service=* tag.

Here of some of the situations where I use highway=service without
service=*:
 - Roads through cemeteries
 - Roads through campgrounds
 - Roads through schools
 - Roads through universities
 - Roads through hotels
 - Roads through museums
 - Roads through prisons
 - Roads through military areas
 - Roads through airports
 - Roads through retirement homes
 - Roads through resorts
 - Roads through reservoirs (sometimes over dams)
 - Roads through ski areas
 - Roads that serve privately-owned inholdings surrounded by public land
 - Maintenance roads in parks
 - Private semi-residential roads that serve multiple driveways
 - Non-public roads though industrial areas

This is just off the top of my head. There are probably dozens more in
use across the globe.

My feeling is that these uses do not require and would not much benefit
from a specified service= tag. I don't see the need for service=prison,
service=ski_area, service=campground, etc.

Jason


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

Re: [Tagging] addr:street for routes

[Jmapb]

On 8/1/2020 12:51 AM, Joseph Eisenberg wrote:


Similarly, if you ask someone the name of the road in California with
ref="CA 96",
they will tell you "Highway 96" or perhaps "The river road". They
won't say
"Nah, it doesn't have a name, just a State highway number."


So in that situation, how would you choose what value to use for
`addr:street` on residences and POIs?

J

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

Re: [Tagging] addr:street for routes

[Jmapb]

On 7/31/2020 4:24 PM, Sarah Hoffmann wrote:


Put one of the variants into addr:street and then all the variants
as alternative names onto the road. Obviously that stretch of road
is referred to under all these names, so this is what we should map.


Putting aside the question of *which* variant to put into `addr:street`,
this sounds like an approach that could work. But we might end up with
something like `alt_name=Highway 214;Route 214;State Highway 214;New
York 214;NY-214;New York State Route 214` (or the name_1 ... name_n
equivalents). I could live with that if it actually helped the geocoding
but it's not exactly graceful.

Ultimately, though, these are alternate names for the route, not for the
stretch of road. (Which might have its own list of names! For instance,
a particular stretch of Ulster County Route 40 is known as Main Street,
Plank Road, Old Plank Road, Old Route 28, and Mount Tremper-Phoenicia Road.)


It really doesn't matter that the road has officially no name. The
goal is to map what's on the ground.


For the road itself, what's on the ground is simply the highway shield
with the number 214. There's no textual version of the name anywhere
(except as used for the addresses of residences and POIs.) Best practice
for these sorts of roads, I'm told, is to omit `name=*`, tag `ref=*`,
and add to a route relation.

For the addresses along the road, the vast majority are signed with just
a housenumber, and those POI signs that do include a street name are
inconsistent. Government data sources are also inconsistent.

But an on-the-ground mapper can observe that those housenumbers belong
to this road, which here is known only by its route number. I feel there
should be a way to encode that observation without asking the mapper to
choose a particular textual representation of the route's name...
especially since it's hard to do that in a consistent manner.

(Whatever the solution, my aim here is to get an address search that works!)

Jason


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

Re: [Tagging] addr:street for routes

[Jmapb]

On 7/31/2020 1:00 PM, Paul Johnson wrote:

I'd go with the official address.  It's not rare to find addresses in
the US where what goes on an envelope doesn't match what the street is
actually called. Nor is it rare to find the wiki to be wrong


Sometimes the official address is unclear. Example, the firehouse at
housenumber 58. The fire department website says "58 NY-214", the county
records list the parcel address as "58 Route 214" with "Route 214 PO Box
281" as the mailing address. The USPS website likes the address "58
State Route 214" which is what I put for now.

(As far as the wiki goes, of course there are problems. My hope is to
clarify this particular point and edit the wiki accordingly.)

On 7/31/2020 2:02 PM, Kevin Kenny wrote:

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


With that goal in mind, we could say that an address should conform to
usps.com's formatting (preferably sans the all-caps and the zip+4.) In
this case, a spot check shows that to be "State Route 214". But are we
allowed, license-wise, to pull from usps.com?

(In real life of course, delivery companies will get parcels labeled
every which way, and will tend to parse them intelligently, knowing that
highway route names in street addresses are inconsistent.)


That issue is the reason that I formerly advocated having the way
carry the tag `name="State Route 214`" if the street has no other name
and postal addresses use the reference.  I was convinced by many
others here that the consensus is that the latter is poor practice,
and that simply having the `addr:street` show a name that attaches to
no way is correct.


And as you've acquiesced to this, so have I. But unfortunately it
doesn't seem to work for search. For the firehouse, Nominatum will
return results (not perfect but close) for 58 NY 214 and 58 NY-214 but
none of the other variations, including the currently tagged USPS-valid
address of "58 State Route 214.


I think that duplicating the ref `CR 23C` or `NY 214` literally in the
`addr:name` is a less-than-optimal practice

I don't love it either. It would be more appropriate in an
`addr:route_ref` key, but I imagine it would be pretty confusing for
most mappers to have to choose between that and `addr:street`.

I strongly prefer having the name spelt out, and possibly including
the authority:  `New York State Route 214` or `Greene County Route
23C`.  Note that the word 'Route' is appropriate for both of these;
New York doesn't have roads formally named 'State Highway' or 'County
Road' - both are 'Routes' in the official documentation.


So this is yet another version of the street name I didn't mention! And
I'd have no problem making this the standard, but I *would* like to be
able to standardize... maybe not nationally, maybe not even state-wide,
but at least per route.



One reason for spelling out everything is that these fields often wind
up in voice-synthesis software, and it's much easier to deal with
spelt-out words than obscure abbreviations. To this day, when I go to
Schoharie, OSMand will direct me onto 'Enn Wye Thirty Amperes toward
Shah-ha-ree' because Android's voice synthesis lacks a pronunciation
for 'Schoharie' and the context for 'NY 30A'. (I've also heard highway
numbers read out as 'Enn Wye Nine Newtons', 'You Ess Nine Watts', 'See
Are Twenty-Three Coulombs', and so on - apparently a letter following
a string of digits is consistently interpreted as being the
abbreviation of an SI unit.)

Side note: We really ought to settle on name:pronunciation or some
similar key, because otherwise there is No Flippin' Way that
navigation software will ever realize that Schoharie is
/skoʊˈheɪɹˌiː/, Valatie is /vəˈleɪ.ʃə/, or Cairo is /ˈkeɪɹ.oʊ/. You're
an Upstater, so you know what I'm talking about! (For those who
aren't, the voice of Salli on
http://ipa-reader.xyz/?text=v%C9%99%CB%88le%C9%AA.%CA%83%C9%99 is
pretty close to the local pronunciation, although her intonation isn't
quite right on 'Schoharie'.)


That's pretty funny with the newtons & coulombs... It could be
alleviated with name:pronunciation, which isn't "approved" but is
formally documented and in use in a few thousand places. If you think
you've mastered the pronunciation of Schoharie, go ahead and tag it...
OSMand and Android will probably catch up in about 15 years.

On 7/31/2020 2:13 PM, Matthew Woehlke wrote:

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


As I mentioned above, I'm concerned less about validation tools and more
about search. Ideally they should be picking up the same sort of
problems, though.

Jason

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

[Tagging] addr:street for routes

[Jmapb]

Hi all, what's the best way to tag the addr:street of an address along a
highway route?

Example, I'm mapping houses and POIs along NY 212:
https://www.openstreetmap.org/relation/411064

Some segments of the route are tagged name=Main Street and the addresses
there use Main Street for their street name -- easy.

But most of the ways in the route have no valid name. Segments were
imported from TIGER with name=State Highway 214 but that's been removed
in favor of ref=NY 214. Written addresses found in government data and
POI signs/websites/business cards are various: Highway 214, Route 214,
State Highway 214, State Route 214, NY Route 214, New York 214, NY-214,
etc. Most buildings are signed with a housenumber only.

Is it best to simply tag addr:street=NY 214, matching the ref tag of the
segment and the name tag of the route? This isn't consistent with the
wiki, which specifically says addr:street should match the *name* of a
nearby *way*.

Thanks, Jason

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

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

[Jmapb]

Hi Tobias, I've been giving this some thought. My conclusion is that
user validation of tags shouldn't be stored in the same database table
as the tags themselves. It's clear that as the map data ages, tag
validation is going to be a task with parallel and equal importance to
tagging itself, but with its own workflows and complexities. The
validation will have its own history separate from the tagging history,
and I believe it would be best to design the data model accordingly.

Using nodes as an example for the moment, I'd like to consider the
creation of a new table alongside node_tags, perhaps called
node_tag_validation. I imagine the fields would be:
 - node_id
 - user_id
 - tag key
 - current node version (to identify the current tag value being
validated -- or maybe just a copy of the current tag value, if that's
too cumbersome)
 - validation result (valid/invalid/unsure)
 - optional comment
 - timestamp

This would allow a map validator to:
 - confirm a tag or subset of tags, rather than the state of the entire
element
 - record agreement without updating the element
 - record unverifiability/disagreement/skepticism without changing or
deleting a tag (since sometimes there's middle ground between confirming
a certain tag and knowing that it's incorrect.)
 - weigh in on the validity/invalidity of the *absence* of a particular
tag, which can be just as important as evaluating the tags that are there.

It would also allow easy query of various users' judgement of a
particular tag over time, which would allow for more informed survey and QA.

This design would eliminate some of the potential problems that have
come up in this thread:
 - check date tags getting out of sync with tag values
 - overcrowding elements with check date tags, and the verifiability of
these tags (the validation history can have looser verifiability
requirements than the map data)
 - resistance to changesets that make no actual changes but simply
update a timestamp (and increment the version) to indicate new validation
 - debate over correct implementation of namespaces (eg
check_date:smoothness or smoothness:check_date)

Note that this table (or these tables, presuming one each for
node/way/relation) would not actually need to reside in the OSM database
itself, although that would make it easier if the goal were to share
among multiple QA projects, not just StreetComplete.

Thanks for your work!
Jason


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

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

[Jmapb]

On 7/24/2020 7:12 PM, Cj Malone wrote:




OSM does not store edit timestamps for individual tags, only for the
object as a whole. Finding out when a tag was changed requires a
review of the entire history. I had to do this once when I saw a
clear highway=motorway_link tagged as highway=motorway, with me as
the last user to edit that road segment. Turns out the original
mapper was the one to make the tagging mistake, not yours truly, but
I only found this once reviewing the history.


Yeah, that option would require a new API and work done on the OSM
server to both calculate the last time a tag was edited, serve it and
store the timestamp when "touched" or updated. But once that's done
it's done for multiple clients, not just StreetComplete.

Otherwise StreetComplete would need to use the History API one each
individual nwr and try to calculate the age of a tag.


It sounds to me like what you're describing would require not just a new
API but a change to the database schema to add a datetime field to each
tag. Otherwise there would be no way to encode the timestamp of the
confirmation of an existing tag that does not need changing. The history
API will only tell you when tags change. The tag validation from the
wizard you described two posts above -- there's no way to record that
validation. Except maybe to shoehorn it into the info tags on the
changeset itself.

My preference is to avoid updating a element if all info is complete and
nothing has changed. I suppose a single datetime field for last survey
might be workable, but I fear it will lead to giant bogus "survey"
changesets changing nothing but the "last survey" field. I don't think
the field would ultimately be trustworthy because it isn't verifiable.

Jason

___
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"?

[Jmapb]

On 7/22/2020 12:05 PM, bkil wrote:


My guess is that the adoption of a dismounted_bicycle=* tag or similar
would require significantly *less* work than re-examining all current
bicycle=no ways.


Yes, I think that would be workable.

Nonetheless, I completely agree with you, =no should mean =no! But I
fear we're in the minority, and that the sloppy tagging of the
past has
a formidable inertia.


I disagree, see my other answer relating to agriculture.

Also, it contradicts the principle of least surprise that most
countries do not have such restrictions, hence regardless of how you
would like to redefine `bicycle=no`, half of the world would still
keep tagging it incorrectly.


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, or dismount my horse and lead
it along a horse=no way.

I'm not asking for a stricter redefinition of bicycle=no because I
suspect it's simply not feasible at this point, especially given the
continued popular support for the interpretation that allows dismounted
travel. But it's clear why there's confusion here. Precisely because of
this inconsistency in the meaning of *=no, the strictest documented
bicycle tag value does not correctly describe the strictest real-world
cases (which are not rare.) And I guarantee that many mappers do not
know that they're implicitly permitting dismounted bicycle travel when
they tag bicycle=no, especially if they're aware of the bicycle=dismount
tag.

At the same time, I fear that defining a new value, stricter than =no
(eg =prohibited, =banned, etc) would probably cause more problems than
it would solve, given the number of data consumers that would need to
adapt to this change. This is why I reluctantly suggested adding a
second tag (dismounted_bicycle=no) alongside bicycle=no, even though it
feels like an ugly hack. Other possibilities might be
prohibited=bicycle, bicycle:prohibited=yes. foot:pushing_bicycle=no,
foot:conditional=no @ (pushing_bicycle)... all pretty hard to love.

Maybe I'm wrong and a stricter-than-no value could be adopted without
too much pain? There is already limited use of bicycle=prohibited. (OSRM
currently appears to ignore it, see
https://www.openstreetmap.org/way/244518832 and
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=45.61895%2C13.86592%3B45.61999%2C13.86804
.)

Jason

___
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"?

[Jmapb]

On 7/22/2020 11:34 AM, Tod Fitch wrote:



On Jul 22, 2020, at 8:09 AM, Jmapb mailto:jm...@gmx.com>> wrote:

If this unfortunate tagging practice really needs to be preserved (the
idea of retagging so many bicycle=no ways is certainly daunting) then
I'd suggest a new key, dismounted_bicycle=*, which will function as a
regulation key (like smoking=*) rather than a vehicle access key.
Total bicycle prohibition would be encoded with both bicycle=no and
dismounted_bicycle=no, and other dismounted_bicycle=* values can be
developed for whatever the regulations are in particular situations.


Why? The suggestion that all the places that properly tagged bicycles=no
now need to be revisited and have a new dismounted_bicycles=no tag added
implies that the people who took “no” to mean something other than “no”
prevail and the rest of us have to go back and re-tag things.

Since many miles/kilometers of ways will need to be retagged either way,
why not go with the straight forward “no means no” and “dismount means
dismount”? Makes a lot more sense to me that “no only really means no if
there is an additional dismounted_bicycle=no” tag too.


My guess is that the adoption of a dismounted_bicycle=* tag or similar
would require significantly *less* work than re-examining all current
bicycle=no ways.

Nonetheless, I completely agree with you, =no should mean =no! But I
fear we're in the minority, and that the sloppy tagging of the past has
a formidable inertia.

J

___
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"?

[Jmapb]

On 7/22/2020 11:27 AM, bkil wrote:

According to OSM wiki history, `bicycle=dismount` is a pretty recent
tag, perhaps less than 7 years old. I think `bicycle=no` was invented
much earlier. Hence it is you who wants to redefine a well established tag.

According to the first version of access=* in 2006:

https://wiki.openstreetmap.org/w/index.php?title=Key:access&oldid=3772
 >  Closed to or unsuitable for bicycle traffic



Yes, my guess is that early mappers felt no need for bicycle=dismount
because it was simply presumed that foot=yes + bicycle=no meant the same
thing -- the assumption of a very bicycle-friendly culture!

The obvious problem with bicycle=closed is that it's rarely used so
routing software will probably not be looking for it, and so will
happily send bicycles along bicycle=closed ways. In fact, I wanted to
test some routers but I can't find a single bicycle=closed way currently
tagged on the whole map.

The other subtler problem is that it might be possible to
confuse"bicycle=closed" with"bicycle=folded" especially for non-native
English speakers.

J

___
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"?

[Jmapb]

On 7/22/2020 10:34 AM, Allroads wrote:


https://commons.wikimedia.org/wiki/File:Waterloopbos._Natuurgebied_van_Natuurmonumenten._Informatiebord.jpg
- Fietsers op verharde fietspaden en wegen
-Bicyclist on paved cycleway and roads.
Here is written what is allowed.
But more important:
Overigens verboden toegang Artikel 461 W.v.S.
Others prohibited access, article 461 Code criminal law.
The word  “Overigens” means:  all the other which is not mentioned
above on the sign
Not pushing a bicycle on a unpaved cyclway, path, tracks. So others
then “wegen” roads.
A active Openmapstreet member got  a ticket for pushing his bike on a
not allowed “wegen” by a certified ranger (BOA) Community service officer.


I wonder if carrying a bicycle (possibly folded) would also be
prohibited on these unpaved ways?

As was mentioned in the last thread, the rules for most federal
wilderness areas in the USA strictly prohibit possession of any bicycle
on the property, whether the wheels ever touch the ground or not.
Rangers will fine the violators.

To me, the simplest and most logical tagging approach would be:
 - bicycle=no means no bicycles, ridden or otherwise
 - bicycle=dismount means pushing is allowed
 - other values can be used for even more restrictive situations:
bicycle=carried, bicycle=folded, bicycle=boxed...

But the problem with this, as I've learned, is decades of tagging by
mappers who had no experience with the idea of bicycles being completely
prohibited, so used bicycle=no to mean bicycle=dismount in situations
where foot traffic was permitted.

If this unfortunate tagging practice really needs to be preserved (the
idea of retagging so many bicycle=no ways is certainly daunting) then
I'd suggest a new key, dismounted_bicycle=*, which will function as a
regulation key (like smoking=*) rather than a vehicle access key. Total
bicycle prohibition would be encoded with both bicycle=no and
dismounted_bicycle=no, and other dismounted_bicycle=* values can be
developed for whatever the regulations are in particular situations.

Jason

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

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

[Jmapb]

On 7/21/2020 11:02 AM, Jan Michel wrote:

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

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

Jan


I agree that a slightly metaphorical use of information=guidepost is the
best idea here -- it doesn't have to be a literal post. (A trail blaze
was originally a physical scratch in the tree bark, but it's rare to see
that now and the meaning has expanded to accommodate other styles.)

All of the alternative guideposts that Michal mentioned -- rock faces,
trees, walls, similar existing surfaces -- would be best encoded using
the location=* tag IMO.

J


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

Re: [Tagging] How to tag minor commercial roads?

[Jmapb]

On 7/16/2020 1:17 PM, Matthew Woehlke wrote:

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?


The exact definition of highway=service is a little murky, but I think
of it as a way intended to serve a particular feature (or set of them)
as opposed to a way that is part of the general public road network
(which would be residential and up.)

This looks like highway=service to me, as does that circle and the
adjacent segment of Wharton Drive.

J



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

Re: [Tagging] relations & paths

[Jmapb]

On 5/14/2020 12:07 PM, Mateusz Konieczny via Tagging wrote:

May 14, 2020, 16:40 by jm...@gmx.com:

On 5/14/2020 10:01 AM, Paul Johnson wrote:



On Thu, May 14, 2020 at 5:48 AM Steve Doerr
mailto:doerr.step...@gmail.com>> wrote:

On 14/05/2020 09:31, Jo wrote:



On Wed, May 13, 2020, 17:44 Jmapb mailto:jm...@gmx.com>> wrote:

Regarding the original question -- in what circumstances
are single-member walking/hiking/biking route relations
a good mapping practice -- what would be your answer?


Always


Doesn't that
violatehttps://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
?


No.  The route traverses the way, it's not the way.


Okay. But surely this doesn't mean that every named footway or
path should be part of a route relation.

The bike trail that brad linked to,
https://www.openstreetmap.org/relation/6632400 -- I've never been
there but I don't offhand see any reason to call it a route. (Brad
has been there, I assume, because it looks like he updated it 2
days ago.) There's no information in the relation tags that isn't
also on the way itself. Is there any benefit to creating a route
relation in cases like this?

Better handling of future way splits, consistency.


I can see the advantage of using a route relation as a somewhat
future-proof persistent identity -- a relation URL that will show the
whole trail even if the way is split to add a bridge, specify surface,
etc. At the same time, though, it feels like a bit of a stretch to
declare any named trail of any length as a route, and I'm not inclined
to tack route relations overtop of the single-segment trails I'm working
on (unless they're long or part of a network.)

As I mentioned, I suspect that a large force behind this is mappers
wishing certain trails to be processed or rendered differently by
various third-party software. Regardless, if there really is burgeoning
enthusiasm for this technique, one of you single-segment route advocates
might consider explaining it on the wiki. The current language uses a
lot of plurals...

"may go along roads or trails or combinations of these"
"consist of paths taken repeatedly"
"Add all different ways of the foot/hiking route to this relation. The
order of the ways matters."

... which leaves mappers like me & Brad scratching our heads when we
encounter one of these singleton routes.

J

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

Re: [Tagging] relations & paths

[Jmapb]

On 5/14/2020 10:01 AM, Paul Johnson wrote:



On Thu, May 14, 2020 at 5:48 AM Steve Doerr mailto:doerr.step...@gmail.com>> wrote:

On 14/05/2020 09:31, Jo wrote:



On Wed, May 13, 2020, 17:44 Jmapb mailto:jm...@gmx.com>> wrote:

Regarding the original question -- in what circumstances are
single-member walking/hiking/biking route relations a good
mapping practice -- what would be your answer?


Always


Doesn't that violate
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ?


No.  The route traverses the way, it's not the way.


Okay. But surely this doesn't mean that every named footway or path
should be part of a route relation.

The bike trail that brad linked to,
https://www.openstreetmap.org/relation/6632400 -- I've never been there
but I don't offhand see any reason to call it a route. (Brad has been
there, I assume, because it looks like he updated it 2 days ago.)
There's no information in the relation tags that isn't also on the way
itself. Is there any benefit to creating a route relation in cases like
this?

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

Re: [Tagging] relations & paths

[Jmapb]

On 5/13/2020 10:12 AM, Paul Johnson wrote:



We've had relations for over a decade now, IIRC.  It's time to stop
treating this basic primitive as entity-non-grata.  If tools
/still/ can't deal with this, this is on the tools and their
developers now.


Sure. Regarding the original question -- in what circumstances are
single-member walking/hiking/biking route relations a good mapping
practice -- what would be your answer?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relations & paths

[Jmapb]

On 5/12/2020 10:58 PM, Paul Johnson wrote:

On Tue, May 12, 2020 at 9:37 PM brad mailto:bradha...@fastmail.com>> wrote:

OK, but it seems redundant to me.   A trail/path get tagged as a
path.
There's a trailhead and a sign, it gets a tagged with a name.  
Why does
it need to be a route also?


Same reason all 0.11 miles of I 95 in Washington DC is part of a
route.  It's part of a route.


Yes but that's *part* of a route, a route relation with many other
members. Brad's asking about single-member route relations.

My understanding, still evolving, is that tagging conventions originally
developed for long-distance walking routes -- thing like osmc:symbol,
colour, distance, network -- are sometimes applicable to shorter trails,
including those that are only a single highway=path/footway. Mappers
reading the wiki page for osmc:symbol will be told that this tag is only
to be used with route relations. Some mappers who want to add a symbol
to a single-highway trail might tag osmc:symbol directly on the highway
anyway (Taginfo shows 2924 instances of this) and some might create a
single-member route relation.

Another thing to consider -- for vehicle roads we have a many-tiered
hierarchy from motorway down to track, which assists in routing and
rendering. Paths and footways have no such hierarchy, so adding them to
a relation along with the relation-specific tags is one technique
mappers have used to call out trails of greater importance.

Finally there's the issue of software and rendering support. Waymarked
Trails, as Kevin mentioned, only supports route relations. I believe
other hiking map renderers work similarly. Of course this is not how OSM
is "supposed" to work -- structuring data for a particular renderer or
software -- but nonetheless it is a factor in how people map.

Jason

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

Re: [Tagging] Running but no hiking/walking

[Jmapb]

On 5/1/2020 7:48 PM, Martin Koppenhoefer wrote:


Another idea could be to introduce “running” as a new state of foot, e.g.
foot=no
foot:conditional =yes @ running


I like this, a little less cheeky than conjuring an arbitrary unsigned
minspeed for runners. And would be likely interpreted "correctly" by
routing software in its current state (assuming users of pedestrian
routing are more likely planning a walk than a run.)

J


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

Re: [Tagging] Running but no hiking/walking

[Jmapb]

On 5/1/2020 4:37 PM, Mike Thompson wrote:

Hello,

We have a trail [0] around here where walking/hiking is not allowed,
but running is. Currently it is tagged foot=yes, which doesn't give
the full story. In case you are wondering how such a situation could
come about, it is because the land manager wants faster traffic (trail
runners, mountain bikes and horses) on this trail, and slower traffic
(walkers/hikers) on a more or less parallel route.  Any suggestions as
to how to tag?

Thanks,

Mike


[0] https://www.openstreetmap.org/way/449200803


minspeed:foot? A value of around 6 or 7 (default unit is km/hour) should
separate the fast walkers from the joggers. Of course it's anyone's
guess if there would ever be any software support for this key.

Another approach would be to leave off the highway tag and tag it a
leisure=track + sport=running + bicycle=yes/designated. Routing software
would probably ignore it for pedestrian mode but might still route
bicycles on it.

Jason


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

Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

[Jmapb]

On 4/16/2020 4:46 AM, Paul Allen wrote:

On Thu, 16 Apr 2020 at 04:08, Andrew Harvey mailto:andrew.harv...@gmail.com>> wrote:

To sidestep your question, oneway=yes on a highway=footway,
cycleway or path already implies it's not accessible to vehicles
so a oneway tag on any of those highway tags should apply to all
modes of transport. So highway=footway + oneway=yes shouldn't need
any other tags like oneway:foot.


That works when only a single mode of transport is permitted.  It may not
work when more than one mode of transport is permitted. Or does the
one-way on a one-way street apply to pedestrians as well as cars?

Since we may need to be able to specify oneway to individual modes
of transport when multiple modes of transport are permitted, it makes
sense to do so in a consistent manner even when only one mode of
transport is permitted.


I've always believed that the oneway key applies to all non-pedestrian
traffic -- except on footway, path, steps, and pedestrian, where it
applies to all traffic. And of course individual modes can be overridden
with a oneway:*=* tag.

It's not entirely consistent per se, but it's pretty simple and the
preponderance of oneway=* tags on footways and oneway:foot=* tags on
other highways tells me that many mappers understand and use this
convention.

To me, foot:backward=no seems like a awkward solution to a contrived
problem.

J

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Jmapb]

On 4/2/2020 9:29 AM, Paul Johnson wrote:



On Thu, Apr 2, 2020 at 3:10 AM Andrew Harvey mailto:andrew.harv...@gmail.com>> wrote:

My view based on current usage, reading of the wiki and general
opinion is that highway=cycleway is meant for any path that is
either designed/intended for bicycles or specifically designated
(signposted) for bicycles, irrespective of if it's an urban track
or mountain biking track.

So a mountain bike track and an urban cycle track should both be
tagged with highway=cycleway as the primary tag. surface= and
smoothness= can help for both to help guide users on which kind of
bicycle the track is suitable for, and mtb:scale=/mtb:scale:imba=
are used to indicate this is a designated mountain biking track.

highway=path is specifically for a general use / unspecified path,
which a mountain biking track may be if it's informal/shared, but
purpose built and signposted mountain bike tracks don't fall into
that category.

A similar thing applies to hiking tracks, sometimes they are
designated walking paths so use highway=footway + surface +
sac_scale, but sometimes they are just an unmarked or mixed use
path so are highway=path + surface + sac_scale.


This is also my read on it.  But we also need more than just
highway=path/cycleway and sometimes footway for bicycle facilities,
there's a bigger hierarchy than this.  Also seen a lot of situations
where highway=cycleway_link would be handy.


Perhaps highway=mtbway, which would be to cycleway what track is to
residential. It's ugly but it seems that a lot of people feel that
highway=path is not an ideal tag for a purpose-built mountain bike
trail. If highway=cycleway + mtb:scale above 1 is considered troll
tagging, then maybe mtbway is worth considering.

Btw, since the original example Phyks posted is one of mine, I can
describe exactly how the tagging happened:

 - Noticing local mtb trails tagged as hw=cycleway (can't remember
which ones exactly).
 - Reading the cycleway wiki page and seeing no counterindications to
this tagging, concluding that a mountain bike is a bicycle and that
trails primarily designed for mountain bikes should be cycleways.
 - Visiting this park and seeing from the park map and personal
observation that some trails were primarily designed for mountain bikes.
 - Reading the park map where trails are described as "easier", "more
difficult", and "most difficult" which I mapped to mtb:scale 0, 1, and 2
-- with a clear changeset comment that these values are guesses and
should be revised by knowledgeable people. (I'm not a mountain biker
myself; I walked these trails.)

Is mtb:scale=2 correct for this trail? Maybe not. Maybe I should have
mapped them to 0, 0+, and 1. Maybe they're all 0. But these ratings are
kind of subjective. Could a general purpose bicycle handle this trail?
I'm sorry to say that I can't remember. I'll survey again when I can,
but someone experienced with mountain biking could probably do better.

Jason

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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb via Tagging]

On 3/15/2020 6:18 AM, Markus Peloso wrote:


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

A small facility where people drop off and pick up various types of
items in the sense of free sharing.

Hi

After "Clarify whatever explicit abstaining is the same as no vote"
and the change of the Proposal process page I reopen the voting, maybe
someone wants to change their vote or add a comment.

In the meantime we have got some new inputs:

Summary

- We hade discuss about give box, hiker box, public refrigerator, free
pantry and food sharing and how this things could be documented in
OpenStreetMap.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/food_sharing#Arguments_and_comments_from_the_Tagging_.5BPublic_refrigerators.5D_E-Mails

- New Proposed feature "food sharing"
https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing

- New Proposed feature "donation of goods"
https://wiki.openstreetmap.org/wiki/Proposed_features/donation_of_goods

- Some mappers tag blessing boxes with new amenity=give_box tag
https://overpass-turbo.eu/s/RAA


Thanks for your patience and perseverance, Markus!

It's clear that give boxes will be approved as a feature. The only
remaining questions I see are:

1. What's the best tag for them? (Some people don't like "give_box" --
maybe an opportunity to experiment with ranked-choice voting?)

2. What related amenities are distinct enough that they deserve their
own separate tags?
 - Public bookcase, obviously.
 - Separating the food sharing amenities seems like a good idea. I'd be
in favor of a single tag to which refrigerated=yes could be added to
indicate a public refrigerator.
 - I like the idea of a separate tag for hiker boxes, because (as I
mentioned in the public refrigerator thread) it's very common to have
them as part of another map feature like post office, shop, hotel, or
campsite, so simply being able to add hiker_box=yes would be great.
 - I've never heard the term "blessing box" before but it seems like
they'd best be classified as either food sharing or give box, depending
on the inventory.

Jason

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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb]

On 3/5/2020 9:27 AM, Peter Elderson wrote:

Do you know trails with detached sections? We have some in Nederland,
on the islands. Doesn't fit in the proposed role scheme, I think.

Vr gr Peter Elderson


See this section of the E10 in Czechia (
https://www.openstreetmap.org/relation/5465693 ) -- there's no
connection between these three sections of trail, and I don't know if
there ever will be. I think the E* European long-distance trails have a
lot of these discontiguous sections.

In the USA I know of the North Country Trail, which is very incompletely
mapped in OSM ( https://www.openstreetmap.org/relation/8808051 ). Much
of it is made up of other trails. Unlike other long-distance trails, the
North Country Trail doesn't claim to be contiguous on a micro level, and
has hundreds of disjoined sections. It shares a lot of physical trail
with the Finger Lakes Trail in New York State, but (by my understanding)
in a conceptually different way: The Finger Lakes Trail aims to be
contiguous and will consider a half mile (or much more in some cases)
walk along a residential road between two sections of wilderness to be
part of the route. The North Country Trail will include the sections of
hiking trail through both of the wilderness portions, but will not
include the road walk. When you step onto the road, you've left the
North Country Trail but you're still on the Finger Lakes Trail. Once you
go back into the woods, you're on both trails again.

Jason

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

Re: [Tagging] Public refrigerators

[Jmapb]

On 3/2/2020 3:57 PM, Kevin Kenny wrote:

I'm sure that there'd be a subcategory for 'hiker boxes' as well.
  http://www.thetrailmaster.com/hike-smart/hiker-boxes-share-and-share-alike/
https://www.whiteblaze.net/forum/showthread.php/55460-quot-I-found-it-in-a-hiker-box-quot
Major long-distance trails in the US often have them at resupply points.

I've used them to leave gear, (for example a pair of gaiters that I
was never going to use again because they turned out to be one size
too small for my boots) and supplies (for example, about 750 ml of
denatured alcohol when the store had it in litre cans, or three rolls
of toilet paper from a 4-pack) in them. I've raided them to top up on
things like hand sanitizer, plastic bags and coffee filters. (A hiker
might need to carry a handful of filters or Ziplocs between resupply
points; the stores sell them in packages of 100. Perfect application
for 'share alike!') I even found that one contained a replacement for
a broken buckle for one of the straps on my backpack - just when I
needed one.


Hiker boxes are mentioned as part of the give_box proposal, tagged with
hiking=yes. Works for me, though I'd be fine with an amenity=hiker_box
tag if it appears to be warranted. That would make it easier to tag the
presence of a hiker box (hiker_box=yes) at a post office, shop, shelter,
hotel, etc.

It's impossible to predict what can be left and found -- in my
experience: clothing, food, instant drinks, maps, books, batteries, fuel
(including white gas, propane canisters, esbits, and alcohol), non-fuel
alcohol, painkillers, cookware, water bottles, water filters, tent
stakes, rope, ziplocks, duct tape, sewing kits, shoelaces, soap,
shampoo, toothpaste, probably a lot I'm forgetting. Often there are
unlabeled ziplocks full of mysterious powder, and it's anyone's guess if
it's food, beverage, or soap.

A related idea that might be worth tagging is: Places near a hiking
trail that will receive and hold resupply packages, including any
prohibited items (fuel eg) and whether a fee is charged for the service.
Very often these places will also feature hiker boxes stocked from
superfluous supplies.

Jason


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

Re: [Tagging] Public refrigerators

[Jmapb]

On 2/29/2020 3:43 AM, Markus Peloso wrote:


I find amenity=give_box is different from amenity=food_sharing as a
shop=general is different from shop=supermarket.

In Switzerland if I go into a supermarket I found products of daily
hygiene but the main thing is about shopping for food.


True, and the use of the word "pantry" on the free pantry I mentioned
tells me that it's primarily for food, so it should be fine to tag it as
a free pantry and use a description tag for other info. There doesn't
currently seem to be a better tag for a public pantry, so  I was
inclined to call it a give box -- but it's distinct enough that it could
get its own tag.


The main thing by a give box is about sharing items. In the
description I explicit excluded amenity=give_box + food=only because
if you go to e give box you expect some items like clothes, small
appliances, dishes, toys.


Based on the proposal it seems like there's quite a range, so you can't
know what a give box is for without checking additional tags. If this is
not true -- if there's a set list of things that every give box should
support -- then we'll end up needing other tags for bunch of new
features (eg for the free art box.)


Does a free pantry have some social aspect? Like given food to
underprivileged or homless people social_facility:for
=underprivileged,
social_facility:for
=homeless,
…

Based on the description on this website
http://www.littlefreepantry.org/ I think the main thing is about
sharing food and it is some kind of social service.


I think Joseph's point is well-taken that there's a scale problem with
using the word "facility" for a cupboard or fridge. It would be similar
to using "library" for a public bookcase. Doesn't mean that we couldn't
add eg "public_pantry:for=underprivileged" of course.

The distinction is complicated by the fact that "food pantry" is
sometimes used as a friendlier name for full-scale food bank facilities.
(There are also many shops and restaurants called "pantry" of course --
it's a common synecdoche.)

Here's where my head's landed:

Public bookcase - Primarily for free sharing of books, may (in my
experience) sometimes have other items like music or movies. Has its own
well-supported tag. Rendered as a roof over a book.

Free pantry - Primarily for free sharing of food, may include other
items such as personal hygiene products. Often has a "donate to those in
need" social service aspect, but this is not required. Probably deserves
its own tag. Maybe render it as a roof over a hamburger or apple.

Public refrigerator - A special case of free pantry, tag with
refrigerated=yes.

Give box (or whatever we end up naming it) - Catch-all for everything
that's not specified for books or food, although in some cases they may
include books or food. May have a social service aspect, but not
required. Will hopefully get its own tag. Maybe render it as a roof over
a gift box (shop=gift icon).

J


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

Re: [Tagging] Public refrigerators

[Jmapb]

On 2/26/2020 4:32 PM, Martin Koppenhoefer wrote:

On 26. Feb 2020, at 08:56, Markus Peloso  wrote:

The amenity=give_box tag is specific for sharing and reusing none food items. 
Please do not use it for food sharing


+1, although these are somehow similar features from a certain point of view, 
they are also significantly different features from another point of view. I am 
in favor of keeping a distinction on the main tag level.


The give_box proposal specifically said that food sharing was *not* to
be included in the give_box schema.

I voted for that, but since then, with the proposal stalled, I ran into
what I'd called a give box for "packaged food & personal care items."
It's labeled "free pantry" but it's not just for food.
https://i.imgur.com/UzhuIBo.jpg (Non-refrigerated, obviously. There were
actually cans of food in here but not visible in this shot.)

Also hiker boxes -- which were explicitly part of the give_box proposal
-- often have food as well as clothing, gear, books, maps, and fuel. So
maybe the prohibition of food in give_box isn't ideal.

Regardless, though, I don't think a public refrigerator should be a
subtag of give_box -- it's too distinct. I think
amenity=public_refrigerator makes sense. Using amenity=social_facility
plus a subtag would also be fine I guess.

Jason


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

Re: [Tagging] man_made=petroleum_well vs man_made=pumping_rig

[Jmapb]

On 2/26/2020 4:59 PM, Joseph Eisenberg wrote:

It's also possible to have a functioning petroleum well without any notable 
surface-level equipment


So in that case, there would be no "pumping rig", right? There would
just be some pipes and valves the the wellhead, aka a "Christmas
tree": https://en.wikipedia.org/wiki/Wellhead and
https://en.wikipedia.org/wiki/Completion_(oil_and_gas_wells)

Do you know if all "pumping rigs" are similar in appearance to a
pumpjack, or are there others that look quite different?
https://en.wikipedia.org/wiki/Pumpjack - I've seen many of these in
California and Texas.


Christmas tree, yes, exactly! But they're not all quite that elaborate.
Sometimes they look more like fire hydrants. And I guess that goes
against my claim of "no notable surface-level equipment" because lots of
people like to map fire hydrants.

The pumpjacks are what I know -- I'm no expert but it's a safe
assumption that there are other designs out there.

J



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

Re: [Tagging] man_made=petroleum_well vs man_made=pumping_rig

[Jmapb via Tagging]

On 2/26/2020 3:54 AM, Joseph Eisenberg wrote:

There are some users on the wiki who seem to treat these two tags as
near-synonyms

man_made=petroleum_well
man_made=pumping_rig

The later was approved, but the first is much more common.

The proposal in 2008 for pumping_rig said

"A tag for pumping platforms - gas, oil, etc. The rig may be on ground or water"

But petroleum_well says just: "An oil well is a boring in the Earth
that is designed to bring petroleum oil or gas to the surface."

I believe not all petrolum wells have a pumping rig? Can someone
confirm that these tags are different?


Oil wells generally begin with a boring apparatus housed in a vertical
derrick (drilling tower). Depending on the circumstances, the derrick
might be dismantled when the well is ready for production.

Once a well is in production, a pumping rig (which I'd call a pumpjack)
is installed, to pull the crude up and into a pipeline or storage tank.
It's possible to have multiple pumpjacks for a single well -- they're
not synonymous.

It's also possible to have a functioning petroleum well without any
notable surface-level equipment, especially a gas well.

Jason



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

Re: [Tagging] Feature Proposal - RFC - in-kind_donation

[Jmapb via Tagging]

On 2/16/2020 8:21 AM, Steve Doerr wrote:

On 15/02/2020 16:56, Markus Peloso wrote:


https://wiki.openstreetmap.org/wiki/Proposed_features/in-kind_donation

For a place that takes in-kind donations.



My immediate reaction is that this sounds like a very similar concept
to 'give box', which was the subject of a recent RFC. Do we need two
ways of tagging such similar things?


The defining feature of the give box is that the public can freely
access it for both giving and taking. With this feature (in-kind
donation) the public can give goods but wouldn't expect to freely take
things that others have given.

It's similar to recycling but implies that the goods are reused rather
than used as raw materials. Personally I feel this is a bit of a
continuum and I don't see a problem with tagging in-kind donation sites
as a type of recycling.


On 2/16/2020 8:28 AM, Steve Doerr wrote:


Anyway, it's a quirk of the English language that a phrase that
normally consists of separate words is generally hyphenated when it is
used 'attributively', i.e. as a quasi-adjective before a noun. So I
might write, 'He made a donation in kind' but 'He made an in-kind
donation'.


A well-put description! The phrase is hyphenated when it functions as an
adjective. See
https://en.wikipedia.org/wiki/English_compound#Hyphenated_compound_modifiers
for some other examples and exceptions.

J

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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb via Tagging]

On 2/6/2020 10:47 AM, Paul Allen wrote:

And if they wanted to comment but not vote they'd add their comment to the
talk page instead.  Right?


Absolutely! If that's what the instructions said. But they clearly say
that if you do want to comment, but you don't want to vote, then choose
"abstain."

J


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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb via Tagging]

[Sorry for the repost, corrected wiki link below...]

On 2/6/2020 5:40 AM, Martin Koppenhoefer wrote:


Actually, in the past we always have counted every kind of comment
(vote yes / no and abstain) as part of the total, which indeed led to
the situation that an (explicit) abstention effectively counted like a
no-vote.
Are we going to change this now? If yes, it should be documented (and
maybe also voted upon).

That *is* how it's currently documented -- and if abstain is intended to
be counted equivalent to no, then the proposal documentation should
change to reflect this.

The current description of "approved" on
https://wiki.openstreetmap.org/wiki/Proposal_process is:
> A rule of thumb for enough support is 8 unanimous approval votes or
at least 10 votes with more than 74 % approval

The current description of "abstain" on
https://wiki.openstreetmap.org/wiki/Template:Proposed_feature_voting is:
> If you don't want to vote but have comments

Someone who chooses "abstain" according to this template presumably
believes they are merely commenting, *not* voting. If they wanted their
vote to count as the equivalent to "no," they'd vote "no"... right?

Maybe the "abstain" option should be removed altogether. But in the
meantime it seems irregular to tally votes according to different rules
than those that were documented when the vote occurred.

Jason

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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb via Tagging]

On 2/6/2020 5:40 AM, Martin Koppenhoefer wrote:


Actually, in the past we always have counted every kind of comment
(vote yes / no and abstain) as part of the total, which indeed led to
the situation that an (explicit) abstention effectively counted like a
no-vote.
Are we going to change this now? If yes, it should be documented (and
maybe also voted upon).

That *is* how it's currently documented -- and if abstain is intended to
be counted equivalent to no, then the proposal documentation should
change to reflect this.

The current description of "approved" on
https://wiki.openstreetmap.org/wiki/Proposal_process is:
> A rule of thumb for enough support is 8 unanimous approval votes or
at least 10 votes with more than 74 % approval

The current description of "abstain" on
https://wiki.openstreetmap.org/wiki/Template:Proposal_Page is:
> If you don't want to vote but have comments

Someone who chooses "abstain" according to this template presumably
believes they are merely commenting, *not* voting. If they wanted their
vote to count as the equivalent to "no," they'd vote "no"... right?

Maybe the "abstain" option should be removed altogether. But in the
meantime it seems irregular to tally votes according to different rules
than those that were documented when the vote occurred.

Jason

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

Re: [Tagging] amenity=faculty?

[Jmapb]

On 2/5/2020 6:21 PM, Lionel Giard wrote:

Site relation are more used to put the tag "amenity=university" and
all the information only 1 time for the whole university when it is
spread across a city or multiple sites. This site relation equal to
the amenity=university area under a campus that's all grouped into one
place. Otherwise, if you query the data, you'll see many
amenity=university (which means multiple universities) that are
exactly the same which is wrong.


I would generally just use a multipolygon relation for this. Any
contiguous portions of university campus are mapped as closed ways with
role "outer." Any isolated university buildings are also added to the
relation with role "outer". All the top-level university tags, including
amenity=university, go on the relation. (But it can get tricky if some
university office or department occupies an undefined portion of a
particular building that is otherwise not controlled by the university
-- I tend to just use nodes tagged with name/operator/website and leave
these out of the relation, which is not ideal.)

J


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

Re: [Tagging] amenity=faculty?

[Jmapb]

On 2/5/2020 4:36 AM, Lionel Giard wrote:


Thus, it seems difficult to find "one" subdivision that will always
work worldwide ?! :-) Maybe that we should keep a generic word and
allow everything in it (like subdivision=* with the name of "School",
"Institute", "College",... if relevant) ?


I agree the various terms I've seen (faculty, department, school,
college, institute, program(me), division, educational unit) don't seem
to line up worldwide or even within some small regions.

A generic term, with the site-specific term listed as part of the name=*
tag, seems like a good solution. I'd probably be happier with department
or division as the generic term, but subdivision might work.

(In discussions like these I can't help thinking about the various
proposals for a unifying education=* tag, and how that might affect the
tagging of sort of hierarchy. The most recent one, currently "under
way", is
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative
.)

Jason


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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb]

On 2/5/2020 8:58 AM, Joseph Eisenberg wrote:

Well, if we count all of those, it is 68% (13/19) which is less than
the 74% cut-off.


Is it normal to count abstentions as part of the vote total? The
proposal template text (
https://wiki.openstreetmap.org/wiki/Template:Proposed_feature_voting )
says "I have comments but abstain from voting" followed by the
description "If you don't want to vote but have comments." Unless
there's a clear precedent otherwise, it sounds like "abstain" should not
be part of the vote count.

If abstentions did count in the vote total, then mathematically there'd
be no difference between "oppose" and "abstain," and it would be
impossible to leave comments without affecting the voting.

Jason


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

Re: [Tagging] Ski picnic room

[Jmapb]

On 2/3/2020 5:55 PM, Warin wrote:

On 30/1/20 9:23 pm, MARLIN LUKE wrote:

Noticed amenity=shelter. I initially thought about combining it with
shelter-type:picnic, but it seems too... "open" for me. Like, not a
complete building.

I'll use this in the meantime


There is shelter_type=weather_shelter that looks more enclosed.

Perhaps shelter_type=picnic_enclosed?



I'm not a skier myself, but while hiking I've encountered ski shelters
that sound similar to the one Martin was describing, though a little
more primitive (ie, no vending machines.)


I've heard them called "warming huts" but I don't know how universal
that terminology is. Checking taginfo for shelter_type=warming_hut shows
exactly one use. And the ones I've seen are more like cabins than huts,
so I'd be reluctant to tag shelter_type=warming_hut unless the meaning
is quite clear.


One of the more popular values of shelter_type is simply
shelter_type=building. To me this would mean enclosed, but wouldn't
imply picnic facilities (which could of course be mapped separately.)


Jason

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

Re: [Tagging] road names and refs

[Jmapb]

On 1/31/2020 11:56 AM, Jmapb wrote:

They don't have their own street signs, and addresses
along them will be 12345 Route 28 (or 12345 State Route 28, or 12345
State Highway 28, or 12345 NY 28... poorly standardized.) There might be
a case for removing the name= from these, maybe even tagging them as
highway=service. ( eg https://www.openstreetmap.org/way/20215809 ).


...Mea culpa, this one *does* in fact have its own "OLD ROUTE 28" street
sign:

https://binged.it/31nKVOh (pretty blurry in this pic)

J


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

Re: [Tagging] road names and refs

[Jmapb]

On 1/30/2020 6:22 PM, Kevin Kenny wrote:

Uhm.  It looks pretty much like any other `highway=unclassified`. The
signs say 'Old Route 7' in the style the township uses for rural
roads. There are no shields or chaining markers to indicate that it's
a state highway. And it's been called, 'Old Route 7' for decades. This
isn't a case of the state adding 'OLD' in place of a directional
marker, this is just that the town never saw fit to name the remaining
road anything else, and put up signs showing the name as it is.  (And
I've given the wrong number, but I'm far too lazy to look up the
correct one.)


I've mapped some bits of Old Route 28 in New York. In most places the
current NY 28 is on the same roadbed as the old highway, but here and
there small segments of the former road remain. They're mostly tagged
"name=Old Route 28" from TIGER (I see one "name=Old St Hwy 28").

Some bits are close enough to the new route 28 that they serve as little
access roads. They don't have their own street signs, and addresses
along them will be 12345 Route 28 (or 12345 State Route 28, or 12345
State Highway 28, or 12345 NY 28... poorly standardized.) There might be
a case for removing the name= from these, maybe even tagging them as
highway=service. ( eg https://www.openstreetmap.org/way/20215809 ).

Other sections are further removed and have their own road signs (long
green street signs, not highway shields) that say "OLD ROUTE 28". House
and business addresses use Old Route 28 as the street name. These ways
should definitely keep the tag "name=Old Route 28".

In neither case would I say that adding an old_ref or old_name tag is
wrong per se, but I doubt that it would ever be particularly helpful.

But there are some situations where I'd say old_ref is a good idea, see
these signs from the transition from US-666 to US-491:
https://i.imgur.com/znnYnpt.jpg

J


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

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[Jmapb]

On 1/29/2020 6:14 PM, Joseph Eisenberg wrote:

The healthcare=* tags were formally proposed and voted on 10 years ago.
Included in that proposal (
https://wiki.openstreetmap.org/w/index.php?oldid=1318635  ) was the idea
that dual-tagging some features with both amenity=*/healthcare=* would
be the norm until the healthcare=* tags had wide usage and software support.

But healthcare=pharmacy was never included in the proposal. In fact
the proposal authors originally wanted to change amenity=pharmacy to
shop=pharmacy, but changed the proposal due to negative comments.

https://wiki.openstreetmap.org/w/index.php?oldid=1318635  - link to
voted proposal

This explains why healthcare=pharmacy was unused prior to the iD
change (the other 4 tags had a small amount of use, though only a
couple percent of the amenity=hospital/doctors/clinic/dentist tags)

Note also that the voted proposal does not mention replacing
amenity=clinic with healthcare=clinic, and does not specifically state
that any tags are to be deprecated.


It's true that some values of healthcare=* were not included in the
original proposal. This is normal, new values get added to existing keys
all the time, and are documented on the relevant wiki pages if they gain
traction.  A wiki reader who's interested in the history can research it
by reading the original proposal and paging through the page versions.
We don't need to crowd the table with footnotes.

The approved proposal specifically called for replacing amenity=hospital
with healthcare=hospital, amenity=doctors with healthcare=doctor, and
amenity=dentist with healthcare=dentist. Even though the proposal did
include healthcare=clinic, it did not, as you note, specifically call
for replacement of amenity=clinic. The word "deprecate" was never used.
But if there ever *is* a time to consider deprecating amenity=hospital
etc, it certainly isn't now. Maybe we can talk about it in 10 or 20
years. Meanwhile there *will* be some dual tagging. Both
amenity=hospital and healthcare=hospital are correct tags -- one because
it's a de facto tag with over 150 thousand uses, and one because it's
been proposed, voted on, and approved.

Your current claim on the wiki that these overlapping tags are used by
only "one editor" (ie, iD) is completely false. I use them all the time,
and I avoid iD like the plague. If you're still interested in the
quality of the healthcare=* page, please have another pass at making it
factually correct, *useful* for new users, and from a neutral point of view.

Thanks, Jason


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

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[Jmapb]

On 1/29/2020 2:23 PM, Andrew Hain wrote:

Is it time for another controversial decisions page then?


The healthcare=* tags were formally proposed and voted on 10 years ago.
Included in that proposal (
https://wiki.openstreetmap.org/w/index.php?oldid=1318635 ) was the idea
that dual-tagging some features with both amenity=*/healthcare=* would
be the norm until the healthcare=* tags had wide usage and software support.

Carto started rendering healthcare=* features last year (or maybe late
2018) but ran into a bug. This is a setback for the healthcare=* tags,
but people are still using them! Hopefully Carto will begin rendering
them again soon.

The iD team has decided to encourage the dual tagging in the mean time.
Although I feel that iD's a bit forceful with this stuff and should give
users more information about what they're choosing to "upgrade," this
doesn't seem particularly controversial (especially compared to other iD
decisions) because it's following an officially approved proposal.

Jason


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

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[Jmapb]

On 1/29/2020 8:50 AM, Lionel Giard wrote:


That's clearer when we get all the history thank you Joseph ! :-)
I agree with you that the added value of duplicating the key is very
limited, so i understand your edit on the wiki. ^_^


IMO, unilaterally deprecating healthcare=clinic/dentist/doctor/hospital
on the healthcare=* page is a bit heavyhanded. These are part of a voted
and approved proposal.

Jason


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Jmapb]

On 1/28/2020 4:49 PM, Kevin Kenny wrote:


Be that as it may, there are a great many  `highway=path` objects
where the intent was `combined foot- and cycleway`. The concept that a
`footway` is urban while a `path` represents something more like a
wilderness trail is a rather new one to me. (I'm not saying that it's
new to the community. I may have been misinformed. Many other mappers
were similarly misinformed. Moreover, I've tagged some `footway`
objects that _are_ wilderness trails, as well as urban `path` objects,
and that, too, seems to match local practice.)

Given the large number of objects that are mistagged under the
understanding being proffered, it strikes me that the ship has sailed.
Since `surface=*` and `width=*` are available, they are likely to be
the only reliable way to disambiguate a paved footway from a dirt
hiking trail, or a paved doubletrack from a MTB trail.


My impression from this thread is that none of the three
(highway=footway, highway=cycleway, and highway=path) are deemed
inherently invalid for mapping a mixed bicycle/foot way. Some mappers
may have a heuristic for which to choose or avoid, but there doesn't
seem to be an official rule that holds worldwide. I'm sure a lot of it
is down to local mapping styles. And apparently the urban/rural thing is
a red herring, at least for mixed-use ways.

J


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Jmapb]

On 1/28/2020 4:23 PM, Tomas Straupis wrote:

   Yet for ten years or even more the logic was that if the same way is
designated for both pedestrians and cyclists, it cannot be tagged with
highway=footway - as it is for cyclists as well, it cannot be tagged
with highway=cycleway because it is for pedestrians as well, so such
shared ways for this long period were tagged as
highway=path+bicycle=designated+foot=designated. This has also been
the preset in the main OSM editor - JOSM. This is in documentation and
maps for ten or more years.

   Are there any reasons why this must change now? Any benefits?


When I draw a highway=cycleway using the JOSM preset, it offers the
option to tag it with foot=yes/no/dedicated. Likewise, when I draw a
highway=footway, it offers bicycle=yes/no/dedicated. I can't say how
long it's been there because I don't generally use the presets. J


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Jmapb]

On 1/27/2020 3:53 PM, Andrew Davidson wrote:

The same user also changed the Australian tagging guidelines without
discussion, which we didn't notice till last October:

https://lists.openstreetmap.org/pipermail/talk-au/2019-October/013009.html

and they were reverted. Didn't notice at the time that he'd also
edited the parent page.

My own impression over the years has been that mappers use
highway=cycleway on anything that primarily for bicycle traffic,
and add
access keys for any other permitted traffic. Similarly for
highway=footway. So "highway=cycleway + foot=yes" and
"highway=footway +
bicycle=designated" are quite common.


Using cycleway/footway to map primary/secondary paths is a informal
but common practice.

Is there a general consensus that
these are better mapped as highway=path?


 I had a go at summarising the case against path back in October:

https://lists.openstreetmap.org/pipermail/talk-au/2019-October/013017.html


Thanks for the background. Looks like Richard Fairhurst already reverted
the "shared foot/bicycle must be path" assertion on the cycleway=* page. J

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

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[Jmapb]

On 1/28/2020 9:23 AM, Joseph Eisenberg wrote:

The pages are nearly identical.

Actually, the healthcare=pharmacy page was just made recently by
copying the amenity=pharmacy page. Before it was only documented
minimally at Key:healthcare


I believe the mappers who developed the healthcare=* scheme included
equivalents of the established heathcare-related amenity tags (doctors,
clinic, hospital, dentist, pharmacy) with the hope of slowly changing
features to the healthcare=* tags, with a long transitional phase where
some would be tagged with both amenity=* and healthcare=*. So it
wouldn't surprise me if the documentation is an exact copy.

At some point it appeared to me that iD was automatically adding the
equivalent healthcare=* tags to some amenities -- but it may have
actually been iD's "branding" bot that did that, matching amenities with
certain names.

IMO the healthcare tags deserve a chance and we shouldn't try to chip
away at them. But it would help to explain the situation on the relevant
wiki pages.

Jason


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

[Jmapb]

On 1/27/2020 12:27 PM, Martin Koppenhoefer wrote:


Am Mo., 27. Jan. 2020 um 16:37 Uhr schrieb Jmapb mailto:jm...@gmx.com>>:

And also editing the
highway=path page, which currently says it's not for use in urban
situations.



this seems very strange and is likely the result of fiddling. In the
areas I am aware of, path is the standard way to map mixed mode ways
regardless of context (urban or not).


I misremembered the phrasing slightly -- the actual text on the
highway=path page is


For "urban paths" which are designated for "pedestrians only", it's
better to use highway=footway.


This was added by Geow, an experienced and active German mapper, in
2015. Reading the actual text, I guess that recommendation doesn't have
direct bearing on the question here, which is mixed-use paths not
pedestrian-only paths.

The image caption on highway=path used to say  "semi-urban path" but
this was removed last year by Geow (who left the helpful comment
"Changed incorrect and misleading image caption. Note that "path" is not
restricted to semi-urban and may be sign posted as well" -- now *that's*
how you edit a wiki, my friends!)

J

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

[Tagging] highway=path for *all* mixed foot/bicycle highways?

[Jmapb]

Hi all, just noticed this passage on the cycleway=* wiki page (
https://wiki.openstreetmap.org/wiki/Key:cycleway ):


For mapping a separate path (on a separate way) dedicated to cycling
traffic use highway=cycleway. Foot traffic is restricted on these paths.

  *  Do not use highway=cycleway on paths for both cyclist and foot
traffic (such as shared paths). Instead use highway=path with
bicycle=designated and foot=designated. Add also segregated=yes or
segregated=no) as applicable.
   * For paths where cycling is not permissible use highway=footway.
If cycling is permissible even if it is not signed but legally
permissible on a path, use highway=path (and a combination of the
segregated key and designated tag as applicable) and not highway=footway.


(This was added by wiki user Aaronsta last May, with no change description.)

Does anyone know if there was a discussion, here or elsewhere, that led
to this change?

My own impression over the years has been that mappers use
highway=cycleway on anything that primarily for bicycle traffic, and add
access keys for any other permitted traffic. Similarly for
highway=footway. So "highway=cycleway + foot=yes" and "highway=footway +
bicycle=designated" are quite common. Is there a general consensus that
these are better mapped as highway=path?

If so, we might want to consider standardizing the highway=cycleway and
highway=footway wiki pages with this same rule. And also editing the
highway=path page, which currently says it's not for use in urban
situations.

Thanks, Jason


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

Re: [Tagging] Feature Proposal - Voting - give box

[Jmapb]

On 1/21/2020 3:42 AM, Markus Peloso wrote:


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

A small facility where people drop off and pick up various types of
items in the sense of free sharing.

Hi

Thanks for the discussion, inputs and improvement to this tag.

*I request for voting now.*

Feel free to give also a negative answer if you only don’t like the
name. Then please write in the comments what name you prefer. Based on
the result I will made a second vote with a new name. Other suggested
names are:

• amenity=free_box

    • amenity=free_goods

    • amenity=give_take_box

    • shop=freeshop

Best regards,

Markus


Thanks Markus -- I added a photo of a "Free art" box for the gallery. 
If anyone has a photo of a hiker box (something like this:
https://photos.thetrek.co/wp-content/uploads/2019/04/12101802/EEB4E5C5-EAFA-4059-A0AA-3AF6DD324552-700x525.jpeg
) I think it would make a good addition.

Jason

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

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[Jmapb]

On 1/15/2020 10:26 AM, marc marc wrote:


Le 15.01.20 à 16:15, Jmapb via Tagging a écrit :


Don't forget about man_made=drinking_fountain!

omg, what's the diff with amenity=drinking_water ?
the direction of water flow upwards?
348 out of 371 objects also have an amenity tag, which
shows the problem.

it would indeed be a good idea not to forget it and to ask the user if
it is a fountain in the osm sense (a bit artistic) or a water jet. and
add the most current tag.


As I understand, amenity=drinking_water is really just referring to the
availability of potable water, and doesn't describe the form. It could
be a a drinking fountain, a bottle filler, spring, a well, a pump, a
water tap on the side of a building, a bottle filler, who knows?

J


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

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[Jmapb via Tagging]

On 1/15/2020 12:55 AM, European Water Project wrote:

Would it be appropriate to use the tag "seasonal" for a water fountain
(whether tagged as "amenity=drinking_water" or "amenity = fountain and
drinking_water = yes" )?


Don't forget about man_made=drinking_fountain!

J


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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jmapb]

On 1/14/2020 9:13 AM, Jarek Piórkowski wrote:

Here's how the mappers have seen the tags in question so far,
according to Taginfo:

oneway:foot=no 1267 occurrences (not all from one region)
oneway:foot=yes 89
oneway:foot=-1, 1 occurrence

foot:oneway=no 48
foot:oneway=yes 2

foot:backward=designated 45
foot:backward=yes 41
foot:backward=no 40
foot:backward=use_sidepath (not really applicable here) 18
foot:backward=permissive 6
foot:backward=private 1

foot:forward=no 41
foot:forward=designated (not really applicable?) 36
foot:forward=use_sidepath (not really applicable) 23
foot:forward=yes 20
foot:forward=customers 4 (only customers and only one-way?)
foot:forward=destination 3 (might be Hotel California)
foot:forward=permissive 2

--Jarek


Thanks, and I'd like to add to this list:

highway=footway + oneway=* 26505
highway=footway + oneway:bicycle=* 2611
highway=footway + piste:oneway=* 1137

(Oh dear, looks like the ski mappers have chosen a different namespace
style than the bicycle mappers...)

J



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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jmapb]

On 1/13/2020 9:43 AM, Kevin Kenny wrote:

On Mon, Jan 13, 2020 at 8:21 AM Paul Allen  wrote:

Not very intuitive but, perhaps in rare cases, necessary.  What if the road is
one-way to both vehicles and pedestrians but vehicles go from A to B whilst
pedestrians go from B to A?

You beat me to it!

I know I've seen a footway on the verge of the roadway signed, 'WALK
ON LEFT, FACING TRAFFIC.' If the road was a dual-carriageway (it might
have been, I don't recall now), then we'd have had exactly that
situation.  "Just reverse the way" isn't a solution when it's forward
for one mode and backward for another.


The "traditional" (by my observation) way to tag this would be:
highway=residential
oneway=yes
oneway:foot=-1

Using the forward/backward tags, it would be:
highway=residential
oneway=yes
foot:forward=no
foot:backward=yes

IMO they're both ugly. Don't love -1, and don't love introducing a new
backward/forward scheme with basically the same meaning and possibly
ambiguous interactions with the older oneway scheme.

...Scouting around on Overpass, I found one footway that was tagged
something like this:
highway=footway
foot:forward=designated
foot:backward=yes

I think it was something like a nature trail or historic walk where
there's a designed direction of foot traffic but it's not an actual
restriction. That's the best justification I've seen for the
foot:forward/foot:backward tags, though of course one could conjur up
some value like oneway=intended that could mean the same thing.

J


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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jmapb]

On 1/13/2020 9:46 AM, Volker Schmidt wrote:


Personally, I have no problem with oneway=yes having different
implications depending on the value of the highway key. In general I
would expect the oneway value to align the predominant use of the
highway in question.

More specifically:

  - I would expect a oneway=yes tag to apply to foot traffic on
footway.

No. There are thousands of footways with
bicycle=yes|official|designated to make them mixed foot-cycleways


Sure, there are many footways with allowance for an extra sort of
traffic, most commonly bicycles. If these footways are tagged
oneway=yes, I'd expect the other kinds of traffic to follow that rule
too, unless overridden with e.g. oneway:bicycle=no.



  - I would also expect a oneway=yes tag to apply to foot traffic on
pedestrian, path, and cycleway -- unless explicitly nullified with a
oneway:foot=no tag.

 No. There are thousands of pedestrain, path, cycleway with
bicycle=yes|official|designated to make them mixed foot-cycleways


I don't understand the "No." Nothing I wrote precludes using these ways
for both foot and bicycle traffic.

Cycleways are primarily for bicycles, so I'd expect a oneway tag on a
cycleway to primarily describe the bicycle traffic. If foot traffic is
also permitted on a oneway cycleway, I'd expect it to follow the same
oneway rule, unless explicitly overridden with a oneway:foot tag.

Pedestrian and path are a little more ambiguous, but again, I'd expect
the oneway tag to apply to whatever the predominant traffic is. And if
tagged oneway, I'd expect that oneway restriction to apply to foot
traffic unless overridden with a oneway:foot tag.

I'm not *advocating* for this to be a rule -- I'm just describing how
I'm accustomed to interpreting the existing tags. As we know, the
documentation is imperfect. If there's a better way of doing this,
great! Let's document it.

J

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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jmapb via Tagging]

On 1/11/2020 7:13 PM, Jarek Piórkowski wrote:


On Sat, 11 Jan 2020 at 18:18, Jmapb via Tagging
  wrote:

https://www.openstreetmap.org/way/97010406
- It was originally a vehicle route but was changed to pedestrian with
painted bike and foot lanes. For motor vehicles, only emergency and
specifically permitted delivery traffic is allowed.
- It was *always* one-way, and the one-way signs are still there.
Bicycles and permitted motor vehicles are required to follow the one-way
signs.
- Pedestrians can move in either direction, and this is explicitly
indicated by painted marks in the pedestrian lane. (Thus there's a
oneway:foot=no tag, and it's worth noting that OSRM respects oneway:foot
and routes pedestrians "backwards" but GraphHopper does not.)

That's a good counterexample - thanks.

I was thinking of a somewhat similar example of Stanley Park Seawall
in Vancouver, which is also one-way for cyclists, but is mapped with
separate ways for footway and cycleway. However the Seawall has a
physical separation in form of a small curb between the two modes, so
that's defensible. From Esri imagery it looks like Prospect Park ways
are separated by mode only with paint, so having separate ways for the
modes is not as elegant or arguably correct.

So it looks like we will indeed need a new tag to specify one-way-ness
for pedestrians.


Correct, the Prospect Park drives have paint separating the lanes, but
nothing physical. So mapping separate ways would be unorthodox.

Personally, I have no problem with oneway=yes having different
implications depending on the value of the highway key. In general I
would expect the oneway value to align the predominant use of the
highway in question.

More specifically:

 - I would expect a oneway=yes tag apply to foot traffic on footway.
 - I would also expect a oneway=yes tag to apply to foot traffic on
pedestrian, path, and cycleway -- unless explicitly nullified with a
oneway:foot=no tag.
 - I would not expect a oneway=yes tag to apply to foot traffic on
track, service, unclassified, residential, or any larger roadway, unless
made explicit with a oneway:foot=yes tag.

Of course I understand that from a data consumer's point of view it's
irritating when a tag has different meanings in different contexts --
especially if these differences are not formally documented.

Jason


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

Re: [Tagging] How to tag oneway restriction applying to pedestrians?

[Jmapb via Tagging]

On 1/11/2020 11:16 AM, Jarek Piórkowski wrote:


I imagine that virtually all real-world pedestrian ways that are
one-way for pedestrians would be on dedicated pedestrian ways - that
is, highway=footway. If that's correct, oneway=yes can be interpreted
as referring to pedestrians on footways (it looks like osm-carto
already does this?). I struggle to imagine a one-way pedestrian way
that is also open to bicycle riders (dismount still works in this
scheme). Perhaps the only other thing could be highway=path, where
there could be some ambiguity with bicycles. But at least we can avoid
the "street with sidewalk" interpretation. Does anyone have
counterexamples?


Not sure if it's a counterexample, but here's a hw=pedestrian in a park
in Brooklyn, New York:

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

- It was originally a vehicle route but was changed to pedestrian with
painted bike and foot lanes. For motor vehicles, only emergency and
specifically permitted delivery traffic is allowed.
- It was *always* one-way, and the one-way signs are still there.
Bicycles and permitted motor vehicles are required to follow the one-way
signs.
- Pedestrians can move in either direction, and this is explicitly
indicated by painted marks in the pedestrian lane. (Thus there's a
oneway:foot=no tag, and it's worth noting that OSRM respects oneway:foot
and routes pedestrians "backwards" but GraphHopper does not.)

Jason


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

Re: [Tagging] Feature Proposal - RFC - give box

[Jmapb via Tagging]

On 1/7/2020 7:26 AM, Paul Allen wrote:

And yet the examples you give are shops, or shelves within shops. 
They are
NOT boxes.  On those grounds alone, "give box" is a very bad name.  In
any case,
who is doing the giving to whom?

https://en.wikipedia.org/wiki/Give-away_shop uses the generic term
"give-away
shop" (which I think is too clunky) and has alternatives "freeshop"
and "swap shop."
I think "freeshop" describes it far better than "give box."  I think
"swap shop" is
a sub-category of "freeshop" in that a swap shop requires an exchange, and
whatever we end up calling it we need a subtag to specify whether an
exchange
is required.


From my limited experience (mostly USA), I have the impression that the
majority of these dinguses are boxes or cabinets rather than shops.

Personally I've encountered "hiker boxes" (commonly found in amenities
near hiking trails), free food boxes, free clothing boxes, free art
cabinets (just discovered those last week), and of course the venerable
public bookcase (which has its own tag.) All of these operate on the
give and/or take model -- I've never seen one where a swap is required.

I agree that amenity=reuse is not particularly specific and would be
prone to misinterpretation. But calling a cardboard box in the corner of
a post office "freeshop" doesn't seem right either.

If what's being tagged really is an entire shop, I'd probably prefer to
just use the shop tag, e.g. shop=second_hand + fee=no.

If we're looking for a new all-encompassing tag for things smaller than
an an entire shop, I'd suggest something like amenity=free_goods,
goods=*, goods:location=box/shelf/cabinet. (Would this also be used for
situations where swap is required? It's possible with a bit of troll
tagging, I suppose, like free_goods:swap_only=yes or some other awkward
tag.)

Jason

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

Re: [Tagging] Feature Proposal - RFC - Givebox

[Jmapb via Tagging]

On 1/6/2020 5:41 PM, Markus Peloso wrote:


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

A facility where people drop off and pick up various types of goods in
the sense of free sharing.

Hi

Based on the
https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
 and the
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag
I describe a tag for facilities similar to public bookcases but with
all kinds of (none food) goods.


Hi Markus, why not just "reuse" amenity=reuse? It already has some small
measure of adoption. (Taginfo shows 68 uses.)

J

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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb]

On 12/9/2019 3:43 AM, Peter Elderson wrote:


I have walked many "Camino" sections in Italy. The "checkpoints" are
just stamps, you can get them at many shops, hotels, restaurants,
tourist info points and the like on the way. They will stamp anything
for anyone who asks. There is no register, nothing is checked. I would
not call them checkpoints and I would certainly not attempt to map
them. In Nederland, I don't know about shops, hotels and restaurants.
On the other hand, there are special places like convents and some
churches where pilgrims can stay the night and eat very cheap or free.
They would check and maybe register the pilgrim's passport, I guess.
These points would merit rendering and routing, I think. I don't know
if it helps to tie it to a particular route though. It's a POI passed
by one or more routes. The map can show it, routers can use it and it
can be exported in a gpx or kml.
It's one of those things I would not map unless I can be reasonably
sure it will be maintained and used for actual rendering, routing
and/or export.


Haven't hiked any bits of the Camino myself, so my impressions are
secondhand, but I was told some places -- I think the second type you
mention, the convents etc -- are required checkpoints for official
completion of the route. And to any other passers-by, they're simply a
convent, an inn, whatever amenity they actually are (and of course
should be mapped as such.)

Regardless of whether this is a correct description of the way
checkpoints function on the Camino de Santiago, it's an illustration of
how a checkpoint COULD relate to a particular route but not to another
that shares the same way. So if (big if) we want hiking route relations
to support non-highway members, this is something to consider.

J

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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb]

On 12/8/2019 6:44 PM, Peter Elderson wrote:



Could you envision a node passed by two hikes, and being a checkpoint
for the one and nothing special for the other?


Camino de Santiago ( https://www.openstreetmap.org/relation/153968 )
comes to mind. Hikers doing the whole route carry passports that are
stamped at checkpoints along the way, to document completion of the
route. Hikers not attempting to complete the whole route probably
wouldn't have the passport and wouldn't bother with the checkpoints.

And certainly some of the portions of the Camino de Santiago are also
parts of other routes, eg the sub-sub relation
https://www.openstreetmap.org/relation/3523300 is part of the Camino de
Santiago ( via https://www.openstreetmap.org/relation/138227 ), and is
also part of the European long-distance hiking route E3 -- which as far
as I know doesn't feature a checkpoint system.

Jason


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

Re: [Tagging] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb]

On 12/7/2019 11:52 AM, s8evq wrote:

On Sat, 7 Dec 2019 10:30:37 +1100, Warin <61sundow...@gmail.com> wrote:


For nodes .. think the roles of ways should be done first, but some
thoughts for later proposal/s.

Are they necessary?


In my limited experience mapping hiking routes, I have not yet come across any 
real use for nodes in hiking relations, but I'm curious if other people have 
good uses.
As far as I know, there is also not much documented in the wiki on the topic of 
nodes in hiking/cycling relations.


Possibly for checkpoints?

https://wiki.openstreetmap.org/wiki/Key:checkpoint


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Jmapb via Tagging]

On 12/6/2019 1:28 PM, Janko Mihelić wrote:

I think the "forward" and "backward" don't belong in a role of a
relation. Oneway=yes on a way should be enough. In the Wiki discussion
it is said that if there is one little "oneway" way in a big branch,
then all the ways in a branch should be checked to see if the whole
branch is oneway. But that means we are doing the work of a router
directly in the tags.

We should just mark "oneway" ways as such, and leave the rest to the
routers.


If I recall, there were cases of one-way routes whose constituent ways
were *not* one-way. I can't bring one to mind offhand though.



Also, "main" and "alternative" are orthogonal to "forward" and
"backward". We should then have "main:forward",
"alternative:backward", and so on. That doesn't make sense, and is not
what "role" is traditionally used for. Public transport routes used to
use them, but not in the new scheme.


I think you're correct about the orthogonality but I disagree with the
implication. "forward" and "backward" without a prefix can be presumed
to refer to the main trail. If roles like "alternate:forward" and
"shortcut:backward" prove necessary and useful then mappers will  and
data consumers will use them, but I don't feel they need to be part of
the initial proposal.

Jason


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

Re: [Tagging] Feature Proposal – RFC – notary

[Jmapb]

On 12/3/2019 3:26 PM, Sebastian Martin Dicke wrote:

I often found offices of lawyers, which are notaries, too, and office
sharings of lawyers and notaries. To tag this appropriate, I wrote a
proposal:


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


Definition: Notary services offered by a lawyers office


Hi Sebastian, I've been using service:notary=* (rather than notary=*) to
fit in with the service schema described on the
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcopyshop page. Taginfo
counts 37, which I imagine are mostly mine.

At least in the USA, there's some overlap between the sorts of places
that offer copyshop services and the sorts of places that offer notary
services. Notary services are also commonly found at banks, estate
agents, travel agents, and, as you mentioned, lawyers.

Jason


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

Re: [Tagging] shop selling trucks

[Jmapb]

On 11/16/2019 12:21 PM, Martin Koppenhoefer wrote:


I have found a shop that sells Volvo and Volkswagen commercial
vehicles (large trucks). Looking in the wiki, it suggested the tag
shop=car should/could also be used for this, but I find it puzzling.
How would someone looking at the map understand, that this shop=car,
brand=Volkswagen;Volvo is only selling trucks? Wouldn't it make more
sense to tag these with a different tag. e.g. shop=truck?

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar

Cheers,
Martin


Hi Martin, we have shop=hgv documented for this. It's rarely used but I
say go for it!

https://wiki.openstreetmap.org/wiki/Hgv#shop.3Dhgv

Jason





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

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

[Jmapb via Tagging]

On 11/7/2019 2:09 PM, Mark Wagner wrote:

On Thu, 7 Nov 2019 10:26:14 +
marc marc  wrote:


ere possession of a bicycle is forbidden
can you share the a picture of this traffic sign ?


It's a sign for a state natural area rather than a federal wilderness
area, and the situation is a little fuzzy on walking bicycles (it
depends on what "operate" means), but the sign, if present, might
look something like this: https://imgur.com/4qOuNmf

It's also possible that the sign would simply be something like
"entering Wenaha-Tucannon Wilderness" with a standard "no bicycles"
symbol, with "no bicycles" being understood to mean "no possession of
bicycles" rather than "no riding bicycles".


This is a typical US wilderness area
sign:https://i.imgur.com/7YQOhgIl.jpg 

Here's a pictographic variation: https://i.imgur.com/K5afLpOl.jpg

In neither case is the ride/push distinction called out. But if forest
rangers see me with a bike, telling them "I was just pushing it" isn't
going to prevent a hefty fine.

Depending on where you enter a park or wilderness area, you may or may
not pass an info board like this, with more explicit details about
regulations: https://i.imgur.com/uYQg0DPl.jpg

Possibly there would be a specific prohibition of
pushing/carrying/possession of bicycles somewhere in there. But even
without these detailed rules, if I saw any kind of "no bicycle" rule or
sign, I would infer that dismounted pushing was also prohibited.

J

___
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"?

[Jmapb via Tagging]

On 11/6/2019 3:08 AM, Mateusz Konieczny wrote:

bicycle_pushed=no?

bicycle_pushed is more clear for someone encountering it
for the first time - bicycle=total_ban is a bit confusing

Especially as in some places access for bicycles
may be "never" (explicit "no bicycle" signs)
or "only during extreme weather" (one of cases
when it is legal to cycle on sidewalks in Poland).
First case should be tagged as bicycle=no, not bicycle=total_ban.

Also, it may be OK to carry bicycle in a box and not OK
to push (not road access, but in some train you are not allowed to
enter with bicycle,
bit once bicycle is in a box this is considered as entirely fine)


Maybe I'm missing something here but I don't see any reason why data
consumers, including the bicycle modes of routing engines, should ever
interpret bicycle=no in a way that permits walking bicycles. This is
exactly why we have a bicycle=dismount tag.

Carrying a bicycle is an edge case that might deserve its own value --
bicycle=carried works for me. And if we need further refined values to
explicitly permit a folding bike or bike-in-a-box, no problem:
bicycle=folded, bicycle=boxed.

(Special permission for extreme weather should be encoded with some
variation of the conditional access tag scheme.)

Jason


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

Re: [Tagging] Hunting stands, bird and wildlife hides

[Jmapb via Tagging]

On 10/22/2019 10:36 AM, Ilya Zverev wrote:

I understand the reasoning, but I don’t see how can I follow the
“truth on the ground” principle. Are there any guidelines on choosing
the correct tag? For some reason people don’t write its purpose on a
side. And again, images in three of these pages are the same.


My suggestion:

- Does you believe it's for hunting? Tag amenity=hunting_stand (almost
1000 times more popular than hunting=raised_hide).
- Do you believe it's primarily for bird watching? Tag leisure=bird_hide.
- Neither of the above but it still appears to be for watching wildlife?
Tag leisure=wildlife_hide.
- It's a tower but you're not sure what it's for? Tag man_made=tower and
optionally tower:type=observation/whatever your best guess is. (You can
also add tower tags to any of the tags above, if you think it's a good fit.)
- It's not a tower and you're not sure what it's for? Tag
building=yes/hut/shed/cabin/whatever.

J


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

Re: [Tagging] Amenity=Gambling & adult_gaming_center tagging conflict

[Jmapb via Tagging]

On 10/17/2019 1:01 AM, John Willis via Tagging wrote:

Also, how do you specify which games are offered? gambling=pachinko is
in the wiki, but what about adult_gaming_centre? is gambling=* the
default way to define what games are offered at such facilities? that
seems to be vague or missing.


https://wiki.openstreetmap.org/wiki/Key:gambling is pretty clear about
this -- use gambling=* for describing the gambling options at any sort
of map feature, most commonly leisure=adult_gaming_centre,
amenity=casino, and
amenity=gambling.

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

Re: [Tagging] theme it is for me then | Re: How to map Irish pubs?

[Jmapb]

On 10/14/2019 6:07 PM, Martin Koppenhoefer wrote:


There are in some areas pubs that would merit a brand tag (maybe it is
generally common), they have the beer logo aside their name on the
sign, beer mats, menus, glasses , sunshades, everything can be branded
(it could happen they’re “recycling” material like glasses or beer
mats from a different brand, but usually you would get the beer on the
sign as draft beer). For example in Berlin, there are the infamous
“Schultheis-Eckkneipe”n
https://eckkneipen.files.wordpress.com/2011/04/zur_gemuetlichen_ecke_ansicht.jpg?w=614&h=410

or Berliner Kindl
https://upload.wikimedia.org/wikipedia/commons/5/51/Eckkneipe_in_Berlin-Kreuzberg%2C_2009.jpg

these places do not change brand frequently, and verifiability in
Germany is typically quite good (means the signs are big ;) )


My understanding is that this was the original purpose of the "brewery"
key -- to specify the brewery associated with a particular
establishment. It's drifted from that purpose ("brewery=yes" is the most
popular value by an order of magnitude) but I still feel it's a better
fit for this purpose than "brand".

J


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

Re: [Tagging] How to map Irish pubs?

[Jmapb via Tagging]

On 10/8/2019 6:20 PM, Graeme Fitzpatrick wrote:



I was wondering about the same thing, because you've then also got
Country & Western, German, any & all varieties of Gay ... ?

Bit of an awkward one, but there are pub's in Northern & Inland
Australia that white people are NOT welcome in (& I'm absolutely
certain that the same thing, & reverse, applies in many places). Is
that something that we could / should list against OSM pubs?


Other common themes are Polynesian (tiki bar), speakeasy, surfing,
medical... plenty more out there I imagine. There's one bar in NYC
that's themed around smashing appliances with bats.

For gay bars there's a well-established `lgbtq=*` key.

Personally I wouldn't consider ethnic restrictions to be a "theme."
Certainly a tagging scheme to codify the world's various local ethnic
restrictions could be developed, but the topic leaves a bad taste in my
mouth so I'm not inclined to make suggestions.

Jason

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

Re: [Tagging] How to map Irish pubs?

[Jmapb]

On 10/8/2019 4:37 PM, Rory McCann wrote:

What's the best way to tag an Irish pub? Not just a pub in Ireland, but
a specifically themed "Irish Pub" (which are usually outside Ireland)?

There's ~300 instances of `cuisine=irish`, which would make total sense
for places which (also) serve food. Traditionally pubs in Ireland would
rarely serve food. Calling Tayto's “cuisine” is a stretch, and using the
`cuisine` tag seems weird for a bar/pub that doesn't serve any food.

I've used `theme=irish` once or twice. But I don't think anyone else
does, and it's not supported. This might be related to mapping “sports
bars” or other themed bars. In theory the `theme` of a restaurant/bar
could be different from the `cuisine` of any food/drink it serves, so it
might make sense to tag this difference.

Thoughts?


Hi Rory -- I've mapped plenty of "Irish" pubs, mainly in NYC. It's never
occurred to me that they need to be tagged as Irish -- but now I find
myself wondering "How many Irish pubs have I mapped?" and because
there's no tag for it, I have no way to query for it!

I generally use `cuisine=pub` if they serve typical pub fare, which most
here do. I don't tend to see much difference between the food served at
a nominally Irish pub and a nominally English pub. For a place that only
serves packaged food like crisps, I'd usually tag `cuisine=snack`.

I think the idea of `theme=irish` makes some sense, and in fact there
are many other themed amenities that could be tagged with a `theme=*`
key. It's uncommon now, but if it becomes popular it might be picked up
by software. Until then, of course, it will only be noticed by users who
write queries or manually inspect the tags.

In the mean time you can try something simple like `description=Irish
pub` or even `description=Irish pub with Guinness, Smithwick's, and
Tayto's`.

Happy mapping, Jason


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

Re: [Tagging] "not:brand" to mark a shop that isn't part of a chain?

[Jmapb via Tagging]

On 9/14/2019 10:53 AM, Tim Magee wrote:

I would absolutely agree with this use case. Especially for cases such as the
regularly mentioned Burger King. If somebody from out of town is either
traveling through or armchair mapping they could be confused. If they are
using the ID editor, it suggests that you "upgrade the tags" which could lead
to a "Burger King" that is not part of the international Burger King tag
having the same brand:wikidata tag.


Personally I have a problem with the asymmetry of work that this
requires from mappers who need to protect their work from iD versus
mappers who blindly "upgrade" using iD.

The first mapper has to 1) be familiar with all possible brands (Burger
King is a brand most mappers know, but take a look at all the brands in
this list:
https://github.com/osmlab/name-suggestion-index/blob/master/brands/amenity/fast_food.json
...and that's just the fast food!) 2) recognize when a feature might
have a brand conflict 3) look up the brand in question and 4) correctly
tag the "not:" prefix for brand in question. The second mapper simply
has to hit the "upgrade" button when prompted.

I certainly have no problem with the idea that iD and other editors
would respect the "not:brand" tag when applying brand info to a feature.
But I'm not buying the idea that these "not:" tags are the solution to
the increasing problem of brand tags being incorrectly applied by iD
(sometimes along with incorrect corrections to name, cuisine, etc.)

The simple truth is that automatically adding these brand tags is a
mechanical bot edit, and the fact that the bot in question is triggered
by a user clicking an ambiguous "upgrade" button doesn't change that.
These edits should be subject to peer review here on the tagging list,
and the iD branding bot should behave according to the automated edits
code of conduct. Yes, this is slower, but it's the right way. Putting
the onus on the original correct mapper to prevent iD's incorrect tags
seems backward.

Jason



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

Re: [Tagging] Designated spots for dogs to wait

[Jmapb via Tagging]

On 8/20/2019 4:57 AM, Andrew Davidson wrote:

On 20/8/19 6:24 pm, John Willis via Tagging wrote:

     So let's standardize on a tag:


amenity=hitching_post
hitching_post=dog ?



Interestingly, one of the items they sell is a green 30x30cm marker
to go on the sidewalk in front of the pole - literally a sign for the
designated spot for dogs to wait.


Japanese dogs must be pretty cluey ;-)


Sounds like this one literally is a hitching post, so
amenity=hitching_post would be fine. But ideally IMO we'd want something
described by function more than form, so people wouldn't feel like the
need to invent a new tag for each style. (A ring, a doghouse, a
designated indoor room, a fenced pen...)

Actually, this reminds me of bicycle parking more than anything else...
so amenity=animal_parking? Adding animal=dog (horse, camel, whatever)
would mesh well with the existing use of the animal=* tag.

J


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

Re: [Tagging] key educational

[Jmapb via Tagging]

On 8/16/2019 10:56 PM, Warin wrote:

I think the key:educational maybe better used later for schools,
colleges, cram schools etc.


The (dormant) proposal for these was
education=school|university|tutor|cram_school etc.

https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative

I do feel that having "educational" as a key would inevitably lead to
confusion, if these education=* tags ever become accepted and used
(which I personally hope they do.)

J


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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Jmapb via Tagging]

On 8/16/2019 4:59 PM, Kevin Kenny wrote:

a long route may go through several colour changes but will be signed
with its own marker at principal junctions. (Where I map, there are
only a handful of long-distance routes affected by this: the Long
Path, the Highlands Trail, the Finger Lakes Trail, and the North
Country Trail. Other long trails exist and are blazed consistently:
for example, the Northville-Placid Trail and Shawangunk Ridge Trail
are blue for their entire length, and the Appalachian Trail carries
its distinctive rectangular white blazes.)


For the Long Path, certainly I feel the master route and sub-routes
should be tagged aqua (or 80FECE) even though huge portions of the trail
are blazed differently, mainly through the Catskill Park. (The SRT, to
my memory, also has a bit of variation, especially in Minnewaska.)

The European long-distance trails (E1-E12) I've been on are even moreso:
Mainly composed of existing trails and using the existing local blazes,
only mentioned by name at principal junctions -- and even there may or
may not be indicated in their official colour. Though they did seem to
have an official colour sometimes, occasionally. I can't find any master
reference, but I think I remember E10 and E11 being blue, and E8 being
red. Checking out the route relations (wow these are some big
relations!) it looks like they eschew the colour tag and prefer "symbol"
and "osmc:symbol".

(Note that the map at
https://upload.wikimedia.org/wikipedia/commons/c/c8/Map_of_the_European_Long_Distance_Paths.png
shows a distinct color for each trail but I don't think these colors
have any basis on the ground.)

J


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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Jmapb via Tagging]

On 8/16/2019 2:40 PM, s8evq wrote:

The table with the tagging scheme for the hiking/foot routes is getting there: 
https://wiki.openstreetmap.org/wiki/Tagging_scheme_hiking_walking Just a few 
more small things that need to be decided on.


Hi s8evq, nice progress! Just gonna prattle about colour some more...

 - I like the way you phrased "the major colour" of the route symbol;
it will give some guidance on how to tag a route marked by, for example,
the European-style white/yellow/white blaze pictured on the current
Walking Routes page. I've definitely seen trail routes tagged with
multiple colours but that's probably less helpful than just using
"yellow" for the colour in cases like this. (Of course there's also the
"symbol" key for a textual description, and the "osmc:symbol" syntax is
capable of describing a yellow bar on a white background and many other
variations.)

 - Speaking of "yellow", the table specifies that colour should be a
hex triplet, but wiki page for the colour key indicates that named HTML
colours are also acceptable values. And I know many trails are tagged
this way. So probably the new scheme should allow these too?

Jason


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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

[Jmapb via Tagging]

On 8/15/2019 10:11 AM, Martin Koppenhoefer wrote:


Anyway, just a property like "service:bicycle:repair=yes" and a name would not 
work, IMHO


No indeed, I wouldn't recommend it as a stand-alone feature tag. But as
extra tag to a shop or amenity, it think it would help.

Also note that for self-service bike repair we have
"amenity=bicycle_repair_station" -- presumably not the best tag for this
community centre bike repair service (it sounds like volunteers do the
repair work, not the user) but worth mentioning.

By the way, I'm wrong about the history of service:bicycle:* -- it was
discussed and voted on in 2011, approved, and documented in the wiki
under the shop=bicycle page. I must be mis-remembering some other
controversy.

https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

J


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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

[Jmapb via Tagging]

On 8/14/2019 6:45 PM, dcapillae wrote:


Obviusly, «amenity=community_centre»


Sounds correct.

For anything that's not a bicycle shop but still does bicycle repairs
(I've seen cafes, car repair shops, outdoor shops, and even a church
with this service), consider just adding the
"service:bicycle:repair=yes" tag.

The "service:bicycle:*=*" syntax was invent by iD (last year maybe?) and
gets populated when you add a service to a bicycle shop through iD's
"all fields" sidebar. It was controversial at the time (because it's
wordy and was introduced ex cathedra, not discussed beforehand on the
mailing list or wiki) but has nonetheless become popular. As long as
we're using it, no reason it should be restricted only to "shop=bicycle"
IMO.

As far as the fee goes, if *nothing* at the feature in question costs
money, then "fee=no" seems good, otherwise I suppose I'd go with
"service:bicycle:repair:fee=no" (yech!)

Jason


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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Jmapb via Tagging]

On 8/13/2019 4:50 AM, s8evq wrote:


Currently, there are four tagging scheme tables describing how walking (or 
hiking) routes should be tagged.
https://wiki.openstreetmap.org/wiki/Hiking
https://wiki.openstreetmap.org/wiki/Walking_Routes
https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking
https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot


Hi s8evq, I'm withholding judgement for now on the larger question of
combining these, but one comment: All four of these tables describe
'colour' as "especially useful for public transport routes" which isn't
particular relevant to this topic IMO. Maybe "useful for trails blazed
with a specific colour"?

Thanks, Jason


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

Re: [Tagging] Classifying roads from Trunk to Tertiary and Unclassified

[Jmapb via Tagging]

On 8/13/2019 12:14 PM, Kevin Kenny wrote:

Alas, we can't do what Google Maps does, and aggregate the private
information of everyone carrying a cell phone to measure current
traffic speeds. That appears to be how Google's router makes its
decisions.


Of course we used to have something along those lines with Strava RIP.

Smaller-scale but still useful -- The rideshare company Juno, which uses
OSM data for both routing and map display, shares a rolling aggregate of
their GPS traces which can be enabled as a layer in JOSM. No doubt it
could be algorithmically cross-reference with road classification; I've
just been inspecting it visually. Juno only operates in NYC for now, and
the data has clear demographic limitations (it shows which roads are
priorities for the kind of people who either work for or use rideshare
services). But it actually covers the city's grid pretty well, and I've
found it useful.

(See
https://lists.openstreetmap.org/pipermail/talk/2019-March/082303.html
...also there were a couple Maproulette challenge using this data to
spot incorrect one-ways, bad turn restrictions, missing connections,
etc, see
https://lists.openstreetmap.org/pipermail/talk-us/2019-February/019210.html
https://lists.openstreetmap.org/pipermail/talk-us/2019-February/019224.html
)

Note that this didn't require a bunch of end-user data consumers to
install an app which shares their location data with OSM. Obviously
Juno's customers do install the Juno app, but the shared data comes from
the driver's app, not the rider's.

Also note that Juno's decision to share back to OSM in this way was
entirely optional -- I don't think any reasonable interpretation of the
ODbL would actually require this. Nonetheless it's a nice precedent, and
if other companies that consume OSM data chose to give back in this way
it would help.

(Of course the trigger for this whole process was the fact that OSM's
road and address data in NYC was good enough that it was  a reasonable
decision to use it in a business setting!)

Jason


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

Re: [Tagging] Tagging of bullrings

[Jmapb]

On 8/4/2019 7:09 PM, dcapillae wrote

I have asked the OSM community in Spain and it seems that some mapper prefer
"building=bullring" instead of "building=stadium". I think the right tag is
"building=stadium" because we use this tag for stadiums, no matter what type
of stadium they are, and a bullring is a stadium. However, I guess there's
not much difference.


The question as I see it is: When you look at the building in question,
do you think "this building looks like a bullring" or do you think "this
building looks like a stadium, and bullfighting is the primary sport here"?

I don't know if there's a distinct style of traditional bullring
architecture, but if there is, then building=bullring makes sense for
those. (And in fact such buildings might still be tagged
building=bullring even if bullfighting no longer happens there.)

Furthermore, if a more generic-looking stadium were built that was not
in the distinctive bullring style, but was still primary used for
bullfights, then building=stadium might be a better choice for that one.

J


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

Re: [Tagging] Tagging of bullrings

[Jmapb]

On 7/31/2019 1:19 PM, dcapillae wrote:


leisure=stadium
sport=bullfighting (in use)


Hi Daniel -- definitely this one: leisure=stadium + sport=bullfighting. 
You might also want to use the building=stadium tag, if the stadium
occupies the entire building in question (assuming it's in a building --
I'm guessing they all are but I'm not too familiar with bullfighting
stadia.)

Jason


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