[Tagging] IndoorOSM 2.0

[Simon Poole]

This is really just a heads up on the ongoing discussion in the indoor
forum http://forum.openstreetmap.org/viewforum.php?id=67 and the
competing proposals https://wiki.openstreetmap.org/wiki/IndoorOSM_2.0
and https://wiki.openstreetmap.org/wiki/F3DB .

I have to admit even though the IndoorOSM 2.0 was mainly intended as a
straw man to re-start the discussion, I kind of like the now
minimalistic approach it has, its biggest weakness is however that there
are currently no applications that actually consume the data in the
format (which is mainly due to lack of time on my behalf).

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] interpolated housenumbers on single objects

[Simon Poole]

Am 20.08.2014 12:11, schrieb Ilpo Järvinen:
... lots of stuff from past experiences ...

There is no reason not to immediately enter the address data, preferably
as entrance nodes if the building outlines exist, if they don't, placing
an address node at an appropriate place is far easier if you are
actually standing/walking past the building in question.

All the address surveying I've done in the last couple of months has
time wise been dominated by the time it takes to walk from building to
building.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] interpolated housenumbers on single objects

[Simon Poole]

IMHO mapping house numbers while on a bicycle is one of those things
that simply doesn't really work, contrary to other things that work well
(road signs etc). Not that it couldn't be done, but the technical effort
required to do so is significant (aka in the direction of googles
streetview tricycle) and you still end up with having to post process,
which again takes more time than doing it properly (at 1st glance
slower) in the fist place.

Simon


Am 20.08.2014 13:52, schrieb Ilpo Järvinen:
 On Wed, 20 Aug 2014, Simon Poole wrote:
 Am 20.08.2014 12:11, schrieb Ilpo Järvinen:
 ... lots of stuff from past experiences ...

 There is no reason not to immediately enter the address data, preferably
 as entrance nodes if the building outlines exist, if they don't, placing
 an address node at an appropriate place is far easier if you are
 actually standing/walking past the building in question.

 All the address surveying I've done in the last couple of months has
 time wise been dominated by the time it takes to walk from building to
 building.
 
 Nice, but how would you do positioning of such nodes while cycling past 
 the buildings? :-)
 
 I could make only trivial notes (to a draft SMS to be exact but that 
 won't work with too fancy phones with touch keyboards though ;-)) that 
 heavily depended near-term memory because the time available to mark 
 individual address (or entrance) is very limited. Also, almost no time is 
 wasted while moving from address to another. I was rather happy to
 have occassionally a short break in sequence to catch up/relax (or could 
 use even higher speed, i.e., collect more addresses per time unit).
 
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Simon Poole]

Am 25.08.2014 16:46, schrieb fly:
.
 
 Did you have a look at the three existing proposals about complex
 junctions ?
..

IMHO one of the nice aspects of variant 4 (using an area) is that it
really doesn't collide with however the routing aspects of the junction
are mapped.

@Lukas are the names of the traffic signals/junctions actually used in
addresses (and in principal would be a suitable value for addr:place in
an address)?

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] default value for oneway

[Simon Poole]

I believe that you haven't explicitly said so, but probably essentially
want to be able to find streets that haven't been surveyed and
potentially need a oneway tag and avoid false positives (aka such that
are actually bi-directional).

I don't believe you'll get any further with the oneway tag, but given
that we have similar issues for example with name tags, you could
consider something like proposed in
http://wiki.openstreetmap.org/wiki/Proposed_features/Internal_quality ,
in your case

validate:no_oneway


Simon

PS: the noname tag is actually substantially more popular than
validate:no_name but if you are inventing something new, you might as
well stick to the validate: scheme.


Am 28.08.2014 16:32, schrieb Xavier Noria:
 For the sake of discussion, I believe the interface for setting this
 attribute could be different (I am a software developer).
 
 For example, in graphical interfaces like iD you could have no
 preselected as convenience. But if you send no, you are saying no.
 Otherwise, you could opt-out and leave the value as blank, that
 would mean unknown/unset.
 
 In APIs, the attribute would have no default. If you say no, it is
 no, if you send nothing, it is unset.
 
 That way you could distinguish nos from unsets. Right now you
 cannot because conventions promote saying nothing.
 
 I realize changing any of this may be impossible nowadays, and maybe
 you disagree with that proposal. But if there was a chance to revise
 this I know Ruby on Rails and could work on it.
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] default value for oneway

[Simon Poole]

Am 28.08.2014 17:07, schrieb Xavier Noria:
...
 
 That makes me also wonder as a side-effect about the implication of
 the current contract and the usage patterns it promotes. Implications
 in particular for turn-by-turn indications, but that was secondary, my
 main motivation is the one above.

In any case there are roughly 45 million highway segments on which a
oneway tag could make sense, vs. roughly 6 million oneway=yes and 1.5
million oneway=no. I suspect that it is really -far- too late to change
the semantics of this specific attribute.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] default value for oneway

[Simon Poole]

Am 28.08.2014 19:10, schrieb Xavier Noria:
...
 But for example, every single client software of OSM that is out of
 control of OSM is assuming that contract. That's what I believe makes
 a reset (no NULLs in the database) plus semantic change for NULLs
 would not be possible. No way to synchronize all that client code
 unless that was somehow coordinated as in a major upgrade.
While just a technicality it probably is worth pointing out that in
reality the change you propose would require adding 40 million or so
oneway=no tags to the DB and making a new version of each of the
effected objects. We have worse things in the DB, but still it would
need more than just  uneasiness with the current situation (which is for
largish parts of the world not an issue) to justify the change

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] include smoothness=* in JOSM presets?

[Simon Poole]

As somebody who participates in at least two outdoor activities in which
road conditions are an important comfort factor* (inline skating and
riding a road bike) it would be great to have a reasonably reliable
indication of what to expect on a certain road segment additionally to
the pure mechanical restrictions that can be indicated by the surface tag.

However the smoothness tag does not fulfil the role, its current
definition makes it not only subjective, it is explicitly dependent on
the skill level of the person surveying.

At best the extreme values are meaningful and I would suggest that the
value space at least be reduced (something along the lines of good, bad,
impassable) in any preset.

Simon

* comfort is not the same as usable

Am 31.08.2014 04:11, schrieb Dave Swarthout:
 I also agree with Mateusz. I would like to see use of the smoothness tag
 become more universal so building it into a JOSM preset sounds like a
 good idea.
 
 However, as others have said, the topic has had much discussion but
 little agreement on exactly how to determine the value. A highway that
 has excellent smoothness for automobiles may be not so smooth for a
 bicyclist. It is a subjective tag and there's no getting around that
 fact therefore you can expect some criticism for this addition.
 
 Cheers,
 Dave
 
 
 On Sun, Aug 31, 2014 at 7:31 AM, Martin Koppenhoefer
 dieterdre...@gmail.com mailto:dieterdre...@gmail.com wrote:
 
 
 
  Il giorno 30/ago/2014, alle ore 14:46, Andy Mabbett
 a...@pigsonthewing.org.uk mailto:a...@pigsonthewing.org.uk ha
 scritto:
 
  I doubt three mappers would
  always agree on which to use for a given place.
 
 
 I think complete agreement is not necessary, it would be sufficient
 if it were +-1, similar to road classification with the highway key
 ___
 Tagging mailing list
 Tagging@openstreetmap.org mailto: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
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] include smoothness=* in JOSM presets?

[Simon Poole]

I don't think anybody was complaining about the words used for values
per se, they will still be good for a chuckle in 20 years from now.

However the wiki definition of how the values should be determined is
simply FUBAR, and in no way defines each value pretty good. There is
no point in repeating the discussion from the mailing lists and on the
discussion page yet another time, I would just suggest re-reading them.

Simon

Am 31.08.2014 11:50, schrieb Janko Mihelić:
 The tag smoothness is vague and subjective only if we define it as such.
 Values excellent and bad can be treated as placeholders, and we can
 define them on the wiki as anything we like and then expect mappers to
 use them according to that definition, and not solely by that one string.
 
 If you ask me, the table at this url:
 
 http://wiki.osm.org/wiki/Key:smoothness#Smoothness
 
 defines each value pretty good. Let's put those definitions in Josm, iD
 already has them, and we can finally start treating smoothness as a
 somewhat precise and well defined tag.
 
 Janko
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] include smoothness=* in JOSM presets?

[Simon Poole]

A last try at illustrating the insanity of the smoothness definitions.

Switzerland has an extensive network of signposted inline skating
routes, including the world longest single route at something around
400km (see http://skating.waymarkedtrails.org/en/ ). For readers that
have never used inline skates, conventional (small wheel) inline skates
are likely the means of transport which is most difficult to use on bad
road surfaces so smoothness could be an important criteria if a route
is usable or not.

Given that every part of say route 3 (the 400km one), which BTW only
requires a medium level of skating competence, has been many many times
used by 100s of skaters, according to the wiki definition of smoothness
every segment of the route should be tagged with smoothness=excellent.

In reality the range of surfaces on the route range from very bumpy with
some gravel to OK. If you want to use the illustrations on the wiki as a
guide: from excellent to intermediate. In the end as a consequence the
wiki definition classifies essentially all paved roads as
smoothness=excellent

Now as said: inline skates are likely the method of transport that is
most sensitive to road surfaces and as such wont collapse the smoothness
scale as much as methods of transport that are not quite so sensitive.

So lets have a look at a racing bike with skinny tires, lets say 20mm.
Even with my mediocre bike handling skills riding on anything from
excellent to horrible (again using the illustrations as a guideline) is
not a problem, that doesn't imply that you actually have to like it*.

So that collapses the smoothness scale to: excellent (all paved roads),
good (paved and unpaved roads bits that are actually not usable by
inline skates), very_horrible and impassable.

Really really not useful.

Simon

* it is just one of the things that happens if you decide to follow an
unmapped road in OSM.

Am 31.08.2014 11:50, schrieb Janko Mihelić:
 The tag smoothness is vague and subjective only if we define it as such.
 Values excellent and bad can be treated as placeholders, and we can
 define them on the wiki as anything we like and then expect mappers to
 use them according to that definition, and not solely by that one string.
 
 If you ask me, the table at this url:
 
 http://wiki.osm.org/wiki/Key:smoothness#Smoothness
 
 defines each value pretty good. Let's put those definitions in Josm, iD
 already has them, and we can finally start treating smoothness as a
 somewhat precise and well defined tag.
 
 Janko
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sport= non-physical tags and the exceptions people come up with...

[Simon Poole]

Am 20.10.2014 20:37, schrieb Janko Mihelić:

 
 What people probably want to tag are waters that are interesting to
 scuba divers. Maybe we should make a tag like
 leisure=scuba_diving_attraction.
.

I beg to differ, there is a fairly wide range of restrictions at least
on inland bodies of water in the world, including dedicated (allowed)
entry points and so on. I suspect depending on the protection status the
same goes for salt water too.

The question is really if we should only map such entry points etc that
are marked or if we go further than that.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] oneway=no spams

[Simon Poole]

Am 28.12.2014 um 19:20 schrieb Andy Street:.
 These tags are far from information-less as they convey the fact that
 a mapper has considered the property in question and wishes to record
 that it does not apply. 
I'm afraid that you are kidding yourself in a big way.

Nearly all massive, I will tag everything that applies tagging
extravaganzas are due to misuse of the JOSM access preset, and have
nothing at all to do with the mappers in question having the slightest
idea of what they are actually doing (not to mention that the net
results tend to actually be wrong).



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Simon Poole]

Am 28.03.2015 um 16:10 schrieb Hubert:
 That's not what I wanted to say. A cycleway is mandatory if has one of the 
 signs 237, 240 or 241 AND it is parallel to a road. A sign by itself doesn't 
 make a cycleway mandatory.
 

You have something confused there. Germany has two (forgetting about
lanes for now) kinds of cycleways:

- such without mandatory use provision (used to be andere
Radverkehrsanlagen), there does not seem to be any formal signage for
these and it could be argued that they don't really exist.

- such with a mandatory use provision indicated with one of the already
mentioned three signs.

Mandatory in this context means you have to use the cycleway instead of
a nearby normal road surface/area.

For the later there is a list of reasons why you can be exempt from the
mandatory use provision, for example that there is no other alternative
surface you can cycle on (the example you cited), your vehicle doesn't
fit on the cycleway, the cycleway doesn't actually go to where you want
to go and so on. In other countries this is called common sense.

Now even though I yet have to see an instance of the first kind of
cycleway that can't be modelled with normal access tags, if they are
even necessary in the first place, the community has accepted that in
Germany bicycle=official instead of designated is used for the 2nd kind
of cycleway so that they could theoretically be differentiated.

Further if you want to model the situation even better (nearby road
surfaces are already nearby in OSM data) you can now add
bicycle=use_sidepath to the alternative surface that you are not allowed
to ride on (even though I personally consider that a waste of perfectly
good bits).

There is simply no point in both a practical and theoretical sense for
splitting the official value in to official and in to
I_think_this_might_be_mandatory given that the later is purely
circumstantial.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Simon Poole]

Am 28.03.2015 um 15:31 schrieb Hubert:
 For example a lot of cross country cycleways (like this one 
 https://commons.wikimedia.org/wiki/File:Altmarkrundkurs.jpg )
 can't possibly be mandatory, since there is no road next to it. But they are 
 designated and official. 

There is no such thing as non mandatory cycleways in Switzerland,
however there is no expectation that I use every possible cycleway in
the country every time I get on a bicycle.

Naturally the concept of mandatory only makes sense when there is an
alternative road surface nearby that could be used instead. I see no
point in subjecting the whole world to yet another bicycle tag just
because the German legislative decided that it can't count on its
populace turning its brain on.

Essentially what they are saying: these ways are not mandatory because,
since there is no alternative, you have no choice than to use them.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Simon Poole]

Am 28.03.2015 um 14:23 schrieb Hubert:
 I believe this is the issue here.
 For me bicycle=designated and bicycle=official don't say that a cycleway is 
 mandatory. It only says that this way is meant for cyclist 
 or is built for cyclist only. And while bicycle=official is mostly used for 
 mandatory cycleways there are also cases where it is used 
 for all way with a blue traffic sign or even all cycleways which are 
 official.


Please give an example of a cycleway in Germany (given that this is a
specific German argument) with a blue sign (237, 240 or 241) that is not
mandatory use (and no I don't mean that you could go to court, and, if
you win, get the sign removed based on arguments that the way should not
be signposted as such).

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Simon Poole]

I have to say that this adds yet another value to the bicycle tag that
doesn't solve any problems (note: if at all it naturally should be
mandatory however that is not my primary concern).

We have bicycle=designated and bicycle=official for mandatory use
cycleways (where the concept of such exists). official already tries
to capture a nuance in a specific countries law that is lost on most
(and probably doesn't exist in reality) trying to differentiate further
doesn't make any sense (and we already have use_sidepath thrown in to
the mix).

Simon






signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki edits on junction=roundabout

[Simon Poole]

The background is an osm2pgsql issue, the wiki edit itself is IMHO
mistaken see: https://github.com/openstreetmap/osm2pgsql/issues/304

