Re: [Tagging] [Talk-us] Trunk VS primary

[Wolfgang Zenker]

* Mateusz Konieczny 
> 21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
>> I suggest to keep the road classification consistent at least within
>> a country and try to solve the problem of roads in low-zoom maps at
>> the rendering level, by modifying the list of displayed road classes
>> until a target density of displayed roads is reached. That might
>> become easier to do when we move to vector tiles.

> Seems not doable with OSM data - this
> would require far more road classes
> than we use.

Why would we need more road classes for that? This would only be an
issue if the difference between two "adjacent" classes would be so big
that you would jump from "almost none" to "to many to display" in one
step.

> lane and surface data is also almost
> certainly not helpful here even with full
> coverage

> And it would result in weird transitions
> between countries.

Only if road density changes rapidly at the border, and then we would
just depict the weird transition that exists in reality.

I think it might be possible to upgrade the "minimum zoom level to
display" on a way if there are no already displayed ways in an area,
maybe only if it connects to an already displayed way (recursive).
That way we would boost the minimum zoom level of e.g.
https://www.openstreetmap.org/way/196509120 to zoom-level 11 or maybe
even 9, even with it being just a low quality dirt track going near an
obscure archaeological site in the middle of nowhere.

Wolfgang
( lyx@osm )

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

Re: [Tagging] [Talk-us] Trunk VS primary

[Wolfgang Zenker]

* Joseph Eisenberg  wrote:
> Above it was said that the highway=trunk vs highway=primary
> distinction is mostly for routing applications. But allowing a proper
> rendering is also a main goal of the road tagging system.

> While it's true that road class is useful for routing when there are
> two alterate routes, a main reason to tag highways with a certain
> class is to be able to render maps properly at different zoom levels.

> When you are making a high-scale, low-zoom-level map of a large area
> (say, the whole State of Alaska, all of England, or all of Australia),
> you will want to only render highway=motorway + highway=trunk, because
> showing all highway=primary would lead to rendering many smaller roads
> which are not reasonable to show at that scale in most places.

> [..]

What makes the problem of road classification so hard is that we want it
to do different things at once. For rendering we have on the one hand
the requirement that we want to show all the "relevant" roads for a
given zoom level, on the other hand, as a map user I would expect that
a road shown as e.g. trunk in Massachusets would be quite similar in
characteristics to a road shown as trunk in Montana.

I suggest to keep the road classification consistent at least within
a country and try to solve the problem of roads in low-zoom maps at
the rendering level, by modifying the list of displayed road classes
until a target density of displayed roads is reached. That might
become easier to do when we move to vector tiles.

Wolfgang
( lyx@osm )

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

Re: [Tagging] building typology vs usage

[Wolfgang Zenker]

* Dave F via Tagging  [190913 21:37]:
> On 13/09/2019 16:14, Wolfgang Zenker wrote:
>> That would be kind of redundant, wouldn't it? We already use other tags
>> for the current function of a building,

> I'm repeating much of my of my previous comment, but no, the schema 
> which hijacked building=* to represent the original historical function 
> of a building never took off*. The vast majority of contributors use it 
> for it's current purpose. OSM isn't for the mapping of redundant 
> historical information.

Well, I don't know of any hijacking. This thread is the first time I
have seen people suggesting to tag the current function only in the
building=* tag. But admittedly I'm only active in OSM since 2008, so
that might have happened before that or I might have overlooked it.

>> so building=* is mostly useful
>> when the uilding does look like it was built for some other function
>> than it's current one.

> How do you know what it was originally used for just from your 
> interpretation of what a building of a certain function should look 
> like? It's just guesswork. How does tagging this perception add to, or 
> improve the quality of the OSM database?

I don't care about the buildings original function but about what it
looks like. That might or might not match its original and/or current
function. And if it looks like a run-of-the-mill nothing-special any-
purpose-at-all type of building I tag it as building=yes.

> "OpenStreetMap is a place for mapping things that are both /real and 
> current/"

I agree. I recently mapped https://www.openstreetmap.org/way/722948688
"Howard School" in rural Montana. It is a historic building originally
built as a public school, looks like a fine specimen of a schoolhouse of
it's era, has a prominent sign saying "Howard School" on the front side
and so I tagged it "building=school" even when it has not been used as a
school since 1947 but is used since for community gatherings. So I also
mapped it's current function by adding amenity=community_centre.

Of course different mappers have different opinions about what would be
the best way to tag something, but I don't see this as a weakness but a
strength of OSM. By discussing what we individually think is best and
learning from each other we collectively will arrive at better tagging
by all over time.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] building typology vs usage

[Wolfgang Zenker]

* Joseph Eisenberg  [190913 16:45]:
> I certainly recall reading about this in the wiki, but I agree that in
> common use, the building=* tag appears to be used mostly for the
> current function, rather than specifying a certain form.

