Re: [Tagging] How to overcome lack of consensus

[Dan S]

2013/9/19 Janko Mihelić :
> 2013/9/18 Martin Koppenhoefer 
>>
>> I think it is a bad idea to connect the meaning of osm tags to definitions
>> in wikipedia, because the content of wikipedia articles is not something we
>> control. When the wikipedia article changes (e.g. it gets extended or
>> restrained by splitting it up) it doesn't imply that the objects with a
>> certain tag in osm change nature.
>
>  I agree that can sometimes be a problem, but wikipedia articles about terms
> like school, power plant, lake can hardly be changed in meaning.
>
> Anyway, connection to wikipedia articles is only a small, secondary part of
> my proposal. Links between tags themselves is something we have to document
> somewhere. We have to have a place where a data consumer sees that
> amenity=fastfood is a specific kind of a amenity=restaurant.

...but it isn't! It's a closely-related concept, but to me the concept
"fast food place" is not a subcategory of "restaurant".

This illustrates, to me, that an attempt to add an ontology on top of
the tagging is likely to be vulnerable to the problems it aims to
solve.

However, it's possible we could start to have a fairly low-key move
towards ontology by simply using mediawiki categories. For example if
you add [[Category:placestogetameal]] to the wiki pages for fast_food,
restaurant, cafe, then it's rather likely that data consumers can use
some of the pre-existing mediawiki tools (as used in
http://dbpedia.org/ for example) to extract structured data that
expresses tags' relations. So if you start with wiki categories you
could get fairly far without having to impose a strong ontology.

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - shop=musical_instrument

[Dan S]

Well that one's easy to answer:
http://wiki.openstreetmap.org/wiki/Tag:shop=music
"A shop that primarily sells recorded music (vinyl/CDs)."

Dan

2013/9/21 Bryce Nesbitt :
> Why not "shop=music".  The _instrument classifier seems overly restrictive
> for stores that likely also sell sheet music, parts, and coordinate repairs.
>
> ___
> 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 - shop=musical_instrument

[Dan S]

And British English too - but, that ship has sailed.

Dan

2013/9/23 Bryce Nesbitt :
> But in American English one does talk about a "shoe shop", even though all
> that's on offer there are pairs of "shoes".
>
> ___
> 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] Post vote clean up

[Dan S]

I think you just need to delete this line:
[[Category:Post-vote clean-up]]

?

Dan



2013/9/26 bredy :
> The proposal is this  amenity=toilets
> 
>
> It'is in Approved and in Post vote list
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Post-vote-clean-up-tp5779068p5779097.html
> Sent from the Tagging mailing list archive at Nabble.com.
>
> ___
> 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] Howto tag a play room

[Dan S]

2013/10/1 Martin Koppenhoefer :
>
> 2013/10/1 Дмитрий Киселев 
>>
>> How to tag them?
>> As playground=playroom with some additional tags, or it's better to use
>> individual leisure=playroom tag?
>
>
>
>
> are you going to add an attribute to the supermarket or map the playroom
> with its own geometry?
> According to the wiki the playground tag is used to tag individual
> playground equipment: http://wiki.openstreetmap.org/wiki/Key:playground like
> a sandpit etc.
>
> If you don't consider the playroom a single playground equipment you could
> use leisure=playroom like you suggested, or maybe leisure=playground
> together with indoor=yes?

Sounds OK to me - it seems to me that the main differences from a
"typical" playground can be treated as attributes (indoor=yes,
supervised=yes).

> Btw.: the current definition for leisure=playground says: "Marks a
> children's playground. These are commonly small outdoor areas with
> children's play equipment such as swings, climbing frames and roundabouts."
> 2 questions:
> 1. does "commonly small outdoor area" mean that uncommon ones can be indoor
> and marked with the same tag?
> 2. why do they have to be "small"? How big is "small"?

My reading of "commonly" in that sentence implies that there is no
need for them to be small, nor outdoor. It indicates that the sentence
is just an illustration, not a constraint. I think the sentence works
for a first-language speaker, but if you think it needs to be clearer
(for non-native speakers), please do edit.

> My suggestion is to remove the words "small" and "commonly" and to decide
> whether they have to be outdoor and what would be the suggestion for indoor
> (e.g. playroom).

Sounds good to me.

Best
Dan

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

Re: [Tagging] Pre-proposal: gambling

[Dan S]

2013/10/5 Matthijs Melissen :
>> There are currently various tags for gambling-related shops and amenities
>> in use, including amenity=casino, shop=bookmaker, shop=betting,
>> shop=lottery, and shop=gambling. See here for an overview of usage
>> statistics:
>> http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/gambling
>
> I notice that many users suggest distinguishing between casinos with
> croupiers, and amusement arcades with just slot machines.

Do you? I don't see that, but maybe I've missed it in the thread.

> Currently, both of
> them are grouped in one tag, amenity=casino.
>
> How would the community suggest establishing this split in tags? From a
> previous discussion, it seems that some users do suggest not to (re)define
> existing tags that are already in widespread use. Moreover, it seems that
> some users think that mappers should follow existing use, not definitions as
> voted or definitions from the wiki. However, I don't see how the split of
> meaning of the tag can be established otherwise. Any suggestions?

It's not difficult to handle. You could propose a chained tag such as
"casino=croupier"/"casino=self_service", or something like
"casino:staffed=yes" or "casino:croupier=yes". That second option
looks ugly to me, but the first option looks kinda useable. I don't
have any strong opinions about what should be done.

Note that this has quite a strong analogy with the recent discussion
about supervised vs unsupervised play areas for children...

Dan

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

[Tagging] Wind turbines: big and small

[Dan S]

Hi all,

One of the things I noticed at SOTM was that the Aston campus has two
little wind turbines, perched on top of some of the buildings. They're
quite small, yet the standard OSM style shows them even at zoom level
15, as if they're significant landmarks:



The relevant tags on these items are
   generator:source = wind
   power = generator
   power_source = wind

I've no problem with them being rendered, but I'd suggest it'd be
better to show them only at finer zoom levels. However, as far as I
can tell our renderers don't have much choice, because there's no
tagging that distinguishes a tiny building-mounted turbine from a
massive free-standing turbine.
http://wiki.openstreetmap.org/wiki/Tag:generator:source%3Dwind
In open areas with wind-farms, the turbines are significant landmarks,
so I can see it makes sense to render them then.

I'm suggesting this is not a problem we can leave for the renderer,
since the renderer doesn't know the turbine's significance - it
doesn't know if the turbine is 5 feet high or 50 feet high. (This
implies that tagging the height could be a solution... might be a bit
tricky to get correct height data though...)

Best
Dan

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

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Dan S]

Yes, certainly in the UK at least there is a difference: there are
routes I have seen where bikes are not allowed, *even if* dismounted
and pushed. There are routes where bikes are explicitly allowed only
if dismounted. bicycle=dismount is used over 23,000 times, and I
believe routers like cyclestreets make use of it...

Best
Dan


2013/10/7 fly :
> Hey
>
> I wonder if it is useful to tag bicycle=dismount on ways.
>
> At least in Germany there is no official traffic sign despite of the
> existence of some.
>
> You are allowed to push your bike on every footway/pedestrian plus ways
> with vehicle=no. E.g. it is useless. Either you are allowed to ride
> (bicycle=yes/designated) or not (bicycle=no or vehicle=no)
>
> I can understand if it is used together with barrier on nodes.
>
> How is the situation in other countries ?
>
>
> Cheers fly
>
> ___
> 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] Usefulness of bicycle=dismount on ways

[Dan S]

2013/10/16 Martin Koppenhoefer :
>
>
>> Am 16/ott/2013 um 09:23 schrieb Volker Schmidt :
>>
>> This feature of JOSM indicates to me that there is most likely widespread 
>> use of bicycle=no on crossings with the meaning of bicycle=dismount.
>
> there is really no difference in meaning between bicycle=no (cycling is 
> legally forbidden) and bicycle=dismount (you may not cycle here legally)

Martin, your statement here is the same as the one which fly used to
start this thread, and a few of us in the UK have pointed out that
there is indeed a difference between two situations, both of which
occur often:
* cycling AND pushing a cycle are forbidden (which, UK-based, I
consider bicycle=no)
* cycling BUT NOT pushing a cycle is forbidden (which, UK-based, I
consider bicycle=dismount)

The problem is that different groups of people have interpreted
bicycle=no differently. That's the problem that this thread should
address, if it achieves anything. But it is not helpful when you
assert "there is really no difference in meaning".

Best
Dan

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

Re: [Tagging] tourism=guest_house or tourism=bed_and_breakfast ?

[Dan S]

2013/10/17 Martin Vonwald :
> Hi!
>
> 2013/10/17 Pieren 
>>
>> So, I'm looking if we could reuse the two existing tags
>> or if I should create a sub-tag like "tourism=guest_house" +
>> "guest_house=bed_and_breakfast" or
>> "guest_house=whatever_in_an_independent_building"
>
>
> +1 for the sub-tags.

Sounds fine to me. My understanding is that tourism=bed_and_breakfast
has been used here and there, but then a mild consensus emerged just
to use tourism=guest_house, and the wiki reflects that (i.e. it
doesn't "suggest" tourism=bed_and_breakfast but there are some small
mentions of it remaining). Sub-tags might turn out to be useful, don't
seem harmful...

Dan

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

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Dan S]

2013/10/19 Martin Koppenhoefer :
>
> 2013/10/19 Frank Little 
>>
>> As others have pointed out, bicycle=no may have also been used by mappers
>> to exclude bicycles not just to exclude cycling; I'd say we can't know what
>> people meant (though I imagine mostly it will have had the meaning of 'no
>> cycling').
>
> shall we really question the meaning of well established tags every 2 years
> because in the meantime some mappers might have used it for stuff it wasn't
> intended for?

As Frank pointed out in his message, the wiki is not very explicit
about this non-obvious distinction. Therefore, we shouldn't be
surprised if the meaning gets questioned every 2 years!

FWIW you and others have persuaded me that perhaps indeed we should
have a separate no-pushing-bicycles tag that's not part of bicycle=*
("bicycle:pushed=*"...? or is there anything in actual use?). So a
good way to resolve this would be to make sure that (a) there's a way
to indicate no-pushing-bicycles; and (b) the wiki is explicit on the
distinction we've been discussing (at least all the places Frank
mentions), and preferably crossreferences the no-pushing-bicycles tag
as appropriate.

(Richard mentioned wanting a tag supported by routers. I humbly guess
that can come later - routers don't care about tags that aren't used
yet)

Thanks all for your patience

Dan

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

Re: [Tagging] Wind turbines: big and small

[Dan S]

Thanks all for the thoughts about distinguishing wind turbines that
are/aren't landmarks. Personally I quite liked the landmark=yes
suggestion but, looking at the current tagging, I saw that it simply
has never been used with wind turbines. (Also, the wiki page for
landmark is very ambivalent.) landmark=windmotor is mentioned in the
wiki, and has been used 36 times, but again, the wiki is ambivalent,
suggesting it's not normally to be used.

On the other hand, "man_made=tower" has been used hundreds of times in
combination with wind turbine tags. Now, marking something as being a
tower doesn't make a 100% definite indication of significance. But
since it's already in use, verifiable, and in most cases it goes along
with the distinction I have in mind, I think I intend to go along with
that - I'll add man_made=tower wind turbines that I map, when indeed
they are towers.

Best
Dan


2013/10/7 Dan S :
> Hi all,
>
> One of the things I noticed at SOTM was that the Aston campus has two
> little wind turbines, perched on top of some of the buildings. They're
> quite small, yet the standard OSM style shows them even at zoom level
> 15, as if they're significant landmarks:
>
> <http://www.openstreetmap.org/?mlat=52.4849&mlon=-1.8899#map=15/52.4849/-1.8899>
>
> The relevant tags on these items are
>generator:source = wind
>power = generator
>power_source = wind
>
> I've no problem with them being rendered, but I'd suggest it'd be
> better to show them only at finer zoom levels. However, as far as I
> can tell our renderers don't have much choice, because there's no
> tagging that distinguishes a tiny building-mounted turbine from a
> massive free-standing turbine.
> http://wiki.openstreetmap.org/wiki/Tag:generator:source%3Dwind
> In open areas with wind-farms, the turbines are significant landmarks,
> so I can see it makes sense to render them then.
>
> I'm suggesting this is not a problem we can leave for the renderer,
> since the renderer doesn't know the turbine's significance - it
> doesn't know if the turbine is 5 feet high or 50 feet high. (This
> implies that tagging the height could be a solution... might be a bit
> tricky to get correct height data though...)
>
> Best
> Dan

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

Re: [Tagging] tag for co-working spaces

[Dan S]

2013/11/25 sabas88 :
> 2013/11/25 Severin MENARD 
>>
>> Hi,
>>
>> Seems this does not exist yet. Here is the taginfo situation
>> http://taginfo.openstreetmap.org/search?q=working_space#values
>>
>> What about a office=co_working_space or office=co-working_space?
>>
> Hi,
> I'd prefer something like office=coworking, which is used
>
> http://taginfo.openstreetmap.org/search?q=coworking#values

office=coworking sounds nice

> (the amenity tag shoudn't be used imho)

+1

Dan


>> Sincerely,
>>
>> Severin
>>
>
> Regards,
> Stefano
>>
>> ___
>> 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] Proposal - voting finished - man_made=lamp

[Dan S]

2013/11/26 Tobias Knerr :
> On 26.11.2013 11:33, Martin Koppenhoefer wrote:
>>
>> This proposal was rejected
>> according to our rules and I now set it to rejected in the wiki.
>
> The rules also state "All suggestions should be taken into account
> before a proposal is approved or rejected." The author is trying to do
> just that.

Where can I read the rules? I searched the wiki for "voting" "tag
proposals" etc and couldn't find them.

Dan

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

Re: [Tagging] Proposal - voting finished - man_made=lamp

[Dan S]

2013/11/26 Pieren :
> On Tue, Nov 26, 2013 at 12:44 PM, Dan S  wrote:
>
>> Where can I read the rules? I searched the wiki for "voting" "tag
>> proposals" etc and couldn't find them.
>
> On the "Proposed_features" main page.

Thanks.

> But don't read it as "hard-coded
> rules" but more as recommendations. I don't like when people think
> that the wiki is the bible. But I also don't like people saying that
> the vote process should be completely ignored. Take it as a good
> opportunity to express verbally a maximum of feedbacks, opinions and
> arguments about tags in OSM. It's better than nothing.

I agree strongly. In this case, with an almost perfectly inconclusive
result, I would say it is unfair to stamp the proposal as "rejected"
since there was not a majority no-vote; but equally wrong to stamp it
as "sort-of-accepted" (these are the two main positions in this thread
so far!). The message from the voters is clear: maybe, but not in this
exact form. Maybe the authors of the proposal will refine it to a
stronger proposal, or maybe they won't. But it seems to me that some
informal evolution is the next thing to consider, rather than repeated
rounds of hyper-formalised proposing and voting.

Dan

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

Re: [Tagging] preproposal : internet webcam

[Dan S]

2013/11/28 Egil Hjelmeland :
> I have to my surprise not been able to find any established practice for
> tagging webcams on internet. I am thinking of cameras that display a place,
> so you can click in to see the weather, snow conditions and such. As a
> service to the public, not to Big Brother. So I feel man_made=surveillance
> is wrong. Also I suspect most surveillance cameras are not public on
> internet.

I would like to (politely :) disagree with your split.
man_made=surveillance seems to be perfect IMHO. The word
"surveillance" may feel big-brotherish, but it is literally what a
webcam does. It seems to me you could come up with some nice tags to
add to the surveillance scheme, such as webcam=public

Best
Dan

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

Re: [Tagging] Propose the tag shop=military_surplus

[Dan S]

2013/12/6 Axelos :
> Hello
>
> Le 05/12/2013 12:16, SomeoneElse a écrit :
>
>> Axelos wrote:
>>>
>>>
>>> I proposed the tag shop=military_surplus for the shops selling used
>>> military equipment.
>>> http://wiki.openstreetmap.org/wiki/Military_surplus
>>
>>
>> If you think that it makes sense to tag a particular shop that way just go
>> ahead and use it.  You can use any tags you like.  Taginfo can see 9 others
>> so far:
>>
>> http://taginfo.openstreetmap.org/search?q=military+surplus#values
>>
>> You can also have a look in taginfo for other possible "shop values" that
>> might apply - it could be that one of those is used by people instead of
>> "military_surplus".
>>
>> Cheers,
>>
>> Andy
>
> The wiki is not intended to suggest tags to make homogeneous the database ?

Yes, but proposing/voting is not really important for simple cases
like this - you want to tag shop=military_surplus, you should go ahead
- there's no need to make big formalities of it, people use all sorts
of shop=* tags. If you want to make a wiki page for that tag, please
do make a wiki page, but don't feel you need to add rfc/voting/etc to
it. I'd suggest you remove the "{{Proposal_Page}}" template, and carry
on mapping :)