Am 23.02.2015 um 08:43 schrieb Martin Vonwald:
 Hi!
 
 Can someone please explain these edits to me:
 https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ajunction%3Droundaboutdiff=1142769oldid=1107975
 
 A little overkill - isn't it? And since when is area=no needed?
 
 Best regards,
 Martin
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Wiki Talk] Why OSM and not another collaborative mapping service?

[Simon Poole]

I'm really not sure what this discussion is doing on tagging and have
redirected follow ups to talk (it has in the matter of a few mails
already gone substantially off-topic though).

The page in question is actually a fork of
http://wiki.openstreetmap.org/wiki/Google_Map_Maker which was written as
a response to the introduction of MM.

I personally consider it dangerous to base such a comparison on anything
but general principles. On the one hand you are always in danger of
being out of date and at least in a legal grey zone if not already out
side of it, on the other hand it tends to degenerate in to
political/point of view material, are all commercial companies actually
evil as Xxzme version seems to imply?

Simon


Am 07.05.2015 um 03:59 schrieb jgpacker:
 I call people to review the wiki page Why OSM and not another collaborative
 mapping service?.
 link: 
 http://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service%3F
 
 It was written by a single user as a generic page to compare other
 collaborative mapping services to OSM.
 My issue with this page is that it's not generic at all.
 
 Am I the only one that thinks this?
 
 I didn't want to bother with this until it started being recommended
 elsewhere in the wiki as official.
 
 Cheers,
 John
 
 
 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Wiki-Talk-Why-OSM-and-not-another-collaborative-mapping-service-tp5843604.html
 Sent from the Tagging mailing list archive at Nabble.com.
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Long Tail ( was Removal of amenity from OSM tagging)

[Simon Poole]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 19. Mai 2015 03:18:14 MESZ, johnw jo...@mac.com wrote:


there’s no preset “I want to add a business” or “I want to add a park”
tutorials that walk through the basics and hold your hand, bring up
options and ask you natural language questions to help you learn how to
tag things. a person who just wants to add a node tag can have very
little asked of them, and the node placed in the correct spot. another
mapper can flesh it out later.

I've many times suggested that if we really want to exploit the long tail we 
need wizards not simple editors (I'm not sure that the later actually 
exists). We shoudn't kid ourselves though, we are unlikely to squezze a higher 
conversion rate  to reasonably active mappers out of  our audience that way, 
just a longer long tail. Any way we do it we are asking for people to spend 
more/a significant amount of time contributing and that will only happen if 
somebody is actually interested in the subject matter.
- --
Written with a pen
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQE6BAEBCgAkBQJVWvPCHRxTaW1vbiBQb29sZSA8c2ltb25AcG9vbGUuY2g+AAoJ
EEchcRCS4oLq7oYIALra+wxJH1Ed8cuUWBhPu5zwyej5+YkkOGMj6smxaaYbiSkU
GmiQ6xxJionB+LCKIHo82JYb8fnvFmDyZrycZQvpZdO9IKLl1iPSQKrOsgEQfpp1
iZUo1cnnyrEivmtISUWI0Vm3c5X1vOViDgWi1YbxUgBB3h227Hg98VEXEGq62sU0
7mTFXlvsGOh3Z07xGI7vNh3azDwX1I39MOHaO/hbIbCtBlmtBvfwj/UgoczGkdg4
NDKL0RZEhufNlDXIreZmrOfWnkro/XRrJdTzxX7RR8nJpHqT4yfLC1g0o0s3H8He
+fdCk5rmXyY0l9lO31nCSk6nV6LxlMQG3ZyXhL4=
=whR9
-END PGP SIGNATURE-


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

Re: [Tagging] Long Tail ( was Removal of amenity from OSM tagging)

[Simon Poole]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

We don't have access to non - editing accounts, speculating on the composition 
of them is just that. We do know that not all of the roughly 1.5 million are 
spammers, See my two recent diary posts for more,

On 19. Mai 2015 04:55:30 MESZ, Bryce Nesbitt bry...@obviously.com wrote:
On Mon, May 18, 2015 at 5:28 PM, Clifford Snow
cliff...@snowandsnow.us
wrote:

  I invite each user to join our Meetup Group and invite them to
contact me
 if they have any questions. The response rate is low. A survey could
help
 us identify why they joined, how they want to use OSM and what
special
 interests they have any their desired way of contributing.


Based on my experience running other sites, a huge fraction of the new
users are bots.
Yes, bots that respond to email.




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

- --
Written with a pen
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQE6BAEBCgAkBQJVWu4gHRxTaW1vbiBQb29sZSA8c2ltb25AcG9vbGUuY2g+AAoJ
EEchcRCS4oLqdlgIALPQvdUPy7/1O1SwlyZnn7cq61ksi25XWlYlHnaKrTSCXiWX
ak8hYU8ejRDSwDlen6F1evxAGolla24ylrH0tIza3fOmN0ej7rhTtl1UTnyzzDox
91Ikdp4CHiH70USfPpNC+Xxj0lnqSGUU7q6qH1XH3TzYUTwW+QhUBcRkDgIkhcqL
1t0/Wg3QXwFh5D49JC3vPA7cnr9ySiXyCpz3RE1KTfP5584ZY9Mc6dE2AUVBFpHC
RhZySNWCCBtAedafU9mAskJOwy+nni/n4RZ8NntGntrGdAaSQyyZ852OKgkyTMFF
G7ASRYgWC99MJveRIuaN4sspa5YSgfH6qDQnbQk=
=/JZU
-END PGP SIGNATURE-


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

Re: [Tagging] Long Tail

[Simon Poole]

Am 19.05.2015 um 14:40 schrieb Daniel Koć:
 W dniu 19.05.2015 14:25, SomeoneElse napisał(a):
 
 Also, it's worth mentioning that despite people sometimes describing
 OSM as unfriendly the vast majority of changeset discussion
 comments, especially to new users, are very friendly and happy to
 help.
 
 That's why I want to have some hard data: we really don't know it (on
 the whole project level) what are the common problems or how many casual
 mappers gets the help. We just imagine a lot or know the things only on
 the local level.
 
 Let's simply ask them - short survey for iD users after 30-90 days in
 the project or 50-100 edits (whatever comes first) may give us nice
 metric to think what can we do better.
 

There has been at least one study which gave indications why people stop
contributing (main reason given was time). I don't think that we are
imagining things nor do can I see anything special about OSM in this
respect (a couple of examples have already been given, another one from
me: SCUBA diving, an incredible number of people have done it at least
once, still there is only a low number that actually make it a real
hobby, much to the frustration of the people in the business :-)).

As to how many mappers get a welcome, given that I on my own do roughly
1% of all new mappers (aka 1000/year) for SOSM, I suspect that in total
we are talking of a higher double digit percentage.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours specification

[Simon Poole]

BTW while it is still work in progress (now mainly because the android
UI isn't finished yet)  
https://github.com/simonpoole/OpeningHoursParser is a JavaCC based
parser which attempts to implement the full spec, undoubtedly I've
probably missed one or two special cases, but it is fairly complete.

It currently successfully parses 108'455 of 122'100 test strings (with
some relaxation of rules) of those that fail 10'569 seem to be valid
lexical errors and a large part of the remaining errors seem to have
other issues. The test strings were extracted from the OSM database
(nodes only).

As you say the specification itself is overly complicated (the
optional colon is not really a problem, except that it is not really
clear where it is allowed, there is some further similar fuzziness wrt
comments) and definitely shouldn't have more stuff added to it (with
perhaps the exceptions of adding further variable dates and similar things).

Simon

Am 21.08.2015 um 12:36 schrieb Ruben Maes:
 Friday 21 August 2015 11:48:49, panierav...@riseup.net:
 Hello,

 I recently released a new version of YoHours, a website which allows
 everyone to create and view opening hours in the OSM syntax. It now
 supports seasons-dependent hours (month, week, day, holiday selectors). 

 It's available here:
 http://github.pavie.info/yohours/ 

 The code is available on GitHub: 
 https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours
 [1] 

 If you have any suggestions, let me know :) 

 Cordially, 

 PanierAvide. 
  

 Links:
 --
 [1]
 https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours
 I opened an issue[1] on this GitHub project, because it puts a colon after 
 week, month and monthday selectors.
 PanierAvide replied that the specification allows an optional separator for 
 readability[2]. Indeed, when you read the overly complicated and totally not 
 mapper-focused specification, you can see
 [ year_selector ] [ month_or_monthday_selector ] [ week_selector ] [ 
 separator_for_readability ]

 Whose idea was this? It's already complicated enough that you don't have to 
 add *optional* separators for supposed readability.
 IMO it's just fine without them.

 PS: I always follow the time domains proposal[3]. It's clear and it's 
 compatible with the other specification AFAIK.

 [1] https://github.com/PanierAvide/panieravide.github.io/issues/1
 [2] 
 https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#separator_for_readability
 [3] https://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains



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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "What can I ask ..." list for browsing people

[Simon Poole]

You click on "Help" then on "Beginners Guide"

Am 01.11.2015 um 19:10 schrieb André Pirard:
> ...
>
> What can I show to Mr X?
>
This is extremely off topic btw.


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

People, sometimes creatively, put lots of stuff on signs that don't
necessarily correspond to the set of values that is actually supported
by law*. It frankly doesn't make sense to try and capture each fine
semantic difference (wit visitor vs. destination), particularly as  it
may simply be misguided to start with.

Your Anrainer vs. Anrainerverkehr example for AT doesn't seem to be any
different than the Anwohner/Anlieger difference in DE, which
semantically for routing purposes boils down to private/destination
(which I suspect most routers wouldn't actually differentiate in any case).

@Marc can you point to a reference that shows that "uitgezonderd
aangelanden" is anything else than creativity? Your relevant regulations
seem to only know about "plaatselijk verkeer"

Simon

* naturally there are often access restrictions issued by a court, but
they tend to have longer text inferencing the decision and detailing the
restriction.

Am 06.10.2015 um 09:16 schrieb Friedrich Volkmann:
> On 06.10.2015 07:15, Marc Gemis wrote:
>> And (Flemish) Dutch "aangelanden (verkeer)". 
>>
>> We also have the difference between 
>> "uitgezonderd plaatselijk verkeer" = "except destination"
>> "uitgezonderd aangelanden" = "except 'visitor'"
>>
>> and I even saw
>>
>> "uitgezonderd bewoners" = "except inhabitants" 
>>
>> once on a street.
> I'm glad to see that the tag I'm going to propose will be useful for at
> least one other country.
>
> You can then use:
> uitgezonderd plaatselijk verkeer ... vehicle=destination
> uitgezonderd aangelanden ... vehicle=
> uitgezonderd bewoners ... vehicle=private
>
>> Wonder whether a moving or delivery company would be
>> allowed in the latter case. Or whether someone would try to enforce it in
>> such case.
> I don't know Belgian law, but it might be similar to the situation in
> Austria where "ausgenommen Anrainer" only means residents, no
> moving/delivering companies. That caused lots of problems, because residents
> wanted things delivered to their homes. That's why "ausgenommen
> Anrainerverkehr" was invented, and many "...Anrainer" signs have been
> replaced by "...Anrainerverkehr" signs over the decades. This process will
> surely continue.
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 06.10.2015 um 11:29 schrieb Friedrich Volkmann:
> ...
> It's *not* destination, see my other posts.
> To put it more clearly:
> "destination" targets a location, while Anrainerverkehr targets people.
> You can also see it like this:
> "destination" is about where you go, while Anrainerverkehr is about what you
> wanna do there.
> ...
As already pointed out multiple times you are translating far too
literally.

The value "destination" works perfectly for the concept of "you are only
allowed to enter here for a limited number of activities that require
you to be physically at the specific destination/location" however that
is concretised in the relevant legislation.  



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 06.10.2015 um 12:02 schrieb Martin Koppenhoefer:
>
>
> Yes, I didn't imply this. There's another possibility: split it into
> several tags, that can be combined to describe the actual situation
> (e.g. 2 or 3 rather than one tag). Each of these could have specific
> (global) meaning, and there would be no need for different meanings in
> different countries (like you suggest). Regarding the Austrian
> situation there seem to be at least 2 different similar restrictions
> with different meanings (Anrainer and Anrainerverkehr), so another
> values or key is likely needed anyway.
Anrainer seems to be clearly covered by private and Anrainerverkehr is
bullseye covered by the normal use of destination in DACH.

What is the third value supposed to cover?

Simon
 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 06.10.2015 um 11:15 schrieb Martin Koppenhoefer:
> ...
> whether the routers do evaluate these rules specifically should not
> matter to us. We should try to capture the reality, also in subtle
> details, so that someone _could_ interpret the data precisely if he
> wanted to.
> ...
The proper way to do that is to describe the specific
country/national/whatever detailed semantics of a specific value in a
separate table, just as we do it here:
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
(in the case at hand naturally nobody is ever going to use it, but if it
makes people happy)

Doing the above allows us to limit the possible values to a manageable
set and allows our mappers to tag things without in-depth knowledge of
the the actual detailed regulations. Creating a new value for each
national variant is going to go nowhere.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 05.10.2015 um 12:01 schrieb Friedrich Volkmann:
> ...
> Many people have been using (motor_)vehicle=destination for this, but that's
> just wrong, because "destination" would mean that you are allowed to drive
> in to take a walk or shoot photos. In exchange, "destination" would prohibt
> residents from driving through - but they are actually allowed to do so.
> ...
IMHO you are translating far far too literally and trying to infer a
legal meaning from that translation creating an unnecessary and likely
make-believe edge case.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 05.10.2015 um 14:56 schrieb Volker Schmidt:
> ..
> The wiki http://wiki.openstreetmap.org/wiki/Key:access explicitly
> mentions the German "Anlieger frei" and to the best of my knowledge
> that is equivalent to the Austrian German "Anrainer"
And to the Swiss Zubringerdienst ...



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] new access value

[Simon Poole]

Am 05.10.2015 um 16:36 schrieb Richard:
> ... just trying to imagine the poor router trying to decide how to
> route such an area.

While some of the OSM specific routers haven't implemented it at this
point in time, in general routers have no issue at all with it. The
rough US-equivalent from a routing pov is "No Thru Traffic" (to avoid
lengthy discussions about the exact semantics, note that I wrote
"routing pov").

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Level:ref=*

[Simon Poole]

This seems to lead to tons of unnecessary redundancy as proposed: as an
extra tag on POis that already has a level tag. I would rather be
looking for something that fits in with SIT
(http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging) better. Since
SIT works really well (see OpenLevelUp), even without complicated indoor
elements, something that could be added to a building outline, or
building:part would see to be far better.

The addr:floor issue should be kept separate given that applies to
postal addresses that have different use cases and may different in any
case.

Simon

Am 29.11.2015 um 13:53 schrieb John Willis:
> Still looking for feedback on the idea. 
>
> Javbw
>
> On Nov 14, 2015, at 3:17 PM, johnw  > wrote:
>
>> I created an RFC page for level:ref=*
>>
>> I look forward to your comments. here or on the discussion page. 
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/level:ref
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - Level:ref=*

[Simon Poole]

