Hi Jo/Polyglot and list,
On 22 January 2015 at 12:01, Jo winfi...@gmail.com wrote:
Which too schemes? I think you'd need to be more specific.
1. key=values;separated;by;semicolon
2. several key:subkey=*
It is not as formal as a proposal voting. I would like to know how the
community (those who vote) think about associatedStreet relations. I think
that in Germany the majority does not like them (anymore).
I will announce a end date. This end date will be date of announcement of end
of
Please vote here:
https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet
Is this a formal voting?
Is there a date for start and end vote?
It looks strange, hidden on a Talk:page without the usual template or
RFC or call for votes on the international mailing lists.
althio
First point:
It is good that several people invent, propose and use various schemes.
Second point:
At some point, unification of schemes with similar intent would be great.
As usage grows, having the same kind of data treated differently is a pain
for everyone, mappers, developers, maintainers
I even find the second example more difficult to visualize. It's just
worse
than the first in every respect.
From a mapper's point of view
My little +1 for key:subkey=*
In free text like this thread, several key:subkey=* may look more heavy and
complicated than
like:
amenity=hairdresser
name=Scalp
culture=punk
?
Exactly, I provided other examples in my previous message such as
culture=country, culture=grunge, culture=shinto.
Using several keys ethnicity=* + nationality=* + subculture=* all together
would be unambiguous but I think culture=* does a
Warin 61sundow...@gmail.com wrote:
What is the basic philosophy of OSM tagging at the top level?
...
Is there an FAQ on this? Or has this never been documented
I do not have a FAQ on philosophy, only this and that...
A few entries about 'how to create/propose/use' tags:
John Willis jo...@mac.com wrote:
I think there should be ethnic=*, Nationality=* , or culture=*tag that
can be used [...]
I find culture=* the best so far.
I find it specialised enough (compared to _type=*, origin=*, category=*,
group=* ...)
I find it accurate enough.
I find it generic enough
My main suggestion would be to re-use the same scheme as
Key:opening_hours to define the time when the waterway is likely to
flow.
I would also discard rare/frequent as too subjective. Instead:
approximate duration are not perfect but should improve mutual
understanding.
For instance as in:
I didn't follow every bits of the discussion, so sorry for
interrupting. Sorry also if my proposals are out of scope or already
reviewed. Maybe a fresh view can help.
@Marc amenity=drinking_water // amenity=non_drinking_water
It feels like a good start and compromise.
Either can be associated
It seems that Pieren and I agree on most points.
@François
Maybe drinkable water is a very special case... but here service/use
is much more important than object/feature. The ability to find this
water on a map or from any data consumer is useful. It can even be
essential to many people from
Kotya Karapetyan
2) Suggested tags functionality should be implemented.
I have seen that in the Android editor Vespucci.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
On Jan 14, 2015 5:53 PM, Marc Gemis marc.ge...@gmail.com wrote:
On Wed, Jan 14, 2015 at 12:45 AM, Warin 61sundow...@gmail.com wrote:
I appreciate you concerns. They should have been raised in the
commenting period of the proposal rather than the voting period that is
coming to a close.
-1.
that is not a problem, as multi doesn't exclude all, but all requires
all
Indeed, it is not a problem, it is a solution ! :)
Use two values for slightly different concepts.
multi == multifaith == multiconfessional == various == value1;value2;...
all == non-denominational == nondenominational
Martin Koppenhoefer dieterdre...@gmail.com wrote:
religion=multi looks OK to me, the similarity to sport makes it easier
to remember than religion=all (and it is very likely more accurate, as all
is too inclusive I guess).
Some airports REALLY wants to be that inclusive.
a prayer room for all
This is very related to
amenity=vending_machine (taginfo = 54 000)
with its associated key:
vending=* (taginfo = 50 000)
http://taginfo.openstreetmap.org/keys/vending#values
Maybe we could come up with something that unite the used keys.
On 12 January 2015 at 09:55, k4r573n
John Willis jo...@mac.com wrote:
multi fits the sports tagging scheme well, and I think it is best for the
religion tag too.
Allis not good, as most sports places don have a clay sumo ring or a sandy
pit for beach volleyball set up, so all would be wrong.
@John
I guess this is a reply to
Jgpacker asks on the PoW talk page:
Are [Airports prayer rooms] really tagged with amenity=place_of_worship?
I would say it's quite a different place from a normal religious place,
and should get another tag.
I think they are definitively for worshiping and prayers.
amenity=place_of_worship is
Building on Janko's comment, is this acceptable or lacking in some way?
amenity=shop/vending_machine/...
service:refund=yes
refund:plastic_bottles=*
refund:*=*
___
Tagging mailing list
Tagging@openstreetmap.org
How about...
non-denominational places (Airport chapels ...)
religion=all
places shared between faiths
religion=multi
Optionally more details with a scheme similar to:
religion:christian
http://taginfo.openstreetmap.org/tags/religion=christian=yes/*
religion:muslim
TLDR: consider fence_type=net
I think that these huge nets on poles are barriers, then fences and
then nets. So it fits well within barrier=fence.
from wiki osm [1]: A fence is a freestanding structure designed to
restrict or prevent movement across a boundary. It is generally
distinguished from
On 07/01/2015 11:42 am, johnw jo...@mac.com wrote:
There are 544 uses of barrier=net, and I want to add it into the wiki.
On 7 January 2015 at 05:50, Andrew Harvey andrew.harv...@gmail.com wrote:
I've also used it to tag nets in the water used to provide swimming areas
safe from sharks.
22 matches
Mail list logo
