[Tagging] Feature Proposal - RFC - Telecom local networks

[François Lacombe]

Hi

The telecom networks proposal is currently in RFC and all issues or
questions have been solved.
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

The vote is about to begin shortly, by the end of the week.
The tagging has been in use in France for last months, no big issue rose
and dozen of telecom exchange have been mapped.

Feel free to make any comment.

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

Re: [Tagging] hydrants

[Paul Allen]

On Tue, Oct 9, 2018 at 11:31 PM François Lacombe 
wrote:

> The question about the opening direction should be propagated to this
> draft proposal regarding pipeline valves
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal
>
> I thought about turn_to_close=clockwise / anticlockwise
> Whatever the final answer will be, this definitely have to be the same key
> and values on both fire hydrants and any kind of pipeline valves.
>

Those are both valves operated with rotary motions.  No problem using the
same key/values for
both.  Or for any other kind of valve operated with a rotary motion.  The
problem comes when, as
somebody suggested, applying it to doors too, so then the editor preset
would have to be context
sensitive.  Your choice of key prevents it being applied to doors.

A less-obvious problem is applying it to taps.  The taps in my home are
rotary.  But I've
encountered taps operated with levers and taps operated with push buttons.
That is
probably not the case with fire hydrants.  So taps would have to be dealt
with by another key,
otherwise the authors of editors would be unhappy.  Not that we're likely
to map taps until
nanomapping becomes popular, but somebody suggested it.

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

Re: [Tagging] hydrants

[bkil]

Do note that fire hydrant plates depict opening direction, so if we
would need to store direction to close, a mapper would yet again need
to do mental work, that is not error prone and confusing.
On Wed, Oct 10, 2018 at 12:31 AM François Lacombe
 wrote:
>
> The question about the opening direction should be propagated to this draft 
> proposal regarding pipeline valves
> https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal
>
> I thought about turn_to_close=clockwise / anticlockwise
> Whatever the final answer will be, this definitely have to be the same key 
> and values on both fire hydrants and any kind of pipeline valves.
>
> The proposal can change at anytime until RFC.
> All the best
>
> François
>
> Le mar. 9 oct. 2018 à 23:13, Paul Allen  a écrit :
>>
>> On Tue, Oct 9, 2018 at 9:34 PM Viking  wrote:
>>>
>>>
>>> As we did for most of the tags in [0], I would not use fire_hydrant: prefix 
>>> because we want a slim
>>>
>>> database and because  opening:direction=* is (or can be) used for other 
>>> objects, as doors, taps, etc.
>>
>>
>> There are differing viewpoints on this.
>>
>> 1) Minimize database keys by applying them as widely as possible.  So 
>> opening:direction applies to
>> doors, taps, fire hydrants, etc.  Database designers might think this way, 
>> as might most ordinary
>> mappers and most programmers.
>>
>> 2) Don't re-use keys in this way because you end up with different sets of 
>> values that apply in
>> different situations.  People who program map editors tend to think this 
>> way.  Each time you use
>> opening:direction for a different type of object the programmer has to 
>> special-case the set of possible
>> values based on the associated values in order to populate drop-downs.  If 
>> you're mapping a
>> tap you want the choice of opening:direction to be limited to clockwise and 
>> counterclockwise and
>> not be confused by also seeing inwards and outwards; but for doors you want 
>> inwards and outwards
>> but not clockwise and counterclockwise (unless it's a rotating door).
>>
>> I can see merits in both viewpoints.  The people who write map editors tend 
>> to win these arguments
>> because most mappers choose from what the editor presents to them. :)
>>
>> --
>> Paul
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Combined waste/recycling bins

[Martin Koppenhoefer]

sent from a phone

> On 9. Oct 2018, at 21:19, bkil  wrote:
> 
> amenity=waste_basket
> waste=dog_excrement
> vending=excrement_bags
> 
> I've also seen waste_basket:excrement_bags=yes and fee=no, but I don't
> see much value in these at this point in time.



while vending=* with fee=no is some kind of open contradiction, without the fee 
tag the contradiction is implicitly still there in many instances.

Shouldn’t that better be „dispensing“ rather than vending?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

This whole "trying to cram everything including direction and how it
relates to everything into a node" idea is fundamentally hosed.  Also
literally why relations are a thing that exist.

On Tue, Oct 9, 2018 at 5:26 PM yo paseopor  wrote:

>
>
> On Tue, Oct 9, 2018 at 8:37 PM Tobias Knerr  wrote:
>
>> On 09.10.2018 17:42, yo paseopor wrote:
>> > So Please , let's talk about it. What will be the correct way to tag a
>> > traffic sign?
>>
>> How about the existing tagging scheme for traffic signs on nodes,
>> documented at https://wiki.osm.org/Key:traffic_sign ?
>>
>> To sum it up:
>>
>> - Place a node for the traffic sign into the highway=* way.¹
>>
> It is
>
>> - Tag the node as traffic_sign=:.
>>
> It is
>
>> - As with your suggestion,  is the ISO country code.
>>
> It is
>
>> -  is composed of one or more country-specific traffic sign ids, as
>> an ordered list separated by commas.
>>
> It is better to manage the information with each position to avoid the
> mixtures. One of the errors of the mass edition were the edition of
> ways...with traffic signs tag. If any way would not have this key dedicated
> to the nodes there weren't these errors.
>
>> - If there are multiple groups of traffic signs, these groups are
>> separated by semicolons.
>>
> Each traffic sign can have its position like Finnish people do , with :2
> :3 :4 subkeys
>
>> - Custom inscriptions on a sign are appended to the sign id in square
>> brackets [].
>>
> but which information are these brackets? Are maxspeed values? Are
> maxleght values? Are custom inscriptions or designations? It is better to
> expose this information with their own keys to process it by the renders
>
>>
>> ¹ The page also documents how to map traffic signs next to the way, but
>> I understand you would like to talk about mapping them as part of the way.
>>
> Thanks for this consideration
>
>>
>> I haven't seen a convincing reason for changing this yet. I'm aware of
>> the general argument against semicolon-separated or comma-separated
>> lists of values, but imo this is less critical for keys that have
>> well-defined semantics for such characters.
>>
> multiple values are a problem for the processing of the data. Nowadays a
> lot of values are yes/no, etc. In this way of tagging it is logic to make
> the pairs :2 :3 or  :forward:backward, etc.
>
>>
>> > traffic_sign:direction=forward/backward/both
>> >
>> > Also accepts other facing directions like 90/270...
>>
>> In my opinion, traffic signs should use the normal direction=* key for
>> angles such as 90 or 270. This usage is part of the approved proposal of
>> that key:
>>
>
> If direction=0 is forward and direction=180 is =  backward ok I'm agree.
> Because if it marks the cardinal orientation these direction would change
> in every curve making less intuitive the tagging of the direction.
>
>>
>> https://wiki.osm.org/Proposed_features/direction#Point_features
>>
>> Using traffic_sign:direction specifically for the "forward" and
>> "backward" values, as discussed in the recent iD-related thread, is fine.
>>
>
> Some people does not agree and says the reason of the edition (make the
> scheme compatible with iD solution) sucks.
>
>
>>
>> >
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>>
>> I find it hard to discuss this proposal because it includes so many
>> different ideas:
>>
>> - introducing a system of "categories" for signs: caution, warning, etc.
>>
> All these categories you can find in every traffic sign's law and also on
> the API of one of the possible sources: Mapillary. These keys help to make
> human-readable values and also international (because of the people does
> not want to use ISO codes) . There are also in OSM some categories like
> maxspeed , restriction...
>
>
>> - using :2, :3 etc. instead of comma-separated ids
>>
>
> Finnish people do so well
>
>
>> - using human-readable values instead of unambiguous national IDs
>>
>
> It would be an important decision because with country codes we can show
> exact traffic sign as it is for the country, not similar: equal.
>
>> - re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
>>
> Reusing tags for OSM. Only we have to change some options for validators
>
>> - adding a side=* key
>>
> For making a exact position using relatives to the way
>
>> - improving destination sign and roundabout mapping
>>
> Destination signs are one of the more important traffic signs because they
> show towns, local places  which connects to data in real place.
>
>>
>> Trying to change all that at once likely leads to discussions that mix
>> all sorts of loosely related topics.
>
> It is true it is complex. But as the topic for me is so important (making
> a tagging scheme for a World collaborative project like OSM) that I try to
> think ( I have started with this in 2011) how to do it and try and
> establish a complete (4 position, 3 panels (12 localizations) in two
> directions and two sides with 

Re: [Tagging] Game and toy library

[Graeme Fitzpatrick]

On Wed, 10 Oct 2018 at 08:04, Paul Allen  wrote:

> On Tue, Oct 9, 2018 at 10:24 PM ChameleonScales <
> chameleonsca...@protonmail.com> wrote:
>
> amenity:library=game_and_toy
>>
>
> When I added one of these, five months ago, the most popular way of doing
> it was
> amenity=toy_library, so that's what I went with.
>

I was wondering the same question about mapping Family History libraries ie
somewhere you go to study Family History, which has reference files etc

I was thinking:
amenity=library
"something" :-)=family_history

type / library / resource ???

Thanks

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

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[John Willis]

sounds like there are several different kinds of shops being discussed


- old old “markets”, from before there were super markets or convenience shops. 

- import/foreign foods shops catering to a local minority population or special 
cultural interest

- “markets” in developing countries.   


> On Oct 9, 2018, at 11:56 AM, Joseph Eisenberg  
> wrote:
> 
> What do you think about the need for a shop=grocery tag for small shops in 
> developing countries and specialty grocers in cities?
> 
> Are there still small groceries in Japan which sell non-perishable food 
> items, but would not be properly considerd a shop=convenience, shop=general, 
> shop=greengrocer or shop=supermarket?