Am 30.11.2015 um 10:26 schrieb Martin Koppenhoefer:
>
> 2015-11-29 22:05 GMT+01:00 Simon Poole <si...@poole.ch
> <mailto:si...@poole.ch>>:
>
> I would rather be looking for something that fits in with SIT
> (http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging) better.
>
>
>
> I don't see why this doesn't integrate. E.g. your example
> shop=supermarket
> level=0
>
> could have the tags added:
> level:ref=EG
> level:name=Erdgeschoss
>

In a typical mall (were the non-floor plan variant is most  useful) you
can easily have 20, 30 shops per level.

> This might look unneccessary at first glance (and in many cases it
> is), but there are cases with particular floor numbering and naming
> schemes where it is helpful.
>
>  
>
> Since SIT works really well (see OpenLevelUp),
>
>
>
> The min_level-idea doesn't work AFAIK in all cases, where storey
> heights of adjacent buildings are different and they are connected by
> a bridge, and more general, it doesn't work where levels aren't simply
> stacked and uniform for the whole part/buidling but are inclined or
> have varying absolute elevations in different rooms (e.g. connected by
> a ramp). The min_level of which building should apply? I still suggest
> to use building_levels for the amount of all levels of that building
> part / building, not the concept of "building_levels=min_level of a
> neighbouring building until first level+amount of building levels of
> the part that is tagged".
>
> Also buildings with varying floor heights are not depictable (AFAIK).

SIT is not intended as a replacement for S3DB which you seem to be
implying and I'm not quite sure why you believe you can't model a
connection between two floors potentially with different numbering
schemes  in two different buildings given that the numbering -is- local
to the building or building:part.

Simon


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Agreement on units and tagging for maxstay?

[Simon Poole]

The German version of the wiki page  specifies minutes when no unit is
given and this is what is in use in JOSM and Vespucci.

Simon

Am 09.12.2015 um 23:00 schrieb Bryan Housel:
> We recently got a request to add the `maxstay` field to iD’s parking
> preset.  This seems like a useful field, but the currently tagged
> values for maxstay are a mess:
>  http://taginfo.openstreetmap.org/keys/?key=maxstay#values
>
> This seems partly because OSM encourages certain values to be tagged
> with standard SI unit abbreviations (a good thing), but we don’t have
> any guidance on tagging values for times.
>
> 1.  http://wiki.openstreetmap.org/wiki/Map_Features/Units
> I’d like to propose to add to this page, guidelines for tagging times
> that follow the conventions established in other fields with units.
>
> Measure: Time
> Default SI unit:  Seconds?  (no strong preference here)
>
> Explicit specifications: 
> Seconds: `s`
> Minutes: `min`
> Days:  `day`
> Weeks: `wk`
> with examples using `maxstay` tag.
>
> 2.  http://wiki.openstreetmap.org/wiki/Key:maxstay
> I’d like to propose to update this page to use tagging detailed above.
>
>
> Thanks!
> Bryan
>
>
> Re: https://github.com/openstreetmap/iD/issues/2866
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Subject: Feature Proposal - RFC - highway=social_path

[Simon Poole]

This one of the more bewildering threads I've ever seen on tagging.

Surely we have more than enough tags to indicate the physical attributes
of ways for movement by foot or single track vehicles, and yes as nearly
always there is a some overlap and grey area between when you would use
a footway and when a path. But in the end it is up to the data consumers
to actually do something with the tags (and clearly they could
differentiate between a well trodden path in a city park and a difficult
hiking route even now) and adding yet another variant is not going to
help at all.

The other point discussed indicating important/official status/whatever
of a route clearly belongs, well, on the route and given that nearly all
the examples given are routes consisting of multiple ways with
potentially differing characteristics surely for once this is a clear
case for route relations (and tagging importance as an attribute of them).

Simon





signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of Multi-Use Building

[Simon Poole]

Either nodes and/or SIT
(http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging)

openlevelup.net can be used to visualize.


Simon


Am 28.06.2016 um 13:05 schrieb jeffrey.rho...@geogr.uni-giessen.de:
> Hello,
> I'm currently working on a Campus Information System via OSM for my
> university, and stumbled upon a tagging problem:
>
> The University has rented officers in some multi-leveled buildings
> that include both Offices (commercial and University), Flats, and
> shops on the gorund floor.
> I oculdn't find any definite information o nthat on the Net, just
> multiple ideas, though none of which seemed to be an official consens
> on hwo to tag such building.
>
> Is it best to set up a building, and then trow multiple ' point'
> objects in there with the tagging for the specific uses, or setting up
> subsections for each use in the buidings own tags, or something i
> missed entirely?
>
> Thanks in Advance,
> Jeffrey Rhodes
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - access:electric = * - Access key for vehicles powered by an electric motor

[Simon Poole]

IMHO the main issue with this proposal is that the legal and technical
situation is in flux and it is rather unlikely that access will be based
on propulsion technology itself. For example access could be emissions
based (as in the German "Umweltzonen"
https://en.wikipedia.org/wiki/Low-emission_zone#Germany ) or we might
end up having additional vehicle classes.

Simon


Am 26.06.2016 um 14:57 schrieb Martien Scheepens:
>
> Hi,
>
>  
>
> I would like to make my first submission to the tagging scheme:
>
>  
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/access:electric
>
>  
>
> The key [[Key:access#Transport mode restrictions]] features keys for
> access restrictions by mode of transport. It details the type of
> vehicle, but does not specify the type of engine.
>
> With the rise of the electric engine, the first law-makers are
> allowing the more silent and environment-friendly engine exclusive
> access in sensitive areas.
>
>  
>
> I would like to hear from you, if it is a useful addition and if
> covered all important points.
>
>  
>
> Cheers,
>
>  
>
> Martien
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=yes for multiple building

[Simon Poole]

IMHO we always allow and support progression from rough to more detailed.

If actual building outlines are difficult to determine then one outline
for the complex is completely OK. Typical example: medieval cities.

Am 16.03.2016 um 15:47 schrieb joost schouppe:
> Is it OK to map multiple buildings as one closed line with the
> building=yes tag? Or does building=yes imply it is one single building?
> There is the terrace value, but that implies one orderly structure,
> not the hodgepodge of houses, buildings and extensions that define
> organically grown blocks.
>
> There are a couple of "multiple" values too, which make sense, but is
> undocumented and maybe overly precise.
>
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
>  | Reddit
>  | Wordpress
> 
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=yes for multiple building

[Simon Poole]

We are really discussing two different issues here.

- use of building key for buildup areas that should be
landuse=residential or other landuse variants, don't think anybody
disagrees that building is misplaced is such situations

- use of one building outline for a complex of potentially more than one
building that are adjacent and not easily divided in to individual
component structures (I had to laugh at the suggested "can stand on its
own" criteria, having seen other building collapse when one in a row has
been demolished).

Simon

Am 17.03.2016 um 06:41 schrieb Jean-Marc Liotier:
> On 03/16/2016 03:47 PM, joost schouppe wrote:
>> Is it OK to map multiple buildings as one closed line with the
>> building=yes tag ? Or does building=yes imply it is one single
>> building ?
>
> building=yes is a single building.
>
> I have encountered this problem a lot in Senegal. I talked with local
> mappers and I found the root cause: university GIS courses teach them
> to map "built-up zones" and they gravitate towards building=yes for
> that. We are pushing the message that it is not the right way to do it
> - that is what landuse=* is for and there are also some place=* such
> as place=city_block.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] sloped_curb, kerb and god knows what left in limbo ......

[Simon Poole]

Accidentally I noticed today that iD was suggesting a sloped_curb tag
for crossings, it piqued my curiosity a bit and it seems that we have
the situation now, that we have two different tagging systems in
moderate use (~20'000 occurrences of slopped_curb and  kerb each). But
no documentation for the one
(https://wiki.openstreetmap.org/wiki/Proposed_features/dropped_kerb is
what you get redirected to for slopped_curb but the page does not have
any useful content and indication of which values should be used) and a
long abandoned proposal for the other
https://wiki.openstreetmap.org/wiki/Proposed_features/kerb

While the abandoned proposal seems to be more complete and I can't say
anything about the other variant because of the lacking documentation, I
don't really care either way, it would simply make easier if we could
come to some consensus on what the actual current state is and what the
preferred tagging is.


Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] JOSM preset with strange tag values

[Simon Poole]

Two observations 

- the motorcycle preset in its present form (well with the exception of
an improvement from yours truly) exists since at least JOSM 3498 6 years
ago ... debating the motivations of whoever added the sale key is rather
moot at this point in time.

- pure motorcycle rental places are very very rare (pls don't assume
that it is the same as with cars), at least I and I suspect most other
bikers are likely to  search for dealerships and then check if they
provide rentals or not.

And yes, the sale key is rather weird,

Simon

Am 04.03.2016 um 07:56 schrieb Marc Gemis:
> On Thu, Mar 3, 2016 at 7:24 PM, Martin Koppenhoefer
>  wrote:
>>> Am 03.03.2016 um 14:41 schrieb Marc Gemis :
>>>
>>> I'l agree that when there are separate tags for rental and repair
>>> there is no need for sales=no.
>>> Only when you try to bring everything under 1 umbrella the sales=no makes 
>>> sense.
>>
>> I don't see why a place to rent motorcycles should be tagged in a way that 
>> facilitates confusion with a place that sells motorcycles. Why would you do 
>> this? People look either for the first or the second but almost never they 
>> don't care, so a distinction at the top level seems right.
> While I don't want to defend the scheme of the preset (you should
> contact the author of the preset on why he/she choose that scheme),
> there are some benefits with that schema.
> With this schema I only need 1 query shop=motorcycle + rental=yes (or
> whatever is in the preset) to find all places where you can rent
> motorcycles.
>
> With the duck tagging, you need the union of 3 "queries"
>
> - one for pure rental places
> - one for shop + rental
> - one for repair + rental.
>
> Otherwise you might miss places where you can rent a motorcycle. So
> the distinction at the top is not useful for this search. The same is
> true in case you look for a repair shop, as shops selling motorcycles
> usually offer service as well. Hence, the distinction is not always
> right imho.
>
> My original comment was just triggered by Martin stating that
> sale/sales does not makes sense. It does makes sense in case you merge
> all three, But shop=motorcycle is a bad choice in that case. For some
> queries it would be nice to have all motorcycle related commercial
> activities under 1 tag.
> This does not mean that I ask to change the current preferred way of 3
> top level tags. I just want to point out that there is a downside on
> the current schema (with 3 toplevel tags) as well.
>
> regards
>
> m
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft of proposal tag 'sells' for shops..

[Simon Poole]

It really really really really is not a good idea to pollute the key
name space with an indeterminate number of sub-keys* instead of placing
values in the, no surprise there, value part. it essentially guarantees
that nobody will ever evaluate any of the information and even if the
proposal would be accepted it wouldn't make any difference at all.

Simon

* for a small number of well defined and documented sub-keys it is not
particular nice, but can be tolerated.

Am 06.03.2016 um 02:01 schrieb Warin:
> I have created a draft for the tag 'sells'.
>
> This an attempt to subvert the present creation of other tag/s (by
> stealth) that, in my view, can be much better.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Sells
>
> Comments here please.
> ---
>
>
> Proposal
>
> A tag to indicate what a shop sells with some detail.
>
>
> Rationale
>
> Presently people are add uncoordinated sub tags for each type of shop.
> The first thing that is being identified are the items sold by the shop.
>
> It would be better to have a sub tag that can be used under any shop
> type that uses the same system. It is also beneficial in that a
> 'general_store' can than use that same system, making searches easier?
>
> The word 'sells' is chosen to reflect the intended use without any
> confusion. The word 'sale' implies a single event over a limited time
> with reduced priced.
>
>
> Examples
>
> sells:motorcycle:yamaha=yes
>
> sells:motorcycle:honda=yes
>
>
> sells:bread:wholemeal=yes
>
> sells:bread:sourdough=yes
>
> sells:bread:tip_top=yes
>
>
> sells:cloths:children=yes
>
> This saves individual solution for each type of shop as is presently
> being propagated e.g.;
>
> http://wiki.openstreetmap.org/wiki/Key:clothes
>
> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dtobacco
>
> and there are, as yet, undocumented but placed in JOSM presets, tags
> for motorcycles!
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

[Simon Poole]

Am 03.03.2016 um 11:23 schrieb Martin Koppenhoefer:
>
> 2016-03-02 17:42 GMT+01:00 Simon Poole <si...@poole.ch
> <mailto:si...@poole.ch>>:
>
> While the abandoned proposal seems to be more complete and I can't say
> anything about the other variant because of the lacking
> documentation, I
> don't really care either way, it would simply make easier if we could
> come to some consensus on what the actual current state is and
> what the
> preferred tagging is.
>
>
>
> I do care: prefer "kerb" for consistency, as this is Imperial style.
> We already had changed the "curb" to "kerb" many years ago, and IMHO
> there's no gain in re-introducing the yankee curb.

The problem is "we" didn't. As already pointed out, there is only a
proposal that has been bit-rotting for multiple years (it probably, when
used on a crossing node, should have kerb:right and kerb:left variants
for the asymmetric cases, but that is the only thing I see that might be
improved). There's not even a JOSM preset for it.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

[Simon Poole]

As pointed in my first mail out the issue is deprecating an existing
scheme in the wiki without replacing it with something else that is
either recognized as "how we do it now" or "approved" (the issue is not
that there is yet another scheme bit rotting in proposal state).

My question was solely if there is some consensus that the kerb proposal
is actually how it should be tagged now or if it is truly defunct and
the original tagging scheme should continued to be used (as iD does).

Simon

Am 03.03.2016 um 11:58 schrieb Martin Koppenhoefer:
>
> 2016-03-03 11:43 GMT+01:00 Simon Poole <si...@poole.ch
> <mailto:si...@poole.ch>>:
>
> The problem is "we" didn't. As already pointed out, there is only
> a proposal that has been bit-rotting for multiple years (it
> probably, when used on a crossing node, should have kerb:right and
> kerb:left variants for the asymmetric cases, but that is the only
> thing I see that might be improved). There's not even a JOSM
> preset for it. 
>
>
>
>
> What is wrong with the proposal ("bitrotting")? The tag it documents
> are used 24.000+ times. I agree with the addition of direction
> dependent tags for asymetric situations, you should put this on the
> discussion page, maybe in this paragraph:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/kerb#Kerb_direction
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

[Simon Poole]

Recently I believe in this case was 2010 .

Simon

Am 07.03.2016 um 19:39 schrieb Andy Mabbett:
> On 2 March 2016 at 16:42, Simon Poole <si...@poole.ch> wrote:
>> While the abandoned proposal seems to be more complete and I can't say
>> anything about the other variant because of the lacking documentation, I
>> don't really care either way, it would simply make easier if we could
>> come to some consensus on what the actual current state is and what the
>> preferred tagging is.
> I notice that two pages have recently been marked as "deprecated", in favour 
> of:
>
>http://wiki.openstreetmap.org/wiki/Key:kerb
>
> I find the latter unhelpful; it assumes that all wheelchairs are the
> same, and seems to leave no way to say that a kerb is "dropped" (using
> whatever term may be preferred), if the editor does not know which
> /type/ of dropped kerb it is.
>
> I would prefer, say:
>
> kerb=dropped
> dropped-kerb=rolled
>
> instead of, say:
>
> kerb=rolled
>
> since the former allows the use of:
>
>  kerb=dropped
>
> alone.
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

[Simon Poole]

If you scroll down you will notice that there was never a sloped_kerb
proposal as the page is actually the proposal for amenity=sloped_curb
which was marked as inactive here
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/sloped_kerb=670959
(which is understandable given that proposing it as a value of amenity
was questionable even at that time and only has 63 uses in total).

In any case it didn't seem to have any bearing on the use of sloped_curb
and curb keys which seem to be completely undocumented, but are at least
in use (see my original posting).

Simon
 
Am 07.03.2016 um 19:39 schrieb Andy Mabbett:
> On 2 March 2016 at 16:42, Simon Poole <si...@poole.ch> wrote:
>> While the abandoned proposal seems to be more complete and I can't say
>> anything about the other variant because of the lacking documentation, I
>> don't really care either way, it would simply make easier if we could
>> come to some consensus on what the actual current state is and what the
>> preferred tagging is.
> I notice that two pages have recently been marked as "deprecated", in favour 
> of:
>
>http://wiki.openstreetmap.org/wiki/Key:kerb
>
> I find the latter unhelpful; it assumes that all wheelchairs are the
> same, and seems to leave no way to say that a kerb is "dropped" (using
> whatever term may be preferred), if the editor does not know which
> /type/ of dropped kerb it is.
>
> I would prefer, say:
>
> kerb=dropped
> dropped-kerb=rolled
>
> instead of, say:
>
> kerb=rolled
>
> since the former allows the use of:
>
>  kerb=dropped
>
> alone.
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] setting proposals to abandoned

