Re: [Tagging] shop=cannabis including medical cannabis

[Jmapb via Tagging]

On 6/14/2019 5:33 PM, Dave Swarthout wrote:


Martin wrote:

>It would imply adding shop=cannabis to pharmacies? In some countries
the sale of medicine is restricted to pharmacies.

Not necessarily. IMO, we could also use the cannabis:medical=yes/only
tag to pharmacies offering it.


Yes, my understanding is that shop=cannabis is only for shops whose sole
purpose (or at least clear primary purpose) is the sale of cannabis. It
shouldn't automatically be added to any POI where legal cannabis is
available.

A pharmacy that sells a variety of medicines should not be tagged as
shop=cannabis, but could still be tagged with cannabis:*=* (similar to
drink:wine=yes at shop=deli.)

IMO the shop=cannabis tag should not be used at all in any jurisdiction
where legal cannabis is only available through general purpose
pharmacies. (I don't know of any such places, but I assume they exist
somewhere, or will at some point.) And obviously it also shouldn't be
used in jurisdictions where all cannabis sales are illegal.

J


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

Re: [Tagging] shop=cannabis including medical cannabis

[Jmapb via Tagging]

It is done. Interested parties, please see
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcannabis and comment here
or there. I'll be watching the discussion page. J

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

Re: [Tagging] Designated spots for dogs to wait

[Jmapb via Tagging]

On 6/18/2019 10:14 AM, Paul Allen wrote:


Are there any objections to man_made=hitching_point? I think it
will be a little used item.


You're probably right there.  Not much call for it.  And unlikely to
be rendered until we get vector
carto, and maybe not even then.  But, analogously to Internet Rule 34
(if it exists, there is porn
of it, no exceptions): if it exists, somebody will want to map it.  So
let's standardize on a tag: to
reduce the number of people creating ad hoc tags for it and to avoid
somebody inventing a silly
tag like landuse=dog_corral or tourism=dog_loop.


Naturally Brooklyn NY has to come to come along and complicate things:

https://hellodogspot.com
https://pix11.com/2017/05/24/rentable-dog-houses-brooklyn-dog-parker/

Why tie your dog to a hook for free when instead you could pay for a
private climate-controlled doghouse on the sidewalk, complete with a
smartphone app that locks the door and shows you the doghouse webcam?

I don't think any of these are mapped yet (in fact I think this
company's in decline because I used to see these all over and no longer
do). I wouldn't want to tag these as "hitching_point" because there's no
hitch. I might have been inclined to shoehorn them into
amenity=animal_boarding, but it since they fill the same need at the
hitching points I wonder if there should be a tag that could apply to
both of these items.

Jason

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Jmapb via Tagging]

On 7/2/2019 8:20 AM, marc marc wrote:


Le 02.07.19 à 13:38, Joseph Eisenberg a écrit :

There are two similar property tags that describe the presence of a
barbecue (BBQ) grill at another feature such as a campsite or picnic
site.

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

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

If you check taghistory.raifer.tech it's clear that
barbecue_grill=yes/no is older and still slightly more common, but
bbq=yes/no is becoming more common in the past 2 years.

The similar feature tag is amenity=bbq


Is there a reason to pick one of these two tags over the other?

I like having the same string between the main tag for the device
and the key for the caracteristic of a site having this device.
so imho bbq=yes is better


Certainly tagging foo=yes to indicate that amenity=foo exists as part of
another feature is standard practice in many cases (atm, toilets, bar
being the most prominent).

Nonetheless I think bbq=yes is ambiguous. To me, the most natural
interpretation of bbq=* is to indicate whether barbecuing is permitted,
rather than to specify the presence or absence of an on-site bbq apparatus.

Consider the situation brought up in this thread last month:

https://lists.openstreetmap.org/pipermail/tagging/2019-June/046064.html

The question was: how to tag a feature where barbecuing is permitted,
but no fixed bbq grill exists? The best suggestion was
bring_own_bbq=yes. But the combination of bbq=no and bring_own_bbq=yes
seems contradictory. Despite the inconsistent spelling,
barbecue_grill=no + bring_own_bbq=yes makes more sense... slightly more.

I'm afraid the possibilities are complex enough that I'd actually
suggest using a bbq:* namespace, ie:

bbq=yes
bbq:grills=yes/no/1+
bbq:bring_own=yes/no

There's the issue of redefining bbq=yes, which has 219 uses... but those
219 uses are already ambiguous IMO -- the only thing I know for sure is
that barbecuing is permitted there. So I don't actually think this is a
redefinition, just a clarification.

(These subtags could also be used to clarify amenity=bbq, which
according to Joseph Eisenberg at
https://lists.openstreetmap.org/pipermail/tagging/2019-June/046072.html
is already ambiguous on the German version of the wiki, covering both
the grill itself and the area where grilling is allowed.)