I know the shops that you speak of. They were the local “everyday needs” shop - 
the market/grocery shop, very similar to a general store - but in an urban 
area. they were the only shop that had some of everything that wasn't covered 
by the Rice shop, fish shop, the butcher, and the produce stand:  curry mix, 
spices, dish soap, eggs, milk, toilet paper, etc. they would be shop=market, if 
that exists.They still exist in Japan, but are almost gone. The mom-n-pop ones 
are operated by people that live over the shop, and they are still operated for 
the locals to come sit there and gossip - but everyone goes to the supermarket 
3 minutes away. they never look like they sell anything, and most have been 
shuttered, but a few are still there.  the only corner market I knew of was 
there are a few shop=general out in the mountains - but all the “markets” were 
put out of business by supermarkets a long time ago in California. I know of 
only one from personal experience. I hear of the “corner shop” or “bodegas” in 
New York - similar to the little corner market Bullitt buys his frozen dinners 
from in the movie in San Francisco - they seem to be disappearing in developed 
countries.

They are the proto-market: the Convenience store is more convenient, they have 
no departments, they are not specific enough to be a greengrocer nor have a 
stock of blankets, bullets, motor oil, and firewood like a general store - they 
are the “daily market”, not a giant supermarket - the corner store. 

a small market for daily living in developing countries feels like it would be 
a shop=general - a general store has a certain feeling when it is the only 
retail building in 40 miles in any direction, perhaps that is similar to the 
developing country shops. 

I think shop=general for the small developing countries’ markets or these 
fading local markets would be a good kludge, but it is not a fit **at all** for 
some specialty shop in a big city.

> Mediterranean groceries or Caribbean foods, as found in some big cities.


This is a great question. there are all kinds of [asian country] markets in San 
Diego, and there are Philippine, Brazilian, and “Halal foods” shops here in my 
area of Japan. There are also chain shops catering to “foreign foods” : 
American snacks, British mints, South American Coffee, Italian pasta, etc. they 
almost always are around food. 

if there is a convenience store, a supermarket, a “halal foods” shop, and a 
butcher shop on the same block - that isn’t 4 “markets” - I think the idea of a 
“foreign foods" market is good - and then choose a theme or country, or 
religion, or similar tag would work.  . I don’t know how that aspect would be 
tagged - but the type of shop - the “import goods from some far off place 
catering to a minorty group that lives in the region” is a very very common 
occurrence, and very very rarely considered by the majority residents to be a 
place to go shopping (they all shop at the supermarket, as their ethnic and 
culturally specific goods are stocked there). I think having a shop=halal and a 
shop=Japanese would be wrong - as the only place they would be used is outside 
those areas, and confusing for people inside those areas. 

If we try to come up with a tag that fits all these uses, it won’t fit. We need 
to create shop=* tags to fit these separately. 

Javbw




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

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

[Lionel Giard]

The problem i see with that "multipurpose" value is that it give no
information and could be misused for other tower:type (like
defensive;observation) which should not be rendered as communication_tower.
Thus i would propose to render the "communication_tower" based on the
height > 250 m (arbitrary value for example) when in combination with
tower:type=communication (even when others tower:type are mentioned like in
your example : "tower:type=communication;observation"). I don't know if it
is feasible for the renderer to identify the presence of only one value in
the tag ? Otherwise i suppose it would need to put all alternative
available... :s

Le mar. 9 oct. 2018 à 02:28, Graeme Fitzpatrick  a
écrit :

>
>
>
> On Tue, 9 Oct 2018 at 10:13, Joseph Eisenberg 
> wrote:
>
>> " If you combine communications;observation, which would it render as?"
>>
>> It won't render at all, unless an individual renderer adds support for
>> this specific combination
>>
>
> Thanks Joseph
>
> So, if we use the existing rendered =communications_tower icon for my
> suggested =multipurpose, that will still render so the massive, visible for
> a long distance towers will be easily visible on the map
>
> 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] Greengrocer vs grocery vs shop=food?

[Dave Swarthout]

You know, some people have advocated for a tag or, more properly, a set of
tags that can enumerate the items sold by a given shop. The tag set uses
the key "sells:*=yes/no. So if a given shop sells Korean food, one could
tag it as shop=food (or shop=convenience or grocery, or general) and
sells:korean_food=yes, or sells:pierogi=yes, etc.. The list can be as long
as one wants and the items sold can be queried via search engines or what
have you. A similar scheme has been proposed for bicycle and motorcycle
shops that employ the service:bicycle:*=yes/no tag set so one can tag
service:bicycle:repair=yes/no, service:bicycle:rental=yes/no, etc.

I'm not advocating this scenario but thought it might be of interest. I do
think it would be nice to have some overriding methodology to govern the
construction of these new tags we keep wanting to invent.

The sells key only has a few uses so far but for some reason it appeals to
me; here's the Taginfo link:
https://taginfo.openstreetmap.org/search?q=sells

The service proposal is here:
https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

Cheers,

Dave

On Tue, Oct 9, 2018 at 4:33 PM Joseph Eisenberg 
wrote:

> If you think the specialty shops should have there own tag, we could start
> using shop=specialty_grocery
>
> But I would like someone from England to confirm if this is the specific
> British term.
>
> I’m ok with using shop=general for the small shops in developing
> countries, if we can edit the wiki to allow use in towns and cities.
>
> I don’t believe there is shop=market tag yet. There is amenity=marketplace
> for public markets, found in old town centers in Europe but much more
> common in the developing world. Probably shop=market would be too easily
> confused with marketplaces.
> On Tue, Oct 9, 2018 at 5:42 PM John Willis  wrote:
>
>> sounds like there are several different kinds of shops being discussed
>>
>>
>> - old old “markets”, from before there were super markets or convenience
>> shops.
>>
>> - import/foreign foods shops catering to a local minority population or
>> special cultural interest
>>
>> - “markets” in developing countries.
>>
>>
>> On Oct 9, 2018, at 11:56 AM, Joseph Eisenberg 
>> wrote:
>>
>> What do you think about the need for a shop=grocery tag for small shops
>> in developing countries and specialty grocers in cities?
>>
>>
>> Are there still small groceries in Japan which sell non-perishable food
>> items, but would not be properly considerd a shop=convenience,
>> shop=general, shop=greengrocer or shop=supermarket?
>>
>>
>> I know the shops that you speak of. They were the local “everyday needs”
>> shop - the market/grocery shop, very similar to a general store - but in an
>> urban area. they were the only shop that had some of everything that wasn't
>> covered by the Rice shop, fish shop, the butcher, and the produce stand:
>>  curry mix, spices, dish soap, eggs, milk, toilet paper, etc. they would be
>> shop=market, if that exists.They still exist in Japan, but are almost gone.
>> The mom-n-pop ones are operated by people that live over the shop, and they
>> are still operated for the locals to come sit there and gossip - but
>> everyone goes to the supermarket 3 minutes away. they never look like they
>> sell anything, and most have been shuttered, but a few are still there.
>>  the only corner market I knew of was there are a few shop=general out in
>> the mountains - but all the “markets” were put out of business by
>> supermarkets a long time ago in California. I know of only one from
>> personal experience. I hear of the “corner shop” or “bodegas” in New York -
>> similar to the little corner market Bullitt buys his frozen dinners from in
>> the movie in San Francisco - they seem to be disappearing in developed
>> countries.
>>
>> They are the proto-market: the Convenience store is more convenient, they
>> have no departments, they are not specific enough to be a greengrocer nor
>> have a stock of blankets, bullets, motor oil, and firewood like a general
>> store - they are the “daily market”, not a giant supermarket - the corner
>> store.
>>
>> a small market for daily living in developing countries feels like it
>> would be a shop=general - a general store has a certain feeling when it is
>> the only retail building in 40 miles in any direction, perhaps that is
>> similar to the developing country shops.
>>
>> I think shop=general for the small developing countries’ markets or these
>> fading local markets would be a good kludge, but it is not a fit **at all**
>> for some specialty shop in a big city.
>>
>> Mediterranean groceries or Caribbean foods, as found in some big cities.
>>
>>
>> This is a great question. there are all kinds of [asian country] markets
>> in San Diego, and there are Philippine, Brazilian, and “Halal foods” shops
>> here in my area of Japan. There are also chain shops catering to “foreign
>> foods” : American snacks, British mints, South American Coffee, Italian
>> pasta, etc. 

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[Martin Koppenhoefer]

Am Di., 9. Okt. 2018 um 04:57 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> I think I agree with you that "take-and-bake" places are a type of
> restaurant or fast-food; that's how they are being tagged in the USA.
>
>


IMHO a restaurant usually requires tables (or culturally dependend maybe an
alternative place to eat) and according to the cultural context some kind
of seating or place to seat, and typically also a waiter/table service.
Both, restaurants and fast food places require that you can get there and
get something ready to eat. If all they sell are products that require
further preparation / cooking, I would not tag them as restaurant or fast
food (with the exception of places that provide a possibility where you can
cook on the premises, and that are considered restaurants / fast food).

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

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[Joseph Eisenberg]

If you think the specialty shops should have there own tag, we could start
using shop=specialty_grocery

But I would like someone from England to confirm if this is the specific
British term.

I’m ok with using shop=general for the small shops in developing countries,
if we can edit the wiki to allow use in towns and cities.

I don’t believe there is shop=market tag yet. There is amenity=marketplace
for public markets, found in old town centers in Europe but much more
common in the developing world. Probably shop=market would be too easily
confused with marketplaces.
On Tue, Oct 9, 2018 at 5:42 PM John Willis  wrote:

> sounds like there are several different kinds of shops being discussed
>
>
> - old old “markets”, from before there were super markets or convenience
> shops.
>
> - import/foreign foods shops catering to a local minority population or
> special cultural interest
>
> - “markets” in developing countries.
>
>
> On Oct 9, 2018, at 11:56 AM, Joseph Eisenberg 
> wrote:
>
> What do you think about the need for a shop=grocery tag for small shops in
> developing countries and specialty grocers in cities?
>
>
> Are there still small groceries in Japan which sell non-perishable food
> items, but would not be properly considerd a shop=convenience,
> shop=general, shop=greengrocer or shop=supermarket?
>
>
> I know the shops that you speak of. They were the local “everyday needs”
> shop - the market/grocery shop, very similar to a general store - but in an
> urban area. they were the only shop that had some of everything that wasn't
> covered by the Rice shop, fish shop, the butcher, and the produce stand:
>  curry mix, spices, dish soap, eggs, milk, toilet paper, etc. they would be
> shop=market, if that exists.They still exist in Japan, but are almost gone.
> The mom-n-pop ones are operated by people that live over the shop, and they
> are still operated for the locals to come sit there and gossip - but
> everyone goes to the supermarket 3 minutes away. they never look like they
> sell anything, and most have been shuttered, but a few are still there.
>  the only corner market I knew of was there are a few shop=general out in
> the mountains - but all the “markets” were put out of business by
> supermarkets a long time ago in California. I know of only one from
> personal experience. I hear of the “corner shop” or “bodegas” in New York -
> similar to the little corner market Bullitt buys his frozen dinners from in
> the movie in San Francisco - they seem to be disappearing in developed
> countries.
>
> They are the proto-market: the Convenience store is more convenient, they
> have no departments, they are not specific enough to be a greengrocer nor
> have a stock of blankets, bullets, motor oil, and firewood like a general
> store - they are the “daily market”, not a giant supermarket - the corner
> store.
>
> a small market for daily living in developing countries feels like it
> would be a shop=general - a general store has a certain feeling when it is
> the only retail building in 40 miles in any direction, perhaps that is
> similar to the developing country shops.
>
> I think shop=general for the small developing countries’ markets or these
> fading local markets would be a good kludge, but it is not a fit **at all**
> for some specialty shop in a big city.
>
> Mediterranean groceries or Caribbean foods, as found in some big cities.
>
>
> This is a great question. there are all kinds of [asian country] markets
> in San Diego, and there are Philippine, Brazilian, and “Halal foods” shops
> here in my area of Japan. There are also chain shops catering to “foreign
> foods” : American snacks, British mints, South American Coffee, Italian
> pasta, etc. they almost always are around food.
>
> if there is a convenience store, a supermarket, a “halal foods” shop, and
> a butcher shop on the same block - that isn’t 4 “markets” - I think the
> idea of a “foreign foods" market is good - and then choose a theme or
> country, or religion, or similar tag would work.  . I don’t know how that
> aspect would be tagged - but the type of shop - the “import goods from some
> far off place catering to a minorty group that lives in the region” is a
> very very common occurrence, and very very rarely considered by the
> majority residents to be a place to go shopping (they all shop at the
> supermarket, as their ethnic and culturally specific goods are stocked
> there). I think having a shop=halal and a shop=Japanese would be wrong - as
> the only place they would be used is outside those areas, and confusing for
> people inside those areas.
>
> If we try to come up with a tag that fits all these uses, it won’t fit. We
> need to create shop=* tags to fit these separately.
>
> Javbw
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[Martin Koppenhoefer]

Am Di., 9. Okt. 2018 um 00:52 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> In the USA there are shops that sell custom fresh pizzas, but they are
> uncooked. You take the prepared pizza home and cook it yourself. In the
> western USA, the chain is named “Papa Murphy’s Take And Bake Pizza”
>
> These have generally been tagged as restaurants or fastfood. In this case
> takeaway=only would be a great tag.
>
> I think it's reasonable to consider these in the category of "places that
> sell prepared food" eg restaurant/fast_food, because you often need to
> reheat take-away items.
> I would not think of these places as equivalent to a grocery or
> greengrocer.
>


While they are not similar to a grocery store, they clearly aren't similar
to a fast food or restaurant either, because you cannot go there and eat
something. If you compare them to a butcher, they are somehow similar
(butchers tend to sell prepared food which needs cooking at home for
completion, at least in Germany). The fact that they prepare the pizza
according to your wishes and fresh is a clear distinction compared to shops
that sell only frozen food. I would suggest a proper category for these
take and bake shops, maybe shop=take_and_bake? Or they would be a candidate
for the food=take_and_bake shop for specialist food shops that aren't delis
(would this be also applicable to ethnic food shops = food shops that sell
food which is typical "somewhere else", e.g. chinese convenience stores
outside china, or would a subtag for shop=convenience work better?).

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

[Tagging] Combined waste/recycling bins

[Paul Allen]

A village a few miles from me (but in a different county) recently got one
of
these combined litter/recycling bins:
https://www.facebook.com/permalink.php?story_fbid=2241627292737699=1632021387031629&__tn__=C-R

How to tag?  Each of the two sections is around the size of a large
amenity=waste_basket.  The recycling half is a little smaller than the
amenity=recycling + recycling_type=container images in the wiki, and they
are a little smaller than the recycling containers I see around here.

In any case, if I put both of those tags on a node only one of them would
be rendered. If I use two nodes that are almost touching, only one of
them would be rendered.

These combined disposal things appear to be catching on, so I'd
expect to see them increasingly replacing existing
amenity=waste_basket.  It seems to me we probably need a dedicated
tag that everyone agrees on (no chance of that happening) and then
convincing the renderer folks to render it (the odds of that happening
can only be expressed as multiples of the square root of -1).

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

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[Jmapb]

On 10/9/2018 6:55 AM, Martin Koppenhoefer wrote:

Both, restaurants and fast food places require that you can get there 
and get something ready to eat. If all they sell are products that 
require further preparation / cooking, I would not tag them as 
restaurant or fast food (with the exception of places that provide a 
possibility where you can cook on the premises, and that are 
considered restaurants / fast food).


Cheers,
Martin



I agree... if the food is not edible when it's purchased, it isn't fast 
food or restaurant food.


I'm favor of rendering shop=food. I think of it as a parallel syntax to 
shop=clothes. A clothes shop can be further described with 
clothes=women, clothes=hats etc. Or =clothes can be replaced with a 
narrower value, like shop=shoes, shop=fashion. Likewise, it makes sense 
to use shop=food (possibly in combination with food=*) if none of the 
more specific food shop tags like deli, convenience, greengrocer, or 
supermarket are a good fit.


J

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

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

[Martin Koppenhoefer]

Am Di., 9. Okt. 2018 um 14:28 Uhr schrieb Jonathon Rossi :

>
> My first thought was some sort of "landmark=yes" tag, there is already a
> "denotation=landmark" tag for trees, however it appears like there might
> have been a landmark tag in the past that was deprecated, and I realise
> that it would be a stupid tag because you'd have to tag everything.
>


just because you could tag a lot of stuff, it doesn't mean you have to.
landmark on a tower could be used to denote significance, on the other
hand, most towers will be landmarks.



>
> My next thought was to apply "tourism=viewpoint", however that assumes
> public access to enter the tower. The Eiffel Tower is tagged
> "tourism=attraction" and "tower:type=communication;observation". Could
> tourism=attraction be a good option, it indicates something for tourists
> (or locals) to go and check out a bit like tourism=viewpoint even if you
> can only see it from the ground and can't go inside?
>


-1, tourism=attraction is a prominence flag without real meaning (it is
often hard to verify and it is not applied similarly on a global level
(often not even on a local level). People use it also for stuff they want
to have rendered on the map, and for which there is no established tag.
Therefore, the tag and its rendering actually slow down the development of
tags with more semantic meaning. If you have a specific scope (like
dividing the prominent from the insignificant towers), you should define
the criterion and develop specific tagging to represent it.





>
> Regarding mast vs tower, I've generally tagged buildings as towers (i.e.
> you can enter them even if just a staircase) and non-buildings as a mast
> (including a free standing metal or concrete pole with comms equipment
> mounted atop). I don't really mind, but a clear definition is definitely
> needed because I was unsure until I looked around at a heap of examples and
> just went with the building/non-building distinction.
>


+1, I would not insist for "guyed" for masts, and maybe not even for "free
standing" for towers. I would focus on the presence of platforms, visitors
or at least people regularly going there and staying there (e.g. an airport
control tower). I still believe, most true tower types should be main tags
(man_made=control_tower, )

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

Re: [Tagging] Combined waste/recycling bins

[Joseph Eisenberg]

Re: “convincing the renderer folks to render it“
Not as hard as you think. The folks at OpenStreetMap Carto have just
revamped the mapping of recycling and waste bins.
If you can get > 1000 uses of a new tag and can think of a good icon, it
could get rendered.
-Joseph

On Tue, Oct 9, 2018 at 11:32 PM Paul Allen  wrote:

> A village a few miles from me (but in a different county) recently got one
> of
> these combined litter/recycling bins:
>
> https://www.facebook.com/permalink.php?story_fbid=2241627292737699=1632021387031629&__tn__=C-R
>
> How to tag?  Each of the two sections is around the size of a large
> amenity=waste_basket.  The recycling half is a little smaller than the
> amenity=recycling + recycling_type=container images in the wiki, and they
> are a little smaller than the recycling containers I see around here.
>
> In any case, if I put both of those tags on a node only one of them would
> be rendered. If I use two nodes that are almost touching, only one of
> them would be rendered.
>
> These combined disposal things appear to be catching on, so I'd
> expect to see them increasingly replacing existing
> amenity=waste_basket.  It seems to me we probably need a dedicated
> tag that everyone agrees on (no chance of that happening) and then
> convincing the renderer folks to render it (the odds of that happening
> can only be expressed as multiples of the square root of -1).
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Traffic_sign discussion

[yo paseopor]

I want to start the mother of all discussions about traffic signs

It is not the first attempt to do that. Last days, with iD implementation
and my message I have think it was the solution. Also I have waited some
days and communicate to this list my intentions to adopt the proposed iD
scheme. But when I start to do the modifications... People complains about
it (I am sorry if there was some errors "translating" to the new scheme).