[Simon Poole]

Slightly off-topic but there is a renewed effort to improve the
childcare/pre-school education under way on the German forum. Naturally
the issues that you touched on have not gone away and it remains tricky
to get find a solution that is reasonably simple to tag and at the same
time tries to keep the amount confusion due to the many many different
systems and use of the same expressions for very different things as low
as possible.

Simon

Am 27.03.2016 um 23:23 schrieb Tom Pfeifer:
> Shawn K. Quinn wrote on 2016/03/27 20:02:
>> I can agree with setting this proposal as abandoned. However, we do need
>> better tagging for childcare facilities and it is disappointing that the
>> talk Monica Stephens gave back in 2012 has apparently fallen on deaf
>> ears.
>
> I just watched that talk and fully disagree. The talk was using anecdotes
> as evidence and quite rhetorical. The proposal cited as example was
> rejected
> because it was immature and self-contradictory and had a fuzzy scope,
> not because
> the male contributors to OSM would not be able to classify child care
> facilities,
> or not interested in.
>
> The true aspect in the talk was the cultural diversification in
> educational and
> childcare systems, which was insufficiently considered in the previous
> approaches.
>
> These facilities are like the highway tag, they need national
> interpretation
> how to use them .
>
> tom
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Suggested way to map disputed country borders

[Simon Poole]

As somebody who regularly has to respond to complaints from officials
and others on boundary matters, I fail to see how mapping additional
borders (and a lot of them, given that there are nearly no countries
without disputes) is going to help. Matter of fact it is guaranteed to
make things worse and at the same time not help with legislation as in
China or proposed in India.

The current mapping of de-facto boundaries of effective control is
easily defensible and has a certain logic that even the greatest
nationalists typically will accept (that knowing who really controls an
area is helpful in avoiding getting killed).

Simply adding 100s if not 1000s of possible variants to OSM proper
(nothing against making them available elsewhere) will simply increase
the pressure from all sides to get their version of reality rendered on
osm.org (and other high profile sites).

Simon


Am 19.05.2016 um 10:05 schrieb Rory McCann:
> On 07/05/16 11:54, Andy Townsend wrote:
>> The problem with answering Rory's original question directly is that in
>> OSM we try and "map what's on the ground", and don't map stuff that's
>> never going to happen (for example, if a village thinks that it'd be
>> really nice if there was a bypass around it, but there's no concrete
>> proposal, no funding and no likelihood of it happening, we don't map
>> that bypass).  A number of territory claims are for national historic
>> pride reasons only and are unlikely ever to result in any changes to
>> actual administrative boundaries*.
> I'm not suggesting mapping every little "someone in $COUNTRY thinks
> $AREA should be in their country", I'm suggesting mapping areas which
> governments claim. Imagine you had to make a map for the government of
> $COUNTRY, and they required the borders to be one way. That's the kind
> of thing that I think should be in OSM. You should be able to use OSM,
> and only OSM, to make a map that is acceptable to any government.
>
> Both of the example maps of Russia/Ukraine and India/Pakistan require
> the use of another data set. Which is a shame. One should be able to
> generate that from OSM entirely.
>
> Rory
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Artworks inside the Louvre

[Simon Poole]

Isn't this a bit of a non-question, given that neither the indoor, nor
the level tag is currently imported in to the rendering database, so you
really only have the option of testing if the object in question is in a
building outline or not (which may be a bit expensive).

Simon

Am 24.07.2016 um 00:42 schrieb Daniel Koć:
> We are on the way to render artworks on osm-carto (default map layer
> on main website), but during testing phase I've found that in Louvre
> they are tagged not only on the exterior, but also some of them are
> inside the building (as part of the permanent exposition, I guess).
>
> This made me think if - and how - should we tag such features? Current
> definition is laconic and does not help in this case ("A tag for
> public pieces of art"). Should we just add "indoor=yes" (currently
> 67k+ uses), find new tagging scheme or just introduce a policy which
> doesn't let tagging them?
>
> It is important for a rendering strategy - we're not able to recognize
> which are visible outside and which are not and it creates a visual mess:
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/2236#issuecomment-234687333
>
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Layer and highway=steps

[Simon Poole]

Bjoern

The layer attribute is only used for overlapping OSM elements to
indicate their relative position ( indoor mapping should be using
"level" (the SIT tagging scheme has already been referenced). In a pure
indoor scenario I would consider layer unnecessary (JOSM will naturally
complain bitterly, but that's life, and standard renderers will simply
ignore the level tag). BTW Kings's Cross already has some indoor mapping
(all overground at this point in time):
http://openlevelup.net/?lat=51.531616=-0.124528=19=0=0=1=1=0=0=0=0

@all

While we are on the topic, maybe it would be time to move the draft to a
more permanent status given that none of the other proposals has gained
traction or have substantial design issues.

Simon

Am 02.07.2016 um 13:47 schrieb Bjoern Hassler:
>
> Hi Volker,
>
> My question does relate to overlapping steps, see
> http://overpass-turbo.eu/s/h5F for context (King's Cross underground,
> London). Yes, layer rather than level.
>
> I'm thinking about accessibility, as well as ease of mapping. Suppose
> you are at a certain location, how do you determine what
> steps/escalators/elevators connect to that location (from other
> floors)? In other words, what are your access options to that layer.
>
> Similarly for mapping: because of the extensive network, it's hard to
> see what's what. With layer on steps you could examine the data layer
> by layer. If only footways have layers, what overpass query would you
> use to include steps?
>
> Thanks for note on up/down. The wiki documentation does suggest this:
> "By convention, the /direction of the way/ should preferably point
> uphill, but the key incline
> =* should always be
> added to the way (see the talk
> page
> for more
> details)." So no default direction as you say, but convention and
> recommended incline tag.
>
> Bjoern
>
> On 2 Jul 2016 12:04, "Volker Schmidt"  > wrote:
>
> "layer" is not relevant here. The "layer" tag is only used to
> indicate the relative vertical position of the object with respect
> to other objects. So steps would only have a layer tag if they are
> crossing another way, but not connecting to it.
>
> To indicate the up or down direction of steps, you can use the tag
> incline=up|down. There is no default direction of steps, as far a
> I know.
>
> Your question may refer to the "level" tag. In that case your
> steps are connecting different floor levels of a building. I would
> not assign a "level" tag value to a stair that connects the first
> floor (level=1) with the second floor (level=2) of a building.
>
> Volker
>
> On 2 July 2016 at 12:28, Bjoern Hassler  > wrote:
>
> Hi all,
>
> What is the consensus on the  layer tag for steps?
>
> In the direction of the way, steps should normally run
> uphill/upwards, say from layer=-2 to layer=-1.
>
> Should the steps be tagged with layer=-2 or layer=-1? Or both
> (using different tags)?
>
> Thanks,
> Bjoern
>
>
> ___
> 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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "no right turn on red" tagging?

[Simon Poole]

The defaults per territory concept exists since a -very- long time
(2008)  ...
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

In this case IMHO given that the sign doesn't actually change
access/routing it simply modifies the meaning of the traffic signal, any
tagging should be on the signal and a restriction relation doesn't
actually make any sense.

Simon



Am 02.07.2016 um 18:17 schrieb Colin Smale:
>
> One of these days someone will introduce the concept of defaults per
> territory. My prediction is that this suggestion will either get
> mercilessly shot down in flames, or be quietly accepted, probably
> depending on who suggests it. 
>
>  
>
> //colin
>
> On 2016-07-02 18:06, Johnparis wrote:
>
>> Ooh, I think Martin's suggestion would become a MAJOR project.
>>
>> If I recall correctly, "right turn permitted on red after stop" is
>> the traffic law in the entire United States with the sole exception
>> of New York City. (Wikipedia says this has been the case since late
>> 1978.)
>>
>> Are you seriously suggesting that virtually every single traffic
>> signal in the United States be tagged with "right turn permitted on
>> red after stop" instead of tagging the few with "no turn on red"? How
>> does this comport with the notion of tagging what you see -- the only
>> signs you'll see in the USA are "no turn on red" (with the exception
>> of NYC).
>>
>> John
>>
>>
>> Martin Koppenhoefer > > wrote:
>> >
>> >
>> > Message: 2
>> > Date: Sat, 2 Jul 2016 17:06:59 +0200
>> > From: Martin Koppenhoefer > >
>> > To: "Tag discussion, strategy and related tools"
>> > >
>> > Subject: Re: [Tagging] "no right turn on red" tagging?
>> > Message-ID: <45fed486-3423-40d5-80e4-5d6406fe0...@gmail.com
>> >
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> >
>> >
>> > sent from a phone
>> >
>> > > Il giorno 02 lug 2016, alle ore 16:55, Nathan Wessel
>> >
>> ha critto:
>> > >
>> > >
>> > > Who is right here? Should I report this as a bug and change the
>> wiki to allow turns on ^no_.*" relations as standard or should the
>> tagging be changed? And how?
>> > >
>> >
>> >
>> > right turn on red is something that isn't generally allowed, some
>> countries do, some do if additional signs are posted. I'd suggest to
>> explicitly tag the positive case (right turn on red is allowed),
>> rather than assuming a default of yes and tag the negative cases.
>> >
>> > 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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - CoreIndoor

[Simon Poole]

Currently nothing breaks when SIT is used and additional ways are added
as a stop gap measure to enable "current" routing engines to work a bit
in such areas (just as it is common to do with pedestrian areas and so
on), and nobody has suggested that such mapping be outlawed (if that was
at all possible in an OSM context).

What however is being requested is that we add a parallel tagging scheme
to SIT based on using ways. That would seem to be turning the clock back
5 years. IndoorOSM, on which SIT is loosely based historically, used
areas for corridors and similar elements and had a working routing
engine that didn't require adding additional ways in 2012. It would seem
silly to spend effort to closely specify something that we want to move
away from.

See
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2017/Project_Ideas#Support_for_indoor_routing_.28SIT_schema.29
for something that would allow us to move forward, not backward.

Simon


Am 19.02.2017 um 12:06 schrieb Richard:
> On Mon, Feb 13, 2017 at 11:42:13PM +0100, Tobias Knerr wrote:
>
>> (2.) Corridors/stairs can use ways
>>
>> This is probably where opinions will vary the most. The decision in favour
>> of area tagging was one of the most fundamental that we made when drafting
>> SIT. Because of this, using highway ways for corridors feels like a big
>> change away from SIT, not merely an extension.
> not really for or against it, but one thing that should be considered is the
> large number of buildings mapped without SIT but with some indoor elements
> and ways mapped using various other methods eg tunnel=buidling_passage,
> highway=corridor, covered etc.
> Those should not be orthogonal to SIT but enhance each other where possible.
>
> Richard
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access: motorcar and goods, how to read the hierarchy

[Simon Poole]

Mistake #1: assuming that there is a vehicle class hierarchy (of any kind).

Typically law-makers see no reason to conform to computer science
niceties when drafting regulations (rightly so) and will simply add or
deduct vehicle properties in ways that make sense for the regulation in
question (well most of the time :-)).

The OSM hierarchical approach makes sense from a practical mapping pov,
but will have issues accurately modelling such edge cases and I would
suggest just living with that.

Simon

PS: as I pointed out years back, vehicle class hierarchies also tend to
change between moving and resting traffic.

 


Am 17.02.2017 um 11:57 schrieb Martin Koppenhoefer:
> Looking at the current state of access tag documentation:
>
> https://wiki.openstreetmap.org/wiki/Key:access
>
> isn't "goods" a subclass of motorcar, rather than a parallel class of
> it's own?
>
> I came across this, because the Italian driving code has besides
> others these 2 classes (interestingly they also have a distinct class
> for animal drawn sleighs):
>
> - autoveicolo: super class which requires:
>   - at least 4 wheels, motorbikes excluded
>   - motor
>   and has subclasses from a) to n)
>   basically it is a subclass of "motor_vehicle", including cars,
> busses, tractors,  and hgv, but excluding quads, trikes, motorbikes,
> light motorbikes, cars with 3 wheels (e.g. Piaggio ape), some tractors,
>
> - autovettura: vehicles for the transport of persons, max 9 seats, but
> excluding some other classes (like goods).
>
> Question is: what is motorcar meant to mean in OSM?
>
> Isn't there a general problem with the hierarchy? Imagine finding a
> sign forbidding motorcars to pass. Isn't this including hgv as well?
> (In Germany at least it does), but in our hierarchy, motorcar and hgv
> are side a side.
>
> Cheers,
> Martin
>
>
>
>
>
> ___
> for reference:
> https://it.wikisource.org/wiki/D.Lgs._30_aprile_1992,_n._285_-_Nuovo_codice_della_strada/Titolo_III
>
> 54a: "autovetture: veicoli destinati al trasporto di persone, aventi
> al massimo nove posti, compreso quello del conducente;"
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of Country Names

[Simon Poole]

On 25.10.2016 21:47, Kevin Kenny wrote:
> It gets even more complicated in places of disputed sovereignty, where
> the choice of name makes a political statement and speech is not as free
> as it usually is in the West. In the PRC, it would actually be unlawful
> to put the name 中華民國 (or 中华民国) on a map, while in Taiwan, it
> might be lawful to put 臺灣, but would be regarded as politically
> suspicious. 中华台北 is an ambiguous fiction that satisfies nobody, and
> WTO's 臺澎金馬個別關稅領域 is no better.

That however is a different can of worms, this discussion is mainly
about what countries call the territories over which they have actual
control, not about what some countries would like to call countries that
they have no control over (and there is a fair number of such conflicts).

