Re: [Tagging] Default Language Format; language:default or default:language?

[Graeme Fitzpatrick]

On Tue, 2 Oct 2018 at 11:17, Joseph Eisenberg 
wrote:

>
> *TL:DR -* the language of a Brand names cannot always be determined (but
> in this case it's English).
> Usualy the most common language in the region will be used for invented
> shop & restaurant brand names,
>

That's something that I've been wondering about during this discussion of
how names would appear & so on.

As a real common example, you have McDonalds all (or virtually) over the
world, so how does the name appear on OSM maps in non-English speaking
countries?

I know that if I use OSM from Australia & go to other countries, then their
map appears in the local language. So if I go to eg Thailand or Cambodia,
https://www.openstreetmap.org/#map=7/16.810/97.405, can I still search OSM
for "McDonalds", or do I have to search for some squiggly hieroglyphics?
(With no offence intended to any Thais or Cambodians!)

Thanks

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Joseph Eisenberg]

You are supposed to be able to get all that information by using a closed
way for the boundary of the RV park. Then all the other features are
contained within that boundary.

On Tue, Oct 2, 2018 at 12:16 PM Paul Johnson  wrote:

>
>
> On Mon, Oct 1, 2018 at 12:13 PM Mateusz Konieczny 
> wrote:
>
>> 1. Oct 2018 10:18 by dieterdre...@gmail.com:
>>
>> site
>>
>>
>> This relation type is a horrible mistake and should not be encouraged by
>> editors
>>
> Care to expand?
>
>> - this data is basically not usable.
>>
> Sure it is.  Say I want to know what amenities an RV park has in another
> city...you could go  "hey, what does Somewhereville RV Park have?" or just
> throw Somewhereville RV Park and get a list of everything that belongs to
> the same site.  Dump station, fuel pump, convenience store, information
> stand, mailboxes, laundry, showers, toilets...regardless of whether or not
> these things are named or not, or even share the same name as the RV park
> itself.  Like, say, "Old Faceful Geyser" (actually a splashpad) in the
> "Jellystone Park" RV park at Lake Eufaula (to use something I might try if
> I was taking my boyfriend and niece truck camping and wasn't actually
> familiar with this being a delightfully furry, yet corny, and relatively
> comfortable for cheap truck-tent camping).
> ___
> 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] My "weirdly unnatural aversion to relations"

[Marc Gemis]

Jochen Topf briefly mentions some problems with relations in his
latest SOTM 2018 talk: https://www.youtube.com/watch?v=rbxabz22ni4

According to him, it's the diversity of the relations without decent
support from the OSM-model makes it hard for data-consumers to process
them. The rest of the talk is mainly about changing the nodes in ways
model, though.

As for site relations, besides Yves, there is also the historic.place
map that does something with the site-relation.

regards

m
On Tue, Oct 2, 2018 at 5:16 AM Paul Johnson  wrote:
>
>
>
> On Mon, Oct 1, 2018 at 12:13 PM Mateusz Konieczny  
> wrote:
>>
>> 1. Oct 2018 10:18 by dieterdre...@gmail.com:
>>
>> site
>>
>>
>> This relation type is a horrible mistake and should not be encouraged by 
>> editors
>
> Care to expand?
>>
>> - this data is basically not usable.
>
> Sure it is.  Say I want to know what amenities an RV park has in another 
> city...you could go  "hey, what does Somewhereville RV Park have?" or just 
> throw Somewhereville RV Park and get a list of everything that belongs to the 
> same site.  Dump station, fuel pump, convenience store, information stand, 
> mailboxes, laundry, showers, toilets...regardless of whether or not these 
> things are named or not, or even share the same name as the RV park itself.  
> Like, say, "Old Faceful Geyser" (actually a splashpad) in the "Jellystone 
> Park" RV park at Lake Eufaula (to use something I might try if I was taking 
> my boyfriend and niece truck camping and wasn't actually familiar with this 
> being a delightfully furry, yet corny, and relatively comfortable for cheap 
> truck-tent camping).
> ___
> 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] My "weirdly unnatural aversion to relations"

[Paul Johnson]

On Mon, Oct 1, 2018 at 12:13 PM Mateusz Konieczny 
wrote:

> 1. Oct 2018 10:18 by dieterdre...@gmail.com:
>
> site
>
>
> This relation type is a horrible mistake and should not be encouraged by
> editors
>
Care to expand?

> - this data is basically not usable.
>
Sure it is.  Say I want to know what amenities an RV park has in another
city...you could go  "hey, what does Somewhereville RV Park have?" or just
throw Somewhereville RV Park and get a list of everything that belongs to
the same site.  Dump station, fuel pump, convenience store, information
stand, mailboxes, laundry, showers, toilets...regardless of whether or not
these things are named or not, or even share the same name as the RV park
itself.  Like, say, "Old Faceful Geyser" (actually a splashpad) in the
"Jellystone Park" RV park at Lake Eufaula (to use something I might try if
I was taking my boyfriend and niece truck camping and wasn't actually
familiar with this being a delightfully furry, yet corny, and relatively
comfortable for cheap truck-tent camping).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Paul Johnson]

On Sun, Sep 30, 2018 at 4:32 AM Frederik Ramm  wrote:

> The idea that turn restrictions are "super critical" but public
> transport relations are not is valid, but subjective; I hope that, as
> the ID editor matures, it will attract a healthy and diverse team of
> main developers so that decisions about what is important and what isn't
> are not a single person's any more!


I had the same thought, adding "Do these devs just like, never travel
without their own vehicle?  Never been to a strange city, possibly in a
different country, with no car or bicycle, and try to make sense of
things?"  Maybe I'm weird.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Mon, Oct 1, 2018 at 4:24 PM yo paseopor  wrote:

>  > ^ This is the problem.  The wiki says we are supposed to do something
>> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
>> needs to be based on a "toplevel" tag like `traffic_sign=*` not
>> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
>> many of their tags have this issue too, where they put a value in the key
>> part, and so we can’t turn it into a preset).
>>
>
>  JOSM can do this change (when you change a way) as you can see on
> https://i.imgur.com/NnLpKWR.jpg
>  If you read taginfo you can find for forward subtags
> https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
> nodes. If you read taginfo for backward
> https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
> than 80 nodes. Are you saying iD doesn't recognise all these tags with
> forward and backward subtags?
>  I give you a solution: make two presets: one for traffic_sign:backward
> and other with the same values for traffic_sign:forward.
>