So Please , let's talk about it. What will be the correct way to tag a
traffic sign?

I start with my option. Traffic sign as a NODE on the way x direction.
Because traffic sign is relative to the way, the road, not the building or
the street itselfs, it is located above, as a road mark, on the right of
the road or on the left of the road (or both of them).

I'm interested in all countries so a good way to do it is with the country
code for every traffic sign you can find in every traffic law in every
country.
It would be interesting also to develope a generic scheme for tagging it
(not only the country/code)

traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of
each country traffic signs law)

Also it is facing to the direction of the way (forward and backward). In
OSM ways have the direction you have drawn it. So the info is relative to
this direction.

As an issue detected in iD with it to make possible the edition of traffic
signs good way was the traffic_signals solution: an specific key.

traffic_sign:direction=forward/backward/both

Also accepts other facing directions like 90/270...

Also we need the info relative to the way of its location , the side where
it is: Is it on the right? Is it on the left?

side=right/left/both

And also position, because you can have more than one traffic sign. Finnish
people give the solution :2

traffic_sign:2=*

To tag this we have some informations sources (of course first of all local
knowledge) like Mapillary or OpenStreetCam.

Tools we have now:

JOSM preset
JOSM style
JOSM Kendzi3D's configuration files and models
Leaflet traffic signs map
Taginfo stats

More info about it :

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

Main characteristics of the scheme:

-Scalable (you can locate every traffic sign in every place)
-Exportable (you can locate every traffic sign of every country in the
World, with or without JOSM wizards)
-1 key / 1 value (for making the renders easy to adopt it)

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

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

[Jonathon Rossi]

On Tue, Oct 9, 2018 at 5:34 PM Lionel Giard  wrote:

> The problem i see with that "multipurpose" value is that it give no
> information and could be misused for other tower:type (like
> defensive;observation) which should not be rendered as communication_tower.
> Thus i would propose to render the "communication_tower" based on the
> height > 250 m (arbitrary value for example) when in combination with
> tower:type=communication (even when others tower:type are mentioned like in
> your example : "tower:type=communication;observation"). I don't know if it
> is feasible for the renderer to identify the presence of only one value in
> the tag ? Otherwise i suppose it would need to put all alternative
> available... :s
>

Rather than trying to make up information (in the renderer) based on a
tower type or arbitrary height, wouldn't it be better to just indicate if
the tower is useful as a navigation aid and seen from a distance? Towers on
a mountain might not reach the arbitrary height but are still one of these
big towers because the surrounding area is much lower?

My first thought was some sort of "landmark=yes" tag, there is already a
"denotation=landmark" tag for trees, however it appears like there might
have been a landmark tag in the past that was deprecated, and I realise
that it would be a stupid tag because you'd have to tag everything.

My next thought was to apply "tourism=viewpoint", however that assumes
public access to enter the tower. The Eiffel Tower is tagged
"tourism=attraction" and "tower:type=communication;observation". Could
tourism=attraction be a good option, it indicates something for tourists
(or locals) to go and check out a bit like tourism=viewpoint even if you
can only see it from the ground and can't go inside?

Regarding mast vs tower, I've generally tagged buildings as towers (i.e.
you can enter them even if just a staircase) and non-buildings as a mast
(including a free standing metal or concrete pole with comms equipment
mounted atop). I don't really mind, but a clear definition is definitely
needed because I was unsure until I looked around at a heap of examples and
just went with the building/non-building distinction.

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

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

[Greg Troxel]

Graeme Fitzpatrick  writes:

> On Tue, 9 Oct 2018 at 03:58, SelfishSeahorse 
> wrote:
>
>> There is a risk that towers and masts are defined differently in
>> English, but perhaps Martin's idea to combine the two definitions
>> would make sense nevertheless.

Part of the issue is UK English vs US English, and usage common in
professional or amateur radio language vs public usage.

The same thing will be:

UK: Mobile phone mast
US: cell tower

> So, how about we clean up the various mixtures of definitions, &
> conflicting photos, to:
>
> man_made=mast: a vertical structure, supported by external guys and
> anchors. (Possibly also include: Has no internal access, can only be
> climbed by ladder?)

> man_made=tower: a tall, slim, freestanding vertical structure with internal
> access

The guy wires or not is made into the main thing here, but it's really a
detail.  In amateur radio, the same kind of tower (e.g. Rohn 45
sections, which are lattice) can sometimes be freestanding and sometimes
guyed.  Adding guy wires does not make them a mast.   There is a TV
antenna structure near me that might be 300m tall, is lattice, and it
has guys.  It is definitely "tower" by US usage.

In US amateur usage, mast often refers to something that is up to maybe
4" in diameter (and thus basically not climbable).  Often guyed, but not
always.  Basically, you add guy wires when you need to, which is a
function of material strength, height, wind loading of antennas on top,
and the wind levels you want the thing to survive.

In US cellular infrastructure, there are big lattice things that look
like someone obviously could climb them.  There are also things that are
several feet in diameter and round.  For all I know, these are the same
towers inside with a fairing to make them look better, and some may be
climbable internally.   But they are big, and function the same way, so
I would call them tower.

> man_made=communications_tower: to be deprecated (but also create a new
> tower:type=multipurpose for the massive 150m+ combined communication /
> observation / tourist attraction buildings)
>
> man-made=pole: (currently not defined) a usually vertical column used as a
> support for overhead utilities such as cables or antennae (Do we need a
> height reference eg a pole is <15m - if it's 15m+, it becomes a tower?)

So what's the difference between a pole and a mast?
A pole is used for power, and is usually wood, and a mast for antennas,
usually metal?

The world has a variety of shades of these things and there are going to
be edge cases.  The question is what we are trying to represent and why.
Arguably having a height tag is the most important thing for renderers.

So I would say of tall thin things to hold other things up high (which
leaves out arguing about vertical antennas):

  tower: anything lattice, anything > 1m diameter, anything > 50m high.
  ok to be guyed or not.  (so a 4m triangular lattice with 0.3m edges is
  still a tower, but that's ok with me)

  pole: anything not a tower, probably cannot be guyed, and either wood
  or > 0.25m diameter, such as is typically used for power lines (wood
  in distribution, and big wood or steel tubular in transmission (which
  also uses lattice).

  mast: anyhing not a tower or a pole.  ok to be guyed or not.
  Typically <= 0.1m diamater, but anything up to 0.25m is ok.

This definition proposal admits that these are all subtypes of the same
thing, and that things that people call towers are more substantial than
things called masts.

Really what I suggest is not so far from what you suggested, except that
I am de-emphasizing guying and calling anything that is big/substantial
by any of several metrics a tower.

I would probably also call broadcast antennas around 1 MHz "tower", even
though there the point is not to hold up something but the structure is
the antenna.  We could do the same for something used as an antenna that
is otherwise a mast.   Map users after all usually want to use these as
navigation references - at least that's why there are shown on
traditional nautical charts.

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

Re: [Tagging] Combined waste/recycling bins

[Paul Allen]

On Tue, Oct 9, 2018 at 5:09 PM marc marc  wrote:

> Le 09. 10. 18 à 16:30, Paul Allen a écrit :
> > How to tag?
>
> amenity=recycling
> recycling:cans=yes
> recycling:paper=yes
>

So far, so good.

recycling:PET=yes or recycling:plastic_bottles=yes
>

It's neither of those.  The plastic type isn't specified and it's not just
for bottles.  It may well
be the case that everything deposited is a PET bottle, but it need not be.

recycling:waste=yes
>

Umm, waste doesn't get recycled.  That's why it's waste.  One half of it is
a mixed-recycling
container and the other half is a container for non-recyclable rubbish.


> > only one of them would be rendered
>
> feel free to find/create/publish a icon that show the different types
> accepted by a container.
>

I think that's overkill.  It would be difficult (probably impossible) to
produce a legible icon for each
combination.  The best that might be possible is something incorporating
the current waste
receptacle icon with a recycling icon.  And I have my doubts about that
(it's certainly beyond my
artistic talents).

I just thought of something else.  People in that same village keep saying
that there aren't enough
doggy poo receptacles.  So their county council (but not mine, that I've
seen) provides containers for
specifically that kind of waste and no other.

If you're a tourist with a dog, you probably want to know about all three
kinds of receptacle.

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

Re: [Tagging] Combined waste/recycling bins

[marc marc]

Le 09. 10. 18 à 16:30, Paul Allen a écrit :
> How to tag?

amenity=recycling
recycling:cans=yes
recycling:paper=yes
recycling:PET=yes or recycling:plastic_bottles=yes
recycling:waste=yes


> only one of them would be rendered

feel free to find/create/publish a icon that show the different types 
accepted by a container.
it seems complicated to me, however, to consider an icon for each 
combination, it will probably be necessary at first to limit oneself to 
this combination if it is the new "norm" for you... and hope that the 
rendering team accepts this idea
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Telecom local networks

[Graeme Fitzpatrick]

Massive job, thanks Francois! :-)

Question for you pleasse.

Following on from the discussion re towers & masts, I've just mapped a
couple of mobile phone towers.

What should we call the base station hut / building usually adjacent to the
base of the tower

My understanding is they're not a street cabinet as you can walk inside
them.

So"
building=hut

telecom=???

communication=mobile_phone???

Thoughts / suggestions?

Thanks

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

Re: [Tagging] Game and toy library

[Paul Allen]

On Tue, Oct 9, 2018 at 10:24 PM ChameleonScales <
chameleonsca...@protonmail.com> wrote:

amenity:library=game_and_toy
>

When I added one of these, five months ago, the most popular way of doing
it was
amenity=toy_library, so that's what I went with.

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

Re: [Tagging] hydrants

[François Lacombe]

The question about the opening direction should be propagated to this draft
proposal regarding pipeline valves
https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal

I thought about turn_to_close=clockwise / anticlockwise
Whatever the final answer will be, this definitely have to be the same key
and values on both fire hydrants and any kind of pipeline valves.

The proposal can change at anytime until RFC.
All the best

François

Le mar. 9 oct. 2018 à 23:13, Paul Allen  a écrit :

> On Tue, Oct 9, 2018 at 9:34 PM Viking  wrote:
>
>>
>> As we did for most of the tags in [0], I would not use fire_hydrant:
>> prefix because we want a slim
>
> database and because  opening:direction=* is (or can be) used for other
>> objects, as doors, taps, etc.
>>
>
> There are differing viewpoints on this.
>
> 1) Minimize database keys by applying them as widely as possible.  So
> opening:direction applies to
> doors, taps, fire hydrants, etc.  Database designers might think this way,
> as might most ordinary
> mappers and most programmers.
>
> 2) Don't re-use keys in this way because you end up with different sets of
> values that apply in
> different situations.  People who program map editors tend to think this
> way.  Each time you use
> opening:direction for a different type of object the programmer has to
> special-case the set of possible
> values based on the associated values in order to populate drop-downs.  If
> you're mapping a
> tap you want the choice of opening:direction to be limited to clockwise
> and counterclockwise and
> not be confused by also seeing inwards and outwards; but for doors you
> want inwards and outwards
> but not clockwise and counterclockwise (unless it's a rotating door).
>
> I can see merits in both viewpoints.  The people who write map editors
> tend to win these arguments
> because most mappers choose from what the editor presents to them. :)
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Telecom local networks