That would be kind of redundant, wouldn't it? We already use other tags
for the current function of a building, so building=* is mostly useful
when the building does look like it was built for some other function
than it's current one.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] Populated settlement classification

[Wolfgang Zenker]

* Iago Casabiell  [190907 18:29]:
> Exactly, so how do we solve this?

Very simple: By letting the people tag it that live there and have local
knowledge. They know what the place is called locally, and that usually
is based on a complex amalgamation of size, population, cultural,
economic and historical significance. And it is usually seen in relation
to other places nearby.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] map of international institutions, such as EU institutions in Brussels

[Wolfgang Zenker]

Hi,

* Robert Riemann  [190907 17:19]:
> I crosspost this topic from [OSM-talk-be] for its relevance in other areas of 
> the card. I suggest in this mail to agree on a tag or create a new tag.

> I would like to generate a map of EU buildings in Brussels similar to this 
> one: https://www.consilium.europa.eu/media/29697/qc0214964enn.pdf

> However, I noticed that many buildings are not tagged accordingly, but 
> instead 
> have only a POI.

> For this reason, I want to ensure that the surface itself is tagged, so that 
> with a query such as http://overpass-turbo.eu/s/M6o a map can be generated.

> Can you please advise me which tags should be used on building shapes and POI 
> to map EU institutions perfectly?

the buildings should be tagged according to their function, regardless
of who works there. You might have to use the operator key or invent a
new one if you want to tag that the building is used for a specific
operator, in this case the EU.

> [..] However, European Union offices are 
> spread over the entire world (including their permanent representations).

The permanent representations of countries to the EU and vice versa
should according to https://wiki.openstreetmap.org/wiki/Tag:office%3Ddiplomatic
be tagged as office=diplomatic, diplomatic=mission, country=,
target=EU for representation of a country to the EU; switch country and
target for a reprentation of the EU in a country.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] Verifiability wiki page: "Geometry" section added

[Wolfgang Zenker]

* Tobias Knerr  [190428 14:31]:
> On 28.04.19 13:51, Mateusz Konieczny wrote:
>> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
>> often have scattered houses and farms extending outward for several
>> kilometers. In this case the approximate center of the place may be
>> well-know, but the outer limits are not clearly determined,
>> so mapping as an area is not verifiable."

>> is a good description of a common situation. Are you claiming that it
>> never happens?

> I agree that this is a common situation. However, I'm claiming that we
> actually know _more_ than just the hamlet's center in that situation.
> There will often be houses that are well known to be part of that
> hamlet, and other houses (in fact, almost 100% of the world's houses)
> that everyone will agree are not part of that hamlet.

> So the world's houses and farms can be (somewhat simplistically) divided
> into 3 sets:
> A: Verifiably part of the hamlet.
> B: Verifiably not part of the hamlet.
> C: May or may not be part of the hamlet.

> In my opinion, verifiability is not a valid reason to stop people from
> attempting to map the sets A and/or B.

Let me suggest a way to map features with "fuzzy" borders based on A and
B as defined above: We could use a relation that contains one ore more
objects (nodes/ways/relationjs) that are "inside" or "part of" our
feature and zero or more objects that are "near by but outside" our
feature. Features defined in this way could be used for basically two
things only, labelling that feature on a rendered map, and searching for
objects "in" or "near" that feature (where "in" and "near" could return
the same result, as the exact border is "fuzzy" anyway).
Examples: A valley could have a river or stream "inside" and maybe
another river at its mouth or mountains around it as "nearby but
outside". A mountain range could have some peaks "inside" and maybe
valleys outside.
The most difficult thing here is probably finding a good name for that
relation type and for the "inside" and "near by but outside" roles.

Wolfgang

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

Re: [Tagging] Facts and opinions

[Wolfgang Zenker]

* Bryan Housel  [190107 16:12]:
> And on “the wiki”, I have basically given up on the OSM wiki [..].
> If something is “not documented on the wiki” that means nothing because the 
> wiki is not documentation.

That sounds kind of weird, because the Wiki basically only exists to be
used for documentation of the OpenStreetMap project. Care to tell us
where you would expect to find documentation? And by documentation, I
mean things like explaining concepts, how to do and not do things,
examples, etc.
Taginfo supplies only a tiny subset of what mappers need as documentation,
so where to get the rest if not the Wiki?

Curious,
Wolfgang
( lyx @ osm )

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

Re: [Tagging] Can OSM become a geospacial database?

[Wolfgang Zenker]

* Eugene Podshivalov  [181209 12:34]:
> вс, 9 дек. 2018 г. в 14:10, Marc Gemis :

>> We have tags for that (waterway=stream, ditch, ... / amenity=school,
>> college, university, kindergarten), I don't understand why we should
>> change the usage of name for that.

> How would you map American "streamlet", "brook", "creek" and "river" to the
> two generic "stream" and "river" in OSM?
> Currently they are just putting in the name field, so the only ways to fide
> all "brooks" is by searching the name fields which is not a proper database
> approach.

Most probably you would not want to look for all "brooks", because
"brook" is just one of multiple words that mean the same thing. There is
no semantic difference between a "brook" and a "stream" in general
nowadays. Its just that in different regions of the english speaking
world different words were commonly used, and people in America used
whatever word they were familiar with.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] iD Editor - unclear translations ( QA ) - 2018Oct