Dan

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

Re: [Tagging] Mechanical edit - Voting - Musical instrument (reminder)

[Dan S]

2013/12/9 Martin Koppenhoefer :
>
> 2013/12/9 Matthijs Melissen 
>>
>> Just to keep you up-to-date: the data working group has not responded
>> yet to my request for approval of this mechanical edit. They have not
>> indicated a time span they need to decide, or even acknowledged
>> receipt, so at this moment, I cannot give any further information on
>> whether or when the mechanical edit will happen.
>
> It sounds strange to me that the DWG would "approve an edit" beforehand.
> Usually it is the community to approve such actions (if they are possible at
> all). Where did you get the idea from that DWG should or would "approve" a
> mechanical edit?

Matthijs says it quite clearly in his proposal page: "Although not a
formal requirement either, I have asked the Data Working Group for
permission before carrying out this edit."

(You may be right that it's odd to get the DWG explicitly involved in
such pre-approval, and they might not want to set that precedent...
but I guess the DWG will have more to say about that than me...)

Dan

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

Re: [Tagging] Topographic place names

[Dan S]

2013/12/10 Andrew Errington :
> On Tue, 10 Dec 2013 19:26:55 Steve Bennett wrote:
>> Hi all,
>>   My cycletouring map, http://cycletour.org, has been slowly morphing into
>> a general topographic map[1]. One thing that's missing, though, is names
>> for topographic features like mountain ranges, spurs, and general areas.
>>
>> Looking at http://wiki.openstreetmap.org/wiki/Category:En:Key:natural,
>> there seem to be some gaps.
>>
>> - how do you tag a mountain range? That is, not a single ridge or mountain,
>> but a line of mountains, potentially hundreds or even thousands of
>> kilometres long
>> - how do you tag a spur? In Australia, many spurs are named, ("Champion
>> spur", "Son of a bitch spur"). natural=ridge perhaps?
>> - how do you name a generic geographic feature, like a cluster of rocks
>> ("Mushroom rocks") or a vague features like "the blowhole", "something
>> hollow". The tags are all very specific and seem to imply the ability to
>> render it somehow other than using words. (I have ended up using
>> place=locality for some of these but it doesn't seem right.)
>>
>> Steve
>> [1] See this area for instance: http://bit.ly/1gVmycD
>
>
> Yes please!  I just added some hiking trails and had a named spur[1] that I
> wanted to record.  I used place=locality, but it seems wrong for the same
> reasons you give.  I'd suggest that since we have natural=peak, and
> natural=saddle we should have natural=spur.  natural=ridge, if it's not
> already used, should be for ridges.  Perhaps we could also have
> natural=feature for a general named 'thing' that is visible and well known.
> Could be any sort of rock, outcrop, fissure etc.

All sounds good. Note that for rocks and outcrops we do have tags:
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock
(I was using natural=rock before but it seems natural=bare_rock is
preferred since less ambiguous. I tend to use this for standing rock
areas as well as for flat ones...)

Dan


> [1] http://www.openstreetmap.org/#map=15/35.7236/128.0624&layers=C

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

Re: [Tagging] how to tag a terrace?

[Dan S]

2013/12/13 Martin Koppenhoefer :
>
>
> Am 13/dic/2013 um 13:37 schrieb Fabrizio Carrai :
>
> The final results is [1] a multypoligon the includes few components,
> including:
>
> A highway=pedestrian area, with black and white tiles marked as
> surface=paving_stones (that's the one with the terrace's balustrades)
> An acquarium [4]
> Grass areas
> A gazebo construction
>
> For this reason I would not mark it as "terrace" and definitively not
> "building".
>
> The multipolygon is fine, it just lacks tagging ;-)
>
> The only tags that characterize it right now are the name and Wikipedia tag,
> there is no osm tag to say what it is.

"highway=pedestrian area, with [...] surface=paving_stones" seems to
tag it pretty well to me.

Note that may be a translation issue. In english the word "terrace"
used in this context basically just refers to the pedestrian area...
https://en.wikipedia.org/wiki/Terrace_%28building%29

> IMHO building would fit, what are the alternatives? man_made and historic,
> but historic would exclude similar constructions of recent make. Man_made is
> usually for more technical stuff, and in the past we used building even for
> ships (that don't move any more, with a restaurant inside).

building doesn't make sense to me. It is "built" in the sense of being
"man-made" or "architectural", but then so is a bridge, a fountain,
etc.

Perhaps you could say what _aspect_ of the terrace you consider is not
reflected in the tagging that Fabrizio describes? The photo you
originally linked to shows a large and decorative pedestrian area,
which is not difficult to map. The multipolygon collects together the
geographic features that people presumably think of when they think of
the name Terrazza Mascagni. So, if those things don't satisfy you,
there must be some additional _quality_ that you have in mind?

Best
Dan

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

Re: [Tagging] how to tag a terrace?

[Dan S]

2013/12/13 Martin Koppenhoefer :
>
> 2013/12/13 Dan S 
>>
>> "highway=pedestrian area, with [...] surface=paving_stones" seems to
>> tag it pretty well to me.
>
>
>
> those tags aren't on the relation that represents the whole object though.
>
>
>>
>>
>> > IMHO building would fit, what are the alternatives? man_made and
>> > historic,
>> > but historic would exclude similar constructions of recent make.
>> > Man_made is
>> > usually for more technical stuff, and in the past we used building even
>> > for
>> > ships (that don't move any more, with a restaurant inside).
>>
>> building doesn't make sense to me. It is "built" in the sense of being
>> "man-made" or "architectural", but then so is a bridge, a fountain,
>> etc.
>
>
>
> yes, as we don't have a tag for bridges either (all we use is an attribute
> to a railway or highway that it is on a bridge, we don't actually map the
> bridge itself, besides the bridge relation maybe), a building=bridge is fine
> for me as well.
>>
>> Perhaps you could say what _aspect_ of the terrace you consider is not
>> reflected in the tagging that Fabrizio describes?
>
> Actually it was himself who described that the terrace consists of several
> parts:
>
> A highway=pedestrian area, with black and white tiles marked as
> surface=paving_stones (that's the one with the terrace's balustrades)
> An acquarium [4]
> Grass areas
> A gazebo construction
>
>> The photo you
>> originally linked to shows a large and decorative pedestrian area,
>> which is not difficult to map.
>
> it is not just a pedestrian area, it is also retaining walls, ceiling, a
> pavillon, stairs, foundations, ...
> http://img76.imageshack.us/img76/474/terrazzamascagniwj9.jpg
>
>
>> The multipolygon collects together the
>> geographic features that people presumably think of when they think of
>> the name Terrazza Mascagni. So, if those things don't satisfy you,
>> there must be some additional _quality_ that you have in mind?
>
> I think that there is clearly an "object"  which is called "terrazza xy"
> which consists of several parts, which is a built structure, and which is
> more than just a pedestrian area. I think that who created the multipolygon
> relation thought the same (hence he created the relation and attached the
> name and wikipedia link to it).

I know you think it's clear, but it isn't clear to me what the "edges"
of this "object" might be, which is why I asked you if you could say
some more about this. If I understand you right, maybe one of the
closest parallels in OSM tagging would be leisure=park? I'm not
suggesting you should use this tag, just that maybe the object you
have in mind has a similar ontological status. For example it's weird
to me to think that "grass areas" or other buildings (mentioned above)
would be considered a sub-part of a building=* object. But, for
example, it's quite common for leisure=park objects to have grass
areas and buildings inside.

Dan

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

Re: [Tagging] How to map holiday flats? New tag "tourism=holiday_flat" or extend existing "tourism=chalet"

[Dan S]

2014/1/3 Richard Welty :
> On 1/2/14 8:31 PM, Dave Swarthout wrote:
>> I think of the word "flat" as being distinctly British. I have only
>> rarely heard the word "flat" used to describe and apartment in the
>> U.S. When I first glanced at the beginning of this thread I thought
>> the OP was referring to flats of flowers. LOL
> flat was once much more commonly used in the US.
>
> and since OSM tends towards UK English usage, i think it's
> perfectly reasonable for OSM to use the term.

Reasonable, but since both "flat" and "apartment" may be vulnerable to
some international confusion, it's worth bearing that in mind.

We already have good tagging for building types, so it seems to me
there's no particular need to use the tourism=* tag to indicate
whether the accommodation is a free-standing chalet or a flat. If I
were starting from scratch, I might advocate tourism=self_catering.
But tourism=chalet is very close in meaning (except for the
implication that it's a free-standing building!) so I wonder if we can
simply use that existing tag, and let the building=* tags help us
decide if we want to spend our holiday in a free-standing structure!

I'd suggest that adding tourism=holiday_flat as well as tourism=chalet
is compounding an existing problem, making it so we have two tags
rather than one which unhelpfully merge building-type information and
primary-use information. I'd really like to suggest either modifying
the definition of tourism=chalet so it's more inclusive, or using
something like tourism=self_catering.

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - trafficability

[Dan S]

Hi,

It reminds me quite a lot of opening_hours
http://wiki.openstreetmap.org/wiki/Key:opening_hours
Would that be appropriate?

Dan


2014/1/3 BGNO BGNO 
>
> Hi,
>
> I am proposing a new key: 
> http://wiki.openstreetmap.org/wiki/Proposed_features/trafficability
>
> Cheers
>
> BGNO
>
> ___
> 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 map holiday flats? New tag "tourism=holiday_flat" or extend existing "tourism=chalet"

[Dan S]

Sounds good to me too, nice and simple :)

Dan

2014/1/6 Dave Swarthout :
>> Personally I would go with tourism=apartment or apartments.
> +1
>
> On Mon, Jan 6, 2014 at 5:02 PM, Martin Koppenhoefer 
> wrote:
>>
>>
>>
>> > Am 05/gen/2014 um 17:44 schrieb Dudley Ibbett
>> > :
>> >
>> > Personally I would go with tourism=apartment or apartments.
>>
>> +1, thought this was already established practice.
>>
>> cheers,
>> Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> ___
> 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] Proposal - Voting finished - Gambling

[Dan S]

2014/1/19 Jörg Frings-Fürst :
> Hallo,
>
>
> On So, 2014-01-19 at 17:33 +0100, Martin Koppenhoefer wrote:
>> 2014/1/19 Matthijs Melissen 
> [...]
>>
>> Actually this is a formal reason to extend the voting period according to
>> our standards. Being personally one of the approvers I do not want to
>> prevent the approval, but maybe the opposers will. The wiki states that
>> you'd need either 8 yes votes and no opposing votes, or at least a total of
>> 15 votes.
>> https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
>>
>
>
> That's an extension to an already existing tagging. Then this applies:
> "(search as Whether a feature is already in use)". Or?

I don't have a strong opinion on the proposal, but no big objections,
so I've just added my yes vote in order that the voting threshold is
not a problem.

Dan

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

Re: [Tagging] Proposal - Voting finished - Gambling

[Dan S]

I do not disagree... the system is imperfect, but such is life.

2014/1/19 Chris Hill :
> Which just shows, yet again, how phoney and pointless voting is.
>
>
>>
>>I don't have a strong opinion on the proposal, but no big objections,
>>so I've just added my yes vote in order that the voting threshold is
>>not a problem.
>
> ---
> cheers, Chris
> osm user, chillly

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

Re: [Tagging] feature Proposal - RFC 2 - tourism = apartment

[Dan S]

2014-02-16 8:29 GMT+00:00 Philip Barnes :
> On Sun, 2014-02-16 at 07:06 +0700, Dave Swarthout wrote:
>> >I would prefer the plural tourism=apartments.
>>
>>
>> I prefer singular because the plural term explicitly states that more
>> than one unit is available to rent while the singular implies only
>> that there is at least one unit for rent on a short term basis.
>> Therefore the plural designation might often be wrong while the
>> singular will not.
>>
> +1
> The plural also implies that all of the apartments in the building are
> available for short term holiday rental, whereas in reality there is
> likely to be a mix of rental and residential apartments in the building.
>
> Phil (trigpoint)

FWIW, I too am happy with the singular tourism=apartment.

I'll repeat what I said on the talk page: beds=* would be better as
capacity=*. Otherwise, looks OK to me.

Best
Dan

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

Re: [Tagging] Architectural Monuments - ideas?

[Dan S]

2014-02-17 12:58 GMT+00:00 nounours77 :
> Dear Clifford, dear Pierren,
>
> thanks for your thoughts. Here some answers
>
>
>> What/Who defines what is an Architectural Monument? When I think it is more
>> along the lines of what Wikipedia [1] defines as a monument.
>
> No, I'm not (specifically) talking about specific monuments created for 
> commemoration purpose.
>
>> What I think
>> of as a building designed by famous architects,  it is more along the lines
>> of a Frank Gehry building. i.e. The  Guggenheim
>> Museum
>
> Yes, this I have in mind, and even "less important".
>
>> Can you clarify your proposal to help me better understand. (Pics would be
>> great.)
>
> Find 2 examples from the Basel-list under [1] and [2]
>
>> Also, do you mean an actual import? If so, please make sure the list is
>> licensed appropriately for OSM and you discuss on the import mailing list.
>
> Yes, I'm talking about a specific import. It's part of the import of the 
> geodata of the State of Basel. Yes, we have explicit right to do so in 
> written from the government authority [3]. No, I did not intend to discuss it 
> on the import mailing list, since it's a very local import, I discussed it on 
> the swiss-talk only.

I'm not going to jump on this but you will very likely be frowned upon
for not mentioning it to the imports list.

> Pieren:
>
>> More seriously, is it not something very subjective ? is OSM the right
>> place for such list ? At least, "heritage" [1] is based on something
>> "verifiable" [2].
>
> Yes, it is subjectively what is relevant enough to be tagged in OSM.
> The current list is a bit less subjective, since it's the official government 
> list of the state of Basel which enumerates 36 buildings as being of 
> architectural interest. Is this verifiable enough?

Ah! This official listing sounds much better, to me. You could perhaps
use "listed_status" as we do in the UK, if that is appropriate:
http://wiki.openstreetmap.org/wiki/Key:listed_status

> Thinking of it, a solution might be to just create Wikipediapages for all of 
> the 36 buildings (most are probably already there), and then set the 
> wikipedia tag to the building? But would that no remove information, since 
> there are so many wikipedia-tags, how can I get a map of all architectural 
> monuments in a city?

You would need to combine the two datasets. One way of doing this is
via linked-data: dbpedia (which gives you data from wikipedia
about-boxes, and linkedgeodata which gives you OSM.
http://dbpedia.org/
http://linkedgeodata.org/

Dan

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

Re: [Tagging] How to tag a public works facility ?

[Dan S]

Hi -

In the past I've seen people use landuse=depot
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Ddepot

Dan


2014-02-19 9:06 GMT+00:00 Pieren :
> It's a small area with several buildings where the municipality is
> storing vehicles and the maintenance and repair services. Someone
> suggests to use "amenity=public_building" but it's deprecated now in
> the wiki... "building=public" doesn't fit well here because it's an
> area and is not open to the public.
> Something new like "amenity=public_works" ? (0 in taginfo)
>
> Pieren
>
> ___
> 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 a public works facility ?

[Dan S]

Any reasons not to use landuse=depot? Besides the sparsity of its wiki page...
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Ddepot
428 instances in taginfo


2014-02-19 16:27 GMT+00:00 Tod Fitch :
> For what it is worth, in the area I live in such facilities seem to be called 
> "corporate yards".
>
> Since "industrial=depot" seems to have only one use at present and does not 
> fit exactly. At least it does not fit in my mind. Perhaps it could be tagged 
> as "landuse=industrial, industrial=corporate_yard" with operator="City of 
> " and maybe name="XXX Corporate Yard"
>
> -Tod
>
>
>
> On Feb 19, 2014, at 3:37 AM, SomeoneElse wrote:
>
>> Pieren wrote:
>>> It's a small area with several buildings where the municipality is
>>> storing vehicles and the maintenance and repair services.
>>
>> I've gone with "landuse=industrial, industrial=depot" for these in the past:
>>
>> http://www.openstreetmap.org/way/254083705
>>
>> (although arguably the "name" on that should actually be "operator")
>>
>>> Someone
>>> suggests to use "amenity=public_building" but it's deprecated now in
>>> the wiki...
>>
>> Whoever edited the wiki clearly failed to communicate with all the editor 
>> authors since "amenity=public_building" is a default in P2 (not that it's 
>> relevant in this case, since what you're describing isn't just a building.
>>
>> Cheers,
>>
>> Andy
>>
>>
>> ___
>> 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] Fwd: tag for planetarium

[Dan S]

Hi all,

Well amenity=* has been something of a default choice in the past, so
the definition is quite stretched from "community facilities" as the
wiki puts it. There are some well-established tags that might be
better as leisure=* or tourism=* if we were starting from scratch. So
I'd suggest tourism=planetarium might be the best choice; but all of
the suggestions are fine really!

Dan


2014-02-25 0:28 GMT+00:00 Dave Swarthout :
> I think amenity=planetarium is perfectly reasonable. A planetarium is a
> place that resembles a theater but the "show" involves models of the planets
> and/or the stars & universe. If OSM can have an amenity=brothel tag, we can
> certainly have an amenity tag for planetaria, which are in my opinion
> "something for the benefit/enjoyment of society as a whole" whereas it is
> arguable whether brothels fit into that category. ;-)
>
>
> On Tue, Feb 25, 2014 at 5:27 AM, John Packer  wrote:
>>
>> Perhaps instead of amenity=*, it should be added to tourism=*.
>>
>> It seems that's where the discussion is going to.
>>
>>
>> 2014-02-24 19:23 GMT-03:00 Richard Welty :
>>>
>>> On 2/24/14 5:17 PM, Colin Smale wrote:
>>> >
>>> >
>>> > I would not call it an amenity, which is (to me, native UK English
>>> > speaker) something for the benefit/enjoyment of society as a whole (or
>>> > at least a large part of it). These days a planetarium is probably for
>>> > enjoyment/entertainment (suggesting leisure=planetarium).
>>>
>>> on the other hand, in my experience Planetariums are usually
>>> attached to museums of one kind or another, whether science
>>> museums or children's museums.
>>>
>>> richard
>>> --
>>> rwe...@averillpark.net
>>>  Averill Park Networking - GIS & IT Consulting
>>>  OpenStreetMap - PostgreSQL - Linux
>>>  Java - Web Applications - Search
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> ___
> 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] Hot springs