[Paul Allen]

On Tue, Oct 9, 2018 at 11:05 PM François Lacombe 
wrote:

> Feel free to make any comment.
>

I thought you'd agreed that "Central Office" was left-pond terminology and,
since OSM is
based on right-pond terminology, you'd use "Exchange" instead.  There are
several places in
the proposal (including a heading) that refer to "Central Office."

I'm also baffled by "A central office is a building, a part of a building
or in some countries a street cabinet which connect a subscriber's home
with the service provider devices."  I don't think of a street cabinet
near subscribers full of DSLAMS as being central or an office, nor is it an
exchange.  It's a street
cabinet acting as a distribution hub.  Please do not try to force every
small collection of equipment
into the "Central Office"/"Exchange" model.  Otherwise you'll end up having
to map fibre optic
repeaters as central offices or exchanges.  I think it's down to bad
editing, but maybe you do
want to think of street cabinets as central offices (I don't).

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

Re: [Tagging] Game and toy library

[Martin Koppenhoefer]

sent from a phone

> On 10. Oct 2018, at 00:03, Paul Allen  wrote:
> 
> When I added one of these, five months ago, the most popular way of doing it 
> was
> amenity=toy_library, so that's what I went with.


+1, kiss


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

Re: [Tagging] Feature Proposal - RFC - Telecom local networks

[François Lacombe]

Hi Paul,

Le mer. 10 oct. 2018 à 00:31, Paul Allen  a écrit :

> I thought you'd agreed that "Central Office" was left-pond terminology
> and, since OSM is
> based on right-pond terminology, you'd use "Exchange" instead.  There are
> several places in
> the proposal (including a heading) that refer to "Central Office."
>

That's right, and the proposal has been updated to use the proper
terminology. Thanks.


> I'm also baffled by "A central office is a building, a part of a building
> or in some countries a street cabinet which connect a subscriber's home
> with the service provider devices."  I don't think of a street cabinet
> near subscribers full of DSLAMS as being central or an office, nor is it
> an exchange.  It's a street
> cabinet acting as a distribution hub.
>
It depends.
We can find the two possibilities and I don't write that all telecom
cabinets are actual telephone exchanges.

Such a cabinet :
https://lafibre.info/images/orange/201312_saints-geosmes_nra_med_2.jpg
hosts DSLAM, switches and WDM and is definitely an actual telephone
exchange in a street cabinet.
It's sometimes directly written on them: In France, NRA = Noeud de
Raccordement Abonnés = Subscribers connection node = Telephone exchange.
More here : https://lafibre.info/reseau-orange/nra-med/

Whereas this :
https://wiki.openstreetmap.org/wiki/File:British_outdoor_dslam_inside.jpg
is a more simpler outdoor dslam *linked* to an actual and remote telephone
exchange.
Then it's not a telecom exchange but a local loop component (distribution
hub, why not)


> Please do not try to force every small collection of equipment
> into the "Central Office"/"Exchange" model.
>
That's not my point nor my intention: I introduce telecom=service_device
for standalone dslams which are not in a proper telephone exchange.

Tagging proposal are here to provide consistent terminology to cover as
many cases as we can encounter on field.
Finding telecom networks data may be hard and this proposal is followed by
long term work to encourage telecom operators to open their network
documentation.
Open data will be required to complete the map.

All the best

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

Re: [Tagging] Traffic_sign discussion

[Martin Koppenhoefer]

sent from a phone

> On 9. Oct 2018, at 23:03, yo paseopor  wrote:
> 
> for this reason the solution of tag the traffic signs ON the way it's the 
> best way to do it. Traffic signs are relative to their ways (because if the 
> way does not exist the existance of traffic sign is non-sense). Ways have 
> direction, also their nodes can have this reference.


to me there is no point in mapping traffic signs on ways. Traffic signs are 
punctual items, their supposed effect (our interpretation what they imply for 
which way) is already mapped with established tags on the way. It is more 
accurate and more useful (for finding problems and inconsistencies) to have the 
signs mapped as nodes. 

Let me give you an example: I do find it helpful to map maxspeed signs on nodes 
(doing it at the side of the highway because this implies the direction), 
because it helps to verify and maintain the speed limit data on the highway. If 
these were replaced by tags on the highway it would be less useful, because 
they would merely repeat the information that maxspeed already gives, and you 
won’t have neither the confirmation of repeated max speed signs nor would you 
know until where a later discovered sign with a different maxspeed is “at most” 
valid. Every time you discover a new sign, with the tag on the way method you 
start again “from scratch”.

Adding traffic sign ids to ways makes only sense if you mistrust the osm tags, 
e.g. because there aren’t the exact tags you would need to describe the effect 
of a sign. My suggestion would be to improve/amend the system of human readable 
tags in this case, so that they fulfill your local requirements.

I do recognize there can be some usefulness in both information (actual signs 
and their position=nodes, and the actual signs that led to certain tags being 
applied on an object (=ways)). I am not sure it is a good idea to use the same 
tags for it.


Cheers,
Martin


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

Re: [Tagging] Traffic_sign discussion

[Colin Smale]

I am not saying these cases are impossible, only that they have to be
accommodated, preferably as uniformly as possible. It is not intended as
criticism, but as a critical test of fitness for purpose. If the tagging
scheme can't handle these real-world situations, it's not ready for
go-live yet.

On 2018-10-09 23:40, yo paseopor wrote:

> On Tue, Oct 9, 2018 at 8:16 PM Colin Smale  wrote: 
> 
>> I can think of a couple of non-trivial cases which will need to be handled: 
>> 
>> 1) multiple signs on a single post
> 
> As Finnish people do we can add subkey :2 :3 :4... (European regulations does 
> nit recommend more than 3 traffic_signs together to make better their 
> readibility.

This is of course a fairly easy one. What European regulations are you
referring to here by the way? 

>> 2) signs with a dependent (qualifier) sign, such as "except for buses"
> 
> Complementary signs are also traffic signs (in second, in third position) 
> with its own code, so they need their information (the same osm tags we have 
> for ways?)  and position. A few weeks ago in this list I talk about the 
> possible changes for "designation" value to make a key with this more 
> specific information

How do you make the link between the qualifier and the main sign it
applies to? Does it only apply to the one sign immediately above? Or to
all signs above? Or the sign(s) below? How would these links work for
multiple qualifier signs, like "except for buses" / "except with
permit"? 

>> 3) one or more signs on a larger panel - too large to represent as a node
> 
> Sorry but I don't agree with you... because I test it...and it works. Example 
> for a complete destination traffic sign 
> 
> COLOUR:ARROW
> black
> 
> COLOUR:ARROW:LOWER_PANEL
> white
> 
> COLOUR:BACK
> white
> 
> COLOUR:BACK:LOWER_PANEL
> blue
> 
> COLOUR:REF
> red
> 
> COLOUR:REF:LOWER_PANEL
> blue
> 
> COLOUR:TEXT
> white
> 
> COLOUR:TEXT:LOWER_PANEL
> white
> 
> DESTINATION:LOWER
> Coma-ruga
> 
> DESTINATION:LOWER_PANEL
> Barcelona
> 
> DESTINATION:LOWER_PANEL:LOWER
> Aeroport
> 
> DESTINATION:LOWER_PANEL:UPPER
> Vilanova i la Geltrú
> 
> DESTINATION:SYMBOL:LOWER_PANEL:LOWER
> airport
> 
> DESTINATION:UPPER
> El Vendrell
> 
> LENGTH [1]
> 500
> 
> REF [2]
> N-340
> 
> REF:LOWER_PANEL
> C-32
> 
> SIDE
> up
> 
> TIME:1
> 00:05
> 
> TIME:3
> 00:05
> 
> TIME:B
> 01:00
> 
> TIME:B:1
> 00:20
> 
> TIME:B:3
> 00:45
> 
> TRAFFIC_SIGN:2:FORWARD
> ES:S235a
> 
> TRAFFIC_SIGN:FORWARD
> ES:S235a
> 
> TURN:DESTINATION
> under
> 
> TURN:DESTINATION:LOWER_PANEL
> under
> 
> TYPE [3]
> destination_sign

How does anyone or anything (a data consumer) connect the
"traffic_sign:forward=ES:S235a" to the way that it applies to? Not all
junctions are nice 4-way 90-degree junctions. What have you "tested"
exactly? Where do you place the node for this sign in relation to the
way? Maybe if you could give a link or an exact location of this sign,
then we could have a look and see what you intend. 