[Wolfgang Zenker]

Hi,

* Imre Samu  [181006 12:43]:
> the google  sheet is not perfect
> better link for view:
> https://docs.google.com/spreadsheets/d/1DNNuPjjnp6oOXLS2Wtrn__NdCtFN7wy7Lvdm7K1bES0/edit?usp=sharing

thanks for sharing this. This does highlight not only translation
problems IMHO. While there are some cases like amenity=bank vs.
amenity=bench that could be solved by a more specific word for one or
both in translations (e.g. German "Sitzbank" for bench) there are other
cases that point to tags that are too specialized (e.g. shop=fashion vs.
shop=boutique vs. shop=clothing), differentiate based on a specific
cultural context that does not exist everywhere (e.g. landuse=churchyard
vs. amenity=grave_yard vs. landuse=cemetery), or are simply not well
designed (e.g. natural=wood vs. landuser=forest).
The identical translation for X in a context of amenity=X vs. building=X 
would be not a problem IMHO, as the building tag would be a secondary
tag usually.

Wolfgang
( lyx @ osm )

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Wolfgang Zenker]

Hi,

* Joseph Eisenberg  [180927 13:10]:
> Re: do “the current
> proposals would mean that any POI (not referring to a government
> building) in Brussels needs to be retagged to name:XX or add
> default:language:XX (?)

> There are no mandatory tags in OSM, nothing needs to be retagged. But there
> would be the option to add
> default:language=fr to a shop in Flanders which has a name in French. This
> would help database users know that this shop name is in French rather than
> Flemish. I believe this will be very useful, and I think mappers will enjoy
> the chance to add the extra tags where necessary. Mapping is a bit
> addictive, right?
> [..]

this is one of the points where I have the impression that we are not
all talking about the same problem. For me a "default value" is a value
that is to be assumed if no specific value is available. So for me a
tag containing the word "default" would imply that it does NOT apply to
the object with that tag itself. If there is a default:language=XX tag
on an admin boundary, I would - by looking at the name of that key -
assume this is the language for things inside that admin boundary unless
these "things inside" specify a different language for themself. But I
would expext e.g. a POI within that area that uses a different language
to have a language=XX tag, not a default:language=XX tag.

Wolfgang

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Wolfgang Zenker]

* Christoph Hormann  [180926 20:43]:
> On Wednesday 26 September 2018, Wolfgang Zenker wrote:
>> it appears to me that before discussing possible solutions we should
>> better agree on what the problem is. So far I see several related but
>> different problems mixed into one and consequently no possible
>> agreement on the solution.

> I summarized the advantages of the proposed approach (in the variant 
> with a format string which is slightly different from the proposal 
> discussed) in

> http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/

> The aim is ultimately to:

> * allow mappers to accurately document information on names of features 
> in all situations that might exist world wide where there are 
> verifiable names with as little effort and in the least error prone way 
> as possible.
> * allow data users to interpret this data without constraints due to 
> intransparent preprocessing performed by the mappers.

I'm not sure that all the participants in this discussion and all the
supporters of the draft proposal (and previous proposals) do really
agree on the ultimate aim of that proposal. Hence my suggestion to
explore the problem space first and find out what problem(s) different
people try to solve with that proposal, then identify the constraints
that reduce the possible solutions space and the "nice to have"
properties that we'ld like to see in the solution.
Looking at the result of that second phase we can then decide which
problems can be solved together in one proposal and which problems
should be solved independently. And only after that it makes sense
IMHO to propose a solution.

>> d) If there are names in multiple languages combined to form the name
>>tag in case a, I want to know how to split a given value into the
>>component languages.

> That would be kind of the inverse to the method proposed here.  Parsing 
> the existing aggregate name tag based on additional format information 
> tagged would be fairly complicated, very fragile and hard to maintain 
> in the databse.  Several proposals have been made to tag which language 
> the name tag contains:

> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information
> https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name

> but this only covers the single language case and would only have 
> addressed a very small fraction of the naming problems in OSM.

It's true that the proposal at the head of the discussion covers mostly
my case e), and d) would be the inverse, but you yourself mentioned the
idea to use language information to control speech synthesis for audio
output of names, and the information on which part of the name tag was
in which language would of course help with that.