[Dan S]

2014-03-03 12:53 GMT+00:00 nounours77 :
>
>> I have significantly changed 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring
>> with the intention to revive the proposal - thanks for any comments and 
>> enhancments.
>
>
> Dear Richard,
>
> thanks for your initiative. I agree with your arguments why a specific tag 
> "natural=hot_spring" is better than "natural=spring" and "temp=*". It is 
> something different.
>
> Not sure about the word "consistence" which looks strange to me (but I'm not 
> native).

"consistence" is not standard English. You probably don't mean
"consistency" either. "content"?

Dan

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

Re: [Tagging] Fixing wrong opening_hours automatically

[Dan S]

2014-03-06 17:13 GMT+00:00 Robin `ypid` Schneider :
> On 06.03.2014 10:47, Martin Koppenhoefer wrote:
>> 2014-03-05 21:25 GMT+01:00 Robin `ypid` Schneider :
>>
>>> There is no key öffnungszeiten, but yes it is only about the key
>>> opening_hours.
>>> As said before I am not going to change the meaning. The value '"nach
>>> Vereinbarung"' is used more often so that's another reason for that.
>>>
>>
>>
>> I am generally opposing german language values in formalized tags *),
>> especially where a generic fact is expressed that has a corresponding word
>> in English like here. For this reason I am opposing that you normalize
>> those tags as it would distort the actual tagging numbers and next time
>> you'd be able to say that there are even more of these values, all unified
>> in the same clean format ;-)
>
> In general I agree with you. But I see the comment in opening_hours more like
> the description key which can (or should) be in local language.

I'm sorry but if it is description-like, then it is free text and
shouldn't be auto-standardised in the manner you propose. You need to
decide if you think it is description-like (== free text, local
language) or formalised (==set of possible labels, british english).

Dan

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

Re: [Tagging] What is OSM: a base layer for individual maps, or a fully featured geobased information system?

[Dan S]

Hi -

I'm afraid the answer is "neither". OSM is a database for geodata that
is open-licensed, publicly verifiable and not short-term. This means
it's more than just a base-layer. But it also means it's not a
database for all possible geodata. We don't include holiday apartment
reviews/ratings because they're too subjective; we don't include the
local temperature because it changes too quickly.

You're going to have to live with the fact that (a) no-one wants to
render your tag until it has some momentum, while (b) rendering
certainly helps a tag get momentum, but that doesn't mean that your
tag "deserves" that benefit yet. Much better is if you start using
your tag, and then maybe the community of boat-sharing users starts to
use it too, and maybe renders a special boat-sharing map, and the
tagging develops organically. It doesn't make a big difference whether
it's been officially voted in or not.

There will always be geodata that doesn't belong in OSM, such as house
prices, tripadvisor ratings, crime rates. OSM doesn't need to ingest
this data in order to be useful; it needs to be available to get
mashed-up with this data.

Best
Dan


2014-03-29 12:41 GMT+00:00 nounours77 :
> Hi there,
>
> Not sure if this is the right place for this philosophical question. But
> starting from the comment of Brycenesbitt to my apartment-proposal "I feel
> this will become yet another piece of unmaintanable data in OSM." and
> several comments I got on my boat_sharing proposal "just use it, don't go
> through proposal process" I think it's a important question. What do we
> define tags for?
>
> A) OSM is just a base layer
> We tag just for general features of the landscape, and maybe roads. This
> will make a beautiful map, which then can be used as a base layer, e.g. for
> a holiday-apartment renting agency, which than can render all there
> apartments from their own private database as an overlay on OSM base layer.
> => this will mean, "we" do not have to maintain the apartment info, nor has
> the provider to bother with OSM. This is much easier. But means that the
> information is only avaible on the agencies website, and thus there will be
> million places I have to look for the info.
>
> B) OSM as a fully featured geobased information system
> We see of OSM a a standalone, fully featured geobased information system. I
> can take the map in my pocket (like on the iPhone App "PocketEarth", or
> "OsmAnd"), and will everywhere have any kind of information. I'm driving
> through a village, I like it, and I want to stay. So, where are the next
> nice holiday-apartments around me?
> Of course, this only works, if the data is maintained and current. But: I
> want OSM to get important enough that every service provider offering a
> service to a wide enough public is just forced in his own interest to
> publish it's data on OSM and keep it current.
>
> As a conclusion for us this means: Yes, we need a defined tagging (accepted
> proposal) for tourism=apartment, ifnot, never ever all service providers
> will put their apartment on OSM. And never the Apps like PocketEarth or
> OsmAnd will support to render it.
> I was advised by several persons that I should just use
> "tourism=boat_sharing", and not bother about going through a proposal and
> voting process. BUT: I asked OsmAnd to render the tag, and the answer was -
> quite understandable: "Only officially supported tags will be rendered".
> There we are again with the well know snake which bites it's tail: No data -
> no rendering. No rendering, nobody collects data or publishes it on OSM.
> My answer to this would be: make a reasonable, understandable, clear and
> clean tagging scheme, discuss it, vote it, document it. If done properly,
> the data will come and the rendering as well.
>
> Please, what is your vision of OSM? A or B?
>
> If A, I will stop bothering about tourism=apartment, amenity=boat_sharing,
> or amenity=nursery, since this are all "service informations" you can argue
> you can find somewhere else ...
> But if it's B), then we need all that to make OSM the best, most complete
> and inevitable geobased information system.
>
> Thanks for your comments, and yes, I reopened the boat_sharing proposal for
> voting, just in case somebody wants to support me!!!
>
> Have a nice week-end,
>
> Nounours77
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/boat_sharing
> https://wiki.openstreetmap.org/wiki/Proposed_features/apartment
>
>
> ___
> 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] Issues relating to URIs and tagging

[Dan S]

Hi Andy,

2014-04-01 16:29 GMT+01:00 Andy Mabbett :
> Hello everyone,
>
> This is my first post to the list, which I've just joined, but I've
> been a mapper for a few years and some of you might remember me as
> compere at last year's State of the Map.

And well done indeed!

> Yesterday, I met with the W3Cs'  "data on the web best practice"
> working group. At their request, I gave a talk on the use of URIs
> (particularly linked data URIs) and related tags,  in OSM.
>
> I described, and we then discussed, how we tag entities in OSM, using
> UIDs but not necessarily URLs, and issues facing data users who need
> to resolve those UIDs back to URLs; for example:
>
> openplaques_plaque = 1536
>
> to:
>
>http://openplaques.org/plaques/1536
>
> To that end, I've just modified [[Template:KeyDescription]] by adding
> two parameters:
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:historic%3Dmemorial&diff=prev&oldid=1010411
>
> for "website" and "url_pattern"

That URL doesn't seem right. I think you mean


> see:
>
>https://wiki.openstreetmap.org/wiki/Key:openplaques_plaque
>
> of an example of how they're intended to be used (the label display
> needs tweaking).

Tell me if I've misunderstood you, but you're proposing that the
url_pattern given in the wiki "infobox" KeyDescription is intended to
be machine-readable, in the sense that a third-party data consumer can
plug url_pattern together with the actual key-values found in OSM and
automatically find the URL for something? If so, the idea is
intriguing and I think it's a nice lightweight thing we can do.

I have a small quibble which is please change it from "URL" to "URI",
since I think the latter is the more appropriate concept. We're aiming
to interlink _identities_ of items really, for the machines.

> The model used there fails with Wikipedia links,
> expressed as "en:Example", because the equivalent URL is
> . Any suggestions for dealing
> with that?

I don't see a plausible way of dealing with this that wouldn't be a
crazy hack. So I'd recommend that data re-users will simply need to
treat this as a special case if it's important to them. (I've always
thought the wikipedia tag would have worked better as
"wikipedia:en=Example" -- in that case, your template approach would
have worked fine.)

> They were very impressed with the inclusion of Wikidata IDs
>
>
>
> The sooner we move that from "Talk:Proposed_features/" to "Key:", the better.

Wikidata proposal looks good to me.

> Other issues which are unhelpful to data re-users include keys with
> missing documentation; redundant keys ("Key:openplaques_plaque" vs
> "Key:openplaques_id");

I have never seen these tags, but there are very few uses - this
example is probably really easy to consolidate into one tag.

The harder cases will - as discussed in recent threads on this list -
will remain in a state of productive controversy for a long time to
come! Sorry, data re-users, but that's wiki-life for you.

> ambiguous keys ("ref=1234" - ref in whose database?)

That's an interesting question. "ref" is widely used, and generally
used quite coherently, _but_ its meaning is contextual on other tags.
For example, "amenity=post_box" & "operator=Royal Mail" tells you
where to expect the ref to point. I wonder if "operator" sets the
context in many other cases? (I accept, of course, that many objects
aren't tagged with operator.)

> and the perennial problem of the lack of stable URIs for entities in OSM. I 
> have yet to solve that one...

OSM objects are not stable, same as Wikipedia articles. For Wikipedia
they provide partial stability through long-term historical "oldid"
links and redirects. I don't think tagging (i.e. this list) can solve
the permalink problem. It needs osm.org to provide a URL scheme that
allows people to link to a specific historical _version_ of an osm
object. We already provide direct links to changesets and to object
histories, so the data is all there.

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - Wikidata

[Dan S]

2014-04-01 22:17 GMT+01:00 Tobias Knerr :
> On 01.04.2014 19:04, Andy Mabbett wrote:
>> I commend this proposal to the list:
>>
>>https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
>
> I like Wikidata and therefore want to see this proposal approved. :)
>
> What I'm interested in, though: If an object exists both in Wikipedia
> and Wikidata, would you expect both tags to be used? Wikipedia links can
> be obtained from the Wikidata API for a given Wikidata ID and vice
> versa, so one of the two would suffice.

Long-term, it seems possible that wikidata might end up as the primary
way to make these cross-reference connections, but that depends on the
future evolution of both osm and of wikidata. Short- and medium-term,
existing wikipedia tagging is not going to be deprecated or
automatically replaced, services will probably continue to make use of
it, and it has some advantages (such as readability). I don't think we
should "expect" both to be used, but it should be no problem if both
are applied to a particular object.

Dan

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

Re: [Tagging] Ticket for JOSM to read contact metadata closed

[Dan S]

2014-04-02 18:25 GMT+01:00 Andy Mabbett :
> Not only was I disappointed to see this ticket:
>
>http://josm.openstreetmap.de/ticket/9885
>
> closed as "wontfix", but I don't understand the reason given:
>
>This format seems not to be used much.
>Too much work for too little gain.
>
> not least since I specifically referred to "an hCard microformat or
> some other contact metadata".
>
> Was I unclear in my proposal?

No, it was clear. However, when I read the ticket, my first thought
was, "That would be ideal for a josm plugin, and I don't see why
anyone would propose it for core josm rather than a plugin." I didn't
want to say it out loud and pre-empt decisions of actual josm
developers.

I know how those microformats work but I don't feel that they're very
common, so I don't have any particular problem with the reason given.
Do you feel to the contrary, that they are "used much"? Do many
business/organisation websites actually add these things?

Best
Dan

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

Re: [Tagging] access=designated - what do we think it means?

[Dan S]

2014-04-11 18:20 GMT+01:00 Pieren :
> On Fri, Apr 11, 2014 at 7:07 PM, Tod Fitch  wrote:
>
 (2) http://wiki.openstreetmap.org/wiki/Tag%3Aaccess%3Ddesignated
>>
>> This is how I understood and have used it.
>
>
> This is what the wiki says:
> "Note that access=designated is not defining what is designated and is
> meaningless. "

Please, before quoting the wiki in a tagging discussion, check if your
choice quote was added two hours ago as a direct result of this
tagging discussion! Quoting that particular sentence from the wiki is
almost exactly equivalent to quoting an email message in this thread.

Dan

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

Re: [Tagging] access=designated - what do we think it means?

[Dan S]

2014-04-11 19:14 GMT+01:00 Vincent Pottier :
> Le 11/04/2014 19:38, Dan S a écrit :
>
>> 2014-04-11 18:20 GMT+01:00 Pieren :
>>>
>>> On Fri, Apr 11, 2014 at 7:07 PM, Tod Fitch  wrote:
>>>
>>>>>> (2) http://wiki.openstreetmap.org/wiki/Tag%3Aaccess%3Ddesignated
>>>>
>>>> This is how I understood and have used it.
>>>
>>>
>>> This is what the wiki says:
>>> "Note that access=designated is not defining what is designated and is
>>> meaningless. "
>>
>> Please, before quoting the wiki in a tagging discussion, check if your
>> choice quote was added two hours ago as a direct result of this
>> tagging discussion! Quoting that particular sentence from the wiki is
>> almost exactly equivalent to quoting an email message in this thread.
>>
>> Dan
>
> It seems that "January 24th 15h40" is a little older than 2 hours.
> And quotting this sentence in the wiki is not exaclty quotting this thread.

Oh my apologies! I clearly misread the date. Sorry for adding
confusion to the confusion!

Dan

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

Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

[Dan S]

2014-05-15 10:00 GMT+01:00 Jean-Marc Liotier :
> Well... Private messages tell me that boules might be popular outside of
> France, so here is a translation for a more international debate...
>
> According to http://wiki.openstreetmap.org/wiki/Tag:sport%3Dboules a
> petanque pitch (leisure=pitch) is:
> sport=boules
> boules=petanque
> (375 nodes, 75 ways - http://overpass-turbo.eu/s/3op)
>
> But according to http://wiki.openstreetmap.org/wiki/FR:Key:sport it is:
> sport=boules
> type=petanque
> (607 nodes, 111 ways - http://overpass-turbo.eu/s/3oo)
>
> Any opinions on a future harmonization of the tagging of boules game types ?

"type" is far too vague - it doesn't namespace at all, so it doesn't
make it definite if it's a type of boules, a type of pitch, etc. The
english wiki says, and I concur, Key:type "should be avoided":
http://wiki.openstreetmap.org/wiki/Key:type
Much better to standardise on the "chaining" approach i.e. "boules=*"
(or "boules:type=*" would have been another possibility in a parallel
universe). Luckily, the number of petanque objects is small enough
that it's possible to harmonise, so long as the nations can agree :)

Just my 2p
Dan

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

Re: [Tagging] cleanup broken import "fix"

[Dan S]

If I understand right you should probably ask imports@ not tagging@
about making bulk edits, even if they're to fix bulk edits!

Best
Dan


2014-05-28 21:53 GMT+01:00 malenki :
> Recently I found some 10.000 (one of two changesets contained 38k)
> objects tagged like this:¹
> | gnis:fcode=39004
> | natural=water
> | nhd:com_id=146082168
> | nhd:fdate=Mon Mar 06 00:00:00 PST 2006
> | nhd:reach_code=18030012024071
> | source=NHD
> | water=lake;pond
>
> They were imported by nmixter and in v1 were tagged like this:
> | ele=0.0
> | gnis:fcode=39004
> | gnis:ftype=LakePond
> | natural=water
> | nhd:com_id=146082168
> | nhd:fdate=Mon Mar 06 00:00:00 PST 2006
> | nhd:reach_code=18030012024071
> | source=NHD
>
> "WorstFixer" removed ele 0.0 and honoured his name by converting
> gnis:ftype=LakePond to
> water=lake;pond
>
> Has anyone objections for removing water=lake;pond and also the other
> proprietary data?
> I'd think
> | natural=water
> and
> | source=NHD
> (and in case it is there)
> intermittent=yes
> should be sufficient
>
> See also: https://github.com/openstreetmap/iD/issues/2237
>
> Regards
> Thomas
>
> ¹ example: https://www.osm.org/way/73966050/history
>
> ___
> 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] Wiki edits, building tags on nodes versus areas

[Dan S]

2014-06-04 18:03 GMT+01:00 bulwersator :
> I guess that push toward tagging POI as nodes is result of fact that in some
> situations only nodes are processed properly (at least that is why I tag new
> features in this way).

I don't think it's a good idea to adapt your tagging practices to suit
systems that can't be bothered to handle ways/relations! Please, if
you think a feature is geographically better represented as a way, do
it as a way.

I prefer to map the physical extent of a shop when possible, since
shops very often occupy a non-trivial physical area (especially large
ones, e.g. supermarkets).

So to answer the original question: no those wiki edits would seem to
be misguided, and for more reasons than just one-feature-one-element.

Just my 2p of course

Best wishes
Dan


>  On Wed, 04 Jun 2014 09:43:25 -0700 Andrew Hain
>  wrote 
>
> Over the past few days there have been a number of wiki edits (mainly but
> not entirely in German) stating that shop=* and similar tags, contrary to
> the “One feature, one OSM element” principle [1], should only ever be put
> on nodes and not on building polygons. I’ve commented on an affected talk
> page without any response.
>
> Is there any justification for these edits?
>
> [1] http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
>
>
>
> ___
> 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] turning layers off