This brings up another issue i have with this forward/backward scheme.
Most traffic_signs are tagged where they stand.  They're not a member of a
way, just adjacent.  What now?


> > Describing what a driver might see when approaching a turn would be an
>> effective use of traffic_sign, but 'node near the way' is pretty useless
>> for routing. For maximal detail you'd need both, but if you're only going
>> to add one, the highway=stop is far more useful.
>>
>
> Best approach is to have the traffic sign "inside" the way because the
> traffic sign is relative to the way. If the way doesn't exist, traffic sign
> is useless, so it is better to map it as a node on the way. Also then you
> have the direction of the way to make relative the traffic sign to the
> direction of driving.
>

This makes sense for on-the-pavement markings, but doesn't really work for
way-adjacent objects.  See also: Why transit tagging is quite complex.


> > OSMand also warns of traffic calming, toll barriers, level crossing,
>> pedestrian crossings and enforcement cameras.
>>
>
> OsmAnd can show some traffic signs in certain moments or resolutions or
> guiding, as they do with maxspeed info.
>

And, weirdly, for tunnels (apparently just plain pulling a sign out of it's
butt for this, too, instead of using the regionally standard sign on
screen), even though it's bloody obvious that you're about to head into a
tunnel (of which there's like, 5 highway tunnels statewide for me, 4 of
which are newly open this month).  But not rumble strips, even though those
can be a critical hazard and are not easy to see before you hit them here.
Yes, this really bothers me because not having a warning in advance on
these invisible things is a bad thing consider that they're often brutal
enough to present the same hazard potential as a cattle grid to cyclists,
motorcycles and really light cars (in my pickup, not so much of an issue,
but still practically heart-attack inducing like a jumpscare out of
nowhere).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Sat, Sep 29, 2018 at 8:41 PM Kevin Kenny  wrote:

> On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson  wrote:
> > I'm still against using forward/backward on nodes, it really feels like
> a hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because a way reversed, and handle more complex situations like "right
> turn permitted without stopping" sign below a "stop" sign, or allow a data
> consumer to be able to display a diagram indicating which ways a stop
> applies to (handy if you encounter, say, a six way intersection with a four
> way stop).
> >
> > I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>
> I agree with you that we need to design relations for the complex
> cases such as what you describe, but I've no problem with the 'hacky'
> approach as well - on the principle of 'make simple things easy and
> complex things possible'. JOSM (and from what I understand, iD, but I
> rarely use it) handles directional nodes on ways fairly competently,
> detecting that the mapper is reversing a way that has such nodes
> attached and asking what to do about them.
>

It still feels a bit brittle, especially if the data consumer is assuming
(correctly) that nodes by themselves lack a direction.  Which is fine when
the traffic control applies to all possible ways and approaches connected
to a node.  A relation does explicitly define how it applies, however, by
defining which nodes are affecting which ways and how without having to
make a lot of assumptions.


> As far as the aversion to relations goes, I think a big part of it is
> simply that the downstream support just isn't there.  The tools do
> multipolygons fairly well, but that is the only relation that is
> really handled well. A bit part of that is that once OSM data has been
> through a stock osm2pgsql, there are no relations any more.
> Multipolygons become first class objects, and all other relations are
> handled at best by devolving their tags upon their components.
>
> (The rest of this message is off the topic of stop signs.)
>

I don't see a regression in some downstream application as being a reason
not to do it.


> You raise the issue of ref=* on ways, and why we still use it. That's
> a clear case where we use it because the downstream systems can't do
> route relations.


Osmand handles it fine.


> I've been trying to help with this - at least to the
> extent of trying to revive Phil! Gold's route relation processing. My
> version is at https://github.com/kennykb/osm-shields, and you can see
> one rendering with shaped shields based on relations at
> https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440=-72.4830=11
> .
> That link is chosen to illustrate an area that intermixes 'tag on way'
> with 'tag on relation'. Unfortunately, my time is limited, so the
> project has stagnated for a few weeks.  I've not given up, though; the
> next task will have to be to generate a pull request to adapt
> osm2pgsql optionally to preserve relations, with two new tables to
> track them.
>

Doing good work there, fixing the problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Paul Johnson]

On Sat, Sep 29, 2018 at 8:23 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Sun, 30 Sep 2018 at 08:58, Paul Johnson  wrote:
>
>>
>> I honestly don't understand why, ten years since it's introduction as
>> OSM's third basic primitive, there's still this weirdly unnatural aversion
>> to relations, even though they're quite a powerful primitive in our toolbox.
>>
>
> Maybe because people don't understand how to use them properly (I know I
> don't?), so they're scared of them?
>
> Some very simple, easily found, instructions / guidelines would be handy.
>

I'll look into adapting the scheme used for traffic enforcement to traffic
control later this week or this weekend.  This has been a peeve of mine for
a while now.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Default Language Format; language:default or default:language?

[Joseph Eisenberg]

It's not always necessary or possible to interpret the language of a brand
name.
It's more useful to know the language of names that are based on natural
language, such as the names of most streets and natural features.
The copyrighted names of restaurants and shops are often entirely invented.
They are legally called "fictitious business names" in the USA.

But in this case I think we can say it's clearly an English brand name.

"Spazio Italian Bistrot" isn't a real name, but a brand name, like KFC,
IKEA, etc.
I suspect the less-common spelling of "Bistrot" is meant to make the brand
more copyright-worthy
"Bistro" was used before "Bistrot" in Paris; so both are correct:
Bistrots/Bistros
in Paris:Definitions, Origins - France: Dining ...


The placement of the adjective "Italian" is clearly English; An Italian or
French speaker would have written "Bistro Italiano" or "Bistrot Italien".
So I would add "name:en=Spazio Italian Bistrot" and "brand=Spazio Italian
Bistrot" if there is more than one location.

For something like "IKEA" or "KFC", I would use "brand" as well:
https://wiki.openstreetmap.org/wiki/Key:brand
If the local location also has a specific name, that should be clearer; eg
"name:en=Portland Oregon IKEA" and "brand=IKEA", or "name:en=Manchester
City Centre KFC", "brand=KFC"