>> 4) signs applying only to certain lanes
> 
> you can specify the lanes and the exact information with all these tags 
> (lanes scheme already exists)

Of course the lanes scheme exists, but it is currently applied to ways.
Should we indicate a bus lane by a node representing the sign, or as an
attribute of the way? Surely not as both. No trucks in the left hand
lane? Easy to tag on the way with lanes tagging, but what about the
sign, which might also say "buses only in the second lane except on
Tuesday" etc etc. I am not trying to be difficult here - these crazy
scenarios really do occur, and OSM needs to be able to deal with them.
You are suggesting encoding this information as tagging on a single
node; I think that's a challenge if you expect anyone/anything to be
able to interpret it properly. 

>> 5) signs on a gantry above (half of) the road
> 
> The example above is like the granty sign (with the same tags)

Is a gantry tagged as a single node, or a "way" crossing the highway?
The gantry may cross the entire highway, but the signs are only in one
direction. How to handle that? 

>> I can understand the argument for mapping the signs as objects in their own 
>> right. This would be limited to being a database of street furniture, unless 
>> and until the effect of the signs can be linked to the effect they have on 
>> traffic (in the broadest sense), which is the starting point for the present 
>> discussion. This is of course a serious exercise to ensure the link from the 
>> sign to the effect is represented unambiguously.
> 
> Barrier nodes acts in routing, why not the prohibition in overtaking? or the 
> city limit? or the warnings?

Indeed, but we are talking about traffic signs here. How would you
propose to  

>> We already have turn restrictions, maxspeed, maxheight etc on the ways 
>> themselves (without needing to have any link to a sign). This model works 
>> reasonably well for routing applications, albeit not without some discussion 
>> about the types of "weight" and so on.

Re: [Tagging] hydrants

[François Lacombe]

Hi,

Le mer. 10 oct. 2018 à 00:45, Paul Allen  a écrit :

> On Tue, Oct 9, 2018 at 11:31 PM François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> The question about the opening direction should be propagated to this
>> draft proposal regarding pipeline valves
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal
>>
>> I thought about turn_to_close=clockwise / anticlockwise
>> Whatever the final answer will be, this definitely have to be the same
>> key and values on both fire hydrants and any kind of pipeline valves.
>>
>
> Those are both valves operated with rotary motions.  No problem using the
> same key/values for
> both.  Or for any other kind of valve operated with a rotary motion.  The
> problem comes when, as
> somebody suggested, applying it to doors too, so then the editor preset
> would have to be context
> sensitive.  Your choice of key prevents it being applied to doors..
>
It depends which doors, and mainly depend of the actuator associated with
the valve
Here is a door valve and a wheel has to be handled to open or close.
http://www.orbinox.com/orbinox/usuariosFtp/conexion/imagenes2163a0.jpg
Datasheet : http://www.orbinox.com/extranet/descarga.aspx?sg=1=1787

It pretty obvious that when no rotation is needed to open or close any
valve, tap or door, then keys like turn_to_close won't be appropriate nor
used.
On valves proposal, turn_to_close will only be available in association
with certain handle=* values (certainly handle=wheel).
handle=* can also be used on fire hydrant if needed.


> Not that we're likely to map taps until
> nanomapping becomes popular, but somebody suggested it.
>

handle=* solves the problem.

All the best

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

Re: [Tagging] Traffic_sign discussion

[Tobias Knerr]

On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?

How about the existing tagging scheme for traffic signs on nodes,
documented at https://wiki.osm.org/Key:traffic_sign ?

To sum it up:

- Place a node for the traffic sign into the highway=* way.¹
- Tag the node as traffic_sign=:.
- As with your suggestion,  is the ISO country code.
-  is composed of one or more country-specific traffic sign ids, as
an ordered list separated by commas.
- If there are multiple groups of traffic signs, these groups are
separated by semicolons.
- Custom inscriptions on a sign are appended to the sign id in square
brackets [].

¹ The page also documents how to map traffic signs next to the way, but
I understand you would like to talk about mapping them as part of the way.

I haven't seen a convincing reason for changing this yet. I'm aware of
the general argument against semicolon-separated or comma-separated
lists of values, but imo this is less critical for keys that have
well-defined semantics for such characters.

> traffic_sign:direction=forward/backward/both
> 
> Also accepts other facing directions like 90/270...

In my opinion, traffic signs should use the normal direction=* key for
angles such as 90 or 270. This usage is part of the approved proposal of
that key:

https://wiki.osm.org/Proposed_features/direction#Point_features

Using traffic_sign:direction specifically for the "forward" and
"backward" values, as discussed in the recent iD-related thread, is fine.

> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging

I find it hard to discuss this proposal because it includes so many
different ideas:

- introducing a system of "categories" for signs: caution, warning, etc.
- using :2, :3 etc. instead of comma-separated ids
- using human-readable values instead of unambiguous national IDs
- re-purposing maxspeed (and maxspeed:hgv etc.) for traffic sign mapping
- adding a side=* key
- improving destination sign and roundabout mapping

Trying to change all that at once likely leads to discussions that mix
all sorts of loosely related topics. And there's not really a reason why
e.g. introducing the side=* key would also require using numeric
suffixes. These are independent changes that could easily be discussed
separately.

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

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

Why not map traffic signs the way enforcement devices are currently mapped
in relations?  That's more foolproof than relying on nodes having nonextant
direction, especially when most traffic signs aren't even members of ways.

On Tue, Oct 9, 2018, 10:46 yo paseopor  wrote:

>
> I want to start the mother of all discussions about traffic signs
>
> It is not the first attempt to do that. Last days, with iD implementation
> and my message I have think it was the solution. Also I have waited some
> days and communicate to this list my intentions to adopt the proposed iD
> scheme. But when I start to do the modifications... People complains about
> it (I am sorry if there was some errors "translating" to the new scheme).
>
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?
>
> I start with my option. Traffic sign as a NODE on the way x direction.
> Because traffic sign is relative to the way, the road, not the building or
> the street itselfs, it is located above, as a road mark, on the right of
> the road or on the left of the road (or both of them).
>
> I'm interested in all countries so a good way to do it is with the country
> code for every traffic sign you can find in every traffic law in every
> country.
> It would be interesting also to develope a generic scheme for tagging it
> (not only the country/code)
>
> traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific
> of each country traffic signs law)
>
> Also it is facing to the direction of the way (forward and backward). In
> OSM ways have the direction you have drawn it. So the info is relative to
> this direction.
>
> As an issue detected in iD with it to make possible the edition of traffic
> signs good way was the traffic_signals solution: an specific key.
>
> traffic_sign:direction=forward/backward/both
>
> Also accepts other facing directions like 90/270...
>
> Also we need the info relative to the way of its location , the side where
> it is: Is it on the right? Is it on the left?
>
> side=right/left/both
>
> And also position, because you can have more than one traffic sign.
> Finnish people give the solution :2
>
> traffic_sign:2=*
>
> To tag this we have some informations sources (of course first of all
> local knowledge) like Mapillary or OpenStreetCam.
>
> Tools we have now:
>
> JOSM preset
> JOSM style
> JOSM Kendzi3D's configuration files and models
> Leaflet traffic signs map
> Taginfo stats
>
> More info about it :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>
> Main characteristics of the scheme:
>
> -Scalable (you can locate every traffic sign in every place)
> -Exportable (you can locate every traffic sign of every country in the
> World, with or without JOSM wizards)
> -1 key / 1 value (for making the renders easy to adopt it)
>
> yopaseopor
> ___
> 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 discussion

[Colin Smale]

I can think of a couple of non-trivial cases which will need to be
handled: 

1) multiple signs on a single post 

2) signs with a dependent (qualifier) sign, such as "except for buses" 

3) one or more signs on a larger panel - too large to represent as a
node 

4) signs applying only to certain lanes 

5) signs on a gantry above (half of) the road 

I can understand the argument for mapping the signs as objects in their
own right. This would be limited to being a database of street
furniture, unless and until the effect of the signs can be linked to the
effect they have on traffic (in the broadest sense), which is the
starting point for the present discussion. This is of course a serious
exercise to ensure the link from the sign to the effect is represented
unambiguously. 

We already have turn restrictions, maxspeed, maxheight etc on the ways
themselves (without needing to have any link to a sign). This model
works reasonably well for routing applications, albeit not without some
discussion about the types of "weight" and so on. 

The point I am trying to make, is that there might not be much of a
"business case" for linking the signs/posts to their effects, and that
mapping them as "street furniture" might be going far enough... 

On 2018-10-09 17:42, yo paseopor wrote:

> I want to start the mother of all discussions about traffic signs 
> 
> It is not the first attempt to do that. Last days, with iD implementation and 
> my message I have think it was the solution. Also I have waited some days and 
> communicate to this list my intentions to adopt the proposed iD scheme. But 
> when I start to do the modifications... People complains about it (I am sorry 
> if there was some errors "translating" to the new scheme). 
> 
> So Please , let's talk about it. What will be the correct way to tag a 
> traffic sign? 
> 
> I start with my option. Traffic sign as a NODE on the way x direction. 
> Because traffic sign is relative to the way, the road, not the building or 
> the street itselfs, it is located above, as a road mark, on the right of the 
> road or on the left of the road (or both of them). 
> 
> I'm interested in all countries so a good way to do it is with the country 
> code for every traffic sign you can find in every traffic law in every 
> country.  
> It would be interesting also to develope a generic scheme for tagging it (not 
> only the country/code) 
> 
> traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific of 
> each country traffic signs law) 
> 
> Also it is facing to the direction of the way (forward and backward). In OSM 
> ways have the direction you have drawn it. So the info is relative to this 
> direction. 
> 
> As an issue detected in iD with it to make possible the edition of traffic 
> signs good way was the traffic_signals solution: an specific key. 
> 
> traffic_sign:direction=forward/backward/both 
> 
> Also accepts other facing directions like 90/270... 
> 
> Also we need the info relative to the way of its location , the side where it 
> is: Is it on the right? Is it on the left?  
> 
> side=right/left/both 
> 
> And also position, because you can have more than one traffic sign. Finnish 
> people give the solution :2 
> 
> traffic_sign:2=* 
> 
> To tag this we have some informations sources (of course first of all local 
> knowledge) like Mapillary or OpenStreetCam. 
> 
> Tools we have now: 
> 
> JOSM preset 
> JOSM style 
> JOSM Kendzi3D's configuration files and models 
> Leaflet traffic signs map 
> Taginfo stats 
> 
> More info about it : 
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>  
> 
> Main characteristics of the scheme: 
> 
> -Scalable (you can locate every traffic sign in every place) 
> -Exportable (you can locate every traffic sign of every country in the World, 
> with or without JOSM wizards) 
> -1 key / 1 value (for making the renders easy to adopt it) 
> 
> yopaseopor 
> ___
> 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 discussion