One problem that I forgot in my list but now remember having been
mentioned in the discussion is
f) I want to know which language(s), if any, are "official" in a given
place (which might be different from both the spoken language(s) and
the language(s) used on name signs).

About the "second phase" I mentioned above, identifying "constraints"
and "nice to haves", this is of course not a clear cut distinction
between the two but more of a continuum. Two give a few examples of what
I have in mind here:
- The proposal MUST NOT alter the meaning of established tags.
  This would be a hard constraint.
- The proposal SHOULD NOT require adding a lot of redundant data to the
  database.
  This would be a constraint, but someone might have an idea why it
  would be justified to break that constraint and maybe he manages to
  convince the rest of us that it would indeed be a good idea.
- The proposal SHOULD NOT require that mappers change their tagging
  (constraint) but SHOULD enable editor software to help mappers to
  create better name tags (nice to have)

I'm afraid that a discussion were everyone has hir own implicit
definition of the problem in mind without writing down what problem
exactly we are trying to solve, and with people disagreeing based on the
constraints that they have in mind without the others in the discussion
knowing what these are, is doomed to failure.

So, I repeat my suggestion that before we try to agree on solutions, we
should find agreement on what the problems are that we try to solve.

Wolfgang

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Wolfgang Zenker]

* Christoph Hormann  [180926 17:53]:
> On Wednesday 26 September 2018, Frederik Ramm wrote:
>> On 26.09.2018 16:14, Christoph Hormann wrote:
>>> Also in Germany we have features with no German name (most notably
>>> probably in regions with significant minority languages but also
>>> for example some English shop names, Italian restaurant names etc.)

>> You are not *really* advocating that when passign an Italian
>> restaurant called "O sole mio" I am expected to tag this with name:it
>> and not give it a proper name tag, are you? Because then I'll
>> promptly point you to a series of places that have a name the
>> language of which is not discernible...

> Yes, indicating that the name of an Italian restaurant in Germany is in 
> Italian can be fairly useful [..]

> Note nothing terribly bad would happen for most applications if someone 
> would incorrectly tag an Italian restaurant name as a German name of 
> course.

> Names in a non-discernible language have so far not been discussed.  I 
> would need to see some examples for this to form an opinion on the 
> matter.  

>>> The whole point of a concept like the one proposed here is to have
>>> a unified system that transparently covers all cases

>> Yes. The unified system goes as follows:

>> "If the default language of the smallest admin boundary enclosing
>> your feature is xx, treat any name tag you encounter as if it was a
>> name:xx tag."

> That would change the meaning of the name tag which is currently "the 
> locally used name or names in some combination" into something 
> different.  This seems very unlikely to happen for a tag with such 
> widespread use.  What you seem to be saying is that this already 
> happens to be the meaning of the name tag in Germany for >90 percent of 
> the names so you don't want the inconvenience of changing it for either 
> the few percent where it is not or to ensure a common tagging system 
> with the rest of the world where this is often much more widely not the 
> case.

> I see your point but as said this would defeat the whole purpose of the 
> idea and would further reduce the chances of it getting widely 
> implemented.  [..]

it appears to me that before discussing possible solutions we should
better agree on what the problem is. So far I see several related but
different problems mixed into one and consequently no possible agreement
on the solution.

The problems I have picked up from the discussion:
a) as a data consumer I want to know the language(s) for a given name tag
b) as a data consumer and as a mapper I want to know which language(s)
   is/are commonly spoken in a place
c) as a data consumer and as a mapper I want to know which language(s)
   is/are ususally used on name signs in a place
d) If there are names in multiple languages combined to form the name
   tag in case a, I want to know how to split a given value into the
   component languages.
e) If names in multiple languages are used together in case c, I want to
   know how to construct the name tag from the component name:xx values.
f... all the points I have missed/forgotten/ignored/...

Wolfgang

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

Re: [Tagging] Access by permit

[Wolfgang Zenker]

Summary first: This looks very good to me, and I think it is in line
with the discussion here in the last few days. I support this.

* Kevin Kenny  [170920 20:39]:
> The last few messages in this thread seem to have quieted much of the
> discussion.  Let me summarize my position, and see if we've achieved
> rough consensus.

> access=permit (and (transport mode)=permit):

> Symbolizes that the landowner requires permission for access, but
> has a policy that grants access to members of the public provided
> that certain formalities are observed.

> Ordinarily this tag will be accompanied by an 'operator=*' tag and
> one or more tags giving contact information (phone=*, fax=*,
> email=*, etc.) and/or an address in the Karlsruhe schema. If the
> contact information for the person or agency that administers
> permission is different from the main contact for a location, way
> or area, or if the address of the permitting person or agency is
> not the physical address of the site, then the tags may be
> prefixed with 'permit:': that is, permit:phone=*, permit::fax=*,
> permit:email=*,permit:addr:*=*, etc.