[Dan S]

(not a "tagging" question really, but)

Top tip: Ctrl-W in JOSM ("wireframe mode") makes areas show as
outlines rather than tinted areas.

Dan


2014-06-05 15:50 GMT+01:00 Matthijs Melissen :
> Yes, in JOSM, you can use the Filters window.
>
> -- Matthijs
>
> On 5 June 2014 15:46, Tom Gertin  wrote:
>> Is it possible to turn visibility of certain layers or feature types off in
>> OpenStreetMap (Id or JOSM), such as features with a landuse tag?
>>
>> I am having a hard time drawing building polygons inside landuse polygons
>> because the landuse polygons have a colored tint to them.
>>
>> Thanks,
>>
>> Tom G.
>>
>> ___
>> 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] highway=track access

[Dan S]

2014-06-05 21:31 GMT+01:00 Janko Mihelić :
> 2014-06-05 17:25 GMT+02:00 Greg Troxel :
>>
>> As for style, I mean something as simple as dashed casings when unpaved,
>> similar to a lot of exiting road maps.  I don't think this adds clutter
>> - there will just be a few pixels missing, and most people will
>> understand it without even looking that the key given usage in other
>> maps.
>
> What about countries where 90% of roads are unpaved? That's not going to
> look very nice.

For what it's worth, please note that the Humanitarian style (already
available on the homepage!) shows paved/unpaved distinctions pretty
well.


> The solution could be that the starting OSM page should default to some
> pretty minimal map, and then one of the optional maps would be this map that
> is designed for mappers.

This sounds to me like a good strategy! osm-carto-sanity vs osm-carto-hyper

Dan

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

Re: [Tagging] Signal-controlled roundabouts

[Dan S]

Roundabouts like this sometimes (in Britain) have "part time traffic
lights". So, some times of day it is a true roundabout, and some times
of day it is a circle of road with traffic signals! I don't know the
one you linked, to but it's possible that is what is going on here.

Dan

2014-06-13 16:54 GMT+01:00 Fernando Trebien :
> Hello,
>
> I used to believe that, by definition, all roundabouts have free
> transit and right of way along the circle, and that anything that
> didn't display that property isn't a roundabout (just a circle). But
> reading the wiki once again, I'm a little in doubt. The wiki mentions
> that this is a roundabout, but I would previously have thought it
> wasn't because of the traffic lights within it:
> http://www.openstreetmap.org/#map=19/52.59689/-1.14146
>
> So why is it a roundabout? Is it because of the circular shape? Or
> could it be because it's impossible to infer that any of the entering
> ways have right of way, since they are all controlled by traffic
> lights?
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> ___
> 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] "No abbreviations in names" edge case

[Dan S]

2014-06-18 15:35 GMT+02:00 Richard Welty :
> On 6/18/14 8:28 AM, Florian Schäfer wrote:
>> What about the homepage of the city [1]? There it says that "The actual
>> name comes from the fact that our town site on a strip of Cherokee land
>> famous for the Oklahoma Land Run. The name stands for *Indian Exchange
>> Land*".
> in this case, i'd argue that the abbreviation is the name
> and you could use note= or something like that to note
> the origin of the name.
> richard

I'd suggest

name=IXL
old_name=Indian Exchange Land

Great edge case :)

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

Re: [Tagging] Where do source tags belong?

[Dan S]

2014-06-26 12:44 GMT+01:00 André Pirard :

>  Hi,  I wonder if this phrase without an explanation link
>  contains appropriate
> instructions (or just press news):
>
> *Since the introduction of changesets these tags are often added as
> changeset  tags rather than
> in the features themselves.*
>
> It sounds like ("rather than") source tags in objects must now be replaced
> by source tags in changesets.
>

Hi Andre,

The sentence says changeset tags are "often" used in preference, and in
your restatement you have converted "often" to "must now be replaced by".
That is a massive difference, and I feel you've misread. I think the
sentence in the wiki strikes the correct balance.



> While doing so may be appropriate to for huge bulk imports, I don't think
> it's always, even generally, the case.
>

I agree.



> Suppose an osm file built from version 2014_04 of BusCo bus stops data.
> The OSM contributors are invited to copy each object to OSM and to check
> the data, esp. coordinates.
> Should:
>
>- this file's objects contain source=BusCo 2014-04 (ISO date)
> - or the contributor be requested to add that tag to the changesets
>for each and every update
>
> In the first case, the tagging will be done without mistakes and the
> source will be very apparent on the main OSM Web map not only for the
> reader to see but also for overpass to filter which data belongs to BusCo
> and even which is not yet at the latest update.
>
> In the mistake prone, second case, the mapper will be asked to force
> himself in different updates for BusCo and for other necessary updates that
> he will inevitably meet in the process, and the net result of that hassle
> will be a misplaced source tag with regard to visibility and overpass.
>
> Which is the best method? Or is there another one?
>
I personally would say that your changeset source tags should only list the
sources that have been used to make the changes you have made. In other
words, your option 2 shouldn't be recommended. In the case you give, I
would recommend to leave object source tags as they are, and add changeset
tags listing any extra sources that the contributor used for their changes.
I know this feels odd because the "total" source of the OSM data ends up
split between object and changeset, but I think it's acceptable way to
progress, and it definitely remains possible for a machine ot calculate the
"total sources list".

 I think that changeset source tagging is only appropriate to mechanical
> imports and that the above phrase should say so or link to some reading
> that does.
>

I disagree. When I do edits using a single source, it makes a lot of sense
to put the source tag on the changeset. When I do edits using multiple
sources, it makes a lot of sense to put the source tags on the objects.



> It seems strange to have to split updates one per object so that the
> correct source tags are present on each when they could equivalently and
> more appropriately be on the object itself.
> Typical, compared to the variety of object source tags format, is this
> scarce instruction in changeset
> :
>
>
>- source =* – specify
>the source for a group of edits
>
>  Typically, "source for" does not say "source of" what.  Of the objects or
> of the edits as a whole import?
>

Good spot. So the text needs improving. I've edited the sentence to try and
improve it. Obviously I've edited it using my own understanding of the
consensus idea of the tag, so if I'm wrong let's just keep improving it :)

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

Re: [Tagging] MyPlace self-storage facilities

[Dan S]

I notice there are also 209 amenity=storage:
http://taginfo.openstreetmap.org/compare/amenity=storage/shop=storage/shop=storage_units/shop=self_storage
Though I can't guarantee they refer to these self-storage places
(could be private storage if not shop?), some of the UK items
definitely are. And it feels kinda amenity-like...

Dan

2014-07-04 10:26 GMT+01:00 Andreas Labres :
> Is there a clue how to tag such self-storage facilities (eg. MyPlace):
>
>http://www.myplace.at/de/where_is_myplace/vienna/hietzing.html
>
> Taginfo finds:
> 94shop=storage_units
> 46shop=storage
> 16shop=self_storage
>
> (plus some typos/uppercase/withspace)
>
> /al
>
> ___
> 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] Synonymous values in the shop key

[Dan S]

Thanks for your work Mateusz!

2014-07-10 10:21 GMT+01:00 Martin Koppenhoefer :
>> Am 10/lug/2014 um 11:19 schrieb Martin Koppenhoefer :
>>
>> I'd be careful with fishmonger vs seafood (is the latter OK for someone who 
>> only sells fresh water fish?)
>
> also shop=fish might be used for pets (fish only)?

That is the only issue that makes me nervous about the suggested
josm-rules; shop=fish might indicate a pet shop in some cases.
Although since the rules are for josm validation so will be checked by
a human, I guess that's low-risk right?

Dan

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

Re: [Tagging] RFC: crossing=* (was: highway=speed_camera equivalent for non-speed enforcement types)

[Dan S]

2014-07-22 10:43 GMT+01:00 André Pirard :
>
> On 2014-07-22 11:01, Jo wrote :
> I have mentioned without much follow-up a similar issue with highway=crossing 
> + crossing=*.
> What OSM calls "crossing", zebra stripes, is in fact a "passage pour piétons" 
> which does not necessarily cross.

Why do you believe that OSM "crossing" refers not to a place where
highways may be crossed, but to any demarcated pedestrian area on a
highway? In british english it's very clear that a crossing is where
people cross. If "passage pour piétons" refers to a more general
category, then you need to be careful not to confuse the categories.

The wiki says (but not at the top) "This tag is for the node at the
intersection of highways and footways." That matches my understanding
of it.
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcrossing

> In Belgium (too), we have quite a number of "passages pour piétons" painted 
> longitudinally and it makes sense.
> Children's safety, for example, is just as important if they have to walk 
> alongside on the road.
> Or it may be painted across a parking lot, in which case mapping 
> highway=crossing ways make sense.
> crossing=* alone (which, as a highway=* tag implicitly means 
> highway:crossing) is sufficient.
>
> So, I am proposing:
>
> to allow crossing=* on any highway=* when the painting is longitudinal
> crossing:right=yes, crossing:left=yes in that case
> highway=crossing for a way painted across an area

If "crossing" were to be used for places where you cannot cross, this
would confuse many people. I'd suggest you need to use a different
tag.

Best
Dan

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

Re: [Tagging] Change in rendering in Mapnik of Nature Reserves.

[Dan S]

Hi Dave,

Not really an issue for the "tagging" mailing list - I don't think the
people who maintain the style are on here. If you're talking about the
main osm.org style then it's "openstreetmap-carto", maintained here:
https://github.com/gravitystorm/openstreetmap-carto/
If you believe there's an issue then you can file an Issue on that
site. But the style is not really managed by community consensus
(praise be, since design-by-committee would make it even uglier than
it is ;) so don't expect a mass of discussion before every change.

Best
Dan

2014-07-23 22:59 GMT+01:00 Dave F. :
> Hi
>
> Change in rendering of Mapnik Nature Reserves.
>
> I probably missed the discussion for the above. Personally I like the
> previous incarnation with NR letters displaying. It was enough on its own to
> indicate a discernible area, but left enough space to infill with areas of
> grass/woods etc.
>
> Now, on its own, it looks bereft of clarity with just a faint dashed border
> line.
>
> What was the reasoning?
>
> Regards
> Dave F.
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
> ___
> 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 road junction names and traffic signal names?

[Dan S]

If place=hamlet is wrong, I believe place=locality is often used as a
generic tag for nodes indicating named locations. Not really a
solution but a simple option.

Dan

2014-07-24 17:01 GMT+01:00 Lukas Sommer :
> Yes, I know that junction=yes works fine for simple crossroads. My question
> is: How should we map complex junctions like
> http://www.openstreetmap.org/node/2351057522#map=19/5.34399/-4.00300 Using
> just an unconnected node like in this example (even after removing the wrong
> place=hamlet tag) maybe is difficult for turn-to-turn navigation software.
> So, how can we solve this?
>
> Lukas Sommer
>
>
> 2014-07-24 15:29 GMT+00:00 Christian Quest :
>
>> Have you looked at http://wiki.openstreetmap.org/wiki/Key%3Ajunction
>>
>> "junction=yes can be useful for a simple junction node that has a name=*
>> tag"
>>
>> I'm using that in the OSM-FR rendering... and even deal with
>> traffic_signals icon shift to display both icon+name. ;)
>>
>>
>>
>> 2014-07-24 16:42 GMT+02:00 Martin Koppenhoefer :
>>>
>>>
>>> 2014-07-24 15:24 GMT+02:00 Lukas Sommer :
>>>
 Current situation:
 We have the tags highway=traffic_signals (for traffic signals on road
 junctions or at straight roads – typical for Japan) and junction=yes (for
 road junctions with or without traffic signals – typical for Ivory Coast) 
 in
 use at OSM. Both tags are almost exclusively used on nodes. They can be 
 used
 together with name=*. This works quite well for simple crossroads (example:
 http://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png)

 Shortcomings of the current situation:
 It isn’t defined how to tag more complex cases.
>>>
>>>
>>>
>>>
>>> maybe the junction key can be used more universally (with different
>>> values), we are already using it also with junction=roundabout, only that it
>>> could be disputed that junction=roundabout is covering the whole junctions
>>> (the entries and exits you often have to a roundabout could be seen as part
>>> of the junction for instance). More in-use values can be found here:
>>> http://taginfo.openstreetmap.org/keys/junction#values
>>> Some of them maybe aren't junctions (what kind of junction is
>>> "approach"?), others are diverging from our standard mantra (no
>>> abbreviations), like "spui" or "ddi" and might merit retagging?
>>>
>>> cheers,
>>> Martin
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> 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] Feature Proposal - RFC - Tag:leisure=gym

[Dan S]

2014-07-30 21:17 GMT+01:00 Andreas Goss :
> http://wiki.openstreetmap.org/wiki/Proposed_features/leisure%3Dgym
>
> As far as I could see nobody touched this topic for quite some time so I
> created a new proposal as this seems to be how native speakers use the word
> today.

It was also how native speakers used the word ten years ago,
throughout the whole lifetime of OSM! That doesn't prevent it from
being ambiguous in the international context, as described in the
amenity=gym page. I don't worry about the outcome of this proposal,
but your rationale doesn't address the issues raised at amenity=gym.

Dan

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

Re: [Tagging] seafood vs fishmonger (was Re: Synonymous values in the shop key)

[Dan S]

2014-07-31 11:02 GMT+01:00 Martin Koppenhoefer :
>
>
>> Am 31/lug/2014 um 10:27 schrieb Holger Jeromin :
>>
>> The voting was performed "using the extended "North-American definition"
>> - there including fresh water":
>> http://wiki.openstreetmap.org/wiki/Proposed_features/seafood_shop
>>
>> So i see no problem in tagging seafood for every dead fish.
>
> we are using British English, so this doesn't fit well

I appreciate that, but despite being a British English speaker I'm
happy with shop=seafood, and maybe we can use sub-tags to designate
variations on the theme. shop=seafood was porposed, voted and approved
4 years ago and is now more common than shop=fishmonger, so I'd
suggest we should make ourselves comfortable with it :)
http://taginfo.openstreetmap.org/compare/shop=seafood/shop=fishmonger/shop=fish

Dan

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

Re: [Tagging] Research laboratory

[Dan S]

Hi Pierre-Alain,

That's a good question. I thought I'd search a couple of names to see
how they are tagged. Here is a selection:

INRIA (in France):
 * office=research  http://www.openstreetmap.org/node/2529263700
 * office=government http://www.openstreetmap.org/way/124838923
 * landuse=commercial (huh?) http://www.openstreetmap.org/way/52380877

Fraunhofer (in Germany):
 * office=research http://www.openstreetmap.org/way/146020861
 * office=research http://www.openstreetmap.org/node/2869588612
 * landuse=industrial http://www.openstreetmap.org/way/244665212
 * landuse=commercial (huh?) http://www.openstreetmap.org/way/62306004

(I haven't listed entries which don't really have any tagging.)

In my opinion office=research is a good choice, and it is already used a lot:
http://taginfo.openstreetmap.org/compare/office=research/industrial=laboratory/office=laboratory

Best
Dan