[Frederik Ramm]

Hi,

On 10/09/2018 05:42 PM, yo paseopor wrote:
> It is not the first attempt to do that. Last days, with iD
> implementation and my message I have think it was the solution. Also I
> have waited some days and communicate to this list my intentions to
> adopt the proposed iD scheme. But when I start to do the
> modifications... People complains about it (I am sorry if there was some
> errors "translating" to the new scheme).

Yes, DWG has also received complaints about these edits, and I am in the
process of reverting them.

At the very least you should have established a consensus on this list
for the precise edit you want to perform. You should have said: I am
going to load objects tagged so-and-so, and I am going to apply these
modifications using these tools.  (consensus doesn't mean everyone has
to be in favour, but you simply went ahead and changed things and wrote
in your changeset comment "#fastag #traffic_signs Apply
traffic_sign:direction tag to avoid problems with new iD editor as an
agreement on tagging list" which almost sounds like you were fixing a
bug and there was consensus, neither of which is strictly true.

I'm not saying these edits cannot ever be made, but they can certainly
not be made in a buggy fashion after a half-hearted attempt at
discussion with no discernible outcome.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] hydrants

[Viking]

Bkill, you added fire_hydrant:opening to wiki page [0], but you should have 
discussed it here and/or in discussion page before.
We did many efforts to widely discuss fire hydrant extensions [1] and finally 
approve them: you should at least discuss your proposal with people who spent 
so much time in this project.

Anyway, as a firefighter, I have to say that the opening direction is a 
marginal tag for firefighting purposes, because you don't need to know this 
information to choose on a map which hydrant to use to refill the fire engine.
But if you still want to add this information, we need to refine it, for this 
reason discussion is important.

The use of handedness=right / left is prone to error.
Normally on hydrants it is indicated the direction of opening and usually it is 
counterclockwise. But technically these hydrants' valves have right-hand 
threads (right handedness): you turn it clockwise to tighten the valve and 
close the hydrant.
So if you read on a hydrant the counterclockwise opening direction, you should 
tag it with handedness=right. This creates confusion to a normal mapper.

direction=clockwise/counterclockwise has similiar problem: you can intend it as 
the opening direction or as the thread direction (closing direction).

On the other hand, fire_hydrant:opening=cw / ccw is not self-explanatory, 
because someone can intend it as the number of openings (couplings).

Personally I would not add this tag at all.
But, if you still want to add this information, I think that something like:

opening:direction=clockwise / counterclockwise

As we did for most of the tags in [0], I would not use fire_hydrant: prefix 
because we want a slim database and because  opening:direction=* is (or can be) 
used for other objects, as doors, taps, etc.

[0] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant
[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions_(part_2)

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] Combined waste/recycling bins

[bkil]

You can tag the doggy bins like so:

amenity=waste_basket
waste=dog_excrement
vending=excrement_bags

I've also seen waste_basket:excrement_bags=yes and fee=no, but I don't
see much value in these at this point in time.
On Tue, Oct 9, 2018 at 6:30 PM Paul Allen  wrote:
>
> On Tue, Oct 9, 2018 at 5:09 PM marc marc  wrote:
>>
>> Le 09. 10. 18 à 16:30, Paul Allen a écrit :
>> > How to tag?
>>
>> amenity=recycling
>> recycling:cans=yes
>> recycling:paper=yes
>
>
> So far, so good.
>
>> recycling:PET=yes or recycling:plastic_bottles=yes
>
>
> It's neither of those.  The plastic type isn't specified and it's not just 
> for bottles.  It may well
> be the case that everything deposited is a PET bottle, but it need not be.
>
>> recycling:waste=yes
>
>
> Umm, waste doesn't get recycled.  That's why it's waste.  One half of it is a 
> mixed-recycling
> container and the other half is a container for non-recyclable rubbish.
>
>>
>> > only one of them would be rendered
>>
>> feel free to find/create/publish a icon that show the different types
>> accepted by a container.
>
>
> I think that's overkill.  It would be difficult (probably impossible) to 
> produce a legible icon for each
> combination.  The best that might be possible is something incorporating the 
> current waste
> receptacle icon with a recycling icon.  And I have my doubts about that (it's 
> certainly beyond my
> artistic talents).
>
> I just thought of something else.  People in that same village keep saying 
> that there aren't enough
> doggy poo receptacles.  So their county council (but not mine, that I've 
> seen) provides containers for
> specifically that kind of waste and no other.
>
> If you're a tourist with a dog, you probably want to know about all three 
> kinds of receptacle.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[bkil]

Why is shop=convenience not a proper tag for "the only retail building
in 40 miles radius"? Extra tags could be invented to highlight that it
has a larger variety of non-food items than usual, or we could
introduce a subtype with convenience=*.
On Tue, Oct 9, 2018 at 10:42 AM John Willis  wrote:
>
> sounds like there are several different kinds of shops being discussed
>
>
> - old old “markets”, from before there were super markets or convenience 
> shops.
>
> - import/foreign foods shops catering to a local minority population or 
> special cultural interest
>
> - “markets” in developing countries.
>
>
> On Oct 9, 2018, at 11:56 AM, Joseph Eisenberg  
> wrote:
>
> What do you think about the need for a shop=grocery tag for small shops in 
> developing countries and specialty grocers in cities?
>
>
> Are there still small groceries in Japan which sell non-perishable food 
> items, but would not be properly considerd a shop=convenience, shop=general, 
> shop=greengrocer or shop=supermarket?
>
>
> I know the shops that you speak of. They were the local “everyday needs” shop 
> - the market/grocery shop, very similar to a general store - but in an urban 
> area. they were the only shop that had some of everything that wasn't covered 
> by the Rice shop, fish shop, the butcher, and the produce stand:  curry mix, 
> spices, dish soap, eggs, milk, toilet paper, etc. they would be shop=market, 
> if that exists.They still exist in Japan, but are almost gone. The mom-n-pop 
> ones are operated by people that live over the shop, and they are still 
> operated for the locals to come sit there and gossip - but everyone goes to 
> the supermarket 3 minutes away. they never look like they sell anything, and 
> most have been shuttered, but a few are still there.  the only corner market 
> I knew of was there are a few shop=general out in the mountains - but all the 
> “markets” were put out of business by supermarkets a long time ago in 
> California. I know of only one from personal experience. I hear of the 
> “corner shop” or “bodegas” in New York - similar to the little corner market 
> Bullitt buys his frozen dinners from in the movie in San Francisco - they 
> seem to be disappearing in developed countries.
>
> They are the proto-market: the Convenience store is more convenient, they 
> have no departments, they are not specific enough to be a greengrocer nor 
> have a stock of blankets, bullets, motor oil, and firewood like a general 
> store - they are the “daily market”, not a giant supermarket - the corner 
> store.
>
> a small market for daily living in developing countries feels like it would 
> be a shop=general - a general store has a certain feeling when it is the only 
> retail building in 40 miles in any direction, perhaps that is similar to the 
> developing country shops.
>
> I think shop=general for the small developing countries’ markets or these 
> fading local markets would be a good kludge, but it is not a fit **at all** 
> for some specialty shop in a big city.
>
> Mediterranean groceries or Caribbean foods, as found in some big cities.
>
>
> This is a great question. there are all kinds of [asian country] markets in 
> San Diego, and there are Philippine, Brazilian, and “Halal foods” shops here 
> in my area of Japan. There are also chain shops catering to “foreign foods” : 
> American snacks, British mints, South American Coffee, Italian pasta, etc. 
> they almost always are around food.
>
> if there is a convenience store, a supermarket, a “halal foods” shop, and a 
> butcher shop on the same block - that isn’t 4 “markets” - I think the idea of 
> a “foreign foods" market is good - and then choose a theme or country, or 
> religion, or similar tag would work.  . I don’t know how that aspect would be 
> tagged - but the type of shop - the “import goods from some far off place 
> catering to a minorty group that lives in the region” is a very very common 
> occurrence, and very very rarely considered by the majority residents to be a 
> place to go shopping (they all shop at the supermarket, as their ethnic and 
> culturally specific goods are stocked there). I think having a shop=halal and 
> a shop=Japanese would be wrong - as the only place they would be used is 
> outside those areas, and confusing for people inside those areas.
>
> If we try to come up with a tag that fits all these uses, it won’t fit. We 
> need to create shop=* tags to fit these separately.
>
> Javbw
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] How to tag prefab / movable buildings

[François Lacombe]

Hi all,

Prefabrication often ease the move of such buildings but it's not mandatory.

According to all suggestions, what about this:
structure:prefabricated=yes (the whole building is prefabricated)
structure:prefabricated=facade (only the facade)
structure:prefabricated= * any building part *

OR
building:prefabricated=yes
facade:prefabricated=yes
* any building part*:prefabricated=yes

structure:prefabricated is not consistent facade:prefabricated=yes since
structure is not an actual building part

I'd go for the second one, let me know.