> At least in some locales, 'permit' is distinguished from 'private'
> in that 'private' areas are at best unknown and at worst allow access
> only to parties with a prior business relationship with the landowner.
> The fact that there is some formal process for obtaining permission
> is useful information at the early stages of trip planning. It is
> distinguished from 'yes' in that one cannot simply arrive at the
> site and expect to access it. Grouping it under 'yes' violates
> the cultural assumptions of at least a significant set of OSM users,
> and grouping it under 'no/private' does the same.

> If details of permit administration are observable on the ground, we
> can work out ways to map them. In the common situation that I have
> observed around me (and I've seen it with properties belonging to New
> York State, several municipal governments, Nature Conservancy, Open
> Space Institute, and several private conservancies), the common
> phrasing on signs is: 'Access by permit only. For information contact:
> [...]' (as opposed to the 'POSTED: No Trespassing' that denotes
> access=private). Since what is ordinarily visible on the ground is the
> signage forbidding unpermitted access (but implying that permission is
> routinely granted), that's the information that I propose to map.
> Since ordinarily I do NOT see details of the permit regime in the
> field, I do not propose any sort of schema for permit administration
> at the present time.

> Is this a minimal proposal that we can all tolerate?

I agree with both the suggested tagging as well as the rationale for
the proposed tagging.

> It would meet my needs for trail mapping. (On some maps, I'd wind up
> further dividing by 'operator' because, for instance, New York City
> access rules are already familiar to most of the intended users. But
> how I choose to render is between me and my users.)

> If it appears acceptable, I'll update the Wiki page and post a summary
> on the 'talk' page.

Please do so.

> Beyond that, this is the first proposal I've made here that seems
> to have enough traction to go forward. Can someone help me with
> the formalities for the voting process, assuming that we've achieved
> a rough consensus? I've not done that before.

Sorry, I have no clue about the voting process here beyond having voted
myself a few times.

Wolfgang

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

Re: [Tagging] siphon underpass

[Wolfgang Zenker]

Hi,

* Volker Schmidt  [170608 15:40]:
> I am looking into how to tag a frequent feature in my area, i.e. a siphon
> underpass, known in Italian as "botte a sifone" or "botte sifone" and in
> French as "pont siphon". This is a non.connecting waterway crossing where
> the lower waterway passes through a U-shaped siphon. The bottom part of the
> U is a tunnel that is lower as the normal level of the waterway.
> [..]
> I could not find any tagging schemes for this in OSM, but I may have missed
> them in ignorance of the proper technical terms.

in German this is called a "Düker". Unfortunately there does not seem to
be a special term for this in English; all translations that I could
find used "culvert". I would tag it as tunnel=culvert and suggest to use
a subtag to specify that it is a special type of culvert, like
culvert=syphon or similar.

Wolfgang


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

Re: [Tagging] Quonset hut

[Wolfgang Zenker]

* Michał Brzozowski  [170413 16:41]:
> I don't see how going from "typology" you conclude it's strictly about
> form. Typology is about types, not saying with respect to what.
> When you look at top building values in Taginfo, it's clear to me
> these state purpose (house, residential, garage, apartments,
> industrial, school and so on), with only exception being hut, other
> non-purpose values from the first page are in fact non-buildings
> (roof).

I'm in between here: building typology would depend on the original
purpose of the building, but that would not necessary still be the
current purpose of the building. So, if a building had originally
been constructed as a church and is built in the style of a church,
but is now used as a restaurant, it would be tagged amenity=restaurant,
building=church.

Wolfgang
(lyx@osm)

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

Re: [Tagging] Railway: Preserved or historic or railway:preserved?

[Wolfgang Zenker]

* Volker Schmidt  [170412 07:54]:
> Any active passenger railway is, among other usages, for tourism. So
> usage=tourism seems to be redundant.

I think usage=tourism is used for railways that are used only for
tourism like rail excursions, dinner trains etc.

Wolfgang
(lyx@osm)

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

Re: [Tagging] Railway: Preserved or historic or railway:preserved?

[Wolfgang Zenker]

Hi,

I'm not a railway expert, but like to comment anyway.

* Dave F  [170411 23:41]:
> I've a length of railway track that runs along part of a disused line. 
> It's not connected to the current network & run purely for tourism.

Well, the track IS operated, so the fact that it used to be part of
a larger network is less important than its current condition.
So I would tag the track railway=rail with the usual additional
tags for name, operator, gauge etc.
It is used purely for tourism, so usage=tourism would be added.
Now I would look at the inventory of that line: Do they still use
historic equipment, maybe from the time when this used to be part of a
larger network? If so, historic=railway would be tagged. Are the tracks
and signaling still preserved from the days of the old network or have
they been renewed with current equipment? If preserved, add
railway:preserved=yes.

Wolfgang
(lyx@osm)

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

Re: [Tagging] Landuse for vacant lots

[Wolfgang Zenker]