2014-08-05 11:06 GMT+01:00 Pierre-Alain Dorange :
> Hello,
>
> First sorry for my poor english, i was french (no one is perfect).
>
> I was looking to tag "Research Laboratory" (either private/commercial
> and public), part or not part of a univercity. This Research laboratory
> are big one with industrial facility (like plant) for biological,
> geological or nuclear research.
>
> I do not find satisfaying tags for that (but perhaps i do not search the
> right way).
>
> OSM wiki do not have info about that (except a 2008 proposal [1])
>
> Taginfo show me :
>
> amenity=laboratory (66)
> building=laboratory (10)
> office=laboratory , but it was pure R&D (not industrial ones)
> health_facility:type=laboratory (138) : but only for medical research
> research_institution=yes (2008 proposal)
> laboratory=*
>
> For big/industrial research lab i would use
> "industrial=laboratory" + "laboratory=nuclear"
> inside a "landuse=industrial"
> For small ones (not industrial) :
> "building=laboratory" + "laboratory=nuclear"
>
> What about this ?
> --
> Pierre-Alain Dorange
> OSM experiences : 
>
>
> ___
> 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] Climbing access path

[Dan S]

The sac_scale is about difficulty, not permission. I assume from
Karsten's original message that only climbers are permitted to use
those paths. If so, then access=customers is appropriate, and
customers=climbers seems helpful...

Dan

2014-08-07 9:50 GMT+01:00 Marc Gemis :
> Wouldn't it be better to use the sac_scale [1] instead of artificially
> limiting it to customers ?
>
> regards
>
> m
>
> [1 ]http://wiki.openstreetmap.org/wiki/Key:sac_scale
>
>
> On Thu, Aug 7, 2014 at 9:51 AM, k4r573n  wrote:
>>
>> I would like to distinguish between hiking paths and climbing_access
>> paths.
>> In my area only climbers are allowed to use the paths to access the
>> cliffs.
>>
>> Therefore I thought of this tagging for climbing_access paths:
>>   access=customers
>>   customers=climbers
>>
>> what I found so far:
>>   path=climbing_access
>>   taginfo found 391 items
>>   eg here:
>>   http://overpass-turbo.eu/s/4sK
>>
>> any suggestions how we should map this?
>>
>> Karsten
>>
>> ___
>> 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] Climbing access path

[Dan S]

2014-08-08 10:21 GMT+01:00 k4r573n :
> On 07.08.2014 12:05, Tom Pfeifer wrote:
>> If I understand Karsten correctly, the limitation is not about payment,
>> it is to limit the number of people using this path. This would be
>> typical for climbing crags in
>> http://wiki.openstreetmap.org/wiki/Conservation
>> areas.
>>
>> A typical example is the sandstone climbing in Saxonia/Germany, which
>> is in
>> a national park that even has a core zone.
>> http://www.openstreetmap.org/relation/1595534
>>
>> The agreement between the protectionists and the climbing associations
>> is that only people "destined" to climb should leave the hiking paths
>> marked for the general public and use those narrow access paths.
>>
>> Thus it would be possible to tag
>> access=destination
>> which could then be specified with
>> destination=climbing
>
> Tom - yes you understood me right :)
> There is no one who check whether your a climber or not or want to have
> a fee - but these path are not aimed to be used by the general public.
>
> I admit that access=customers doesn't fit here so
> summed up we have these approaches:
>   access=destination
>   destination=climbing
>
> or
>   access=climbers
>
> or
>   access=no
>   climbing=yes
>
> I'm ok with each of them but which one should be documented in the wiki

I'd vote for the first one (destination). I'm not keen on the third
one since climbing=* would need to become widely recognised as an
access tag, which doesn't feel very scaleable.

Best
Dan

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

Re: [Tagging] Mapping cave tunnels passable by human

[Dan S]

2014-08-14 11:40 GMT+01:00 Mateusz Konieczny :
> 2014-08-14 12:31 GMT+02:00 Martin Vonwald :
>
>> 2014-08-14 12:25 GMT+02:00 André Pirard :
>>>
>>> On 2014-08-14 11:08, Janko Mihelić wrote :
>>>
>>> Well first, tunnel=yes is obviously wrong. We need to replace this with
>>> cave=yes. Other than that, I have no problems with this. If a cave has two
>>> cave entrances, then information that they are connected by footpaths is
>>> valuable information.
>>>
>>> Obviously?  Regarding paths and waterways, especially ones fitted up for
>>> tourism, I wonder...
>>
>>
>> Maybe not completely obvious, but I would agree with Janko. In my opinion,
>> a "tunnel" is man-made, while a "cave" is not.
>
>
> Neither OSM wiki nor Wikipedia restricts it this way. There is even section
> about natural tunnels - see
> https://en.wikipedia.org/wiki/Tunnel#Natural_tunnels (though caves are not
> mentioned there).
>
> Note, I am not a native speaker - maybe it sound terrible, worse than for
> example using highway as tag also for private roads.

As a native speaker I may as well chip in, and say I have no problem
at all with "tunnel" referring to a natural tunnel as part of a cave
system.

> But I see absolutely no benefit from a completely separate tagging (that
> nobody would support).

Well, no-one ever supports "new" tagging, the question is if it's
needed. But I agree, I can't see a benefit keeping it separate.

Dan

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

Re: [Tagging] Mapping cave tunnels passable by human

[Dan S]

2014-08-14 12:01 GMT+01:00 Friedrich Volkmann :
> On 14.08.2014 07:29, Mateusz Konieczny wrote:
>> I added to http://wiki.openstreetmap.org/wiki/Cave#Tagging_in_OSM how
>> these may be mapped
>
> Given that you want to discuss wiki changes, you should start the discussion
> before you actually do the changes. You should also refer to this mailing
> list thread in the comment of your wiki change, or in the talk page. I
> received an automated notification that you changed the wiki and did not
> know about the mailing list thread, so I corrected the wiki. Now I am
> surprised that there's a discussion in another medium.
>
>> ("tunnels that are available for humans but closed for typical
>> tourists may be mapped as highway=path with tunnel=yes and access=private,
>> and routes available for tourists as highway=footway (highway=steps) with
>> tunnel=yes").
>
> I am not sure about English terminology. In German, we call natural cavities
> "Höhlen" (caves), and artificial cavities "Stollen" (adits?). A straight
> "Stollen" with an entrance on each end is a "Tunnel" (tunnel). I think that
> the meaning of the English word "tunnel" is just the same as in German. In
> that case, tunnels and caves are mutually exclusive.

Not in my native opinion, but let's see what other natives think too.

> I also do not understand why you connect highway=path with private access.
> Paths may or may not be publicly accessible, as are footways. Footways are
> by definition even more restricted, namely to pedestrians.
>
>> I think that it is an obvious idea, but wiki claimed that "At the moment
>> there just a
>> tag to map the entrance to a cave." despite fact that existing tags fit well.
>
> No, they do not fit. Caves are complex three-dimenional structures. In most
> caves there are no paths. You go or climb or rope down whereever you feel 
> like.

This is the same as with a pedestrian square - there's no specific
route in the square and you go wherever you feel. However it's useful
to make them part of the OSM database, both for showing their
existence and to help with various routing applications.

>> I am pretty sure that it is a good idea, but maybe there is some superior
>> scheme or
>> I missed something.
>
> There is no scheme, and I doubt that cave maps belong in a geo database.
> Cave maps are very detailed, and there are special applications for cave
> rendering. For Austria, there's also a database called Spelix, accessable
> via web browser. It contains cave surveys and maps, photos and other data.
> Getting all of that data to OSM would mean continuous duplicated effort and
> yet the data in OSM will never be as complete as the original data. I have
> surveyed a lot of caves and for sure I will not draw all of my cave maps
> again only to get them into OSM. If you are interested in caves, get access
> to dedicated cave databases.

It's great that these specialist databases exist! But as I imply
above, I'd say it is still of value to tag some cave features/routes
in OSM. We can be happy to do this, without attempting the level of
detail in the specialist databases.

>> I wonder about adding something that would denote that way is part of cave,
>> maybe natural=cave_tunnel?
>
> See above. A tunnel is not a cave. If you want to express that a way is
> underground, use layer=-1.

I'm afraid layer=-1 does not express that a feature is underground. It
expresses that a feature is lower than all features at layer=0+, but
there's no guaranteed relationship with ground level. There are quite
a few objects with the implicit layer=0 but which are not at ground
level (e.g. tunnel=culvert items: ).

Best
Dan

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

Re: [Tagging] separator for addr:housenumber=*

[Dan S]

2014-08-18 15:04 GMT+01:00 fly :
> Hey
>
> On the English wiki page [1] "comma" is the proposed separator for
> several values of addr:housenumber.
>
> This contradicts our rule of using "semi-colon" as separator of values
> and I do not have a clue why.

Probably led by what users are already doing, and probably because
renderers produce natural-looking results for places where commas are
conventional. This could be considered tagging-for-the-renderer, if it
weren't already an established micro-convention. I agree with you it's
out of step with convention for other tags.

> I propose to deprecate "comma" and use "semi-colon" instead to harmonize
> our data structure and allow QA software to find problematic values.
>
> What do you think ?

I don't mind. I'm happy with your proposal, if there's enough support for it.

To prevent the tagging-for-the-renderer, it would help if the main
styles would automatically convert "1;3" to "1, 3" when rendering -
I'd be surprised if they already do that, but it would help your
proposal actually happen!

Dan

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

[Tagging] interpolated housenumbers on single objects

[Dan S]

Hi taggers,

When mapping recently, I encountered many addresses which contain
multiple housenumbers behind single entrances. I've used interpolation
before, and used it in the "traditional" sense to map a range along a
row of houses. But here we have an interpolated range on a single
object, not spread across a spatial extent.

I intuitively re-used the addr:interpolation tag, but applied it to a
single object. For example we might have this on a single node or a
building:

  addr:housenumber=100-126
  addr:interpolation=even
  addr:street=Malmesbury Road

Please note that:
 * These house numbers are _not_ flat numbers. That is clear on the ground.
 * From the outside of the block there's no spatial distribution of
those numbers 100-126 so they can't sensibly be represented as a
"traditional" interpolation from one addr to another.

Today (thanks to Fly's email about something else) I noticed that the
wiki says this tagging shouldn't be used. It says:

> You may also add a short way and use addr:interpolation=*. Don't specify the 
> range (e.g., "10-95") directly in the addr:housenumber=* tag. It is 
> impossible to distinguish such ranges from house numbers that officially 
> contain a dash.

I beg to differ. it _is_ possible to distinguish such ranges, because
of the addr:interpolation tag. I certainly understand that software
doesn't currently know that an addr:interpolation tag indicates it may
parse addr:housenumber as a range, but this tagging seemed so
plausible to me that I didn't question it.

Adding a short fake way so that there are addr endpoints seems like a
total hack to me.

How would you tag it?

Best
Dan

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

Re: [Tagging] interpolated housenumbers on single objects

[Dan S]

Hi,

Thanks all for your thoughts. Will and Holger seem to have the same
approach as me, which gives me the confidence to edit the wiki and at
least document this approach:
http://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers

Hopefully I've done it in a way which won't anger those who dislike the idea: ;)

Dan


2014-08-19 22:45 GMT+01:00 Will Phillips :
> I often use the addr:interpolation tag on entrances or buildings. I don't
> understand some people's objection to this. I don't see any ambiguity: if
> the addr:interpolation tag is present the addr:housenumber tag represents a
> range, otherwise it should be interpreted as a single address. As someone
> who maps addresses regularly I find this a quick and convenient way to do
> it. All the alternatives are either cumbersome for the mapper, or are hacky,
> because they involve putting addresses at arbitrary positions within a
> building.
>
> I find that by far the most time consuming part of surveying house numbers
> is actually adding the data afterwards and for this reason I think we should
> be trying to make the tagging quick and straightforward for mappers wherever
> possible. To me restricting the use of addr:interpolation seems an
> unnecessary rule that makes things more difficult. Additionally, we should
> avoid making it unnecessarily complicated for mappers to add useful
> information. For example, if numbers 20 to 40 on a street are accessed
> through a particular door, I want to tag that explicitly, because it's
> useful for routing and accessibility. Advocating tagging that forces me
> instead to stick the addresses at an arbitrary position within the building
> outline is unhelpful.
>
> The proposed Node relation mentioned by Janko Mihelic is I think a useful
> idea for certain situations. For example, I've encountered cases where
> addresses accessed through a single door have more than one postcode, so
> can't be accurately represented on a single node. These relations would
> allow all the addresses to be associated with the entrance. However, I'm not
> convinced it's a good solution for simpler cases because making mappers
> create separate nodes for all the numbers in a range and then linking them
> together with a relation seems over-complicated.
>
> The wiki documentation for using addr:interpolation on single objects has
> been changed several times. As Dan noted, the current version recommends
> against it. A few months ago I reinstated an earlier version that recognised
> and briefly explained this usage, but it was removed by a user who wrote it
> was ambiguous, but they didn't really explain why they thought it so. I
> propose adding it again.
>
>
> ___
> 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] interpolated housenumbers on single objects

[Dan S]

2014-08-20 11:11 GMT+01:00 Ilpo Järvinen :
> On Wed, 20 Aug 2014, Will Phillips wrote:
>
>> On 20/08/2014 00:02, Martin Koppenhoefer wrote:
>> > > Il giorno 19/ago/2014, alle ore 23:45, Will Phillips  
>> > > ha
>> > > scritto:
>> > >
>> > > I find that by far the most time consuming part of surveying house
>> > > numbers is actually adding the data afterwards and for this reason I
>> > > think we should be trying to make the tagging quick and
>> > > straightforward for mappers wherever possible.
>> >
>> > Which editor are you using?
>>
>> I've always used JOSM.
>>
>> Speaking to other mappers, they usually agree that data input for addresses
>> takes 2-3 times as long as the actual surveying.
>
> My experience is that it takes even longer than that especially if the
> area contains small houses rather than bigger buildings. Drawing them
> all is very slow compared with inputting addr data. I'd say 10-20x.
>
>> There are various reasons for this, some specific to mapping where I
>> live (England).
>>
>> Why it takes a long time -
>> 1. The usual problems of reconciling the surveyed data with existing data and
>> the aerial imagery.
>> 2. Adding other detail at the same time. In particular, adding buildings. It
>> would be much quicker if I chose just to add nodes.
>
> So true.
>
> With the experience of tens of thousands addresses survey, this is really
> big obstable. Some of my surveyed data rotted(!) because the drawing delay
> hindered immediate input. That is, I lost the near-term memory about
> details before I could draw all the building I could easily survey
> addresses for.
>
> This is also the reason I really get almost angry when people oppose
> importing building without addresses (because they find them "useless"
> without other details such as addresses included already during the
> import). I doubt that such people have much experience on surveying
> addresses and trying to draw the buildings while inputting the addr data
> to OSM.

I agree with these observations from your experience. Back in January
I said I suspected building outlines were unimportant*. But that was
before I started heavily address-mapping! My opinion now is that a
two-step process works really well: first pass gets basic building
outlines (from aerials or maybe even from imports), then second pass
is address mapping on the ground, which will probably also include
lots of changes to the building outlines. But the first pass makes the
second pass a lot easier - both the surveying and the data entry.

Best
Dan

* http://www.openstreetmap.org/user/mcld/diary/20663

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

Re: [Tagging] Ambiguous surface=wood

[Dan S]

I'd say it's very rare that "wood" could be interpreted as possibly
meaning "woodchip". Woodchip has very different material properties,
and different affordances for travellers. A little bit like saying
"wood" might mean "sawdust" ;)

surface=woodchip is used more often than surface=woodchips, though
neither of them is used very much at the moment:
taginfo.openstreetmap.org/compare/surface=woodchip/surface=woodchips

I would advocate "surface=woodchip" (singular), and preserve the
existing meaning of surface=wood as planks.

Maybe we should document "surface=woodchip"?

Just my 2p
Dan


2014-08-22 6:53 GMT+01:00 Mateusz Konieczny :
> I discovered* that surface=wood is ambiguous and may mean two very different
> things:
> 1) paths with wood chips
> 2) paths paved with wooden planks (for example
> https://pl.wikipedia.org/wiki/Plik:Bernatek_foot-bridge_%28Love_padlocks%29,_Krakow,_Poland.jpg
> )
>
> I want to tag in way that would be clear, now I consider using for the
> second
> situation [surface=wood; wood=planks] or [surface=planks] and
> [surface=wood; wood=chips] or [surface=woodchips] for the first one.
>
> Currently wiki mentions only situation (2).
>
> *http://forum.openstreetmap.org/viewtopic.php?pid=444548#p444548
>
> ___
> 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] separator for addr:housenumber=*

[Dan S]

2014-08-24 11:05 GMT+01:00 Friedrich Volkmann :
> On 20.08.2014 10:18, Holger Jeromin wrote:
>> Andreas Labres wrote on 20.08.2014 04:10:
>>> On 19.08.14 23:17, fly wrote:
 but 265-267 is wrong