All the best
François

Le dim. 30 sept. 2018 à 02:20, Graeme Fitzpatrick  a
écrit :

> How about demountable buildings, which are "supposed" to be temporary (but
> I know of some at schools that have been in place for +30 years now!)
>
> eg https://www.lloydsauctions.com.au/insider/portable-buildings/
>
> 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 discussion

[yo paseopor]

for this reason the solution of tag the traffic signs ON the way it's the
best way to do it. Traffic signs are relative to their ways (because if the
way does not exist the existance of traffic sign is non-sense). Ways have
direction, also their nodes can have this reference.

Relations are complex and also are an item not all the mappers can do. Why
don't accept the easiest way to get this information?
(Now it works without relations)

yopaseopor

On Tue, Oct 9, 2018 at 7:53 PM Paul Johnson  wrote:

> Why not map traffic signs the way enforcement devices are currently mapped
> in relations?  That's more foolproof than relying on nodes having nonextant
> direction, especially when most traffic signs aren't even members of ways.
>
> On Tue, Oct 9, 2018, 10:46 yo paseopor  wrote:
>
>>
>> I want to start the mother of all discussions about traffic signs
>>
>> It is not the first attempt to do that. Last days, with iD implementation
>> and my message I have think it was the solution. Also I have waited some
>> days and communicate to this list my intentions to adopt the proposed iD
>> scheme. But when I start to do the modifications... People complains about
>> it (I am sorry if there was some errors "translating" to the new scheme).
>>
>> So Please , let's talk about it. What will be the correct way to tag a
>> traffic sign?
>>
>> I start with my option. Traffic sign as a NODE on the way x direction.
>> Because traffic sign is relative to the way, the road, not the building or
>> the street itselfs, it is located above, as a road mark, on the right of
>> the road or on the left of the road (or both of them).
>>
>> I'm interested in all countries so a good way to do it is with the
>> country code for every traffic sign you can find in every traffic law in
>> every country.
>> It would be interesting also to develope a generic scheme for tagging it
>> (not only the country/code)
>>
>> traffic_sign=XX:yyy (XX Country ISO code):(yyy ref or number in specific
>> of each country traffic signs law)
>>
>> Also it is facing to the direction of the way (forward and backward). In
>> OSM ways have the direction you have drawn it. So the info is relative to
>> this direction.
>>
>> As an issue detected in iD with it to make possible the edition of
>> traffic signs good way was the traffic_signals solution: an specific key.
>>
>> traffic_sign:direction=forward/backward/both
>>
>> Also accepts other facing directions like 90/270...
>>
>> Also we need the info relative to the way of its location , the side
>> where it is: Is it on the right? Is it on the left?
>>
>> side=right/left/both
>>
>> And also position, because you can have more than one traffic sign.
>> Finnish people give the solution :2
>>
>> traffic_sign:2=*
>>
>> To tag this we have some informations sources (of course first of all
>> local knowledge) like Mapillary or OpenStreetCam.
>>
>> Tools we have now:
>>
>> JOSM preset
>> JOSM style
>> JOSM Kendzi3D's configuration files and models
>> Leaflet traffic signs map
>> Taginfo stats
>>
>> More info about it :
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging
>>
>> Main characteristics of the scheme:
>>
>> -Scalable (you can locate every traffic sign in every place)
>> -Exportable (you can locate every traffic sign of every country in the
>> World, with or without JOSM wizards)
>> -1 key / 1 value (for making the renders easy to adopt it)
>>
>> yopaseopor
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Greengrocer vs grocery vs shop=food?

[John Willis]

> On Oct 10, 2018, at 4:39 AM, bkil  wrote:
> 
> Why is shop=convenience not a proper tag for "the only retail building
> in 40 miles radius"?

Usually, the small retail shop in a very remote place is tailored to the daily 
needs of locals and tourists who do activities in that area. they stock goods 
that the locals need for daily life. 

There is one general store I know of 
https://www.openstreetmap.org/node/2519472645

Someone has tagged it as a convenience store. 

A convenience store is is convenient not only because of its proximity, 
relative to the larger supermarkets, but also because of the limited subset of 
goods. 

A general store is a store of necessity - there is no choice but it. It is the 
only practical choice unless you want to drive 2 hours round trip into "town" 
and get something at a supermarket. 

Perhaps this is bias: I grew up with 7-11s in suburban San Diego and would 
encounter general stores only when out in the mountains or deserts - they carry 
a very different mix of goods. You usually can't buy firewood, snow sleds, or 
video rental at a traditional 7-11. In Japan, you can find convenience stores 
serving very small communities in remote areas - but they carry similar goods 
to the ones in urban centers. They feel like convenience stores. Shop=general 
has some of the same goods as a convenience store - but other goods as well. 
Goods that cater to tourism activities in the area and locals who have no other 
practical choice. The "general store" you see in old western frontier towns is 
a good example. 

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

Re: [Tagging] hydrants

[Paul Allen]

On Tue, Oct 9, 2018 at 9:34 PM Viking  wrote:

>
> As we did for most of the tags in [0], I would not use fire_hydrant:
> prefix because we want a slim

database and because  opening:direction=* is (or can be) used for other
> objects, as doors, taps, etc.
>

There are differing viewpoints on this.

1) Minimize database keys by applying them as widely as possible.  So
opening:direction applies to
doors, taps, fire hydrants, etc.  Database designers might think this way,
as might most ordinary
mappers and most programmers.

2) Don't re-use keys in this way because you end up with different sets of
values that apply in
different situations.  People who program map editors tend to think this
way.  Each time you use
opening:direction for a different type of object the programmer has to
special-case the set of possible
values based on the associated values in order to populate drop-downs.  If
you're mapping a
tap you want the choice of opening:direction to be limited to clockwise and
counterclockwise and
not be confused by also seeing inwards and outwards; but for doors you want
inwards and outwards
but not clockwise and counterclockwise (unless it's a rotating door).

I can see merits in both viewpoints.  The people who write map editors tend
to win these arguments
because most mappers choose from what the editor presents to them. :)

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

[Tagging] Game and toy library

[ChameleonScales]

Hi all,

Game and toy libraries don't fit in any feature type.
They can be but are not necessarily:
- non-profit organizations
- child care facilities
- social faciilties
- toy stores
- libraries
- probably other things

So I think they should have their own feature type and tag.
How about
amenity:library=game_and_toy

Would that be possible?

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic_sign discussion

[Paul Johnson]

On Tue, Oct 9, 2018, 16:05 yo paseopor  wrote:

> for this reason the solution of tag the traffic signs ON the way it's the
> best way to do it. Traffic signs are relative to their ways (because if the
> way does not exist the existance of traffic sign is non-sense). Ways have
> direction, also their nodes can have this reference.
>

It's also not correct, that's not where the sign is.

Relations are complex and also are an item not all the mappers can do.
>

Only if the editor makes it hard.  See also: Turn restrictions, routes.

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

Re: [Tagging] Traffic_sign discussion

[yo paseopor]

On Tue, Oct 9, 2018 at 8:16 PM Colin Smale  wrote:

> I can think of a couple of non-trivial cases which will need to be handled:
>
> 1) multiple signs on a single post
>
  As Finnish people do we can add subkey :2 :3 :4... (European regulations
does nit recommend more than 3 traffic_signs together to make better their
readibility.

>
> 2) signs with a dependent (qualifier) sign, such as "except for buses"
>
 Complementary signs are also traffic signs (in second, in third position)
with its own code, so they need their information (the same osm tags we
have for ways?)  and position. A few weeks ago in this list I talk about
the possible changes for "designation" value to make a key with this more
specific information

> 3) one or more signs on a larger panel - too large to represent as a node
>
Sorry but I don't agree with you... because I test it...and it works.
Example for a complete destination traffic sign

colour:arrow black
colour:arrow:lower_panel white
colour:back white
colour:back:lower_panel blue
colour:ref red
colour:ref:lower_panel blue
colour:text white
colour:text:lower_panel white
destination:lower Coma-ruga
destination:lower_panel Barcelona
destination:lower_panel:lower Aeroport
destination:lower_panel:upper Vilanova i la Geltrú
destination:symbol:lower_panel:lower airport
destination:upper El Vendrell
length  500
ref  N-340
ref:lower_panel C-32
side up
time:1 00:05
time:3 00:05
time:b 01:00
time:b:1 00:20
time:b:3 00:45
traffic_sign:2:forward ES:S235a
traffic_sign:forward ES:S235a
turn:destination under
turn:destination:lower_panel under
type 
destination_sign


> 4) signs applying only to certain lanes
>
you can specify the lanes and the exact information with all these tags
(lanes scheme already exists)

> 5) signs on a gantry above (half of) the road
>
The example above is like the granty sign (with the same tags)

> I can understand the argument for mapping the signs as objects in their
> own right. This would be limited to being a database of street furniture,
> unless and until the effect of the signs can be linked to the effect they
> have on traffic (in the broadest sense), which is the starting point for
> the present discussion. This is of course a serious exercise to ensure the
> link from the sign to the effect is represented unambiguously.
>
Barrier nodes acts in routing, why not the prohibition in overtaking? or
the city limit? or the warnings?


> We already have turn restrictions, maxspeed, maxheight etc on the ways
> themselves (without needing to have any link to a sign). This model works
> reasonably well for routing applications, albeit not without some
> discussion about the types of "weight" and so on.
>
Signs are a next level for routing, for GPS software. Why Street View cars
and software wants to recognize traffic signs? Why don't you have the
possibility to have the traffic signs recreated in your own screen, with
only OSM data in a node?



> The point I am trying to make, is that there might not be much of a
> "business case" for linking the signs/posts to their effects, and that
> mapping them as "street furniture" might be going far enough...
>
More than 30 countries, more than 24000 different traffic signs. In each
country with their own traffic signs...why not? Are street lamps important?
Are recycle bins important? Are Benchs important?

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