Naturally even the current topic can be politically/culturally sensitive
(which is one of the reasons we end up with these multiple names names),
but much less so than territorial claims.

> 
> Some problems don't have good solutions.
> 

IMHO trying to make everybody happy wrt such claims is outside the scope
of OSM and unlikely to be possible in any case.

Simon

> 
> On Tue, Oct 25, 2016 at 3:25 PM, Simon Poole <si...@poole.ch
> <mailto:si...@poole.ch>> wrote:
> 
> 
> As an inhabitant of one the countries mentioned with multiple official
> languages may I quickly chip in: our previous solution was to simply
> leave the name tag empty given that stuffing the 4 official language
> variants in to the name tags was rather unwieldy and even so none of
> them are actually the countries real official name (see
> http://official-name-abbreviations-meaning.all-about-switzerland.info/
> <http://official-name-abbreviations-meaning.all-about-switzerland.info/>)
> .
> 
> This proved impossible to maintain due to fiddling mappers living in a
> neighbour country to the north, so to get a bit of peace and quiet (we
> would have been quite happy with using English on the standard
> rendering), we opted for the current ungainly solution.
> 
> The real simple solution would be to provide a tag with a list of the
> countries official languages and then allow the renderer to choose from
> them in the cases when you want a non-translated name value (and as said
> leave the name tag empty).
> 
> Simon
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> <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 of Country Names

[Simon Poole]

preferred?

Which would nicely cover the case of India Andy was referring to. @andy
btw the whole is about making easier to express local preference, not
harder.


Am 26.10.2016 um 14:34 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> Il giorno 26 ott 2016, alle ore 10:38, Sven Geggus 
>>  ha scritto:
>>
>> having an official langage tag as Simon suggested might be the ways to go.
>
> I'd prefer avoiding the word "official", in favor of eg default or 
> on-the-ground etc.
>
> Cheers,
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Pedibus / Walking bus routes

[Simon Poole]

Yes that seems to be a thing (see
https://en.wikipedia.org/wiki/Walking_bus and
https://de.wikipedia.org/wiki/Pedibus).

We've locally (CH) received a question as to how to map such routes and
there doesn't seem to be any established tagging outside of using
route=foot in France which likely is not a particular good choice.

Creating a tagging for the route itself is not difficult either
route=walking_bus or route=pedibus would work, but what about the stops?
Any suggestions?

Simon

PS: our kids simply walk to kindergarten / school, so I don't really
have a stake in this :-)




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of Country Names

[Simon Poole]

As an inhabitant of one the countries mentioned with multiple official
languages may I quickly chip in: our previous solution was to simply
leave the name tag empty given that stuffing the 4 official language
variants in to the name tags was rather unwieldy and even so none of
them are actually the countries real official name (see
http://official-name-abbreviations-meaning.all-about-switzerland.info/) .

This proved impossible to maintain due to fiddling mappers living in a
neighbour country to the north, so to get a bit of peace and quiet (we
would have been quite happy with using English on the standard
rendering), we opted for the current ungainly solution.

The real simple solution would be to provide a tag with a list of the
countries official languages and then allow the renderer to choose from
them in the cases when you want a non-translated name value (and as said
leave the name tag empty).

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of Country Names

[Simon Poole]

Am 26.10.2016 um 21:56 schrieb Martin Koppenhoefer:

.. a lot of things that are likely right 

But  nobody was discussing removing minority and similar status
language name:xx variants and further they don't normally get included
in the "name" tag as is. Difficult to see why you believe the
suggestions on the table would make the support of such languages worse
(if at all it would seem to be better).

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Solar shop

[Simon Poole]

I believe the correct expression is photovoltaic (which would exclude
hot water generation etc though).


Am 31.07.2017 um 09:07 schrieb SwiftFast:
> The word "solar" alone is a synonym for "Diesel Fuel" in some countries
> and can cause confusion. I'd advise using solar_equipment or
> solar_devices instead.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Beautified JSON presets for natural=tree

[Simon Poole]

On 22.07.2017 20:28, Dave Swarthout wrote:
> ...
>
> Can you expand and clarify your comment for me?
>
>
Just as I wrote, and nothing that I invented, it is considered

a) good practice to tag source on the changeset. Which in turn implies
that if you are using more than one third party data source and it is
not clear what you have been deriving from which source, you should be
creating separate changesets.
b) there are some limited exceptions which are typically name spaced
source keys.

As said this has been state of the art since literally years (not quite
a decade since changesets don't exist quite so long).

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

Re: [Tagging] Beautified JSON presets for natural=tree

[Simon Poole]

On 22.07.2017 16:35, Pander wrote:
> Rarely used tags also take up valuable space in apps such as Vespucci.
>
Just to clarify:  optional tags are, as the name says, optional and do
not use screen real estate except if already in use, or explicitly added

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

Re: [Tagging] OSM+Wikidata intro video

[Simon Poole]

Am 15.06.2017 um 22:02 schrieb Yuri Astrakhan:
> Sorry for the delay - I have updated the license on the license page
> to point to ODbL and OSM -- http://88.99.164.208/wikidata/copyright.html
>
> This service is still looking for a proper home. If you have an extra
> 700GB of space on a server, please PM.
>
Wrong place to ask ... better dev or talk (or both).


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] shop=appliance vs. shop=electronics

[Simon Poole]

And another one from the ragged edge of tagging.

iD has a preset for shop=appliance
http://wiki.openstreetmap.org/wiki/Proposed_features/Appliance_Store , I
assume for shops that sell larger electrical goods washing machines,
dryers, fridges and so on (in German so called  "weisse Ware"). It seems
that historically this wasn't popular and it was suggested to use
shop=electronics
http://wiki.openstreetmap.org/wiki/Tag:shop%3Delectronics . The later
would seem to work reasonably well for the large consumer electronics
markets that sell essentially everything from DVDs, over drones, TVs,
computers and washing machines. But not for smaller shops that are
specialized on just such larger appliances.

Any thoughts?

Simon

PS: no, I don't think it is acceptable to have to enumerate and query
every possible kind of good a shop can sell to find out what its main
kind of business is.




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: How to map a bin with dog excrement bags dispenser

[Simon Poole]

I agree with this, bin=yes is already a well established attribute tag
and for the typical combined dispenser/bins that you see here (1000s of
them) it would seem to be the most correct tagging.

Naturally there are other set-ups with separate bins potentially simply
nearby, they should obviously be modelled as two nodes.

Simon


Am 10.10.2017 um 16:40 schrieb marc marc:
> ..
> the main question :
> it is a waste_basket or vending_machine ?
> the main function is related to bags.
> the bin is useful only after you get a bag.
> if you don't have a bag, you can not use the dedicated bin.
> therefore the few that I have taged have :
> amenity = vending_machine
> vending = excrement_bags
> bin=yes
>
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fashion

[Simon Poole]

I'm afraid we would start running out of usable words real fast if we
could only use those with non-confusing meanings in their original and
other languages (maybe Kindergarten, oh perhaps rather not :-)).

Seriously the term boutique is so firmly anchored in the English
language that doing away with the term in OSM is likely not going to
work. As to Daniels suggestion of adding more subtags, it doesn't seem
to be sensible to replace the existing clothes tag with clothes:type
(minus a couple of values) just so that things are a bit more
systematic. Adding the others, and using them on boutique, fashion and
clothes (plus the other garment related top level objects) why not.

Naturally in the end this doesn't actually answer my question as to what
the defining aspects of shop=fashion are :-).

Simon

Am 29.08.2017 um 19:27 schrieb Severin Menard:
> Hi,
>
> IMHO, I would drop shop=boutique because it is one of the most
> confusing tag, especially in French-speaking contexts.
>
> Basically in French from France, boutique is a generic word meaning
> shop. More than what it sells, it designates the place, generally not
> very large ("magasin" would then more used). A French butcher tells to
> his/her family after the breakfast: "Have a good day everyonem, I will
> open the boutique now". We have an expression for "boutique de"
> (literally shop of) something, that can be used for clothes from which
> I guess derivates the shop=boutique concept. Is it only in the
> Anglo-sphere that the word boutique means this or also in other
> cultural contexts? Eg in Brazil as far as I know people do not use
> boutique, while they are quite fond of French words (like maison
> meaning house) for shops that want to be considered as "chique".
>
> In French-speaking African countries, this generic word is massively
> used for the most generic shop by far: a small convenience store,
> selling food and non food items all over the walls, up to the ceiling,
> where you ask at a desk what you want. This makes it a kind of kiosk,
> even if many are not separate shops but taking one part of the
> basement of a building. And they are not chic at all. And they are
> very, very numerous: in a large city you find one every 50 or 100
> meters. For sure there are more African boutiques in the world than
> the boutiques of hand-made fashion clothes. Of course, new African
> contributors in these countries logically use shop=boutique for their
> own cultural reality so some streets in Africa are full of false-cognates.
>
> So IMHO I would tag these fashionable shop the most generic way as
> possible, not reflecting only one specific cultural context and
> avoiding using boutique. I think a subtag to differentiate
> ready-to-wear and hand-made would fit. What do you think?
>
> Sincerely,
>
> Severin
>
>
> Date: Mon, 28 Aug 2017 14:42:38 +1000
> From: Graeme Fitzpatrick  >
> To: "Tag discussion, strategy and related tools"
>         >
> Subject: Re: [Tagging] shop=fashion
> Message-ID:
>        
>  
> >
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> Just consulted with an authority in these matters - my wife! :-)
>
> Her take:
>
> shop=clothes is chain stores (ie same shop in multiple shopping
> centres /
> towns) aimed at lower-middle end of the market
>
> shop=fashion is middle - higher end, but still chain stores
>
> shop=boutique is "one-off" shops eg selling hand-made rather than
> mass-produced clothes; niche / speciality items etc
>
> Hope that helps?
>
>
> Thanks
>
> Graeme
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fashion

[Simon Poole]

Am 30.08.2017 um 10:01 schrieb Marc Gemis:
> It would be nice if shop=boutique would show an icon with clothes or
> something similar instead of a dot on the default osm-style. So people
> would see they made a mistake.

Not only that.  Any translations and the like should (naturally) give a
name/description in the language that is appropriate.  With other words
using "boutique" as the French translation of shop=boutique would be a
bad idea and I'm wondering if we have this problem with some of the
editors, or if there are other reasons why there is so much confusion,.

Simon

>
> m.
>
> On Wed, Aug 30, 2017 at 9:54 AM, Jean-Marc Liotier  wrote:
>> (late message because antispam rejected before)
>>
>> On 2017-08-29 19:27, Severin Menard wrote:
>>> In French-speaking African countries, this generic word is massively
>>> used for the most generic shop by far: a small convenience store,
>>> selling food and non food items all over the walls, up to the
>>> ceiling, where you ask at a desk what you want. This makes it a kind
>>> of kiosk, even if many are not separate shops but taking one part of
>>> the basement of a building. And they are not chic at all. And they
>>> are very, very numerous: in a large city you find one every 50 or 100
>>> meters. For sure there are more African boutiques in the world than
>>> the boutiques of hand-made fashion clothes. Of course, new African
>>> contributors in these countries logically use shop=boutique for their
>>> own cultural reality so some streets in Africa are full of
>>> false-cognates.
>> Here is what Séverin is talking about: http://overpass-turbo.eu/s/rkV
>> I guarantee that every single one of these shop=boutique in the Dakar
>> Peninsula are these shop=(convenience|kiosk) that most French-speaking
>> West-Africans name "boutique". We regularly correct them but they
>> sprout even faster - so much that it may indeed be argued that we
>> should go with the flow.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fashion

[Simon Poole]

Sorry that was wrong, JOSM uses "Haute Couture"


Am 30.08.2017 um 11:05 schrieb Simon Poole:
>
> Translations for shop=boutique
>
> iD: Petit magasin de mode
>
> JOSM: Boutique
>
>
> Simon
>
> PS: vespucci didn't have a translation, now it is the same as iD
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fashion

[Simon Poole]

Translations for shop=boutique

iD: Petit magasin de mode

JOSM: Boutique


Simon

PS: vespucci didn't have a translation, now it is the same as iD



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fashion

[Simon Poole]

The other place where shop=boutique was translated to Boutique was on
the OSM website, fixed that too.


Am 30.08.2017 um 11:09 schrieb Simon Poole:
>
> Sorry that was wrong, JOSM uses "Haute Couture"
>
>
> Am 30.08.2017 um 11:05 schrieb Simon Poole:
>>
>> Translations for shop=boutique
>>
>> iD: Petit magasin de mode
>>
>> JOSM: Boutique
>>
>>
>> Simon
>>
>> PS: vespucci didn't have a translation, now it is the same as iD
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] shop=fashion

[Simon Poole]

Working on this issue

https://github.com/simonpoole/beautified-JOSM-preset/issues/27

the question turned up if shop=fashion (with 5000 something uses) 
should not be deprecated (==not offered for new use) due to overlap with
shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not
particularly popular with roughly 200 uses). It just doesn't seem to
have a good definition, which is already pointed out on the wiki page
(but without a conclusion).

Any opinions?

Simon


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

Re: [Tagging] shop=fashion

[Simon Poole]

There is already disambiguation within the shop=clothes object with over
10'000 uses of the clothes tag. and I'm not quite sure were your
stipulation shop=fashion is cheaper than shop=boutique comes from.

Simon