*TL:DR -* the language of a Brand names cannot always be determined (but in
this case it's English).
Usualy the most common language in the region will be used for invented
shop & restaurant brand names,
Fall back to "name=*" if you have no idea.
And use "brand=*", since this is often more precise than "name=*" for
restuarants and shops.

Joseph


On Mon, Oct 1, 2018 at 11:18 PM Martin Koppenhoefer 
wrote:

> Do you have an idea how to deal with names that have several languages in
> them, e.g. "Spazio Italian Bistrot"
> https://www.openstreetmap.org/node/5726043060
> (Italian English French in the same name)?
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mast / tower / communication_tower (again)

[Andrew Harvey]

On Tue, 2 Oct 2018 at 07:16, Graeme Fitzpatrick  wrote:
>  Then you get other "fuzzy" ones :-), such as this one that I found yesterday:
> https://www.google.com/maps/@-28.2142429,152.8674011,3a,75y,325.73h,113.86t/data=!3m8!1e1!3m6!1sAF1QipPfNNEI5kmxC-HEqvkJfk2U3sHvxt_CijvrDU1R!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPfNNEI5kmxC-HEqvkJfk2U3sHvxt_CijvrDU1R%3Dw203-h100-k-no-pi-0-ya275.80704-ro0-fo100!7i7168!8i3584
>
> I was in this area last week & went in yesterday to check & if necessary 
> update some map features. I found that this tower is currently mapped as a 
> water_tower 
> https://www.openstreetmap.org/node/740880328#map=19/-28.21438/152.86816. 
> Well, yes, it is as it has a water tank on top, but it also supports various 
> mobile phone & TV antennae, so what should it be?

I would map it based on the primary purpose, which is a water tower.
If it has mobile phone antennas attached you can map these with
"communication:mobile_phone=yes" (I do this where you have a building
with a mobile phone antenna on the roof).

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

Re: [Tagging] landuse for government offices ?

[Joseph Eisenberg]

Civic_admin is a little too specific, but government is not specific
enough. 90% of the land in some western American States will be owned and
managed by some level of government; eg National and State forests and
grasslands, parks and monuments, military reservations, wildlife preserves,
BLM land (used for rangeland and even mining), as well as land used for
administrative buildings.

I suspect military landuse in cities would be at highest risk for confusion
if the tag is landuse=government.

I’m perfectly happy with Civic_Admin, because national and provincial
government functions are also “Civic” in the sense of “for citizens / the
people”, if not in the “civic equals city” sense.

But public_admin would be fine too. I don’t think this would cause any
confusion.

Joseph

On Tue, Oct 2, 2018 at 6:29 AM Graeme Fitzpatrick 
wrote:

> On Tue, 2 Oct 2018 at 05:28, SelfishSeahorse 
> wrote:
>
>>
>> * Isn't 'civic administration' limited to the administration of a town
>> or city (compared to the administration of the state, county etc.)?
>>
>
> I would have said that it applied to any & all levels of Govt - local,
> State & Federal
>
>
>> Maybe it would be better to use ... simply landuse=government (162 uses)
>> instead.
>
>
>  That may be easier / clearer?
>
> * Currently the proposal only includes areas of legislative, executive
>> and governmental administration use, but excludes courts. Wouldn't it
>> make sense to also include courts? People who want to distinguish
>> administration, legislature, executive and judiciary could do this
>> with a sub-tag, e.g. government=*.
>>
>
> I would think that it should be used on all (?) Govt lands / buildings,
> with the exception of military.
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign direction tagging..

[Bryan Housel]

> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
> 
>  > ^ This is the problem.  The wiki says we are supposed to do something like 
> `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to 
> be based on a "toplevel" tag like `traffic_sign=*` not 
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many 
> of their tags have this issue too, where they put a value in the key part, 
> and so we can’t turn it into a preset).
>  
>  JOSM can do this change (when you change a way) as you can see on 
> https://i.imgur.com/NnLpKWR.jpg 

iD will also do this change when reversing a way.  That’s not what my email is 
about.


>  If you read taginfo you can find for forward subtags 
> https://taginfo.openstreetmap.org/search?q=%3Aforward 
>  more than 80 
> nodes. If you read taginfo for backward 
> https://taginfo.openstreetmap.org/search?q=%3Abackward 
>  you can find more 
> than 80 nodes. Are you saying iD doesn't recognise all these tags with 
> forward and backward subtags?

Nope, not saying that at all.


>  I give you a solution: make two presets: one for traffic_sign:backward and 
> other with the same values for traffic_sign:forward. 

That’s a bad solution, so instead we’re going to solve the problem of 
indicating traffic sign direction the same way it’s already solved for traffic 
signals.  `traffic_sign:direction=forward/backward` - simple.  I will even 
convert all the existing traffic signs tagged with `traffic_sign:forward` or 
`traffic_sign:backward` to work this way if you want.  It’s an unambiguous tag 
change.

I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs a 
“Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much less 
translating these concepts to dozens of different languages.


Thanks, Bryan

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

Re: [Tagging] mast / tower / communication_tower (again)

[Martin Koppenhoefer]

sent from a phone

> On 1. Oct 2018, at 23:15, Graeme Fitzpatrick  wrote:
> 
> Well, yes, it is as it has a water tank on top, but it also supports various 
> mobile phone & TV antennae, so what should it be?


it’s a nice edge case to test the current system, I would probably keep the 
water tower tag. 
The tower:type=communication could IMHO still be added. 
https://wiki.openstreetmap.org/wiki/Tag:tower:type%3Dcommunication
You could also add the radio facilities on top. There is man_made=antenna 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dantenna
https://wiki.openstreetmap.org/wiki/Proposed_features/Communications_Transponder


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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

sent from a phone

> On 1. Oct 2018, at 19:11, Mateusz Konieczny  wrote:
> 
> site - This relation type is a horrible mistake and should not be encouraged 
> by editors
> 
> - this data is basically not usable.
> 


I was merely listing the most common relations. associatedStreet is probably 
failed and site is also problematic, I agree. Still any but a very specific 
data editor should at least show there is something and with which tags, or 
block those objects (relations and their members) from editing — doing neither 
will likely result in broken data without the mapper even noticing it.

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

Re: [Tagging] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Tue, 2 Oct 2018 at 07:23, Paul Allen  wrote:

> Given that it has a lattice structure, it is (according to the wiki
> definition) a water mast. :)
>

While by a different definition :-), it's a tower because it doesn't have
any guy wires!

Thanks

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

Re: [Tagging] hydrants

[Viking]

>Hi Alberto,
>Nice to see you back there :)
>Regarding check_date, I'd go in favor of operational_status:date.
>working:* is too specific to fully functional hydrants, what about disused or 
>dry ones?
>Then operational_status is a more complete solution to give state and 
>associated date.
>All the best
>François

Nice to see you too, Francois :)
Well I proposed working_test:date only because it is already in use for 
hydrants.
On the other hand, operational_status is used more often, although 
operational_status:date has only 1 occurence.
Shall we go on discussion page [1]? Even Marc preferred operational status, as 
reported on [1]. 

[1] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions_(part_3)

Best regards,
Alberto




---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Tagging] landuse for government offices ?

[Graeme Fitzpatrick]

On Tue, 2 Oct 2018 at 05:28, SelfishSeahorse 
wrote:

>
> * Isn't 'civic administration' limited to the administration of a town
> or city (compared to the administration of the state, county etc.)?
>

I would have said that it applied to any & all levels of Govt - local,
State & Federal


> Maybe it would be better to use ... simply landuse=government (162 uses)
> instead.


 That may be easier / clearer?

* Currently the proposal only includes areas of legislative, executive
> and governmental administration use, but excludes courts. Wouldn't it
> make sense to also include courts? People who want to distinguish
> administration, legislature, executive and judiciary could do this
> with a sub-tag, e.g. government=*.
>

I would think that it should be used on all (?) Govt lands / buildings,
with the exception of military.

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

>
>  > ^ This is the problem.  The wiki says we are supposed to do something
> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
> needs to be based on a "toplevel" tag like `traffic_sign=*` not
> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
> many of their tags have this issue too, where they put a value in the key
> part, and so we can’t turn it into a preset).
>

 JOSM can do this change (when you change a way) as you can see on
https://i.imgur.com/NnLpKWR.jpg
 If you read taginfo you can find for forward subtags
https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
nodes. If you read taginfo for backward
https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
than 80 nodes. Are you saying iD doesn't recognise all these tags with
forward and backward subtags?
 I give you a solution: make two presets: one for traffic_sign:backward and
other with the same values for traffic_sign:forward.


> >  To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>

Please , for doing traffic_sign:direction is better to put direction=* tag.

> I still highway=give_way and highway=stop with
> direction=forward/backward (which is used by OsmAnd AFAIK).
>

And what about the other traffic signs. Are they not important? Why don't
erase it...from the World if they are not important?
I think OsmAnd can decide what data from OSM they want to use, so if they
decide to support traffic signs they will support it. If they don't want to
they won't support it.
Also remember the don't map for the render think (instead is a "render" so
important like OsmAnd).

> Describing what a driver might see when approaching a turn would be an
> effective use of traffic_sign, but 'node near the way' is pretty useless
> for routing. For maximal detail you'd need both, but if you're only going
> to add one, the highway=stop is far more useful.
>

Best approach is to have the traffic sign "inside" the way because the
traffic sign is relative to the way. If the way doesn't exist, traffic sign
is useless, so it is better to map it as a node on the way. Also then you
have the direction of the way to make relative the traffic sign to the
direction of driving.

> OSMand also warns of traffic calming, toll barriers, level crossing,
> pedestrian crossings and enforcement cameras.
>

OsmAnd can show some traffic signs in certain moments or resolutions or
guiding, as they do with maxspeed info.

> Not all give ways have a sign, some are just give way markings painted on
> the road.
>

Technically markings painted on the road are...traffic signs itself (in
some countries there are specific codes to this items) and also they have
their importance , you cannot ignore them

> I'm still against using forward/backward on nodes, it really feels like a
> hacky way to avoid using a relation (up there with using ref=* on ways to
> describe routes), which would disambiguate things without being so brittle
> just because a way reversed, and handle more complex situations like "right
> turn permitted without stopping" sign below a "stop" sign, or allow a data
> consumer to be able to display a diagram indicating which ways a stop
> applies to (handy if you encounter, say, a six way intersection with a four
> way stop).
>

It is not necessary to make a relation if you put on the way the traffic
signs nodes. JOSM reverse them if you reverse the way and things
complicated like "right turn permitted without stopping" are relative to
the direction you are driving (JOSM only shows you a north orientation and
doesn't allow to "rotate" background and data like GMaps style. So forget
the problem of the side inside a instruction because these instructions
will always be relatives to the traffic sign itself, nor the way you see it
in JOSM or iD (iD also doesn't accept rotate background and data.

> Do you have an example of a pedestrian crossing that OSMand warns you of,
> as I don't see (or maybe just don't notice?) crossing warnings, so I'm
> wondering if they may be tagged somehow differently?
>

OpenMapSurfer shows traffic sign for pedestrian crossings so it is about
the render.

That is what I think about this topic
Salut i senyals de trànsit (Health and traffic signs)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mast / tower / communication_tower (again)

[Paul Allen]

On Mon, Oct 1, 2018 at 10:16 PM Graeme Fitzpatrick 
wrote:

>
> I was in this area last week & went in yesterday to check & if necessary
> update some map features. I found that this tower is currently mapped as a
> water_tower
> https://www.openstreetmap.org/node/740880328#map=19/-28.21438/152.86816.
> Well, yes, it is as it has a water tank on top, but it also supports
> various mobile phone & TV antennae, so what should it be?
>

Given that it has a lattice structure, it is (according to the wiki
definition) a water mast. :)

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

Re: [Tagging] mast / tower / communication_tower (again)

[Graeme Fitzpatrick]

On Tue, 2 Oct 2018 at 00:24, Martin Koppenhoefer 
wrote:

> If this is the reason why we need a distinction, I'd rather use tags that
> state it, then rely on some indirect fuzzy mast/tower distinction.
> man_made=broadcast_tower vs. man_made=cellphone_tower (for example).
> Certainly, choosing "communication tower" for both types but under
> different keys wasn't  a solution that satisfies our requirements (reduce
> confusion and be easily applicable while allowing to distinguish what
> people want to distinguish)
>

 Then you get other "fuzzy" ones :-), such as this one that I found
yesterday:
https://www.google.com/maps/@-28.2142429,152.8674011,3a,75y,325.73h,113.86t/data=!3m8!1e1!3m6!1sAF1QipPfNNEI5kmxC-HEqvkJfk2U3sHvxt_CijvrDU1R!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPfNNEI5kmxC-HEqvkJfk2U3sHvxt_CijvrDU1R%3Dw203-h100-k-no-pi-0-ya275.80704-ro0-fo100!7i7168!8i3584

I was in this area last week & went in yesterday to check & if necessary
update some map features. I found that this tower is currently mapped as a
water_tower
https://www.openstreetmap.org/node/740880328#map=19/-28.21438/152.86816.
Well, yes, it is as it has a water tank on top, but it also supports
various mobile phone & TV antennae, so what should it be?

Thanks

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

Re: [Tagging] Traffic sign direction tagging..

[Kevin Kenny]

On Mon, Oct 1, 2018 at 4:31 AM Paul Norman  wrote:
> Could you provide a link to the osm2pgql issue tracker with the issue in 
> question? I don't recall it, but I've been away a lot and haven't kept up 
> with everything.

I hadn't opened a fresh ticket, because there are existing tickets
against the tools, notably

https://github.com/openstreetmap/osm2pgsql/issues/230#issuecomment-418517270
https://github.com/gravitystorm/openstreetmap-carto/issues/596#issuecomment-418518388

I also made a query to the 'tile-serving' mailing list.

The proposal can be found here:
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql

and I'm asking that comments be posted against this issue:

https://github.com/kennykb/osm-shields/issues/4



Where I've got so far is that I have a stand-alone converter that can
produce the
tables by querying the slim tables (Yes, I understand why that's a bad idea, but
it's what I have to work with before I start bashing away at osm2pgsql, and it
at least gets me rendering. It's also a very fast way to upgrade the
tables without
having to reimport everything.)

I also have a set of stored procedures (insanely complex, but extensively
documented) for placing route markers so that Mapnik can render them, and
a topographic-map rendering that uses the placement.
http://kbk.is-a-geek.net/catskills/test4.html?la=42.7276=-72.4507=12
shows the result. The area that I'm linking to is chosen because it has a mix
of route relations and routes tagged on individual ways, so it demonstrates
that both function.

As far as changes to osm2pgsql go, i looks as if the top-level relation table
 can be handled with fairly light mods to the pathway that imports 'point',
'line', 'polygon' and 'roads'. It essentially could use the same sort of
conversion rules for tags. The big difference is that a relation would have
no geometry.  (This similarity extends to the Lua code for filtering objects,
as well, which appears to be relatively ignorant of geometry in any case.)
The relation-member table is its own sort of object. It has no properties
other than 'role', and it must be populated for everything that's in the
relation table, so there's really no opportunity for fine control the way
we do with tagged objects; a member will either be included (because
its relation is) or not.

It's still a bit of a daunting prospect for me, because I'm not yet
intimately familiar with the code, and there doesn't appear to be
a simple 'road map' for what happens where. If your're amenable to
pull requests for simple improvements to commentary, I'll certainly
try to document what I learn as I learn it.

My understanding is that Sarah 'lonvia' Hoffmann has a very
similar structure underlying the rendering on waymarkedtrails.org,
but I've not examined her code.

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

Re: [Tagging] landuse for government offices ?

[SelfishSeahorse]

Hello everyone!

I haven't forgotten the landuse=civic_admin proposal, but I'm
uncertain about two points and would like to know your opinion:

* Isn't 'civic administration' limited to the administration of a town
or city (compared to the administration of the state, county etc.)?
Maybe it would be better to use landuse=public_administration (24
uses) or simply landuse=government (162 uses) instead. (For
comparison: landuse=civic_admin also has 162 uses.)
* Currently the proposal only includes areas of legislative, executive
and governmental administration use, but excludes courts. Wouldn't it
make sense to also include courts? People who want to distinguish
administration, legislature, executive and judiciary could do this
with a sub-tag, e.g. government=*.

Regards
Markus

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Yves]

Le 1 octobre 2018 19:11:28 GMT+02:00, Mateusz Konieczny 
 a écrit :
>1. Oct 2018 10:18 by dieterdre...@gmail.com
>:
>
>> site
>
>This relation type is a horrible mistake and should not be encouraged
>by editors
>
>
> - this data is basically not usable. 

It's not because you don't in carto that it's not usable. 
I use them in preprocessing daily. 
Yves 

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

Re: [Tagging] Traffic sign direction tagging..

[Yves]

@Paul
I guess it's this one:
https://github.com/openstreetmap/osm2pgsql/issues/230
Yves ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] hydrants

[François Lacombe]

Hi Alberto,

Nice to see you back there :)

Regarding check_date, I'd go in favor of operational_status:date.
working:* is too specific to fully functional hydrants, what about disused
or dry ones?

Then operational_status is a more complete solution to give state and
associated date.

All the best

François


Le ven. 28 sept. 2018 à 23:06, Viking  a écrit :

> Hello, I would like to continue with fire hydrants' new tags [1].
> Instead of the contested check_date=*, what do you think of
> working:test_date=* [2] or working_test:date=* [3], both already in use?
> Which syntax do you prefer?
>
> [1]
> https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_3)
> [2] https://taginfo.openstreetmap.org/keys/working%3Atest_date
> [3] https://taginfo.openstreetmap.org/keys/working_test%3Adate
>
> Best regards,
> Alberto
>
>
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> https://www.avast.com/antivirus
>
>
> ___
> 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] mast / tower / communication_tower (again)

[François Lacombe]

Hi,

Le lun. 1 oct. 2018 à 17:19, José G Moya Y.  a écrit :

> Michael Booth says that this is not a tower, but it seems to have stairs
> inside, and even windows.
>
> https://fr.wikipedia.org/wiki/Tour_hertzien
> ne_de_Villeneuve-d%27Ascq
>

It's definitely a tower.
In French it's called a "Tour" which literally stands for tower.

More globally, man_made should not have any "telecom" or
"telecommunication" values.
man_made=tower is enough and then telecom=* and eventually usage=* may be
used to complete.

All the best

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

1. Oct 2018 10:18 by dieterdre...@gmail.com :


> site




This relation type is a horrible mistake and should not be encouraged by editors


 - this data is basically not usable. 

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

Re: [Tagging] mast / tower / communication_tower (again)

[José G Moya Y .]

Michael Booth says that this is not a tower, but it seems to have stairs
inside, and even windows.

https://fr.wikipedia.org/wiki/Tour_hertzien
ne_de_Villeneuve-d%27Ascq

WP says it is over 100m tall, too.

I don't have a telecomm background, but I think the "seems to be a
building, is hollow inside and has normal stairs instead of outer ladder"
is a good hint for casual mappers.


El lun., 1 oct. 2018 16:24, Martin Koppenhoefer 
escribió:

>
>
> Am Mo., 1. Okt. 2018 um 16:06 Uhr schrieb Andrew Harvey <
> andrew.harv...@gmail.com>:
>
>> The rule of thumb I've been using is a mast being a simple pole (same
>> width at base and top), and a tower being anything else that has more
>> supports.
>>
>
>
> I would not negate that a mast can be tapered.
>
>
>
>>
>> I do think we need something simple to distinguish simple mobile phone
>> towers like (1) and larger television/radio broadcast towers like (2)
>> and it seems like mast/tower is it.
>>
>
>
> If this is the reason why we need a distinction, I'd rather use tags that
> state it, then rely on some indirect fuzzy mast/tower distinction.
> man_made=broadcast_tower vs. man_made=cellphone_tower (for example).
> Certainly, choosing "communication tower" for both types but under
> different keys wasn't  a solution that satisfies our requirements (reduce
> confusion and be easily applicable while allowing to distinguish what
> people want to distinguish).
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mast / tower / communication_tower (again)

[Martin Koppenhoefer]

Am Mo., 1. Okt. 2018 um 16:06 Uhr schrieb Andrew Harvey <
andrew.harv...@gmail.com>:

> The rule of thumb I've been using is a mast being a simple pole (same
> width at base and top), and a tower being anything else that has more
> supports.
>


I would not negate that a mast can be tapered.



>
> I do think we need something simple to distinguish simple mobile phone
> towers like (1) and larger television/radio broadcast towers like (2)
> and it seems like mast/tower is it.
>


If this is the reason why we need a distinction, I'd rather use tags that
state it, then rely on some indirect fuzzy mast/tower distinction.
man_made=broadcast_tower vs. man_made=cellphone_tower (for example).
Certainly, choosing "communication tower" for both types but under
different keys wasn't  a solution that satisfies our requirements (reduce
confusion and be easily applicable while allowing to distinguish what
people want to distinguish).

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

Re: [Tagging] Default Language Format; language:default or default:language?

[Martin Koppenhoefer]

Do you have an idea how to deal with names that have several languages in
them, e.g. "Spazio Italian Bistrot"
https://www.openstreetmap.org/node/5726043060
(Italian English French in the same name)?

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

Re: [Tagging] Default Language Format; language:default or default:language?

[Joseph Eisenberg]

Yuri,
The new proposal does not intend to define what language is used in the
standard "name=*" tag.
This was attempted in 2 proposals last summer (2017), but both failed to be
approved.
(See  name:language

and
  language:name

 )

Rather, this proposal hopes to make it possible for database users to rely
on the language-specific name tags (name:en=*, name:fr=*, name:zh_pinyin=*
etc).

While it is easy enough to check what language is most commonly used in the
name=* tags in most countries, there are too many exception.
This is especially a problem in places where the local community uses two
or even three different names on street signs and in the default OSM name=*;
Examples: Brussels, Ethiopia Hong Kong, Morocco, parts of Spain and
Slovenia, etc; this is just from the Multilingual Names page:
https://wiki.openstreetmap.org/wiki/Multilingual_names#Unofficial_languages_and_dialects
And there are a number of places where local signs are in two languages,
but only one language has been used in OSM up till now.

The hope is that database users will be able to start looking for the
name:xxx=* tags first; based on the code in the default langauge format
tag.
Ror example, in Brussels the map renderer or routing app could look for
name:fr=* and name:nl=* first.
If both fr and nl name tags are present, use these to render the name
label, or to announce the name of the street, for example.
If only one tag (name:fr=* but not name:nl for example), just use that tag.
If neither is found, then use the standard name=* tag as a fall-back.

This is a complicated subject, I hope it is more adequately explained in
the proposal page under "rational", "tagging" and "examples":
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format

For others following along:
I did ask Yuri if it would be possible to re-write the Key:default_language
page and move it to a proposal.
Yuri made this page a few months ago, but it was not yet discussed on this
mailing list or in the proposal process. But I wasn't sure if Yuri would
approve of my changes.
The main difference is handling of multilingual names. I don't believe this
proposal will be accepted if it does not handle regions where more than 1
language is used.
On Yuri's page for default_language=*, it first says that only one language
should be specified, but then offers that two could be used, separated by
"_,_" (eg fr_,_nl).
I believe a semicolon is better, because it is less likely to be used in
actual names and signs, while a comma or dash or slash may be used in some
real names.

There is also no mention of tagging individual map features which use a
different language than the "default" for the region on Yuri's page.
I believe these two issues are important. (See Yuri's wiki page:
https://wiki.openstreetmap.org/wiki/Key:default_language)

-Joseph


On Sun, Sep 30, 2018 at 1:11 PM Yuri Astrakhan 
wrote:

> I still think that if this feature is there to document the language of
> the name tag, we should reuse the default_language [1] -- it is already set
> on more than 200 large regions, covering most of the world. What's the
> point of duplicating it?  If there is a region where name could be in 2 or
> more languages, we may want to introduce a new tag to specifically address
> that in those regions only, e.g. multiple_default_languages_of_the_region
> tag that lists all possible values that the name MAY be in. (the tag name
> might need some work :)).
>
> That said, I fail to understand how it will help data processing. If a
> region could be in FR and DE, you still don't know the language of the
> specific feature's name.  How will the proposal help?  I might have misread
> it though.
>
> [1]  https://wiki.openstreetmap.org/wiki/Key:default_language
>
> On Sat, Sep 29, 2018 at 11:48 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> Any opinions on the order of the tag?
>>
>> Just a couple of people have said that default:language would be
>> preferred to language:default.
>>
>> It will take some time to update the proposal page, so I would like a few
>> more opinions
>>
>> Joseph
>>
>> On Thu, Sep 27, 2018 at 10:16 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> Should we change the tag from language:default to default:language?
>>>
>>> I've found out that language:* has already been used in the format
>>> language:de, language:fr, language:en, etc, for the languages taught at a
>>> school. See
>>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlanguage_school. And
>>> language=* has been used, though rarely.
>>>
>>> There is also a page for default_language, which was made without going
>>> through the proposal process. And there is a new proposal to specify all
>>> "defaults" in the fomat default:subkey, though I have also seen this the
>>> other way around, eg 

Re: [Tagging] mast / tower / communication_tower (again)

[Andrew Harvey]

The rule of thumb I've been using is a mast being a simple pole (same
width at base and top), and a tower being anything else that has more
supports.

I do think we need something simple to distinguish simple mobile phone
towers like (1) and larger television/radio broadcast towers like (2)
and it seems like mast/tower is it.

(1) 
https://www.mapillary.com/app/?focus=photo=-33.93286508330576=151.1835542226=17=LDefrZ_M7MJDsLuLEdJgbw=0.7464902074345785=0.45923282717222375=1.4281437125748506

(2) 
https://www.mapillary.com/app/?focus=photo=-33.8203138889=151.18473611108334=17=9HZD5c2vDjDBTmz-LwKuCA=0.6698933374381035=0.29396379693325986=0
On Sat, 29 Sep 2018 at 08:29, Michael Booth  wrote:
>
> Hi,
>
> I opened an issue on the rendering of man_made=communications_tower on the 
> standard layer over on OSM-carto: 
> https://github.com/gravitystorm/openstreetmap-carto/issues/3414 and think 
> there should be a discussion about the tagging as well.
>
> The Wiki definition is: "a huge tower for transmitting radio applications 
> It is often made from concrete and usually a far visible landmark." 
> https://wiki.openstreetmap.org/wiki/Tag:man%20made=communications%20tower
>
> Looking at examples of this tag in OSM I would guess that out of the <4,000 
> objects worldwide most of them do not conform to that definition. Many of 
> them are small mobile phone/cell site "masts", towers less than 100m, or very 
> tall guyed masts.
>
> I'd like to retag the structures near me to something more suitable - however 
> the wiki pages aren't very clear in distinguishing between the various 
> constructions and sizes for masts and towers.
>
> Hopefully people can agree that the following should be tagged as 
> man_made=mast or tower + tower:type=communication + tower:construction + 
> height? Using TV transmitters in the UK as examples:
>
> mast - guyed lattice, 306m: 
> https://en.wikipedia.org/wiki/Durris_transmitting_station
> mast - guyed tube, 351m: 
> https://en.wikipedia.org/wiki/Belmont_transmitting_station
> tower - lattice, 219m: 
> https://en.wikipedia.org/wiki/Crystal_Palace_transmitting_station
> tower - freestanding, 330m: 
> https://en.wikipedia.org/wiki/Emley_Moor_transmitting_station
>
> But how should these examples be tagged in OSM? All of them are 
> self-supporting structures, so in engineering terms they are not masts.
>
> https://binged.it/2xILZO9
> https://www.geograph.org.uk/photo/2361955
> https://www.geograph.org.uk/photo/2337468
> https://en.wikipedia.org/wiki/Charwelton_BT_Tower
> https://www.geograph.org.uk/photo/2053885
> https://binged.it/2xTxcQK
> https://fr.wikipedia.org/wiki/Tour_hertzienne_de_Villeneuve-d%27Ascq
> https://www.geograph.org.uk/photo/2162874
>
> Fortunately all three of the tags are now all displayed on the standard layer 
> so there shouldn't be any tagging for the renderer. But it would be good to 
> fix the definitions and make the wiki much clearer, especially with more 
> example photos. Then also ensuring the tags are well supported in each 
> editor's presets.
>
> Cheers
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Log bollard fence tagging

[Reuben]

I am just wondering what the best way to tag barriers like this:
https://timberbollards.com.au/products/brisbane-fence-log-barrier-600mm-high

It is closest in design to a split rail fence however it is not a linear 
barrier (you can walk between them), and it doesn't seem right to use to use 
log bollard.

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

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[Martin Koppenhoefer]

Am Mo., 1. Okt. 2018 um 14:54 Uhr schrieb Philip Barnes <
p...@trigpoint.me.uk>:

> In GB licensed premises have to provide free drinking water.
>
> https://www.bbc.co.uk/news/uk-39881236
>



this is definitely not the default situation worldwide, but would it
prevent you from adding some of the proposed tags in the UK, given that
legal defaults which are not visible on the ground shall not be tagged
explicitly?

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

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[Philip Barnes]

In GB licensed premises have to provide free drinking water.

https://www.bbc.co.uk/news/uk-39881236

Phil (trigpoint) 

On 1 October 2018 10:11:08 BST, Martin Koppenhoefer  
wrote:
>Am Sa., 29. Sep. 2018 um 17:33 Uhr schrieb bkil :
>
>>
>>
>> The best visibility for both venues and people should be via OSM
>> itself. However, if we do not highlight these via specific tags, this
>> visibility may be impaired. Renderers could be enhanced to highlight
>> various tag combinations, like drinking_water on bars, restaurants,
>> etc., though that is not ideal. Verification could also be made more
>> difficult, because if I see drinking_water=yes on a pub, I need to
>> first start looking for a vending machine/fountain/tap, if not found,
>> ask for an accessible vending machine/fountain/tap from staff, if
>they
>> don't know anything about those, then I ask whether they could
>> manually refill my container.
>>
>
>
>I am not sure adding drinking_water on bars or pubs would do us a
>favor.
>For one it might be up to the discretion of the current staff  how they
>respond to your request (and could depend whether you have already
>consumed
>something there, know the barkeeper, are accompagnied by babies or
>children, the staff has a good day or not, etc.). There are also places
>that offer a drinking water tap with plastic cups or water bottles so
>you
>can serve yourself without asking anybody. (e.g. first pillar here is
>an
>accessible indoor fountain:
>https://media-cdn.tripadvisor.com/media/photo-s/02/06/a0/ef/gelateria-palazzo-del.jpg
>), and this is quite different than having to ask the staff and
>depending
>on their discretion. How will it be distinguished?
>
>Pubs and bars usually will have opening hours, while drinking_water on
>a
>fountain is generally accessible 24/7. This can be seen from the data
>(combination with what), but it might be safer to explicitly use
>distinct
>tagging (unsure myself).
>
>Cheers,
>Martin

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Refilling a purchased drink

[Martin Koppenhoefer]

Am Sa., 29. Sep. 2018 um 17:29 Uhr schrieb bkil :

> > I am strongly against tagging the business practice how often a _paid_
> glass of
> > beverage is being refilled
> >
>
> Could you please clarify what policy this would violate that makes you
> disapprove?



it is basically a way of giving a discount to customers. Would you also
want to add special offers of your supermarket, like buy one get one free?
Without putting the price for the first (paid) glass in relation to usual
prices, the information about free refills is worthless. E.g. if a glass of
$SOFTDRINK is sold for 5 EUR and you can get up to 2 refills it is still
more expensive than a place where a glass of $SOFTDRINK is sold for 1 EUR.

I am not sure there is (already) a policy, but I believe there is general
agreement not to tag the price structure of shops or other amenities,
unless it is a single fee (like for parking).
For me, this is kind of an edge case here, I would be willing to accept the
tag, but I can see the arguments against it.

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

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[Martin Koppenhoefer]

Am Sa., 29. Sep. 2018 um 17:33 Uhr schrieb bkil :

>
>
> The best visibility for both venues and people should be via OSM
> itself. However, if we do not highlight these via specific tags, this
> visibility may be impaired. Renderers could be enhanced to highlight
> various tag combinations, like drinking_water on bars, restaurants,
> etc., though that is not ideal. Verification could also be made more
> difficult, because if I see drinking_water=yes on a pub, I need to
> first start looking for a vending machine/fountain/tap, if not found,
> ask for an accessible vending machine/fountain/tap from staff, if they
> don't know anything about those, then I ask whether they could
> manually refill my container.
>


I am not sure adding drinking_water on bars or pubs would do us a favor.
For one it might be up to the discretion of the current staff  how they
respond to your request (and could depend whether you have already consumed
something there, know the barkeeper, are accompagnied by babies or
children, the staff has a good day or not, etc.). There are also places
that offer a drinking water tap with plastic cups or water bottles so you
can serve yourself without asking anybody. (e.g. first pillar here is an
accessible indoor fountain:
https://media-cdn.tripadvisor.com/media/photo-s/02/06/a0/ef/gelateria-palazzo-del.jpg
), and this is quite different than having to ask the staff and depending
on their discretion. How will it be distinguished?

Pubs and bars usually will have opening hours, while drinking_water on a
fountain is generally accessible 24/7. This can be seen from the data
(combination with what), but it might be safer to explicitly use distinct
tagging (unsure myself).

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

Re: [Tagging] Traffic sign direction tagging..

[Paul Norman]

On Sep 29, 2018 9:40 PM, Kevin Kenny  wrote:
Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql)
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silenceCould you provide a link to the osm2pgql issue tracker with the issue in question? I don't recall it, but I've been away a lot and haven't kept up with everything.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

Am So., 30. Sep. 2018 um 05:01 Uhr schrieb Bryan Housel :

> On Sep 29, 2018, at 6:56 PM, Paul Johnson  wrote:
>
> I honestly don't understand why, ten years since it's introduction as
> OSM's third basic primitive, there's still this weirdly unnatural aversion
> to relations, even though they're quite a powerful primitive in our toolbox.
>
>
> From my own perspective as the main developer on the main editor for OSM,
> the reason I don’t like relations very much is because:
> - every type of node basically works the same.
> - every type of linear way basically works the same.
> - every type of polygonal area basically works the same
> *- every type of relation is an edge case that requires special code in
> order not to break.  *
>
>

This is somehow misrepresenting the status quo, in particular as there is
no such thing as a "polygonal area" or a "linear way" object type.
Not sure what "type of node" means, is this to be read as differently
tagged nodes, or nodes in different context? A node on a way has different
implications than a POI node inside a polygon, than an isolated tagged node
without an enclosing polygon for instance, or place areas within a place
node inside (this is currently discussed) might have to be treated
differently than place ways where no place node is inside.
Ways can be either linear objects or polygonal features, and we can only
guess about this, or rely on explicit area=yes/no tagging in the few cases
where it is present (980 561 times on ways, or 0.2%, one third of them in
combination with highways), linear ways with direction dependent tags
(retaining wall, coastline, oneway, incline, forward/backward/left/right
) have to be treated more complexly than those ways without them, etc.

Yes, every type of relation is a new datatype (with some being very
similar, like multipolygons and boundary relations), but all of those which
are widely in use, are required to map a certain kind of thing. Unlike the
interpretation of nodes and ways which is more complex than what it might
seem at first glance, the interpretation of relations seems more
straightforward because they are explicit about how they should be read
(tag "type", roles) and they are taylored around the specific usecase for
which they are intended.

I would expect from any editing software that aims to be an universal
OpenStreetMap editing tool, that it strives to handle (at least) the most
used relation types reasonably well, or has good arguments why it doesn't
for a specific type. For reference:
https://taginfo.openstreetmap.org/keys/type#values

multipolygon
restriction
route
boundary
associatedStreet
public_transport
site
destination_sign
waterway
route_master





>
> Anyway, I’m not totally against them, but every one of them is different
> and I can't spend weeks or months supporting every kind of relation or
> public transport schema people dream up unless it’s super critical for
> building a useful map (like turn restrictions).  They are really best for
> features that can not be mapped any other way.
>


Yes, relations should only be used to map relationships that otherwise
cannot be represented. And of course nobody is asking you to implement all
of these on your own.

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