>>
>> Read as "tagging 265-267 alone is wrong".
>>
>>> Disagree. addr:housenumber is the official number given to that building. 
>>> And if
>>> it's "265-267", then addr:housenumber=265-267 is the only correct 
>>> implementation
>>> of this.
>>
>> But osm db needs a hint that 266 is missing. That is obvious on the
>> street (by looking at the right and left building) but not in the data.
>
> The OSM db does not need to know about (the meaning of) housenumbers. Its
> sole purpose is to store data. In this case, the housenumber is "265-267",
> literally! This is not a shortcut for "265;266;267".

Agree strongly - I think it is a mistake to say "osm db needs a hint
that 266 is missing" when considering an address which is officially
labelled as "265-267". If addresses truly are compounds like that (and
not number-ranges) then we can't really make standard inferences about
which numbers are "present" and which are "missing".


> Applications should not attempt to resolve housenumbers that way.

...unless they have been explicitly marked with "addr:interpolation",
which tells us explicitly that they should be resolved :) - discussed
in a separate thread recently.

Dan

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

Re: [Tagging] separator for addr:housenumber=*

[Dan S]

2014-08-24 11:24 GMT+01:00 Friedrich Volkmann :
> On 18.08.2014 22:36, Janko Mihelić wrote:
>> What happens when the same entrance has two housenumbers, each from its own
>> street? I'm sure this exists somewhere.
>
> The housenumber belongs on the building or building part, not the
> entrance(s). When a building (part) has two equivalent addresses, use the
> addr:* schema for one address and the addr2:* schema for the other.

There are quite a lot of objects in the database that disagree with you ;)
http://taginfo.openstreetmap.org/keys/entrance#combinations

This is one of those cases which probably has a strong flavour of
country- or location-specific conventions. There are many addresses in
London which, if I had to tag them as buildings or building parts, I
could not stay sane! On the ground, around here, they are _very_ often
associated with multiple entrances on a building and not with
explicitly indicated building parts.

Best
Dan


>> > I propose to deprecate "comma" and use "semi-colon" instead to 
>> harmonize
>> > our data structure and allow QA software to find problematic values.
>>
>>
>> +1
>
> Semicolons seem more consistent than commas, but I doubt that either of them
> are applicable for real-world addresses. In Austria, we use dashes as
> separators, as Andreas pointed out; except when housenumbers relate to
> different streets (see above).
>
> --
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> ___
> 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] separator for addr:housenumber=*

[Dan S]

Hi Christian,

As I've already mentioned, in the other thread we discussed a
disambiguation. I would suggest that if you find only

  addr:housenumber=265-269

then you can't really assume any interpolation, and I would argue that
even transforming it to "265" and "269" is going beyond what the data
tells you. However, even though it is "going beyond" the data, it may
be a sensible thing to do if you are working specifically on a
geocoding system. (That is application-dependent.)

The problem with going beyond the data is that there may be
housenumbers which officially have dashes in, but would be meaningless
if broken up. (I found these ones for example:

- but there are only a tiny quantity so these examples are not too
serious.)

On the other hand, if you see an object tagged

  addr:housenumber=265-269
  addr:interpolation=odd

then we can be quite confident that the mapper intended you to
interpret this as "265" and "267" and "269".

Best
Dan


2014-08-24 12:31 GMT+01:00 Christian Quest :
> In that case, how should application resolve housenumbers ?
> What tagging do you propose to allow it ?
>
> I'm working on the BANO project who aims to create a nationwide address
> database, using in part OSM data.
> I already have to deal with this kind of addr:housenumber=*
>
> For the moment, 265-269 is transformed into 265 and 269 only, but having
> some tag based clue that we have an odd number range meaning that 267 is
> located at the same place would be a real benefit.
>
>
>
> 2014-08-24 12:05 GMT+02:00 Friedrich Volkmann :
>
>> On 20.08.2014 10:18, Holger Jeromin wrote:
>> > Andreas Labres wrote on 20.08.2014 04:10:
>> >> On 19.08.14 23:17, fly wrote:
>> >>> but 265-267 is wrong
>> >
>> > Read as "tagging 265-267 alone is wrong".
>> >
>> >> Disagree. addr:housenumber is the official number given to that
>> >> building. And if
>> >> it's "265-267", then addr:housenumber=265-267 is the only correct
>> >> implementation
>> >> of this.
>> >
>> > But osm db needs a hint that 266 is missing. That is obvious on the
>> > street (by looking at the right and left building) but not in the data.
>>
>> The OSM db does not need to know about (the meaning of) housenumbers. Its
>> sole purpose is to store data. In this case, the housenumber is "265-267",
>> literally! This is not a shortcut for "265;266;267". Applications should
>> not
>> attempt to resolve housenumbers that way.
>>
>> --
>> Friedrich K. Volkmann   http://www.volki.at/
>> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] default value for "oneway"

[Dan S]

2014-08-28 14:45 GMT+01:00 Xavier Noria :
> On Thu, Aug 28, 2014 at 3:39 PM, Dave F.  wrote:
>
>> I wish people in OSM would stop making things up, believing it makes their
>> point of view stronger.
>
> What?
>
> I am not assuming one-way would be a better default. Nor I am assuming
> anything about the world at large. What are you talking about?

Let's put all that aside.


> I only asked questions:
>
> 1) Which is the rationale? Not because I think it is wrong, but to
> understand it!

As Peter said, the default for services using OSM is always to assume
a way is _not_ oneway unless tagged otherwise.


> 2) In cities and towns where two-way streets are exceptional like
> Barcelona or Madrid, are people expected to tag them "no"? The
> motivation for this question is that there seems to be the convention
> not to tag them, and therefore you cannot tell the confirmed ones from
> the untagged ones.

No, I think more likely is that local mappers have not considered it a
priority to add the oneway tags, or maybe there are so many that it's
a difficult job that isn't finished yet.

Best
Dan

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

[Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

Hi all,

I have been fixing some university tagging (Sheffield contained
hundreds of amenity=university!). For student accommodation, I have
been using

 for buildings:   building=residential + residential=university + operator=*
OR
 for sites:   landuse=residential + residential=university + operator=*

Note that the same scheme seems to me to work well for building and for landuse.

I thought this had been discussed on tagging recently, but I can't
find it, all I can find is the RFC for amenity=dormitory, currently
used 263 times. (I will add that "dormitory" is certainly a little odd
from a British English point of view, notwithstanding the comments
already made to the RFC.)

residential=university has been used by a few people (99 objects, says
overpass). 33 of these are building=residential, 53 are
landuse=residential.

It's clear I'm not the only one using this pattern, though it's not an
approach that's officially adopted as far as I know. To me it seems
very meaningful usage, compatible with existing tagging, and covers
the intended use of amenity=dormitory except for monasteries ;)

Thoughts?

Best
Dan

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

2014-09-19 15:52 GMT+01:00 Tobias Knerr :
> On 19.09.2014 14:22 Dan S wrote:
>>  for buildings:   building=residential + residential=university + operator=*
>> OR
>>  for sites:   landuse=residential + residential=university + operator=*
>>
>> Note that the same scheme seems to me to work well for building and for 
>> landuse.
>>
>> I thought this had been discussed on tagging recently, but I can't
>> find it, all I can find is the RFC for amenity=dormitory, currently
>> used 263 times. (I will add that "dormitory" is certainly a little odd
>> from a British English point of view, notwithstanding the comments
>> already made to the RFC.)
>
> That proposal now suggests amenity=student_accommodation, precisely
> because of the oddness involved with the term "dormitory".

Ah yes, thanks. So now it assumes the occupants are students and not
lecturers ;)

(I'm just being cheeky. I know of universities in which lecturers do
stay in similar accommodation blocks, but that point is not important
enough to argue about...)

> Personally, I prefer using the amenity key rather than building or
> landuse. Landuse lacks the implication that this is one distinct
> facility

OK. I understand why you'd prefer amenity for tagging the usage. If
that tag gets accepted I guess I should use that instead of landuse,
and I understand your arguments there. I feel differently, because I
feel the analogy between a "housing estate" and a multi-building
"student halls" site is quite a strong analogy, neatly represented by
a named area of landuse=residential. But there we go.

> and building values are not supposed to represent usage, but how the building 
> is built.

This week I stayed in university accommodation (even though I'm not a
student ;), and the buildings were purpose-built student halls, so it
would be nice to tag the building appropriately. Alternatives include:
(a) "building=residential" (without subtagging), which is fine if vague;
(b) "building=apartments", which is tolerable but not quite appropriate;
(c) "building=dormitory" which is in use, but it's US English, and to
my Brit English mind just feels wrong. Sorry to moan about the US/UK
difference, but it is indeed a difference:
<http://dictionary.cambridge.org/dictionary/british/dormitory>,
<http://www.oxforddictionaries.com/definition/english/dormitory>
(d) "building=residential + residential=university", the approach I
was using recently. Not as widely used. It has an advantage of
graceful fallback (meaning data-users can understand the objects as
building=residential even if they ignore the subtag).

I still prefer (d) though if building=dormitory becomes widely
accepted then I guess I shall have to swallow that loss for British
english!

Cheers
Dan

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

Re: [Tagging] (Soapy) Massage Parlour

[Dan S]

Hi -

It looks like there's this tag, including a tag suggested for your
specific issue:
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage

Best
Dan

2014-09-21 4:23 GMT+01:00 Mishari Muqbil :
> Hi,
>
> Thailand has these places called "entertainment complexes"[1]  that
> offers bathing + massage services and quite often the expectation is
> that there will be sexual services offered. However, I don't want to tag
> them as brothels as prostitution on the premises is legally not allowed[2].
>
> I propose to tag this as leisure=massage_parlour since that's what the
> Thai English dictionary calls them[3] but I don't want it to be mistaken
> for more family friendly establishments in other parts of the world.
> Colloquially these places are called soapy massage so perhaps
> leisure=soapy_massage? :)
>
> One reason why they should be mapped is just how prominent they are as
> landmarks in general. For example, here's one called Utopia
> http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La
> Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and
> Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw
>
> Any thoughts?
>
> [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat
> [2]
> https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act
> [3]
> http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94
> --
> Best regards
> Mishari Muqbil
> EE32 64BD 7D1F 5946
>
> ___
> 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] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

2014-09-21 0:49 GMT+01:00 Eugene Alvin Villar :
> On Sun, Sep 21, 2014 at 7:09 AM,  wrote:
>>
>> Dormitories are rooms with multiple beds, usually bunk beds and associated
>> with youth hostels,  certainly not suitable for student accommodation where
>> there is typically one student in a room, maybe two but they are certainly
>> not dormitories.
>
> What you're saying is British English usage. Here in the Philippines,
> dormitories are understood to be buildings primarily for students.

Thanks. So we've re-confirmed that the word "dormitory" has some
ambiguities that might be problematic, especially considering that OSM
is based on British English.

Eugene points out "sport=soccer" which is a good example of OSM
deliberately avoiding ambiguities, since in that case the common term
"football" has one meaning in US and one in UK. In that case we
avoided the British term as a special case, to avoid the ambiguity.
Here "dormitory" is the ambiguous term.

But that's all fine, since remember that Hno's tag proposal has
already been altered to amenity=student_accommodation.
https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dstudent_accommodation
I agree with fly that it'd be nice to have a tag which didn't fix the
profession (so that it could be used for nurses/lecturers/etc) but
maybe that's not so bad.

Cheers
Dan

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

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

[Dan S]

2014-09-19 16:15 GMT+01:00 Martin Koppenhoefer :

>
> 2014-09-19 14:22 GMT+02:00 Dan S :
>
>>
>>  for buildings:   building=residential + residential=university +
>> operator=*
>> OR
>>  for sites:   landuse=residential + residential=university + operator=*
>>
>> Note that the same scheme seems to me to work well for building and for
>> landuse.
>
>
>
> I am not sure if this "works". Have you been looking at current values for
> the "residential" key? These are the ones with more than 100 uses:
>
> rural <http://taginfo.openstreetmap.org/tags/residential=rural>
> 78 141
>
> -
>
> urban <http://taginfo.openstreetmap.org/tags/residential=urban>
> 12 698
>
> -
>
> garden <http://taginfo.openstreetmap.org/tags/residential=garden>
> 3 805
>
> -
>
> gated <http://taginfo.openstreetmap.org/tags/residential=gated>
> 884
>
> -
>
> apartments <http://taginfo.openstreetmap.org/tags/residential=apartments>
> 231
>
> -
>
> single_family
> <http://taginfo.openstreetmap.org/tags/residential=single_family>
> 197
>
> -
>
> detached <http://taginfo.openstreetmap.org/tags/residential=detached>
> 133
>
>
>

Thanks Martin. Yes I did look at these. NONE of them have a wiki page, nor
does the residential=* tag in general, so I'm at a loss to work out what is
intended by them!

* Surely the rural/urban distinction is judged by location? Could you have
residential=rural in the town centre? Maybe (since the tag isn't
documented) but I would guess not. So what's the tag for? Does it designate
context, building style, building density...?

* Surely apartments/detached/single_family should be properties of the
building objects?

* residential=garden I quite like, but it seems to duplicate leisure=garden
and it seems strange to me to consider gardens as "residential" since
usually no-one lives in the garden. I wonder if it was ever discussed much.

* residential=gated I like. In theory you can use barrier=* and access=* to
indicate the unusual access constraints for gated residences, but actually
it's not always obvious as that, since non-gated communities might also
have fences etc. So this tag seems to me like it might make a useful
distinction.



> There are already at least 3 different systems (one for rural / urban and
> one for the building typology (detached / single_family / apartments) and
> one for gated communities (what's this, socio-economic aspect of urbanism
> maybe?). Now you seem to be adding yet another one, "university" for
> student's appartments (not really self explaining IMHO).
>

So if not self-explaining, what misunderstandings of
"residential=university" could happen? It seems quite self-explaining to
me, so I'd be grateful if you could offer your perspective of potential
misunderstandings of "residential=university".



> I would use a specific tag for the building typology (e.g.
> building=dormitory or student_accomodation or similar if the building was
> built as such) and another one if it is actually used as such (e.g. under
> the amenity key as suggested by Tobias).
>

Understood. For the building, at least, the subtag works, if used to
indicate building typology.



> I don't see this as a case for adding a specific landuse value, but I do
> agree that refining the generic "residential" into more differentiated
> values by subtagging might be a general option (regardless of this
> particular case of student accomodation), e.g. differentiate according to
> density and
>
> structure (open / closed, not sure about the precise term in English, for
> reference see these two pictures:
> open (=space between buildings)
> http://de.wikipedia.org/wiki/Offene_Bauweise_%28Baurecht%29#mediaviewer/File:Offene_Bauweise.png
> closed (buildings without space between them):
> http://de.wikipedia.org/wiki/Geschlossene_Bauweise_%28Baurecht%29#mediaviewer/File:Geschlossene_Bauweise.png
>

In British English this seems to me to  "detached" vs "semi-detached" vs
"terrace" (though there's not a 1:1 concept match). Again, though, it's not
clear to me why you'd want to tag residential areas as having these
properties, since they're already commonly indicated via the tags/geometry
of the building objects.

Thanks again for your detailed reply.

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

Re: [Tagging] (Soapy) Massage Parlour

[Dan S]

Hi,

Well, that suggestion specifies access limits (i.e. only males age 21
or more), and if those are true facts and they're what you want to
indicate, then go ahead. The access limits don't really tell you if
something is soapy or not, but if you decide you only want to "imply"
that and not to state it explicitly, your approach sounds OK to me.

However, there's NO reason to use amenity=massage_parlour when
shop=massage already exists. Please use it. You said you want to avoid
confusion between soapy and family-friendly, and your age-restriction
works for that, no need to create a duplicate tag.

Best
Dan


2014-09-21 14:52 GMT+01:00 Mishari Muqbil :
> Hi,
>
> I saw that, but I'm not convinced it's the right approach as what I'm
> referring require a specific massage parlor license to operate as
> opposed to a regular traditional massage establishment which is more
> suited for shop=massage. I think it would be akin to saying a
> convenience store and supermarket can all be tagged the same way. Also,
> I'm not comfortable with using sexual as it could be libelous to state
> that something illegal is taking place in these establishments (for
> example, you won't do shop=convenience+marijuana=yes in most parts of
> the world).
>
> How about something like a combination of:
> amenity=massage_parlour
> male=yes
> female=no
> min_age=21
>
> This should be quite accurate.
>
> On 21/9/14 16:04, Dan S wrote:
>> Hi -
>>
>> It looks like there's this tag, including a tag suggested for your
>> specific issue:
>> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage
>>
>> Best
>> Dan
>>
>> 2014-09-21 4:23 GMT+01:00 Mishari Muqbil :
>>> Hi,
>>>
>>> Thailand has these places called "entertainment complexes"[1]  that
>>> offers bathing + massage services and quite often the expectation is
>>> that there will be sexual services offered. However, I don't want to tag
>>> them as brothels as prostitution on the premises is legally not allowed[2].
>>>
>>> I propose to tag this as leisure=massage_parlour since that's what the
>>> Thai English dictionary calls them[3] but I don't want it to be mistaken
>>> for more family friendly establishments in other parts of the world.
>>> Colloquially these places are called soapy massage so perhaps
>>> leisure=soapy_massage? :)
>>>
>>> One reason why they should be mapped is just how prominent they are as
>>> landmarks in general. For example, here's one called Utopia
>>> http://www.mapillary.com/map/im/z1A8OOUw01E5Jc84Mff-1Q this one's La
>>> Defense http://www.mapillary.com/map/im/ho84IFdUxupke-6pwrWW3g and
>>> Colonze http://www.mapillary.com/map/im/469ttdMVw4_1o3vkuvE_xw
>>>
>>> Any thoughts?
>>>
>>> [1] https://en.wikipedia.org/wiki/Prostitution_in_Thailand#Ab_Ob_Nuat
>>> [2]
>>> https://en.wikipedia.org/wiki/Prostitution_in_Thailand#The_Entertainment_Places_Act
>>> [3]
>>> http://th.w3dictionary.org/index.php?q=%E0%B8%AA%E0%B8%96%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%B2%E0%B8%9A%E0%B8%AD%E0%B8%9A%E0%B8%99%E0%B8%A7%E0%B8%94
>>> --
>>> Best regards
>>> Mishari Muqbil
>>> EE32 64BD 7D1F 5946
>>>
>>> ___
>>> 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

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

[Tagging] Feature Proposal - RFC - residential=gated

[Dan S]

Hi all,

Motivated by the discussion around residential=* sub-tagging, I
thought it would be useful to get a bit more clarity, by taking some
existing sub-tagging and putting it through RFC.

Here is a proposal for residential=gated:
http://wiki.openstreetmap.org/wiki/Proposed_features/residential%3Dgated

I chose this tag because it's already used quite a bit, its meaning
seems clear to me, and it seems potentially useful, though I can't
predict if the community more generally will consider it useful.

Please comment on the wiki talk page.

Thanks
Dan

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

[Tagging] RFC: Student accommodation building

[Dan S]

Hi all,

Following the tagging conversation about student accommodation
buildings, I created a proposal wiki page, to document the different
tagging perspectives, and maybe one day work towards half a consensus
;)

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

(Note: this is about tagging a building type; it's separate from Hno's
"amenity=student_accommodation" proposal which aims to tag the usage.)

Best
Dan

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

Re: [Tagging] (Soapy) Massage Parlour

[Dan S]

2014-09-22 7:29 GMT+01:00 Stephan Knauss :
> On 21.09.2014 11:04, Dan S wrote:
>>
>> It looks like there's this tag, including a tag suggested for your
>> specific issue:
>> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage
>
> please don't use shop=massage for this kind of places.
>
> I really don't want them to show up on a map next to Wat Pho massage just
> because the map creator does not take into account some additional tagging
> which says "yes, it's tagged as a massage, but this tag tells you it isn't".
>
> Additional tags can specify something further, but should not change the
> meaning in general.

The original message said this kind of place "offers bathing + massage
services" plus the sexual stuff. My advice was based on that
description. You seem to be saying that these places _don't_ offer
massage services. I don't actually know which of these is true!

Dan

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

Re: [Tagging] Retag: craft=sweep => craft=chimney_sweep

[Dan S]

2014-10-03 12:06 GMT+01:00 Martin Koppenhoefer :
>
> 2014-10-03 12:58 GMT+02:00 Tom Pfeifer :
>>
>> I agree that craft=chimney_sweep is less ambiguous than =sweep
>> alone, and with currently 24 instances in taginfo it would be a
>> good time to change wiki and tags.
> +1

Yes, fine, I would say.

> what about "chimney_sweeping" to indicate the trade/craft (?) rather than
> the professional (person)?

Please, no! "Chimney sweeping" is not a phrase in British English,
whereas "chimney sweep" is. Plus, most of the craft=* tags use the
professional (person):
http://taginfo.openstreetmap.org/keys/craft#values

Dan

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

Re: [Tagging] governmental / public_administrative landuse are not commercial

[Dan S]

2014-10-03 18:14 GMT+01:00 Tom Pfeifer :
> Martin Koppenhoefer wrote on 2014-10-03 15:32:
>>
>> 2014-10-03 15:19 GMT+02:00 Tom Pfeifer:
>>
>> I feel the need for a landuse tag for governmental / administrative
>> use,
>> maybe in the context of further civic use.
>>
>> We do have office=administrative and office=government but no
>> appropriate
>> tag for the land they stand on. Often such buildings are surrounded by
>> some land and often fenced off.
>>
>> not sure if office could also apply to the whole area (site) on which the
>> office building stands (similar to how this is done with other amenities).
>
>
> I'd prefer to keep the office= tag to the building, or different offices in
> a building.
>
>> Just to be sure: when writing about "administration" you are referring
>> only to the "public administration"?
>
>
> Yes absolutely. Any commercial administration can keep the commercial
> landuse.
>
>> Yes. I agree that the current practise of using "commercial" for all kinds
>> of offices seems a bit strange, at least from a German point of view. I am
>> not sure if the term "commercial landuse" is understood differently in
>> English speaking countries. E.g.
>> they do call their centres "commercial district" and "central business
>> district" while in other cultures there might be a less business related
>> term in use to articulate high density with mixed usage, but not focused on
>> business (because there are also
>> other features located typically, like theatres, museums and other culture
>> related facilities).
>> http://en.wikipedia.org/wiki/Commercial_district
>>
>> I see the introduction of a new, more specific key positive, e.g.
>> landuse=public_administration
>
> +1

I would have suggested landuse=civic. Looking at taginfo, I don't see
it in use, though there is a small number of landuse=civil already.
(Plus other stuff of course...)

Dan

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

Re: [Tagging] cleanup of the key natural

[Dan S]

Hi Martin,

OK, well since you requested comments: Firstly, I find it difficult to
understand what makes your proposed split more "coherent" or "easy to
learn" than thewiki- grouping that you propose to revert! By the way
please don't start a revert battle without first talking to that
editor.

Secondly, these tags are used so widely that I think you may have
missed your chance. For example it's not clear to me whether you would
accept natural=tree (see my first point), but since there are more
than 4 million of them, I think you are going to have to accept them.

If you want to make a change to the tagging of a massive number of
objects, you're going to need a _really_ persuasive argument. Not to
persuade me, but to persuade the "crowd"...

Just my 2p

Best
Dan


2014-10-07 14:42 GMT+01:00 Martin Koppenhoefer :
> According to the wiki, the natural key is currently a mixture of different
> aspects of something. The wiki states that it covers a selection of
> "geological" and "landcover" features.
>
> My suggestion is to keep only geological/geographical features in "natural"
> (all three, point features like peak and spring as well as linear features
> like natural=cliff or coastline and areas like
> natural=fell/wetland/beach/heath/bay/scrub/...) and to move the landcover
> features (those describing material rather than features, e.g. "mud" and
> "sand") to a different key (my suggestion is "landcover" but there are also
> mappers advocating "surface").
>
> A more coherent scheme would have a lot of advantages (easier to learn and
> understand because of more inherent logics, easier to maintain and extend
> and would allow to elaborate on different aspects for the same area object
> (i.e. will lead to more detailed data in the end)).
>
> ---
>
> Additionally I have spotted that recently a user has decided to group the
> features according to his interpretation:
> http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:natural&action=history
>
> I believe that this new grouping is disputable and propose to revert this
> change.
> ---
>
>
> Please comment.
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Default maxspeed unit on waterways

[Dan S]

2014-10-29 14:07 GMT+00:00 Pieren :
> On Wed, Oct 29, 2014 at 2:52 PM, Tom Pfeifer  wrote:
>> km/h is derived, at least with an integer multiple of seconds,
>> from SI units. mph and knots are not. I would prefer to keep
>> one default unit per tag, consistently, everything else leads
>> to confusion.
>
> What is leading to confusion is to suggest that km/h is the default
> unit for waterway speed when  knot is in use everywhere.

Pieren, is there an example of confusion actually being caused?


> Please think
> as a contributor, not as QA programmer or data consumer (it's easy to
> check if the speed limit belongs to a waterway or not).

It's easy to think up potential for confusion whichever way we go on
this. Thinking as a contributor, the editing interfaces should make it
clear which units the user is stating/implying - as iD does, for
example. I definitely sympathise with Tom's reasoning for one unit per
tag, so I'd suggest there would need to be a strong case for this
mixed-units approach...

Dan


> And "The knot is a non-SI unit that is "accepted for use with the SI"
> (https://en.wikipedia.org/wiki/Knot_%28unit%29)
>
> Pieren
>
> ___
> 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] Release openstreetmap-carto v2.23.0

[Dan S]

Frederik,

The tagging and the wiki have been that way for many years.
http://wiki.openstreetmap.org/wiki/Bed_and_breakfast

I share your discomfort, since I think of a B&B as a different thing
from a guesthouse. But over the years I've ended up using this tagging
since it's documented and appears to be how people tag. I guess it's
not Matthijs who made this decision...

Best
Dan

2014-10-29 20:55 GMT+00:00 Frederik Ramm :
> Hi,
>
> On 10/29/2014 09:34 PM, Matthijs Melissen wrote:
>> * The tag tourism=bed_and_breakfast is no longer rendered - please use
>> tourism=guest_house instead.
>
> Well - it might be your decision what to render and what not, but you
> shouldn't go so far as to request that people misrepresent reality in
> their mapping.
>
> A private residence where a single bedroom is made available to tourists
> is certainly no "guest house" and shouldn't be tagged as such! It is,
> and remains, a "bed_and_breakfast".
>
> 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

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

Re: [Tagging] path vs footway

[Dan S]

One of the most important differences is that for highway=footway, we
know that pedestrians are allowed (unless other tags alter the access
explicitly). With highway=path we can't always assume that pedestrians
are allowed along it. I know there are routing systems that care about
this difference.

As others have said, the choice of which to use is very very fuzzy,
but if you use highway=path please make sure to use some access
tagging to say what kind of traffic may pass along it.

Best
Dan


2014-11-03 22:38 GMT+00:00 Mike Thompson :
> I am editing trails in a US National Park of which I have first hand
> knowledge.  Nearly all trails in this area have been tagged
> "highway=footway" although most of them are open equally to foot
> traffic and horse traffic. Any reason to leave them as "footways"? The
> wiki suggests that "path" is more appropriate. It would be nice to
> have consistent data, otherwise it suggests that one trail is
> different from the next when if fact they are not.
>
> By the way, might this be an artifact of the defaults in Potlatch?
>
> Thanks,
>
> Mike
>
> ___
> 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] Pathways with steep vertical slopes, accessed via climbing chains

[Dan S]

Hi -

I don't have a direct answer I'm afraid. But please try not to think
about "what gets rendered" - the default style shown on the osm.org
homepage is just one of hundreds of rendering styles that are used. If
there are existing tags in use, great, whether or not they show on the
osm.org rendering. If not, then maybe you and others can think of
tagging that represents things properly - get the semantics right,
leave the rendering to the renderers.

Best
Dan


2014-11-04 3:28 GMT+00:00 johnw :
> Went hiking on mt Miyogi yesterday in Gunma, and like other steep mountain
> parks, sections of the trail were near vertical or completely vertical
> sections of trail that have to be climbed by chains and occasional
> footholds.  the longest was over 30m. the shortest was about 4m.
>
> http://www.openstreetmap.org/#map=16/36.2861/138.7454
>
> http://www.gunmajet.net/wp-content/uploads/2013/07/photo_02-copy.jpg
> someone posted up the route they took, and the hiking maps show the easier
> trail in blue (his yellow route, it goes over a section of chain.) and the
> dangerous ones in red.
> Chains area also used to show access to features near the trail via chain
> assisted climbing
>
> The current tail map needs to be expanded, and I want to work on that. but
> I’m wondering how to visually show that chains are necessary. I know other
> trails in other countries have similar permanent guide fixtures (cables,
> ropes, ladders in the rock,) where normal hikers are expected to use them.
>
> now, you might think that this is considered climbing, and you’d have a
> helmet, but people were scampering up the rocks, old guys and 10 year olds
> alike.  These “blue” sections were considered passable by regular hikers,
> and the upper level sections of the mountain were all marked for
> professional climbers (“red” routes with the red 危 splat) because a slip off
> the trail or the chain would mean death (200m drops).
>
> is there some method to tagging these that is rendered (that’s not steps) to
> visually show that chains or other assist devices are used?
>
> ___
> 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] Combining gas stations & convenience stores

[Dan S]

Hi -

It doesn't make sense to me to have a specific tag for "fuel and
convenience". Maybe I misunderstand you. I would say, keep copying the
addresses! There are lots of situations where multiple co-located
items have the same address, e.g. a small post office inside a
supermarket. If you invented a new tag it would be harder for people
to find the convenience shop...

Best
Dan


2014-12-05 5:19 GMT+00:00 Hans De Kryger :
> Hopefully this gets enough attention on the tagging list. Thought about
> posting this to talk U.S but changed my mind.
>
> Anyways to my problem. One of my passions to map in osm is gas stations.
> I've done hundreds since I've joined and now have fully come to realize a
> persistent problem that occurs frequently. The duplicate address tagging of
> a gas station and convenience store run by the same company. For example,
> say i just added a circle k gas station down the street from me to osm. But
> the gas station also has a convenience store. Well i have to copy over all
> the address info from one poi to the other since leaving the address Field
> blank makes no sense if someone would like to get there using a navigation
> app. I have thought about it a lot. And i go back and forth thinking both
> places should be tagged. Still a part of me thinks it makes no sense to have
> a address for a gas station tagged twice. One reason we cant completely
> combine the gas station and convenience store tag is some gas stations have
> the convenience store run by separate companies. As is the case with a
> circle k down the street from me. The convenience store is a circle k but
> the gas station is a shell. It would be nice to have a separate tag that
> combined the gas and convenience store shop together. I just want to make
> clear i don't want to get rid of the existing tags i just want to add one.
>
> Regards,
>
> Hans
>
>
> ___
> 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] Mapping of kids areas

[Dan S]

Hi,

The obvious question is: why not using leisure=playground? Since the
definition in the first link you give says "an area where kids can
play".

Dan

2014-12-15 10:51 GMT+00:00 Dmitry Kiselev :
> Hi
>
> We have
> http://wiki.openstreetmap.org/wiki/Amenity_features#kids_area.3Dno.2Findoor.2Foutdoor.2Fboth
> for kids areas mappings.
>
> But sometimes kids area is an independant amenity. I think it would be nice
> to have amenity to map such features.
>
> So here is mine proposal for that
> http://wiki.openstreetmap.org/wiki/Kids_area
>
> Looking forward for any comments and suggestions.
>
> --
> dkiselev
> Dmitry Kiselev
>
> ___
> 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] pre-RFC: relation type=cluster/group

[Dan S]

Hi -

Does relation=site help? It sounds to me like a very similar concept:
http://wiki.openstreetmap.org/wiki/Site

Best
Dan

2015-01-06 10:36 GMT+00:00 Friedrich Volkmann :
> I was going to write a proposal for relation type=cluster
> (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster). Looking for
> real-world examples, I noticed that there's a relation type=group for the
> Great Lakes (id=1124369).
>
> What do you like better? type=group or type=cluster?
>
> --
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> ___
> 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] pre-RFC: relation type=cluster/group

[Dan S]

Oh, sorry, I see you mention it in the proposal. Still I don't see
what would be bad about using "site" for the examples in your
proposal, but I'll leave that there since you presumably feel
differently.

Dan

2015-01-06 10:18 GMT+00:00 Dan S :
> Hi -
>
> Does relation=site help? It sounds to me like a very similar concept:
> http://wiki.openstreetmap.org/wiki/Site
>
> Best
> Dan
>
> 2015-01-06 10:36 GMT+00:00 Friedrich Volkmann :
>> I was going to write a proposal for relation type=cluster
>> (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster). Looking for
>> real-world examples, I noticed that there's a relation type=group for the
>> Great Lakes (id=1124369).
>>
>> What do you like better? type=group or type=cluster?
>>
>> --
>> Friedrich K. Volkmann   http://www.volki.at/
>> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>>
>> ___
>> 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] [OSM-talk] Changeset messaging & Notes feature question

[Dan S]

This appears to be nothing to do with "tagging" - you've presumably
sent to this list by mistake...

2015-01-09 12:12 GMT+00:00 Dave F. :
> On 01/01/2015 00:39, Tom Hughes wrote:
>>
>> On 01/01/15 00:36, Dave F. wrote:
>>
>>> I'm struggling to comprehend how a button to turn off the notes layer,
>>> that's separate (& hidden!) from the only obvious button to turn the
>>> layer on can be described as 'logical' to an experienced user let alone
>>> a newbie..
>>
>>
>> Well the problem is that what you see as a "button to turn on the notes
>> layer" is what I see as a "button to add a new note" ;-) That button was
>> intended to encode the "add a note" action, not the "view notes" action.
>
>
> OK, but however you perceive it, it still activates the 'view notes'.
> Although it adds clarity to do so, it's not essential to the 'add a note'
> function.
>
>> If I just wanted to view existing notes I wouldn't use that button, I
>> would open the layer switcher and turn on the notes layer.
>
>
> On a scale of 1 to 10, how obvious do you think that is to the user?
>
>>
>>
 The problem with turning off the notes layer again when the add note
 control is disabled is that it might already have been on before you
 started adding a note, so we would probably have to remember if we had
 turned it on or if it was already on .
>>>
>>>
 Trying to figure out what to do if somebody starts toggling the notes
 layers on and off manually while the add note control is active just
 introduces even more levels of complication...
>>>
>>>
>>> By 'we' do you mean the programmers? I hope not. It's not that
>>> complicated! on/off, yes/no, 0/1 binary! It's the DNA of computers!
>>
>>
>> No I'm not saying the programming is necessary complicated, I'm saying
>> it's hard to know what the correct behaviour is from a UX point of view.
>
>
> I don't really see it as that confusing:
>
> I don't think the 'add note' button needs to turn on the 'view notes', but
> lets assume it does:
>
> * The 'add note' button turns both the add & view layers on & should them
> off again, except if 'view' was previously turned on via hidden option under
> Layers. Then it should leave 'view' on.
>
> * If 'view' is turned off via the Layers menu while 'add' is visible, turn
> 'view' off as it not directly linked or strictly needed to add a note.
>
> Cheers
> Dave F.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
>
> ___
> 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 - addrN:*

[Dan S]

2015-01-15 11:53 GMT+00:00 Martin Koppenhoefer :
>
> 2015-01-15 12:43 GMT+01:00 Janko Mihelić :
>>
>> With addrN:*=* it's clear that the same place has two addresses. If there
>> are two nodes, it seems like there are two places (Two entrances, two
>> apartments, two rooms), each with it's own address. AddrN* is clearly
>> superior in this aspect.
>
> you could use polygons (e.g. 2 distinct multipolygons, one for each
> address), and add a note to inform your fellow mapping colleagues that the
> overlap is intended (note is not needed but nice).

I was thinking about this solution too. The addrN scheme is really
quite awkward so it'd be nice to recommend something like simply
having two nodes/multipolygons with exactly the same overlapping
geometry. However, this gets horrible too: if both of the addresses
refer to a pub, should both objects be amenity=pub? (No!) Should they
be grouped under a relation which holds amenity=pub other properties?
Maybe, but that's getting just as awkward as addrN... It looks like
there's a problem to be solved, and none of the solutions is pleasant.
Hence I abstain ;)

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Dan S]

2015-01-15 23:48 GMT+00:00 Friedrich Volkmann :
> On 15.01.2015 13:10, Dan S wrote:
>> The addrN scheme is really quite awkward
>
> Can you explain why you find it awkward?
>
> It seems to me that the displeasure felt with the addrN scheme is caused by
> a phenomenon called transference. Multiple addresses in the real world are
> awkward, but they do exist and we cannot change that annoying fact.
> Therefore, the negative feeling transfers to the tagging scheme that
> represents the awkward reality. The awkward reality cannot be defeatet, but
> its representation can.

I would give a different reason: I find it awkward because OSM's data
model, with a flat list of key=value tags, doesn't fit well to this
particular reality. A lovely data model would be hierarchical, where
our object could have an "addr" key containing two values, and those
two values would themselves each be a dictionary of "housenumber=Y
street=X ..." etc. That's why I find it awkward - but as I said, in my
opinion there isn't a non-awkward way to solve this!

Dan

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

Re: [Tagging] Ethnic shops

[Dan S]

That's not a flaw - you've already given the solution in your own email:

> Basically you want to label restaurants/shops only if they offer something
> different from what's the typical local fare.




2015-01-16 13:23 GMT+00:00 Volker Schmidt :
> This, and already the existing tagging for restaurant cuisine have a basic
> flaw. They only work in a few countries of the West.
> If you think about it, most likely al restaurants in China would have to
> have cuisine=chinese, or all grocery stores in Marocco would have to be
> labelled convenience=north_african or whatever.
> Basically you want to label restaurants/shops only if they offer something
> different from what's the typical local fare.
>
> I have no proposal, I am just observing.
>
>
>
> On 16 January 2015 at 13:45, Martin Koppenhoefer 
> wrote:
>>
>>
>> 2015-01-16 13:29 GMT+01:00 moltonel 3x Combo :
>>>
>>> I've recently tagged a shop=convenience, convenience=polish. You'll
>>> find a handfull of other examples of convenience=* clothes=*
>>> hairdresser=* on taginfo.
>>
>>
>>
>> I suggest to use a more specific key that already tells in its name what
>> it is about, and that allows for tagging several orthogonal properties. The
>> current values for convenience (in total only used 11 times) are:
>> http://taginfo.openstreetmap.org/keys/convenience#values
>>
>> yes
>> russian
>> mall
>> pet
>> polish
>> variety_store
>> african
>> wine;honey;rice;pastery;book
>>
>> so basically there is no system, and the values make it hard if not
>> impossible to understand what is actually tagged.
>>
>> I have found these in taginfo:
>>
>> ethnicity (total use 65)
>> http://taginfo.openstreetmap.org/keys/ethnicity
>>
>> origin (used more often, but has the same problem then "convenience", it
>> is mixed up with different concepts)
>> http://taginfo.openstreetmap.org/keys/origin#values
>>
>> cheers,
>> Martin
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Tagging road illumination quality

[Dan S]

Hi -

Yes, it's useful to go beyond lit=yes and lit=no. Some of those
suggestions such as "poor" and "sufficient" are too subjective, as I
think you already acknowledge. Not only are they value judgments but
they depend on the user's perspective and needs, so please do try to
avoid them.

Some of the existing values, rarely used, are "indirect", "partial",
"sparsely", "limited". It would be nice if we could grow some
consensus on useful values to use. In my experience sparse lighting is
common (and very different from full street lighting). One
possibility: something like lit=0.5 for a highway which is lit
sparsely (or light is obstructed) so that it is effectlvely lit along
50% of its length...?!

Best
Dan


2015-01-16 20:27 GMT+00:00 Volker Schmidt :
> The light sources' positions often have little to do with the real
> illumination effect.
> In many cases, in my city, cycle paths (in reality they all are mixed-use
> pedestrian and bicycle with priority by law to pedestrians) have been
> produced by converting former sidewalks. The lamp posts are those installed
> for street illumination and often are interspersed with street-side trees.
> Hence the effective illumination on the foot-cycle path is patchy. The only
> way to judge it is to cycle by night and see.
> The reason why this comes up now is that we want to map the cycling
> infrastructure as it really is, with the aim of producing the data for a
> critical map of the cyclability of Padova. All other parameters are already
> taggable, the illumination quality not yet.
>
>
> On 16 January 2015 at 20:14, Frederik Ramm  wrote:
>>
>> Hi,
>>
>> On 01/16/2015 06:18 PM, Volker Schmidt wrote:
>> > This is unfortunately a thorny issue, as there is no easy way to measure
>> > in an objective way the quality of the illumination.
>>
>> Indeed. I would suggest mapping the individual light sources instead.
>>
>> 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
>
>
>
> ___
> 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 - addrN:*

[Dan S]

2015-01-18 20:52 GMT+00:00 Markus Lindholm :
> On 17 January 2015 at 22:16, Friedrich Volkmann  wrote:
>> With the addrN schema, we need one object (a node tagged shop=* and
>> addrN:*=*) for a shop.
>> With the provides_feature relation we need one node for the shop, one node
>> for each address, and one relation.
>
> And if there are two shops that both have the same address? Then your
> scheme breaks down as you would end up with a database with two
> distinct nodes but same address. Clearly a bad thing and against the
> principle of 'One feature - one element'
> http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

This criticism is mistaken. (The wiki page even gives a counterexample
of "More than one of something on the same site" which is rather
similar to "two shops with the same address".) We have lots of
examples in OSM of two distinct objects with the same address - it's
quite common in real life, and if it is a problem then it's nothing to
do with "addrN", it would be a problem with a large portion of our
"addr" data!

Best
Dan

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Dan S]

Now you're insulting the one person who was supporting you? Please
STOP this thread everyone. Please.

2015-01-21 8:55 GMT+00:00 Никита :
>> Just because one can use a regular expression to grep out a certain
>> meaning doesn't mean it's a good thing to do and will always work
> We easily revert these edits in Russia. Quite often user who want to show
> their regex fu will fail so hard to guess actual properly of the real world.
>
> We care about data we map.
> We document it instead of guessing by taginfo.
> We use real tags instead of regexes for users.
>
> We like our newbies. We don't want to insist to use f$#$g perl regexes
> simply to map things around them.
>
> I cannot stop you from using regex. But if I find your changsets erroneous I
> will revert them.
>
>> In fact, nobody forces us to only use yes and no as a value.
> Wrong. It not forces you anything. You can still tag currency:X=fixme.
>
>> The Healthcare 2.0 proposal uses partial, main, yes and no. This can
>> easily applied to a lot of values where it makes sense and it gives the
>> flexibility to distinguish between equal and distinguished importance .
> There way more tagging schemes than single Healthcare 2.0. Yes there
> differences, so what?
>
>> Using semicolon-lists for values was always considered a crutch until a
>> better tagging-scheme comes along.
> You forgot to say "among English speaking users who fail to use JOSM search
> funtion or overpass or taginfo or wiki documentation". I don't care about
> them.
>
>> We all know that the only real solution would be a native data type for
>> arrays in the database but as long as this isn't happening, we have to work
>> around.
> And obviously you choose the worst way to do this. With complicating things
> with REGEX.
>
>
> 2015-01-21 11:42 GMT+03:00 Nadjita :
>>
>> On 21.01.2015 09:06, Никита wrote:
>>
>> > If you trying to parse name=school *with any regex *to map it as
>> > amenity=school* *you are wrong. OSM is not for you.
>> > If you trying to parse currency=bitcoin;coin for coin, then stop it
>> > right now. You have no idea how regexes or tags in osm work.
>>
>> While I think, you should really calm down a bit and not sound so
>> aggressive, I have to agree with you. The purpose of structuring data is
>> not having to use a complicated, but a simple parser. Just because one
>> can use a regular expression to grep out a certain meaning doesn't mean
>> it's a good thing to do and will always work.
>> The only downside of currency:X=yes, currency:Y=yes to currency=X;Y is
>> that it involves more typing. In fact, nobody forces us to only use yes
>> and no as a value. The Healthcare 2.0 proposal uses partial, main, yes
>> and no. This can easily applied to a lot of values where it makes sense
>> and it gives the flexibility to distinguish between equal and
>> distinguished importance .
>> Using semicolon-lists for values was always considered a crutch until a
>> better tagging-scheme comes along.
>> We all know that the only real solution would be a native data type for
>> arrays in the database but as long as this isn't happening, we have to
>> work around.
>> But please let's not drag this down to a personal level and start
>> insulting each other, this isn't going to accomplish anything but anger.
>>
>> - Nadjita
>>
>> ___
>> 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] Deprecation of associatedStreet-relations

[Dan S]

2015-01-22 6:53 GMT+00:00 Marc Gemis :
> It seems like the German community started some voting process on the
> deprecation of the associatedStreet-relation (it was on the mailing list and
> on the forum).
>
> Discussion is going on on the wiki
> https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet

Hi all - does anyone know what the geographic distribution of
associatedStreet is like? taginfo doesn't render a map (it seems it
doesn't do that for relations). I hear rumours it's mainly Germany but
it'd be handy to know.

Best
Dan

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

Re: [Tagging] Ethnic shops

[Dan S]

2015-01-28 18:52 GMT+00:00 Eric SIBERT :
> I started modifying the wiki following our recent discussion.
>
> For cuisine=*, I added:
> "May also apply to other services that deliver food, like convenience."
>
> For shop=convenience, I added (in Tags used in combination):
> "Stores selling specific type of food or with ethnic origin may use
> {{tag|cuisine}} to indicate it."
>
>
> And latter go on with culture=* for nonfood services?

Hi - my 2p: yes sounds fine. I agree with others who said that
culture=* seems a decent choice (since more flexible and less awkward
than ethnicity=*)

Best
Dan

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

Re: [Tagging] Feature Proposal - RFC - Reception Desk

[Dan S]

Hi,

No big objections from me, sounds useful.

However it occurs to me that it would be useful to have some way of
indicating _what_ it is the reception for. For example, if it was part
of a "site" relation*, then a role like role=reception would connect
it to the larger entity in a meaningful way. That might be a suggested
tagging option...

Best
Dan


* http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site



2015-02-06 2:03 GMT+00:00 Warin <61sundow...@gmail.com>:
> Hi,
>
> Request for comment on new tag 'amenity=reception_desk'
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dreception_desk
>
> This comes out of the tag ON HT E tourism=camp_site WIKI PAGE which has a
> sub key of camp_site=reception.
>
> As 'Receptions' are numerous outside of camp sites I think it is best to
> have them available for use under other things - like hotels. So the new
> tag.
>
> 'reception_desk' .. should separate it from other types of receivers .. like
> radio receivers.
>
> Amenity is the best fit so amenity=reception_desk.
>
> what do you think?
>
>
>
>
>
> ___
> 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] building=yes on nodes?

[Dan S]

All building=* on nodes is fine. As others have pointed out, it is
often necessary in HOT aerial mapping when we have low-resolution
imagery to work from.

Also, for humanitarian purposes there are serious uses for node-only
buildings, for estimating the population or the population
distribution in a place.

I've edited the wiki to set onNode=yes. I hope that doesn't lead to a storm

Best
Dan

2015-02-16 18:10 GMT+00:00 Lukas Sommer :
> I would like to return to the original question:
>
> 1.) I think it is confusing to have building=cowshed allowed on nodes,
> but building=cabin not allowed. We should unify this. Either _all_
> building=* keys can be used on nodes, or _none_.
>
> 2.) If we agree on 1.), would we opt to allow nodes or to disallow
> nodes? After reading the previous comments, I would tend to allow it.
>
> Best regards
>
> Lukas
>
> 2015-02-16 12:12 GMT, fly :
>> Am 14.02.2015 um 23:06 schrieb Tobias Knerr:
>>> On 14.02.2015 22:11, SomeoneElse wrote:
 ... it also says that it shouldn't be used on relations, which would
 exclude perfectly valid multipolygons, such as this one:
>>>
>>> Multipolygons are a means to map areas. So they are covered by the area
>>> icon.
>>>
>>> The relation icon stands for relations that are not areas,
>>> just as the way icon stands for ways that are not areas.
>>
>> How about type=building ?
>>
 It appears that again people are trying to use the wiki to "tell other
 people how to map" rather than "describe how things tend to be mapped".
>>>
>>> Nobody is telling anyone not to use multipolygons.
>>
>> This is totally misleading as the type of the object is still a
>> relation. Once we introduce an area object we might cover closed ways
>> and multipolygones as one category. For now we depend on the object type
>> or e.g. editor software already need to implement the area type to offer
>> proper presets.
>>
>> cu fly
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Lukas Sommer
>
> ___
> 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] ?=maze

[Dan S]

Yes Mateusz, +1 from me, sounds good -
Dan

2015-02-19 8:00 GMT+00:00 Mateusz Konieczny :
> I think that attraction=maze is better than attraction:type (shorter,
> without colon, "type" is not
> really adding anything useful, clear detailing of tourism=attraction).
>
> 2015-02-19 3:59 GMT+01:00 Bryce Nesbitt :
>>
>> If it's of interest to outsiders it seems like an attraction.  Thus how
>> about:
>>
>>
>> tourism=attraction
>> attraction:type=maze
>> name=Happy Tunnel Kiddie Maze
>> website=http://maze.example.org/
>>
>>
>> You want all those similar features (maze/tube hill/ride/garden/water
>> park/whatever) to show up on a tourism/visitor type map.
>> This is also a clear case where the existing maze tags could be mass
>> retagged to the new scheme.
>>
>> ---
>> You just want to be clear if a given feature is PART of a larger
>> "attraction" (e.g.
>> one ride in a water park), or if it's the high level feature (e.g. the
>> water park itself).
>> See also http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dtheme_park
>> and the associated 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
>

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