* Shawn K. Quinn  [170312 23:51]:
> On 03/12/2017 04:42 PM, Tristan Anderson wrote:
>> What is the most appropriate landuse tag for vacant lots in urban areas?
>>  That is, land that was previously occupied by a house or other building
>> that has been demolished, no trace of the building remains, and the land
>> is currently overgrown or covered in untended grass.  In the past I have
>> used brownfield, but this is for land scheduled for redevelopment, which
>> is often not the case.

> Any of landuse=grass, natural=grassland, nautral=scrub, natural=wood
> depending on just how overgrown it is. Unless someone has a better idea?

As that land is apparently unused, how about NOT tagging any landuse
at all?

Wolfgang

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

Re: [Tagging] Mapping time zones as geometries (relations)

[Wolfgang Zenker]

Hi,

* Colin Smale  [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this. 

> We need to address reality; I suggest there are the following options: 

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone" 

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent 

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2 

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things. 

> What about maritime TZ boundaries that don't correspond to an admin
> boundary? 

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done. 

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

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

Re: [Tagging] How to tag beginning of a river

[Wolfgang Zenker]

Hi,

* Martin Koppenhoefer  [170225 14:23]:
>> On 25 Feb 2017, at 12:16, Dave F  wrote:

>> Won't the first node of the named way that's most upstream indicate its 
>> start point by default?

>> What advantages will adding a specific 'it starts here' tag bring?

> it would be an explicit way to tag the beginning, otherwise you can't tell 
> whether the start of a river in OSM is also the start of the actual river, or 
> if there are missing parts in OSM.

I usually leave a note "FIXME: stream continues, needs to be mapped"
or similar at the end node of streams or rivers that I map and have
not yet mapped to completion.

Wolfgang

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

Re: [Tagging] self-service laudry machines a camp and caravan sites

[Wolfgang Zenker]

* John Willis  [170219 09:53]:
>> On Feb 19, 2017, at 8:01 AM, Dave Swarthout  wrote:
>> +1
>> Regardless of the "intent" of OSM, this level of tagging does seem excessive 
>> IMO. I've been following the thread and am amazed that this much attention 
>> can be focused on developing tagging for washing machines. I guess the 
>> saying, Your Mileage May Vary, is the operative aphorism LOL

> Although I am personally not so interested in the machines, when the 
> laundromats are not mapped correctly (google maps and Apple maps was missing 
> the 4 closest coin laundry places to my residences when I searched so I added 
> them in both) it is very frustrating.

> If someone was looking to wash a giant bedspread or duvet, knowing there is 
> only one laundromat in town with a giant machine would be very useful.  

Then we might just tag the things that are useful. How about
laundry:oversize_items=yes|no|only ?

Wolfgang

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

Re: [Tagging] knotted willows

[Wolfgang Zenker]

Hi,

* joost schouppe  [170211 09:43]:
> One of the defining small landscape elements in Flanders (and probably many
> rural areas in Europe) is the "knotted willow". I'm not sure if this is the
> right term in English, in Dutch "knotwilg" really is a thing.

> How would you tag such a thing? (I could not find any previous discussions
> anywhere)

> natural=tree
> genus=Salix
> +
> management_style=knotted

> Or something like that?

> Apparently there's two words in Dutch:
> - knotwilg: knotted at about 2 meters high
> - grienden: knotted at a hight of maximum 50 cm

apparently english has words for these managements styles:
- "knotwilg" would be called "Pollarding"
- "grienden" would be called "Coppicing"

Wikipedia has pages on both.

Wolfgang

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

Re: [Tagging] Wrong use of landuse=village_green - but what else to use?

[Wolfgang Zenker]

* Marc Zoutendijk  [170108 21:02]:
>> Op 8 jan. 2017, om 20:20 heeft Tod Fitch  het volgende 
>> geschreven:

>> Based on usage in the United States, it sure sounds like leisure=park is the 
>> tag to use for what you are describing. I see nothing in the wiki page [1] 
>> for park that indicates it must be a minimum size, have a wall, a discrete 
>> entrance or that it has to have a name.  There are a lot of areas local to 
>> me called parks, that are tagged with leisure=park and which do not have 
>> fences/walls/or gates. And some of the smaller ones (colloquially called 
>> “mini-parks”) don’t seem to have names either.

> To me a park is some place that you gan "go into”. E.g." let’s go out for a 
> stroll in the park.”

> The wiki:

> "Typically open to the public, but may be fenced off, and may be temporarily 
> closed e.g. at night time.”

> But i’m talking also about the areas that you find also in the middle of a 
> roundabout.
> Adn I wouldn’t call an area of 14m2 between two sections of a highway, 
> covered with grass and some flowers a “park”.

> No, there really must be something better (I hope) to describe this sort of 
> landuse.

The process of creating and maintaining these green spaces would be called
"urban landscaping" as far as I know. Unfortunately I can't find a better
word for these areas than "green spaces".

Wolfgang

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

Re: [Tagging] Feature Proposal - RFC - Mountaineer's mailbox

[Wolfgang Zenker]

Hi,

* Kevin Kenny  [160906 20:38]:
> On Tue, Sep 6, 2016 at 2:20 PM, ksg  wrote:
>> The tag summit:register=* is not yet defined in the wiki, but is
>> widespread used in the Alps of Europe with > 600 instances.

>> https://taginfo.openstreetmap.org/keys/summit%3Aregister#values

> OK, that sounds good as well. Maybe still have some sort of tagging for the
> type so that we can show a letterbox as Mr Díaz de Argandoña requests?

> (As I said earlier, I'm unlikely to tag such a beast, because the clubs
> where I climb request that climbers not share coordinates of the registers
> or GPS tracks of the routes on the peaks without established trails.)

just to complicate things a bit further: I have seen some registers of
the "I was here" type inside caves, placed there to get an idea how many
people reach that particular part of the cave. summit:register would sound
a bit silly for those.

Wolfgang

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

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

[Wolfgang Zenker]

* Mike N  [160120 21:47]:
> On 1/20/2016 3:39 PM, Dominic Coletti wrote:
>> I see 808,000 uses of name_1 and 65,000 of name_2.

> Many of these are from the US TIGER import, and must not be 
> automatically removed.  They would go into alt_name , etc based on local 
> knowledge.

The problem with that is that TIGER just gives several names for
a way segment without prioritizing them. Sometimes you can identify
some as mis-spellings but in most cases it is impossible to decide
from TIGER data alone which name should be in the name tag and
which one should be somewhere else. Hence the name_x tags with name
and name_x which are for any x presumed equally important.

That could of course be fixed with local knowledge, because many
of these multiple names are simply wrong. We just don't know which
ones, and for most of the rural parts of the US we don't have any
local mappers (yet).

Wolfgang

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

Re: [Tagging] highway = track vs. residential

[Wolfgang Zenker]

* Mateusz Konieczny <matkoni...@gmail.com> [160109 13:12]:
> On Fri, 8 Jan 2016 10:50:37 +0100
> Wolfgang Zenker <wolfg...@lyxys.ka.sub.org> wrote:

>> * Tod Fitch <t...@fitchdesign.com> [160107 23:35]:
>>> My parents house is in a pretty rural part of Arizona and
>>> distinguishing between tracks and driveways or even residential
>>> roads can be difficult there. So my initial instinct was to say
>>> leave the ways in that part of Colorado as tracks as it can be hard
>>> to tell on the imagery.

>>> But looking at the satellite imagery in the area you linked, they
>>> clearly look like unpaved residential roads and dirt driveways.

>>> I’d leave the driveways in but change the tagging to:

>>> highway=service
>>> service=driveway
>>> surface=unpaved
>>> access=private

>> I would do almost the same, but would leave out the access=private,
>> as this is difficult to determine from the aerial imagery, and is
>> implied for service=driveway anyway.

> I would strongly dispute "implied for service=driveway anyway" - in
> some cases service=driveway is accessible for everybody, in
> many cases it is accessible at least for foot traffic.

I agree that at least in most of Europe it would usually be
access=destination rather than access=private. However, I don't
think that any routing engine should route through traffic over
service=driveway.

> In case of known access=private access it should be tagged explicitly.

I agree; but we were talking about "armchair mapping" and in
that case you usually would not know what access rights applied
on the ground, so you should not add an access tag based on a guess.

Wolfgang

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

Re: [Tagging] highway = track vs. residential

[Wolfgang Zenker]

* Tod Fitch  [160107 23:35]:
> My parents house is in a pretty rural part of Arizona and distinguishing 
> between tracks and driveways or even residential roads can be difficult 
> there. So my initial instinct was to say leave the ways in that part of 
> Colorado as tracks as it can be hard to tell on the imagery.

> But looking at the satellite imagery in the area you linked, they clearly 
> look like unpaved residential roads and dirt driveways.

> I’d leave the driveways in but change the tagging to:

> highway=service
> service=driveway
> surface=unpaved
> access=private

I would do almost the same, but would leave out the access=private,
as this is difficult to determine from the aerial imagery, and is
implied for service=driveway anyway.

> For the roads, clearly wider and serving multiple houses in the satellite 
> imagery and with names showing in the 2015 Tiger imagery, I’d tag them as

> highway=residential
> surface=unpaved
> name=(whatever the Tiger 2015 imagery says)

I would use highway=unclassified instead of residential as long as we
are not inside a settlement; the implied rules like default speed limits
tend to be different for inner-town roads and these rural roads and the
tagging should distinguish between these types of road as well.

Wolfgang

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

Re: [Tagging] Deprecating wikipedia Tag

[Wolfgang Zenker]

Hi,

* Thorsten Alge li...@thorsten-alge.de [150525 15:24]:
 Having the wikidata-tag enables an application to select the
 wikipedia-article in the language of the users choice or to easily load
 additional information from wikidata like a cities crest for displaying.
 The advantage would be that a user wouldn't get the German article
 because its a German object but the article in his preferred language.

well, due to Wikipedias interlanguage links, that's equally possible
with Wikipedia links. That's why our Wiki suggests to add only one
language version of the Wikipedia link and not multiple links.
As far as I can see Wikipedia articles usually link to the corresponding
Wikidata entry, so any application could get the same information
regardless of us providing a Wikipedia or a Wikidata link in the
OSM database.

Wolfgang

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

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

[Wolfgang Zenker]

I have placed a request to stop these edits on the users talk page and
warned him that I will ban him if this kind of working against the
community continues.
Please let me know if the problem continues, as I don't watch the tagging
list permanently.

Wolfgang

* Martin Vonwald imagic@gmail.com [150127 11:56]:
 Who has admin power in the Wiki? I again request a ban of this user.

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

Re: [Tagging] waterway=wadi problem

[Wolfgang Zenker]

* Mateusz Konieczny matkoni...@gmail.com [150114 15:45]:
 waterway=wadi is used (18 180 times) and has some support (for example JOSM
 and default map style).

 During implementing rendering of intermittent=yes I discovered major
 problem with this tag -
 the same waterway=wadi may be used for completely dried up waterway,
 intermittent stream, intermittent major river and intermittent ditch.

 Therefore - it seems that using waterway=river/canal/stream/ditch/drain +
 intermittent=yes is clearly superior to using waterway=wadi.

In my experience a wadi will go from completely dried up waterway or
small stream to a raging river within a few seconds after some
rainfall upstream, and back to its former self within a few hours.
Depending on the location, these rainfall events might very well be
a few years apart. When I tag an intermittent stream I usually
have something more benign in mind, like a stream that only exists
during the spring snow melt and is dry the rest of the year, but
maybe that is only my interpretation of an intermittent stream.

Wolfgang

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

Re: [Tagging] Dispute with user over changing wiki page

[Wolfgang Zenker]

Hi,

* Pee Wee piewi...@gmail.com [14 19:20]:
 I thought I just wait some days for other to reply but unfortunately no
 more then yours.  The question we still have is : What can we do? I suppose
 the DWG will only block when harm is done to the OSM database and not on
 any wiki pages. Anyone else for a recommendation as to what we can do?

the wiki admins can block changes to a specific wiki page with a strong
hint to please discuss changes on the mailing list or the talk page
before requesting an unblock of this page. Unfortunately your description
of the problem does not sound as if this would really help, though.

Wolfgang

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

Re: [Tagging] Tagging of topographic areas with a name

[Wolfgang Zenker]

Hi,

* fly lowfligh...@googlemail.com [130817 17:13]:
 On 16.08.2013 19:05, Masi Master wrote:
 Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
 not an area?

 Boundaries describe an area but you are right that they are not really
 boundaries, especially if the border lines are not clearly defined
 [..]

I'm under the impression this discussion is leading to ever more complicated
ideas, due to the problem that the features we want to name on the map
are not really clearly defined areas.

Maybe we should try a completely different approach. We could draw
a way along the approximate center line of the feature and tag it
with name=*, topo_feature=mountain_range|ridge|valley|...
A renderer that wants to display the name should draw it along that
way with the length of the way giving a hint about the size of the
feature.

Wolfgang

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

Re: [Tagging] pastry and confectionery

[Wolfgang Zenker]

* Murry McEntire murry.mcent...@gmail.com [130607 20:15]:
 [..]
 A summary as I understand it:

 We currently have English labels and definitions used for tags for bakery
 and confectionery that have language translation mismatches, especially
 based on common usage of the words.

 English cultures are comfortable using one term for shops of any type
 bakery goods (bakery), but continental Europeans are not. There may be
 regulatory reasons in Europe for not grouping them as a whole.

To broaden the perspective a bit:
All arabic countries that I have travelled to so far have the following
kinds of shop:
- shops that sell bread, often made on premises, and in a few cases also
  cookies and very simple kinds of pastry (basically sweet bread).
  If signs in english are used, these shops are signed as bakery
- shops that sell sweets but no cake, cookies or pastry
- small restaurants that offer (sweet) pastry, to eat in or take out, but
  nothing else (they never offer coffee or tea, so I wouldn't call them cafe)
- places that sell cakes and cookies (mostly takeout, no coffee etc.)
- places that sell coffee and tea, but usually no food. If there are signs
  in english, they usually read cafe or coffee shop

So, my conclusion here is that in the arabic world I would expect a bakery
to be a place selling mostly or only bread.

Wolfgang

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