On 26.08.2017 13:13, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 26. Aug 2017, at 11:15, Simon Poole <si...@poole.ch
> <mailto:si...@poole.ch>> wrote:
>
>> the question turned up if shop=fashion (with 5000 something uses)
>> should not be deprecated (==not offered for new use) due to overlap with
>> shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not
>> particularly popular with roughly 200 uses). It just doesn't seem to
>> have a good definition, which is already pointed out on the wiki page
>> (but without a conclusion).
>
>
> I'd see shop=fashion similar with shop=boutique, while shop=clothes is
> not particularly helpful if you're looking to buy clothes (too
> generic). I'd roughly see it like this: boutique expensive, fashion
> cheap(er), department store both, supermarket cheap ;-)
>
> What would I search for if I wanted to buy a suit or a shirt
> (department shops apart which will sell you anything)? Maybe a
> "boutique for men"? To buy gloves I'd try with a  shop=bags? Or
> shop=leather? Or shop=sports? Or an outdoor shop? There are many
> places to buy clothes, cheap, casual, formal, according to the
> material, for work, gender, age, style, one brand/designer or
> multiple, or no (known) designer, discounter, different types of
> clothing (underwear, shirts, etc.
> I'm rather against reduction of top level shop types, there's IMHO a
> clear distinction between fashion shops and boutiques, with maybe some
> edge cases, but still useful overall. Nonetheless I agree that
> shop=clothes does require subtags to be more useful, but the current
> situation in the clothes key is not working:
> https://taginfo.openstreetmap.org/keys/clothes#values
> There are many orthogonal, specific properties tagged, e.g. target
> group (women, men, children, babies), for specific occasions/uses
> (sports/wedding/workwear), materials (denim/fur), type
> (underwear/lingerie). Fashion would be yet another new category in
> this cauldron (with 111 uses it isn't really significant).
>
> 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] shop=fashion

[Simon Poole]

There is a big difference between a limited number of binary options
and  essentially moving all values in to key space (and I can give a lot
of reasons why it is a really really bad idea in a free form, user
extendible tagging system).

But it seems to be rather off-topic in this thread in any case: I simply
wanted to know if there is a clear characterisation of shop=fashion that
can serve as disambiguation between it and shop=boutique and
shop=clothes (with appropriate additional tags).

We have one voice saying that it should be considered a cheap variant of
boutique limited to clothes, and the others suggesting that it is an
upmarket shop=clothes and that shop=boutique should have a broader not
only clothes definition.

One takeaway is that adding the "clothes" tag both to fashion and
boutique would be a good idea.

Simon

Am 26.08.2017 um 13:53 schrieb Thilo Haug:
>
> Hi all,
>
> I'm in favor of a namespace solution,
> http://wiki.openstreetmap.org/wiki/Namespace
> e.g.
>
> ski:clothes=yes
> surfing:clothes=yes
> motorcycle:clothes=yes
> any_other_sport:clothes=yes
>
> and so on.
>
> This way you may also tag other shops (not just shop=clothes)
> in a way which exactly describes their offers,
> in this example possibly a shop=sports.
>
> The same works also for other services they offer,
> like
> ski:repair=yes
> ski:rental=yes
> ski:parts=yes
>
> This way there's no need to create a new shop type
> or decide whether it's MORE one type of shop (bicycle vs. motorcycle
> vs. car or similar)
> in case they offer very various things.
>
> Cheers,
> Thilo
>
>
> Am 26.08.2017 um 13:13 schrieb Martin Koppenhoefer:
>>
>>
>> sent from a phone
>>
>> On 26. Aug 2017, at 11:15, Simon Poole <si...@poole.ch
>> <mailto:si...@poole.ch>> wrote:
>>
>>> the question turned up if shop=fashion (with 5000 something uses)
>>> should not be deprecated (==not offered for new use) due to overlap with
>>> shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not
>>> particularly popular with roughly 200 uses). It just doesn't seem to
>>> have a good definition, which is already pointed out on the wiki page
>>> (but without a conclusion).
>>
>>
>> I'd see shop=fashion similar with shop=boutique, while shop=clothes
>> is not particularly helpful if you're looking to buy clothes (too
>> generic). I'd roughly see it like this: boutique expensive, fashion
>> cheap(er), department store both, supermarket cheap ;-)
>>
>> What would I search for if I wanted to buy a suit or a shirt
>> (department shops apart which will sell you anything)? Maybe a
>> "boutique for men"? To buy gloves I'd try with a  shop=bags? Or
>> shop=leather? Or shop=sports? Or an outdoor shop? There are many
>> places to buy clothes, cheap, casual, formal, according to the
>> material, for work, gender, age, style, one brand/designer or
>> multiple, or no (known) designer, discounter, different types of
>> clothing (underwear, shirts, etc.
>> I'm rather against reduction of top level shop types, there's IMHO a
>> clear distinction between fashion shops and boutiques, with maybe
>> some edge cases, but still useful overall. Nonetheless I agree that
>> shop=clothes does require subtags to be more useful, but the current
>> situation in the clothes key is not working:
>> https://taginfo.openstreetmap.org/keys/clothes#values
>> There are many orthogonal, specific properties tagged, e.g. target
>> group (women, men, children, babies), for specific occasions/uses
>> (sports/wedding/workwear), materials (denim/fur), type
>> (underwear/lingerie). Fashion would be yet another new category in
>> this cauldron (with 111 uses it isn't really significant).
>>
>> cheers,
>> Martin 
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> -- 
>
> Thilo Haug
> Bismarckstr.37
> 72764 Reutlingen
>
> Mobil: +49 177 3185856
> Festnetz : +49 7121 3826414
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging data where position is not yet known

[Simon Poole]

Not quie sure why this is on tagging, but anyway: a clear yes to adding
the data. Add a FIXME tag stating that it is a rough, village level
position for late surveyors and consumers.

Naturally you might simply be able to sit down with the contributors and
squint at aerial imagery to locate the objects post survey, given that
we slowly have a large selection of global imagery that we can use.

Simon

Am 03.09.2017 um 23:35 schrieb ralph.ayt...@ntlworld.com:
>
> Hi all,
>
>  
>
> I am looking for comments and advice regarding this.
>
>  
>
> I am working with a group of local mappers in Sierra Leone, Africa,
> under the name WAMM (West Africa Motorbike Mappers). They are trying
> to find and identify all the towns, villages, hamlets in Sierra Leone
> and have completed one whole District (Kailahun) and are well into
> their second District (Kenema). At each community they take a GPS
> reading to fix where they are (lat and long supplied) and then ask
> prominent locals (chief/headman/etc) for the name, historical name,
> any alternate names. They have also supplied other important data for
> the community such as the existence of a market and which days it is
> open, also the existence of a water pump. Unfortunately, while they
> have confirmed the existence of the latter two they have not
> identified their position.
>
>  
>
> The names of towns and villages were originally added in 2014 first by
> *rwst* with /source=GNS/ and /gns_ufi=* /and in 2014 by Pierzen_import
> adding Sierra Leone place nodes and Unocha pcodes.
>
>  
>
> WAMM have supplied a spreadsheet with the data collected and want to
> know if it can be added to OpenStreetMap. There are a lot of new names
> of smaller communities and confirmation of the names that the locals
> call their communities. This is not a problem and can be checked
> against the existing data already on OpenStreetMap.
>
>  
>
> I want to know how you feel about adding the market and water_pump
> data that does not yet exist on the map. In Africa the existence of a
> market and/or a water_pump is not only important information for the
> locals, it is important information for any medical or humanitarian
> teams carrying out any assessment or intervention in the area. I wish
> to add this data to the map near the name of the community with a
> fixme stating that the existence has been confirmed but the location
> is not yet known. The fact that it is there will be spotted by
> subsequent mappers and hopefully they will be able to move it to it’s
> correct location.
>
>  
>
> Look forward to hearing from you.
>
>  
>
> Regards
>
>  
>
> Ralph (RAytoun)
>
>  
>
>  
>
> Sent from Mail  for
> Windows 10
>
>  
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road barrier

[Simon Poole]

In general the access categories and rules for "traffic at rest" are
different, than for moving traffic.

As to sign C, 3a (Vienna convention), the OSM access wiki page is a bit
unclear in that it doesn't clearly state that when used in a prohibitory
fashion "motorcar" includes all other dual track vehicles (it is clear
that it does not include single track values), and when used as a
permission it doesn't, but it has that in common with traffic rules in
general.

Simon

Am 28.11.2017 um 12:03 schrieb Georg Feddern:
> Am 28.11.2017 um 11:54 schrieb Selfish Seahorse:
>> On 28 November 2017 at 11:26, Georg Feddern 
>> wrote:
>>> Yes, unfortunately the european common-in-use traffic sign "VEHICLES
>>> PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any
>>> double-tracked
>>> motor vehicles" has no equivalent in the OSM access scheme.
>>> I think it is time for a =double_tracked (motor vehicles)!
>> Are there places where only motorcars are prohibited, but other
>> double-tracked motor vehicles are allowed?
>
> I do not know of any, but ...
>
>>   Otherwise, the
>> description/meaning of motorcar=* could be adjusted.
>
> -1
> motorcar=* is needed, because there are places, that are allowed for
> them _only_ (see parking).
> But Dave is right - the implication of motorhomes under motorcar is
> 'very unfortunate' too - for the same reasons.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

[Simon Poole]

A large number of landuse=village_green seem to be due to an import in
the Czech Republic, where is has been used for essentially any grassy
area. Lots of the leisure=common seem to be actually be leisure=park
with the exception of the HOT helicopter "landing areas".  I would
suggest that maybe fixing the obvious nonsense uses of both tags first
and then re-evaluating might be a better strategy (naturally not
rendering both might supply additional motivation to  fix the issues).

Simon


Am 30.11.2017 um 23:45 schrieb Daniel Koć:
> While making some cleaning in osm-carto we have found that
> leisure=common and leisure=village_green are probably not clear enough
> to show them any more. They both have deep roots in British law and
> history and are frequently misused, as far as I can tell.
>
> Both are very popular - 57k and 86k uses, respectively - and still
> growing:
>
> https://user-images.githubusercontent.com/5439713/33458839-19814f9c-d628-11e7-92fd-b51326fa8b25.png
>
>
> That means that maybe such tagging should be discouraged and replaced
> to not spread the confusion.
>
>




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag for major recipient postcodes

[Simon Poole]

Am 17.12.2017 um 21:22 schrieb Warin:
> As they are not related to a physical address then why use the address
> space?
The addr tag space is for postal addresses, that are not guaranteed to
be physical at all (for example addr:city is the postal city, which
might be completely un-surveyable).

That is not really a problem, the problem is more that we don't have a
scheme for non-postal addresses.

Simon

> Possibly the contact space? contact:mail:postcode=*
>
> -
> I believe 1800 numbers cannot be used internationally, so I don't use
> the ISD codes, that OSM requests, with these.
>
>
>
> On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
>> Do you mean PO box? In some cities, massive PO boxes have a special
>> Zip code/ postal code. It could be a property of the PObox address.
>>
>> Maybe an attribute at the POI is right, as POI use to list email
>> addresses and web addresses, which are independent from actual
>> physical address (as PO boxes are), also.
>>
>> National-wide phone numbers treated (such as +1-800-x in USA,
>> cellphones, "vocal nomad" numbers (+34-51-xx in Spain, if I remember
>> well)  are unlinked to physical addresses too. Are they directions
>> about how to use it?
>>
>>
>>
>> El 17/12/2017 13:58, "Tom Pfeifer" > > escribió:
>>
>> As these postcodes are kind of a virtual address that is not tied
>> to a particular pysical location, my opinion would be _not to add
>> them to OSM_, which is a geo database and not primarily a post
>> code reference database.
>>
>> Typically for those companies in DE, there is an additional
>> physical address which has a different postcode for the street
>> address, which is regularly tagged on the physical location.
>>
>> tom
>>
>> On 17.12.2017 13:42, Rainer wrote:
>>
>> Hi all,
>>
>> recently I came across postal codes in POI addresses, which
>> aren't the classic scheme addr:postcode & addr:city &
>> addr:street & addr:housenumber. However it is a special
>> postcode that is assigned to recipients that receive a big
>> amount of post every day, typically big companies or
>> authorities. This kind of postcode is used only together with
>> addr:city and does not require street and housenumber. So to
>> say the post company has a big sack for post to that special
>> postcode, puts in all the letters that are addressed to it
>> and delivers the sack to the recipient.
>> After some discussion in the german user forum
>> https://forum.openstreetmap.org/viewtopic.php?id=60421
>>  I
>> want to propose a tag for this kind of postcode and would
>> like to discuss it here in the tagging mailing list.
>>
>> The proposal is:  addr:postcode_major_recipient
>>
>> It should be used on POIs, because it is an attribute of the
>> company, authority or whatever, but not as an address of a
>> building, because it is not assigned to such directly. Target
>> is to have a separate tag for this kind of postcode to avoid
>> a mix-up with the normal addr:postcode.
>>
>> As I am not a native British English speaker, I have asked
>> one and consulted the english page of the Deutsche Post.
>> Reference:
>> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB
>> 
>> -> goto More -> Find major recipient
>>
>> Probably similar kinds of postcodes exist also in other post
>> companies in other countries, so inputs about that are welcome.
>>
>>
>> Best regards,
>> Rainer
>>
>>
>> ___
>> 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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Education Reform

[Simon Poole]

You numbers look slightly off, wit:
https://taginfo.openstreetmap.org/tags/amenity=childcare


Am 18.11.2017 um 19:05 schrieb Erkin Alp Güney:
> I am offering this proposal into voting as no replies arrived since last
> month.
>
> Yours, faithfully
> Erkin Alp
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Education Reform

[Simon Poole]

[Christoph pressed send before I did, sigh]

While I'm a bit undecided on if we need an education reform at all and
you need to make clear what the voting is actually on, the underlying
proposal is far from ready for any kind of vote or usage at this point
in time.

You need to at least provide a reasonably thorough treatment of how
existing tagging should be mapped to your new scheme and give some
rationale why you are lumping in non-educational facilities (see
educational=nursery).

Simon


Am 18.11.2017 um 19:05 schrieb Erkin Alp Güney:
> I am offering this proposal into voting as no replies arrived since last
> month.
>
> Yours, faithfully
> Erkin Alp
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Replacing POIs with landuse

[Simon Poole]

Maybe some will want to weigh in on the discussion of the obvious trend:
https://github.com/simonpoole/beautified-JOSM-preset/issues/27#issuecomment-341898723




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Simon Poole]

The aftermath of the (IMHO very unnecessary) change:
https://github.com/openstreetmap/iD/pull/4504#issuecomment-341980655

We now have

- 62 chimney_sweeper

- 36 sweep

- 1 chimney_sweep

and one confused chimney sweep


Am 04.10.2014 um 20:39 schrieb John F. Eldredge:
> Chimney sweeps still exist in the USA, although they offer a variety
> of services. The usual term for the industry is
> Heating/Ventilating/Air Conditioning Repair, often abbreviated to HVAC
> Repair. I had my chimney cleaned a few years ago. The technique used
> was a powerful, truck-mounted vacuum cleaner, plus a large brush moved
> up and down the flue. Modern houses no longer use flues large enough
> to climb into, as they suck nearly all of the heated air up the chimney.
>
> I agree that the value chimney_sweep is more understandable than
> simply sweep, as the latter could be misinterpreted to refer to
> companies that sweep up trash from roads and parking lots.
>
>
> On October 3, 2014 6:32:52 AM CDT, Martin Koppenhoefer
>  wrote:
>
>
> 2014-10-03 13:26 GMT+02:00 SomeoneElse
> >:
>
> If they're a German-specific thing then why not use the German
> word rather than co-opt an English one that doesn't actually
> match the primary function that these people perform?
>
>
>
> they are all chimney sweeps. The list of detailed services,
> obligations and functions is naturally country specific such as
> with any other tag as well. We are not using English tags to
> describe everything in relation to Britain, but because it seemed
> a good way to describe the whole world in a way that would be
> understood by most of the mappers.
>
> I'd also expect chimney sweeps to be operating (still) in Britain,
> as they do necessary maintenance work (maybe you have less
> frequent sweeping, but it still has to be done from time to time).
>
> cheers,
> Martin
>
> 
>
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] brand=* necessary?

[Simon Poole]

On top of all what has already been said, what you -should- be doing
(after discussion) is adding the tags to
https://github.com/osmlab/name-suggestion-index instead of embarking on
a lone crusade to show everybody the light.

It can be argued that the name suggestion index it is a bit at odds with
the point raised be Marc and Christoph, but for many of the
stores/facilities in question there is no difference, and in any case
I've been toying with the idea of supporting brands in their own right,
independently of a name .

Simon

Am 10.05.2018 um 10:47 schrieb Leon Karcher:
> On Thursday 10 May 2018, Christoph Hormann wrote:
> > Also note the edits of DP14_BrandUnification are an undiscussed 
> > mechanical edit and should be reverted.
>
> Undiscussed?
> See https://lists.openstreetmap.org/pipermail/tagging/2018-May/036034.html
>
>
> And it is only partly mechanical since I'm reviewing all objects.
>
> 2018-05-10 10:33 GMT+02:00 Christoph Hormann  >:
>
> On Thursday 10 May 2018, marc marc wrote:
> > Imho it us the opposite : name should be added only if it us not the
> > same as brand
>
> Exactly.  Nme tags are for identifiers that identify the individual
> object, not a whole class of objects.
>
> Also note the edits of DP14_BrandUnification are an undiscussed
> mechanical edit and should be reverted.
>
> -- 
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging of one-way cycle lanes

[Simon Poole]

Am 11.05.2018 um 17:40 schrieb Paul Johnson:
>
> Why the almost religious doctrine level of resistance to change?  Even
> the Linux kernel rewrites entire subsystems from time to time when a
> superior approach comes around.
>
Try to change the semantics of an existing LINUX system call (which is
the real equivalent of what you are proposing) and you will find that
this was a happy party in comparision.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[Simon Poole]

Just as a further data point, we had this discussion in 2016 here
http://lists.openstreetmap.ch/pipermail/talk-ch/2016-October/003827.html


Am 20.05.2018 um 10:38 schrieb Selfish Seahorse:
> On 19 May 2018 at 21:20, Martin Koppenhoefer  wrote:
>> route=walking_bus?
>> that’s duck tagging, simple and concise, and is easy to understand for who 
>> knows the concept.
> +1
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How about a Fork? Re: The endless debate about "landcover" as a top-level tag

[Simon Poole]

Am 08.06.2018 um 11:53 schrieb marc marc:
> Le 08. 06. 18 à 11:34, Rory McCann a écrit :
>> Replicate data from OSM, applying your data transformation programme
> it's already what nearly all use of osm is doing.
> it's named "preprocessor" or alias
> it's waste that nearly all data use need to build their own list.
>
You are assuming that the data consumers doing pre-processing
could/would agree on a specific way to normalize the data.

I envision very long discussions on the "normalizing" mailing list bike
sheding what landuse=forest should be mapped to :-).