Jason


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

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[Jmapb via Tagging]

On 7/5/2019 2:16 AM, Joseph Eisenberg wrote:

So, what's a better term for a test prep centre, cramp school, or
tutoring office? There the rarely used tag office=tutoring, but that
doesn't quite cover a place like Kaplan or Kumon -
https://au.kumonglobal.com/ - https://www.kaptest.com/

amenity=test_prep
amenity=cram_school
office=test_prep
amenity=tutoring

Other options?


See previous discussions this year:

https://lists.openstreetmap.org/pipermail/tagging/2019-January/042561.html
https://lists.openstreetmap.org/pipermail/tagging/2019-February/042983.html
https://lists.openstreetmap.org/pipermail/tagging/2019-March/043617.html
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045457.html

J

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

Re: [Tagging] one feature one element

[Jmapb via Tagging]

On 7/4/2019 11:17 PM, Joseph Eisenberg wrote:

We've also had problems with features tagged "tourism=camp_site" or
"landuse=meadow" plus "barrier=hedge" or "barrier=wall". Is the
barrier supposed to be an area or a linear feature in this case?

I can see the confusion here, but I think this rule still holds:
Normally linear features like barrier and highway will only be
interpreted as areas if tagged with area=yes. The presence of other tags
which imply area is not the same as area=yes.

But it's true that this usage verges on breaking the
one-feature-one-element rule -- unless you think of "fenced camp site"
as a single feature, which is a bit of a stretch.

Regardless, it's quite common to indicate a barrier around a 2D way by
tagging it with barrier=. I don't think it's genuinely ambiguous so I
doubt that it's going away any time soon, barring editor and bot
intervention. (I used to see fenced=yes... but only on pretty old
changesets.)


So I'd like to add a line that recommends to avoid mapping two
different "feature" tags on the same database object.


Which exactly are the "feature" tags? Everything on
https://wiki.openstreetmap.org/wiki/Map_Features ? Obviously building=
shouldn't be included, as it's often combined with other features. I see
cycleway= combined with highway= all the time. Same with sport= and
leisure=, tourism= and historic=. There are many other examples of
commonly used tag combinations, I'm sure.

If you want to try writing a narrower list of "top-level" keys that
should be mutually exclusive, give it a shot -- but I think that's going
to be a short list once we run through it and find all the useful
exceptions.

More likely to work would be: For certain keys, a list of other keys
that should not be used in combination. This list could appear as part
of each section on https://wiki.openstreetmap.org/wiki/Map_Features, or
as its own section on the https://wiki.openstreetmap.org/wiki/Key:*
pages. It might still be difficult to get consensus on these in many cases.

Jason


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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Jmapb via Tagging]

On 7/5/2019 10:56 AM, Joseph Eisenberg wrote:

I don't think it would be necessary to combine "bbq=no" and
"bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
most tags with value "no", can be omitted.


This is true. A better phrasing of the problem would be bbq=yes combined
with bring_own_bbq=yes. Does bbq=yes imply static bbq equipment, or just
permission to bbq that's further refined by the bring_own_bbq=yes tag?

In my mind, the *only* reason bbq=yes would mean the presence of a grill
is by echoing the amenity=atm/atm=yes pattern. But I don't think that
pattern works particularly well in this case. And as you pointed out in
your translation of the German wiki page, even amenity=bbq is already
used both ways, for equipment and permission: "One distinguishes between
free barbecue areas, where you have to take care of the grill yourself
and fixed barbecue areas with existing grill..." -- but there's no
indicating of *how* one distinguishes between the two. Obviously at one
point we didn't care to tag the difference, but now that we do, I don't
see any clear way of tagging all three possibilities
(grill/byo-grill/both) using the current tags.

Jason


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

Re: [Tagging] shared planter where you can harvest for free

[Jmapb via Tagging]

On 7/5/2019 12:18 PM, joost schouppe wrote:


Operator is actually "a specific private citizen"


What's the source of this definition? On the English wiki, operator is
"a company, corporation, person or any other entity who is directly in
charge of the current operation of a map object."

J


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

Re: [Tagging] shared planter where you can harvest for free

[Jmapb via Tagging]

On 7/5/2019 3:08 PM, Paul Allen wrote:


I read joost's comment as "The operator of this map object is a
specific private citizen"
not as a redefinition of "operator."


Hah, probably. Regardless, I do think that Les Incroyables
Comestibles/Incredible Edibles fits better under the brand key, or maybe
network, than operator -- because it sounds like the organization simply
organizes, and does not actually do the upkeep.

Anyway, my suggestion for these free produce spots would be
amenity=public_produce, similar to amenity=public_bookcase.

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

[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