Seriously, in a such attribute rich dataset as OSM, normalizing is never
going to go away for data consumers and wouldn't go away even if we had
a tagging czar and a completely regular tagging scheme. It would be nice
if going forward we don't create more "weird" stuff, but I think that in
general is the case.

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] I can't support transit:lanes

[Simon Poole]

Just as Bryan does, I can see supporting special casing transit
relations (as we already have to do the same for turn restrictions). I
am -very- reluctant to support one-off tag semantics that require
special code to handle them.

Note with respect to the parallel discussion on tagging systematics,
this kind of thing is multiple orders of magnitude worse than
inconsistencies in tag naming and so on (which at least from an editor
pov can typically handled by configuration in a preset).

Simon


Am 11.06.2018 um 06:42 schrieb Bryan Housel:
> I’ve had a few recent conversations about this proposal:
>  https://wiki.openstreetmap.org/wiki/Proposed_features/transit
>
> Unfortunately I can’t support it.
>
> Not only is the name bad (it should be named `transition:lanes` but
> whatever), the bigger problem is that, as proposed, the tag can be
> placed on either a way or a relation.
>
> The problem with tagging these on ways is that/if you split the way,
> the tag breaks/.  
>
> No other tag works this way (except maybe for address interpolation
> lines, but presumably anybody splitting one of those would know that
> they need to adjust the numbers on the endpoints).  
>
> I’m not going to add a special rule in iD to warn people if they are
> splitting a way with a lane transition tag.  I don’t want to speak for
> the JOSM devs, but I doubt they would implement something like this
> either.
>
> The only way I’ll be able to support lane transitions would be as a
> relation that has similar semantics to turn restrictions..
> from/via/to.  Keep it simple (no multi via ways please).  This is
> already an understood way of tagging things that connect 2 ways.
>  (could you imagine if we tagged turn restrictions as
>  maybe-a-relation or maybe-a-way-tag ?? nope!)
>
> I notice that `transit:lanes` has already been tagged on around 4000
> or so ways, so I thought it would be worth pointing out that the
> proposal is Dead on Arrival in it’s current state.  We should rework
> it before people tag too many more of these and end up disappointed.
>
> thanks, Bryan
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] I can't support transit:lanes

[Simon Poole]

Am 11.06.2018 um 17:19 schrieb osm.tagg...@thorsten.engler.id.au:
>
> *From:*Bryan Housel 
> *Sent:* Tuesday, 12 June 2018 01:12
> *To:* osm-tagging 
> *Subject:* Re: [Tagging] I can't support transit:lanes
>
>  
>
> I’ve already written plenty of code to deal with turn restrictions.
>  There are lots of rules for splitting and joining things to other
> things depending on where the via node is. 
>
>  
>
> If you are curious, here is a recent commit where I tried to improve
> iD’s handling of this.
>
> https://github.com/openstreetmap/iD/commit/87841fc4035c7de9e0f58ca50f05f65723ad5226
>
>  
>
> In other words if this new relation works like a turn restriction,
> it’s already mostly supported… Otherwise expect basic editing (like
> splits, joins, connections) to break it.
>
>  
>
>  
>
> You are seriously telling me that if you have two ways that share a
> node, you are unable to figure out what that node is without having it
> explicitly listed as a totally redundant member of the relation?
>
No, we are all quite capable of figuring that out. The issue is having
to hardwire semantics for one tag out of 1000s and while there are a
lots of special cases, mainly when reversing ways, this would be a first
for splitting (and merging likely too).  

Simon

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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=first_aid_kit

[Simon Poole]

If I may say so the page seems a bit weird.

Name on a first aid kit? Draw an area around the shop outline?

Assuming that are simply C errors, I'll fix things in nobody has any
objections.

Simon


Am 20.06.2018 um 19:31 schrieb Bryan Housel:
> Just following up after a week - there wasn’t any significant
> opposition and it looks like somebody added this page:  
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid
> 
>
> Thank you!
> I’ll add the preset to iD and we can consider this one closed 
>
>
>
>> On Jun 11, 2018, at 12:08 AM, Bryan Housel > > wrote:
>>
>> I was looking
>> at https://wiki.openstreetmap.org/wiki/Key:emergency today.
>>
>> Can we add a tag for `emergency=first_aid_kit` ?
>>
>> thanks, Bryan
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=first_aid_kit

[Simon Poole]

I'm actually not quite happy with the whole thing as it would seem to
range from a potentially staffed first aid facility to what you were
looking for, a simple first aid kit. In practical terms that would be a
rather big difference that should be reflected in the tagging.

Simon


Am 20.06.2018 um 19:51 schrieb Bryan Housel:
> I guess `emergency=first_aid` seems fine (since it aims to replace the
> barely used `amenity=first_aid`)
>
> I agree the page looks like a rough draft, but the infobox looks
> pretty good.  Thank you for volunteering to clean it up!
> It should probably be a feature that sits on points only (like
> `emergency=defibrillator`) - the “shop outline” stuff doesn’t make sense.
>
> Thanks, Bryan
>
>
>
>> On Jun 20, 2018, at 1:46 PM, Simon Poole > <mailto:si...@poole.ch>> wrote:
>>
>> Not to mention first_aid vs first_aid_kit what it is supposed to be now?
>>
>>
>> Am 20.06.2018 um 19:40 schrieb Simon Poole:
>>>
>>> If I may say so the page seems a bit weird.
>>>
>>> Name on a first aid kit? Draw an area around the shop outline?
>>>
>>> Assuming that are simply C errors, I'll fix things in nobody has
>>> any objections.
>>>
>>> Simon
>>>
>>>
>>> Am 20.06.2018 um 19:31 schrieb Bryan Housel:
>>>> Just following up after a week - there wasn’t any significant
>>>> opposition and it looks like somebody added this page:  
>>>> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid
>>>> <https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid>
>>>>
>>>> Thank you!
>>>> I’ll add the preset to iD and we can consider this one closed 
>>>>
>>>>
>>>>
>>>>> On Jun 11, 2018, at 12:08 AM, Bryan Housel >>>> <mailto:bhou...@gmail.com>> wrote:
>>>>>
>>>>> I was looking
>>>>> at https://wiki.openstreetmap.org/wiki/Key:emergency today.
>>>>>
>>>>> Can we add a tag for `emergency=first_aid_kit` ?
>>>>>
>>>>> thanks, Bryan
>>>>>
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org <mailto: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 <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD presets

[Simon Poole]

Just a couple of comments:

- both the JOSM and Vespucci default presets are in general under a lot
less pressure and in the end less scrutiny than iDs because they are end
user replaceable and extendable. Naturally the choices made by the devs
still affect tagging, including, oops, errors.

- I suggested a common system for preset storage and generation for GSOC
two years back there wasn't very much uptake of the idea, and at least
one rather hostile reaction. At that time it seemed reasonably viable,
I'm not so sure now, given the way iD presets have evolved. 

- I'm going to do a talk on Presets at SOTM this year (not focused that
much on the topic at hand, but will surely touch on all of the above)

Simon

Am 20.06.2018 um 09:17 schrieb Mateusz Konieczny:
> 19. Jun 2018 21:51 by o...@imagico.de :
>
> If i read you correctly you are unwilling to
>
> * establish verifiable principles for decisions about tagging
> presets in
> iD that limit use of presets to push subjectively preferred tagging
> ideas against existing widely accepted practice.
> * modify iD to allow for more diversity in tagging presets used by
> mappers (for example by offering presets available in JOSM as an
> alternative).
> * refrain from connecting tagging discussions you start here to iD
> preset decisions - including use of your decision power as
> leverage in
> discourse, like with
>
>
> I think that this concerns are valid, though I would not mix it with claim
>
> that editor developers controlling presets is wrong.
>
>
> There is no real alternative, there is no an independent general preset,
>
> and I would not expect to suddenly find people willing to maintain one
> in a
>
> long term.
>
>
> Especially after excluding developers of editors.
>
>
> There is https://github.com/simonpoole/beautified-JOSM-preset but it is
>
>
> - controlled by editor developer anyway
>
> - has nearly no activity from people that are not developers of
> editors using it
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=first_aid_kit

[Simon Poole]

Not to mention first_aid vs first_aid_kit what it is supposed to be now?


Am 20.06.2018 um 19:40 schrieb Simon Poole:
>
> If I may say so the page seems a bit weird.
>
> Name on a first aid kit? Draw an area around the shop outline?
>
> Assuming that are simply C errors, I'll fix things in nobody has any
> objections.
>
> Simon
>
>
> Am 20.06.2018 um 19:31 schrieb Bryan Housel:
>> Just following up after a week - there wasn’t any significant
>> opposition and it looks like somebody added this page:  
>> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dfirst_aid
>> <https://wiki.openstreetmap.org/wiki/Tag:emergency=first_aid>
>>
>> Thank you!
>> I’ll add the preset to iD and we can consider this one closed 
>>
>>
>>
>>> On Jun 11, 2018, at 12:08 AM, Bryan Housel >> <mailto:bhou...@gmail.com>> wrote:
>>>
>>> I was looking
>>> at https://wiki.openstreetmap.org/wiki/Key:emergency today.
>>>
>>> Can we add a tag for `emergency=first_aid_kit` ?
>>>
>>> thanks, Bryan
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto: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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple offices at the same address - (Multiple values for one key)

[Simon Poole]

IMHO three nodes is the solution, add level tags if they are not on the
same floor.

If the address was on the building polygon duplicating the address
information on the POI would not be necessary, but knowing Dutch
numbering schemes, that likely doesn't make sense.

I consider this problem slightly different to the normal one object that
has multiple top level attributes issue, as this is clearly the case of
multiple separate objects sharing common sub tags which I don't really
consider a big problem (assume for example one of the offices moves, the
office node in question can simply be  moved to the new location and
address changes, history preserved. easy to do  for beginners and so on).

Simon

Am 26.10.2017 um 17:01 schrieb Marc Zoutendijk:
> Hi all,
>
> Recently I discovered a tagging where at the same street address and
> house number, 3 different (although related) companies  are located. 
> Because adding multiple values to the same key is not easy to do in
> OSM, (mostly used for adding more telephone numbers, separating the
> numbers with a semicolon), and in this case the mapper had chosen to
> simply add three nodes and duplicate all the relevant address tags.
> Because all three companies had an office=research tag and because the
> office tag is not rendered at all on the standard map(!!) but only
> shows the addr:housenumber (when present), the above described tagging
> resulted in showing 3 times the same address node on the map. Which by
> definition is wrong because a given street address (addr:city +
> addr:street + addr:postcode + addr:housenumber) _must be unique_ - at
> least in the country (The Netherlands) where I live and where I found
> this situation.
>
> In The Netherlands _all_ buildings and the related address nodes were
> (and still are) imported in a huge import (BAG) which was discussed
> years ago and also presented in a wiki:
>
> http://wiki.openstreetmap.org/wiki/BAGimport
>
> Dutch mappers usually add POI information (like a shop, restaurant,
> hotel etc. ) to an existing address node and usually this works well,
> except when we face the situation where more objects share that very
> same address. E.g. it is not uncommon to have a hotel and a bar share
> the same building and address. In this case the hotel is added to the
> (existing) address node and a new node is created for the bar, but
> without the address information and this node is simply put within the
> contour of the hotel building.
>
> The situation I’m describing here, with 3 research offices all sharing
> the same address would (could?) lead to tagging like this:
>
> addr:street=streetname
> addr:housenumber=X
> office=research
> name=“name of first office”;”name of second office”;”name of third office”
> webiste=“website-1”;“website-2”;“website-3”
> phone=“phonenumber-1”;“phonenumber-1”;“phonenumber-1”
>
>
> Which wouldn’t be my choice of solving this problem, suppose the
> values for office would differ as well, this would give even more
> complicated tag combinations. Maintaining/checking it would be cumbersome.
> How to render this mess?
>
> Other solutions have been presented over the years in various wikis,
> forums and mailing-lists, but a satisfactory solution still has to be
> found, hence my question to continue reading and study this proposal
> that was done in 2011:
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress
>
> I wrote the mapper who proposed this a PM and he replied with the
> message that he is no longer very active on OSM.
> I have used this proposed relation for the tagging of the 3 named
> offices here:
>
> http://www.openstreetmap.org/relation/7676306
>
> Of course because this is an unsupported type of relation, nothing
> shows on the map, save the (one) house number, but here you can see
> the situation as it was before I added my changes:
>
> https://marczoutendijk.stackstorage.com/s/vgHPvYALM4p7n6t
>
> With tools like OpenPoiMap you can see some results, but because the
> address tags are removed you have to guess that those 3 offices share
> the same address:
> http://openpoimap.org/?map=various=18=52.81317=6.39542=B00TFFF
>
>
> I must say that this way of tagging (with a relation) looks quite
> clear to me, is easy to do and opens up many possibilities. But is it
> easy to render once accepted? 
>
> Hence:
>
> 1. Should we continue and discuss and finally vote for the proposal
> mentioned above?
> 2. Can you think of another solution for this specific problem: “how
> to map/tag multiple (sometimes even not related) objects to the same
> (one) address node?”
>
> Thanks for any input,
> Marc.
>
>
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] Nonbreakable spaces in name tags

[Simon Poole]

IMHO we should in general treat all unicode space variants as a nomal
ASCII space for processing and comparision purposes and leave it at that.

And we don't have the issues just in name tags, see

SKIP :
{
  "\r"
| "\n"
| " "
| "\t"
| "\u200A"
| "\u2009"
| "\u00A0"
| "\u2008"
| "\u2002"
| "\u2007"
| "\u3000"
| "\u2003"
| "\u2006"
| "\u2005"
| "\u2004"
}

from my OH parser.

Simon


Am 31.01.2018 um 16:25 schrieb Matej Lieskovský:
> So... can we reach some conclusion?
>
> I have a particular situation I need to resolve - some streets consist
> of ways that (among other, meaningful differences) vary in their usage
> of non-breakable spaces. Here are the possible solutions:
>
> 1) Start removing nbsp from local data
> 2) In case of conflict, prefer the variant without nbsp
> 3) In case of conflict, choose the more common variant
> 4) In case of conflict, prefer the variant with (correctly placed) nbsp
> 5) Start adding nbsp to local data
> 6) Leave things as they are
>
> To be perfectly honest, unless we can agree on whether nbsp should be
> encouraged or removed, I will use option 4. Option 6 (status quo) is
> pretty much the worst of both worlds, 5 is undeniably adding nbsp to
> the data (and too much work for now), and an eventual conversion from
> anything to 1 is trivial (which does not work for converting from 2 or
> 3 to 5). Since option 4 at least makes entire streets have the same
> name without loss of data or adding nbsp to streets that are ok so
> far, I consider it to be the best compromise in case of no consensus.
>
> Matej Lieskovský
>
> PS: I am starting to suspect that we might need a wiki page concerning
> Unicode usage in general (nbsp, soft hyphens, roman numerals,
> normalisation...). The link below does seem a little underwhelming:
> https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
>
> On 27 January 2018 at 01:50, Johnparis  wrote:
>> HTML has  for non-breakable spaces (Unicode U+00A0).
>>
>> HTML has  for soft hyphens (Unicode U+00AD).
>>
>> --
>>
>> Message: 2
>> Date: Fri, 26 Jan 2018 23:04:32 +0100
>> From: Richard 
>> To: "Tag discussion, strategy and related tools"
>> 
>> Subject: Re: [Tagging] Nonbreakable spaces in name tags
>> Message-ID: <20180126220432.GA10615@rz.localhost.localdomain>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> On Fri, Jan 26, 2018 at 03:48:42PM +0100, Matej Lieskovský wrote:
>>> Greetings!
>>>
>>> Several Slavic languages have rather formal rules about line breaks.
>> the problem is much broader, sooner or later OSM rendering will hit word
>> splitting.
>>
>>> PS: The rules are formal enough that there exists a 1997 program
>>> "Vlna" ("Tilde"), that can add nonbreakable spaces to TeX source files
>>> and is commonly used for important documents.
>> probably not all OSM languaes have such tools and even if they have it can
>> be tricky to determine which language rules to apply.
>>
>> I would think..
>> * if someone wants to use nonbreakable spaces he should be allowed to do
>>   so and tools should tolerate it (not necessarilly understand but not
>>   break)
>> * if someone wants to use explicit word-split marks/soft-hyphens
>>   this should be somehow allowed too.
>>
>> Otherwise the software should try to do its best and apply heuristics to
>> avoid
>> splitting lines in wrong places.
>> Not splitting 1000 034 should be obvious, roman numbers as well. Prefer not
>> splitting around "lonely" characters.
>> The rendering software can also compare texts with name tags and prefer not
>> to split names at all.
>>
>> Richard
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Nonbreakable spaces in name tags

[Simon Poole]

Am 31.01.2018 um 19:33 schrieb Simon Poole:
> IMHO we should in general treat all unicode space variants as a nomal
that should have been "normal"




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lane geometry in OSM

[Simon Poole]

Am 03.08.2018 um 16:30 schrieb djakk djakk:
> I think it is less verbose. 
>
That isn't necessarily a positive (just as in programming languages).

> There can be multiple ways to express something in osm, like in the
> Ruby language ?
>
While that is certainly the case in OSM, introducing alternative tagging
just to make things difficult is likely not going to make anybody happy.

Simon

>
> djakk
>
>
> Le ven. 3 août 2018 à 16:21, Marc Gemis  > a écrit :
>
> while this might work, why would you try to replace an established
> tagging system ?
> The tagging system turn:lanes:xxx is  supported by several data
> consumers (OsmAnd, maps.me , MagicEarth and
> probably others).
> In many countries people worked on tagging all roads with this system
> after a project set up by the German community.
>
> m.
> On Fri, Aug 3, 2018 at 4:10 PM djakk djakk  > wrote:
> >
> > Hello !
> >
> > What about a tagging method like this :
> >
> > lanes=3
> > lane_2=forward_direction;left_turn
> >
> >  or
> >
> > lanes=3
> > lane_2:direction=forward
> > lane_2:turn=left
> >
> >  instead of
> >
> > lanes=3
> > lanes:forward=2
> > turn:lanes:forward=left|through
> >
> >  ?
> >
> >
> > djakk
> >
> >
> >
> >
> >
> > Le ven. 3 août 2018 à 13:13, Lionel Giard
> mailto:lionel.gi...@gmail.com>> a écrit :
> >>
> >> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a
> suggested way of tagging (in "Examples/Motorways") is using letter
> to indicate which lane goes to where (when there is a transition).
> This could be used to extent the width tagging for transition lane
> (where one lane split to two (or conversely). There are already a
> lot of possibility to tag detailed lanes, but we could indeed add
> the width in it !
> >>
> >> PS: sorry for the previous message, i miss-clicked.
> >>
> >> 2018-08-03 13:08 GMT+02:00 Lionel Giard  >:
> >>>
> >>> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a
> suggested w
> >>>
> >>> 2018-08-02 23:56 GMT+02:00 Tom Hardy  >:
> 
>  I've experimented a bit with lane and road attributes as in
>  https://www.openstreetmap.org/way/505256201 and the adjoining
> intersection.
>  No width, but number, function and placement of lanes.  For
> placement, I
>  always selected the center of the throughway.  This allows
> renderers that pay
>  no attention to lane attributes to render a straight line
> through an
>  intersection.
> 
>  JOSM's "Enhanced lane and road attributes" visualizer shows
> this quite well.
> 
>  --
>  Tom Hardy mailto:rhardy...@gmail.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
> >
> > ___
> > 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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

[Simon Poole]

Am 10.08.2018 um 20:19 schrieb Paul Allen:
>  Because if I'm in
> a strange location, looking at a map that labels a street "Foo Lane"
> that's what I expect to see on the sign.  Anything
> else is misleading and unhelpful.
Couldn't agree more.

Note: we do have "official_name" for identifying when s*** happens.


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging request: missing admin_level tags

[Simon Poole]

I would have to second this observation, this would seem to go exactly
against what we've tried to fix with multi-polygons (not to mention a
future area object type). Not to mention that a single way can be a
member of multiple different borders at different admin levels, so this
would seem to be a non-starter in any case.

Simon


Am 10.03.2018 um 09:14 schrieb Colin Smale:
>
> Matthijs,
>
> This goes against the principle of tagging the relation, not the
> members. An admin area is syntactically analogous to a multipolygon
> and it would be a shame to introduce yet another polygon tagging paradigm.
>
> What are you thinking for other types of
> boundaries? boundary=political, boundary=national_park come to mind.
> Will they be treated differently to boundary=administrative?
>
>  
>
> What do you intend exactly when you say "maritime boundaries"? That
> part of a (national) boundary which crosses water? Or some other
> definition?
>
> Colin
>
> On 2018-03-10 01:51, Matthijs Melissen wrote:
>
>> Hi all,
>>
>> OpenStreetMap Carto, the default stylesheet on openstreetmap.org, is
>> considering to change the mechanism for rendering admin boundaries.
>> The proposed rendering of admin borders will be based on admin
>> boundary ways rather than polygons. This has a number of advantages -
>> for example, it will make it possible to style maritime boundaries
>> differently.
>>
>> The admin boundary ways are already in the database. However, in some
>> cases they are missing an admin_level tag. When the proposed style
>> change will be deployed, boundary=administrative ways without
>> admin_level tag will no longer be rendered. I would therefore suggest
>> to make sure admin_level tags are present on all
>> boundary=administrative ways.
>>
>> A map showing admin boundary ways without admin_level tag (displayed
>> in gray) can be found here:
>> http://product.itoworld.com/map/2?lon=20.00736=51.92203=6
>> As can be seen, most countries already do have admin_level on ways.
>> However, in for example Poland, Iran and Australia, this data seems to
>> be missing.
>>
>> -- Matthijs
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wetap specific tags

[Simon Poole]

Am 23.03.2018 um 14:37 schrieb Volker Schmidt:
> No, obviously, not in the sense that we do that systematically, but
> the problem exists in real terms. Drinking water is in many places of
> the world one of hose pieces of information that would be nice to be
> able to tag: have been here today, it's still working. Petrol stations
> is another. Or in case of areas with low population density the fact
> that a food supply point is still operational can be of great interest
> (When I rode on bicycle the old Route 66 in 2016 one of the essential
> tasks of our group leader was to keep a checklist of food stores,
> water points, and accommodation, in order to keep the ACA route
> description up-to-date)
See https://wiki.openstreetmap.org/wiki/Key:check_date

Simon

PS: not quite sure why everybody time is being wasted discussing 4 year
old edits.

>
> On 23 March 2018 at 14:19, Martin Koppenhoefer  > wrote:
>
>
>
> 2018-03-23 14:09 GMT+01:00 Volker Schmidt  >:
>
> And this raises the obvious question: Do we have any way of
> tagging "tag value verified by survey today" ? This would be
> helpful in many situations. I am thinking about the repeated
> discussions about explicily tagging default values in order to
> underline that the value has been checked.
>
>
>
>
> Volker, do I understand you correctly that you propose to add a
> specific tag for every other tag which says when it was last
> checked? Like amenity=foo, amenity:last_survey=1985-04-01 ? So we
> must not add default tags because we can have a tag
> lanes:last_checked=2018-03-23 which implies that the number of
> lanes is default and must not be tagged explicitly?
> Sounds like a method to increase history bloat. I could check
> every minute that my house is still there, for example, and upload
> the result. ;-)
>
> 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



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD presets

[Simon Poole]

Btw, I've done some work on automatically generating presets from
taginfo in Vespucci 11 (going further than what iD does), and if you so
will the ultimate democratic presets, that I'll likely be touching on too.

Simon


Am 20.06.2018 um 11:41 schrieb Simon Poole:
>
> Just a couple of comments:
>
> - both the JOSM and Vespucci default presets are in general under a
> lot less pressure and in the end less scrutiny than iDs because they
> are end user replaceable and extendable. Naturally the choices made by
> the devs still affect tagging, including, oops, errors.
>
> - I suggested a common system for preset storage and generation for
> GSOC two years back there wasn't very much uptake of the idea, and at
> least one rather hostile reaction. At that time it seemed reasonably
> viable, I'm not so sure now, given the way iD presets have evolved. 
>
> - I'm going to do a talk on Presets at SOTM this year (not focused
> that much on the topic at hand, but will surely touch on all of the above)
>
> Simon
>
> Am 20.06.2018 um 09:17 schrieb Mateusz Konieczny:
>> 19. Jun 2018 21:51 by o...@imagico.de <mailto:o...@imagico.de>:
>>
>> If i read you correctly you are unwilling to
>>
>> * establish verifiable principles for decisions about tagging
>> presets in
>> iD that limit use of presets to push subjectively preferred tagging
>> ideas against existing widely accepted practice.
>> * modify iD to allow for more diversity in tagging presets used by
>> mappers (for example by offering presets available in JOSM as an
>> alternative).
>> * refrain from connecting tagging discussions you start here to iD
>> preset decisions - including use of your decision power as
>> leverage in
>> discourse, like with
>>
>>
>> I think that this concerns are valid, though I would not mix it with
>> claim
>>
>> that editor developers controlling presets is wrong.
>>
>>
>> There is no real alternative, there is no an independent general preset,
>>
>> and I would not expect to suddenly find people willing to maintain
>> one in a
>>
>> long term.
>>
>>
>> Especially after excluding developers of editors.
>>
>>
>> There is https://github.com/simonpoole/beautified-JOSM-preset but it is
>>
>>
>> - controlled by editor developer anyway
>>
>> - has nearly no activity from people that are not developers of
>> editors using it
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

Am 12.10.2018 um 18:37 schrieb Frederik Ramm:
> Hi,
>
> On 10/12/2018 12:54 PM, Tobias Knerr wrote:
>> I agree that this problem calls for a general solution, as it's not
>> specific to opening hours.
> ...
>
> Or can we afford to just skip mapping that detail?
>
It is all fine and dandy for us to abstractly discuss such things, it is
another to explain to Josephine mapper that no, the opening hours of the
shop you want to map are one character too long and you need to map less
detail. I just don't believe that "map less detail" is a concept that
you will be able to convey to a majority of contributors and trying to
do is likely futile.  The trend is simply the consequence of progressing
from the rough to the detailed.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

PS: an extension syntax has the advantage of not breaking downstream
consumers that are relying on maximum 255 char strings, which is
probably a valid concern. A max length change should probably wait in
any case till there are other data model changes (aka API 0.7 :-)) to
minimize the impact.


Am 12.10.2018 um 01:27 schrieb Simon Poole:
> We have a number of keys for which the values can easily exceed 255
> chars besides opening_hours, lane destinations and conditional
> restrictions are good candidates. Not to mention changeset tags. With
> other words it is a general problem which should be tackled with a
> general solution.
>
> One would be to extend at least the available space in the database
> for tag values, however that is a significant amount of work (see
> https://github.com/openstreetmap/openstreetmap-website/issues/1593)
> and I suspect it is unlikely to find support.
>
> The other way to address this would be to provide a general value
> extension syntax that editors and consumers could support for example
> say /key-/ext/-nnn  /The exact semantics would need to be determined
> (how to split and join long values) and the key syntax needs to be
> chosen to minimize possible conflicts.
>
> Simon
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Opening hours too long for OSM

[Simon Poole]

We have a number of keys for which the values can easily exceed 255
chars besides opening_hours, lane destinations and conditional
restrictions are good candidates. Not to mention changeset tags. With
other words it is a general problem which should be tackled with a
general solution.

One would be to extend at least the available space in the database for
tag values, however that is a significant amount of work (see
https://github.com/openstreetmap/openstreetmap-website/issues/1593) and
I suspect it is unlikely to find support.

The other way to address this would be to provide a general value
extension syntax that editors and consumers could support for example
say /key-/ext/-nnn  /The exact semantics would need to be determined
(how to split and join long values) and the key syntax needs to be
chosen to minimize possible conflicts.

Simon




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging