Re: [Tagging] Topographic Prominence for Peaks

[Graeme Fitzpatrick]

On Mon, 24 Sep 2018 at 16:06, Joseph Eisenberg 
wrote:

>
> That’s why we need to check the height of saddles and peaks “by hand”, or
> better yet by survey with GPS.
>

Joseph, just a technical question, thanks, as I don't understand *any* of
the details of what you're wanting to do! :-)

How do you determine the height of the saddle / peak?

Do you sit there & say that that mountain peak is shown on my map as 4500m
& I'm about 300m down, so this saddle is 4200m?

& when you say survey with GPS, is that accurate enough for an altitude
reading? With my Garmin GPS (which admittedly is 10 - 15 years old, but
*wasn't* a cheap one!), I can calibrate it in the back yard at 6m ASL, go
for a day trip & when I get home, it displays the exact same spot as
anything between -5 & +30m ASL :-( When out driving, I've also seen the
altitude display change by 100s of m's instantly, when the road is
virtually flat.

Thanks

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

Re: [Tagging] Default Language Format; language:default or default:language?

[Joseph Eisenberg]

Should we change the tag from language:default to default:language?

I've found out that language:* has already been used in the format
language:de, language:fr, language:en, etc, for the languages taught at a
school. See
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlanguage_school. And
language=* has been used, though rarely.

There is also a page for default_language, which was made without going
through the proposal process. And there is a new proposal to specify all
"defaults" in the fomat default:subkey, though I have also seen this the
other way around, eg key:default, suggested for maxspeed.

I am not wedded to the current tag "language:default=". Please
respond here (or on the talk page) if you prefer default:language= or
default_language=, or if you prefer the current order.

Proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format

Talk page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format

Thank you,
Joseph

On Mon, Sep 24, 2018 at 9:36 PM Joseph Eisenberg 
wrote:

> Please see the Proposal page for the new tag, "language:default= code>"
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>
> Description:
> "Specify the default language format used for names, and recommend use
> of language-specific name tags.
>
> "By making it easier to use language-specific name:code=* tags to be
> used instead of the default name=* tag, this proposal will encourage
> the use of name tags that include the language code for all features.
> This will improve the quality and utility of the database. It will be
> possible to display non-Western languages in their correct orientation
> and script, properly display multilingual names, and to research the
> most commonly used language formats in a particular area.
>
> "The key language:default=* with a 2 or 3 letter ISO language code
> should be tagged on administrative boundary relations, such as
> countries, provinces and aboriginal communities. This is the language
> used for the majority of named features within a particular region, as
> indicated on public signs and in common use by the local community. If
> the language can be written in more than one script, a qualifier can
> be added to specify the script format. More than one language code can
> be listed, separated with a semicolon, if the local community uses
> more than one language on signs or by consensus.
>
> "The language tag should be applied to the largest boundary relation
> that accurately represents the language used for default names. When a
> smaller administrative boundary has a different default language
> format, this boundary should receive a language tag as well. This
> would include boundaries of provinces or aboriginal lands where a
> different language is used.
>
> "The language tag may also be applied to individual features when the
> name is in a different language than the default for the region, or
> when the feature crosses a border."
>
> Please read the whole page, which has quite a number of examples and a
> detailed rationale for the proposal, then please comment here or on
> the discussion page:
>
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>
> Thank you for all of your comments, criticisms and suggestions
> -Joseph
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

[Joseph Eisenberg]

The Proposal page lists a couple of other reasons under "rational:"

*1), 2)* Similar to your points a), and d)

*3)* It is not possible for renderers to properly render bilingual names
when one of the languages should be written in different directions

*4)* Localized and personalized maps, such as those used on smartphone apps
or those optimized for a certain language, cannot show the user's preferred
language as well as the locally preferred name. For example, the French map
style currently renders name:fr
=* when available. But this
loses the locally used name, which is likely to be found on signs, reducing
the utility of the map for orientation and routing. If the map attempts to
display both name:fr =* and
name =* together, this will
lead to rendering the French name twice, when French is included in the name
=*, for example in Morocco or
for mountains on the border with Italy. (See the table below for examples,
in the third column)

*5)* [Similar to b) and d]
Joseph

On Thu, Sep 27, 2018 at 1:48 AM Wolfgang Zenker 
wrote:

> * 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

[Joseph Eisenberg]

While it is a good idea to address the issues around name=* and name:=*
tags, this proposal is a necessary first step before we can do anything
else.
Frederik's perferred solution and Christoph's idea both require there to be
a default language format tag.

I would recommend approving this proposal in some form first, then we can
have a separate discussion about the name tags. So I have removed a couple
of short comments from the proposal to avoid this confusion.

Tags for official languages should also be a separate discussion (though I
also think this idea has merit).

-Joseph



On Thu, Sep 27, 2018 at 7:19 AM Christoph Hormann  wrote:

> On Wednesday 26 September 2018, Wolfgang Zenker wrote:
> > > * 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.
>
> Yes, of course i should have mentioned that this is just my personal
> opinion.  I did not mean to imply to speak for anyone else.
>
> > 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.
>
> Yes, you can try to systematically develop a solution after defining
> requirements and quantifying priorities.  But you need to keep in mind
> that in OSM you have no centralized decision making process as you
> usually have in engineering disciplines.  So you would already have
> trouble finding agreement on what exactly the problem is.  And
> experience tells that the solution space is typically much smaller than
> the problem space when it comes to tagging in OSM.  Long story short:
> Finding consensus on the solution is often much easier than on the
> problem.
>
> Still you are right, systematically collecting all the problems related
> to name data recording in OSM would be quite useful - even if just from
> a single person's perspective.  But that is already quite a huge amount
> of work.
>
> --
> 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

Re: [Tagging] Feature Proposal - RFC - Default Language Format

[Joseph Eisenberg]

The draft proposal about defaults was started on 20-September-2018, after
this proposal, and it is not yet fully developed.

In particular, “def:” is not a great primary tag because “def.” is not a
clear abbreviation in English. It would normally mean “definition” or
“define” rather than “default.”

However, I am willing to change the order of this tag to default:language
or default_language if other people also agree that this would be better

Joseph

On Thu, Sep 27, 2018 at 8:04 AM André Pirard 
wrote:

> On 2018-09-24 14:36, Joseph Eisenberg wrote:
>
> Please see the Proposal page for the new tag, "language:default= code>"
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>
> Description:
> " 
> Specify
>  the default language format used for names, and recommend use
> of language-specific name tags.
>
> "By making it easier to use language-specific name:code=* tags to be
> used instead of the default name=* tag, this proposal will encourage
> the use of name tags that include the language code for all features.
> This will improve the quality and utility of the database. It will be
> possible to display non-Western languages in their correct orientation
> and script, properly display multilingual names, and to research the
> most commonly used language formats in a particular area.
>
> "The key language:default=* with a 2 or 3 letter ISO language code
> should be tagged on administrative boundary relations, such as
> countries, provinces and aboriginal communities. This is the language
> used for the majority of named features within a particular region, as
> indicated on public signs and in common use by the local community. If
> the language can be written in more than one script, a qualifier can
> be added to specify the script format. More than one language code can
> be listed, separated with a semicolon, if the local community uses
> more than one language on signs or by consensus.
>
> "The language tag should be applied to the largest boundary relation
> that accurately represents the language used for default names. When a
> smaller administrative boundary has a different default language
> format, this boundary should receive a language tag as well. This
> would include boundaries of provinces or aboriginal lands where a
> different language is used.
>
> All tags using defaults should not use their own, different but the same
> mechanism defined by the Defaults
>  proposition.
> Hence, a default for a tag
> language=xxx
> which can be coded in any OSM object is
> def:language=xxx
> coded in the administrative relation you say, or equivalent.
>
> This allows uniformly writing/upgrading the same program to handle all
> defaults instead of each default using its own program.
> The Defaults 
> proposition must obviously be decided before the defaults that use it.
>
> All the best,
>
> André.
>
> "The language tag may also be applied to individual features when the
> name is in a different language than the default for the region, or
> when the feature crosses a border."
>
> Please read the whole page, which has quite a number of examples and a
> detailed rationale for the proposal, then please comment here or on
> the discussion 
> page:https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>
> Thank you for all of your comments, criticisms and suggestions
> -Joseph
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Default Language Format

[André Pirard]

On 2018-09-24 14:36, Joseph Eisenberg wrote:
Please see the Proposal page for the new tag, "language:default=" 
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format 
Description: "Specify the default language format used for names, and recommend use

of language-specific name tags.

"By making it easier to use language-specific name:code=* tags to be
used instead of the default name=* tag, this proposal will encourage
the use of name tags that include the language code for all features.
This will improve the quality and utility of the database. It will be
possible to display non-Western languages in their correct orientation
and script, properly display multilingual names, and to research the
most commonly used language formats in a particular area.

"The key language:default=* with a 2 or 3 letter ISO language code
should be tagged on administrative boundary relations, such as
countries, provinces and aboriginal communities. This is the language
used for the majority of named features within a particular region, as
indicated on public signs and in common use by the local community. If
the language can be written in more than one script, a qualifier can
be added to specify the script format. More than one language code can
be listed, separated with a semicolon, if the local community uses
more than one language on signs or by consensus.

"The language tag should be applied to the largest boundary relation
that accurately represents the language used for default names. When a
smaller administrative boundary has a different default language
format, this boundary should receive a language tag as well. This
would include boundaries of provinces or aboriginal lands where a
different language is used.
All tags using defaults should not use their own, different but the same 
mechanism defined by the Defaults 
proposition.

Hence, a default for a tag
language=xxx
which can be coded in any OSM object is
def:language=xxx
coded in the administrative relation you say, or equivalent.

This allows uniformly writing/upgrading the same program to handle all 
defaults instead of each default using its own program.
The Defaults 
proposition 
must obviously be decided before the defaults that use it.


All the best,

André.



"The language tag may also be applied to individual features when the
name is in a different language than the default for the region, or
when the feature crosses a border."

Please read the whole page, which has quite a number of examples and a
detailed rationale for the proposal, then please comment here or on
the discussion page:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format

Thank you for all of your comments, criticisms and suggestions
-Joseph

___
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] Draft Proposal: Default Langauge Format

[Christoph Hormann]

On Wednesday 26 September 2018, Wolfgang Zenker wrote:
> > * 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. 

Yes, of course i should have mentioned that this is just my personal 
opinion.  I did not mean to imply to speak for anyone else.

> 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.

Yes, you can try to systematically develop a solution after defining 
requirements and quantifying priorities.  But you need to keep in mind 
that in OSM you have no centralized decision making process as you 
usually have in engineering disciplines.  So you would already have 
trouble finding agreement on what exactly the problem is.  And 
experience tells that the solution space is typically much smaller than 
the problem space when it comes to tagging in OSM.  Long story short:  
Finding consensus on the solution is often much easier than on the 
problem.

Still you are right, systematically collecting all the problems related 
to name data recording in OSM would be quite useful - even if just from 
a single person's perspective.  But that is already quite a huge amount 
of work.

-- 
Christoph Hormann
http://www.imagico.de/

___
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

[Martin Koppenhoefer]

what about substrings of names? Just found this example where it would be 
needed to indicate that the name is composed of 3 different languages: 
https://www.openstreetmap.org/node/5726043060

Cheers,
Martin

sent from a phone___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

[Christoph Hormann]

On Wednesday 26 September 2018, Frederik Ramm wrote:
>
> I am thinking of retail outlets like
>
> "Tesco"
>
> "Real"
>
> "Saturn"
>
> "Tk-Max"

Ok, i could of course say now these are not names but brands but 
assuming these are names i see two options for those:

* say the language is defined by where the name was originally 
introduced
* say that these are names without a language (which would in my eyes 
not really be a name any more but an identifying string - could consist 
purely of punctuation or emojiis for example) and integrate these into 
the scheme with a key to be selected.

> But I am willing to extend my definition:
>
> "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, unless an explicit name:xx tag exists."

By setting the default language of the admin boundaries you would 
retroactively define the meaning of all the pre-existing name tags 
within it without a case-by-case verification.  You would also 
essentially need to forbid changing the default language information of 
the admin units because that would of course break the whole thing.

> That should pretty much catch everything and give everyone the
> flexibility to map all special cases, while not requiring to re-tag
> every single named object all over the planet.

Let me see if i can formulate your suggestion:

check language:default of the feature -> yy

if yy is defined
  name:yy is the name in yy and the local name
  (can be extended to multiple languages)
else
  check language:default of the admin unit -> xx
  if xx is defined 
if there is name:xx
  name:xx is the name in xx and the local name 
  (and the name tag is meaningless?)
  (can be extended to multiple languages)
else
  name is the name in xx and the local name
  (with multiple languages semantics are unknown)
  else
name (if present) is the local name in unknown language(s)
(legacy fallback)

Apart from the semantic interpretation that name is in xx in case the 
default language is tagged on the admin unit (which comes with the 
problems listed above) this seems exactly the same algorithm i had in 
mind for the proposed method.

The only difference is that because of the problems with the retroactive 
definition of the language of the name tags and the impossibility to 
change the default language of the admin unit in this scenario i would 
in the long term fade out the name tag completely in favour of name:xx.

> I think that generally a more precise recording of languages is
> desirable but if this leads to having to duplicate existing name tags
> into name:xx for every single named place on earth just in order to
> "not defeat the purpose", then I'd like to pass on this idea and wait
> until a less intrusive one comes along.

As said the aim is not to duplicate the name data but to replace the 
generic name tag that has no defined language with the individual 
language name tags.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Philip Barnes]

On Wed, 2018-09-26 at 19:54 +0200, Frederik Ramm wrote:
> Hi,
> 
> On 09/26/2018 05:53 PM, Christoph Hormann wrote:
> > 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.  
> 
> I am thinking of retail outlets like
> 
> "Tesco"
Not a word, but an acronym

TE Stockwell Cohen

Phil (trigpoint)


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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Christoph Hormann]

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.

> 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.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Yves]

Duplicating all 'name' tags to 'name:xx'  in our worldwide database is not so 
shocking, but I still prefer that we map what language is used where than the 
language the 'name' tag is in. It sounds less oriented.
Yves 

Le 26 septembre 2018 19:54:41 GMT+02:00, Frederik Ramm  a 
écrit :
>Hi,
>
>On 09/26/2018 05:53 PM, Christoph Hormann wrote:
>> 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.  
>
>I am thinking of retail outlets like
>
>"Tesco"
>
>"Real"
>
>"Saturn"
>
>"Tk-Max"
>
>>> 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. 
>
>I disagree. My assumption is currently that a name tag in Germany will
>be the German name, and I think for all countries or regions with one
>prevalent language this will be everyone's assumption (that if the
>region has a default language, the name will be the name in the default
>language).
>
>But I am willing to extend my definition:
>
>"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, unless an explicit name:xx tag exists."
>
>That should pretty much catch everything and give everyone the
>flexibility to map all special cases, while not requiring to re-tag
>every single named object all over the planet.
>
>(You will only have to re-tag those objects where the name is in a
>language different from the prevalent language in the region, and where
>you perceive this to be an issue - as you said yourself, the damage
>done
>by assuming that the "O sole mio" assigned to a pizzeria in Germany is
>a
>German rather than an Italian name, is negligible.)
>
>> I see your point but as said this would defeat the whole purpose of
>the 
>> idea
>
>If that is the case, and no workaround can be found because every
>workaround would defeat the purpose of the idea, then I would likely
>oppose the idea.
>
>I think that generally a more precise recording of languages is
>desirable but if this leads to having to duplicate existing name tags
>into name:xx for every single named place on earth just in order to
>"not
>defeat the purpose", then I'd like to pass on this idea and wait until
>a
>less intrusive one comes along.
>
>Bye
>Frederik
>
>-- 
>Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
>E008°23'33"
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

[Frederik Ramm]

Hi,

On 09/26/2018 05:53 PM, Christoph Hormann wrote:
> 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.  

I am thinking of retail outlets like

"Tesco"

"Real"

"Saturn"

"Tk-Max"

>> 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. 

I disagree. My assumption is currently that a name tag in Germany will
be the German name, and I think for all countries or regions with one
prevalent language this will be everyone's assumption (that if the
region has a default language, the name will be the name in the default
language).

But I am willing to extend my definition:

"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, unless an explicit name:xx tag exists."

That should pretty much catch everything and give everyone the
flexibility to map all special cases, while not requiring to re-tag
every single named object all over the planet.

(You will only have to re-tag those objects where the name is in a
language different from the prevalent language in the region, and where
you perceive this to be an issue - as you said yourself, the damage done
by assuming that the "O sole mio" assigned to a pizzeria in Germany is a
German rather than an Italian name, is negligible.)

> I see your point but as said this would defeat the whole purpose of the 
> idea

If that is the case, and no workaround can be found because every
workaround would defeat the purpose of the idea, then I would likely
oppose the idea.

I think that generally a more precise recording of languages is
desirable but if this leads to having to duplicate existing name tags
into name:xx for every single named place on earth just in order to "not
defeat the purpose", then I'd like to pass on this idea and wait until a
less intrusive one comes along.

Bye
Frederik

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

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

Re: [Tagging] 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] Draft Proposal: Default Langauge Format

[Christoph Hormann]

On Wednesday 26 September 2018, Frederik Ramm wrote:
> Hi,
>
> 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 - for example you might want to design an 
app that tells me (as a German or also for example to a Japanese) 
what "O sole mio" actually means - and to do that you have to know it 
is Italian.  Or you might want to create a map with transliterated 
names in some non-Latin script that has different transliteration rules 
for different European languages.  Also you might want to know that the 
name of a Korean Restaurant in Germany is actually in Korean and not in 
Japanese or Chinese (yes, pretty rare scenario for sure but that's not 
the point).

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.  Because data users generally satisfied with 90 percent 
solutions would just ignore it and since this is the vast majority of 
data users nothing would happen effectively.  The idea behind the 
proposed concept is to create a real solution for the naming problem in 
OSM.  It would require everyone to adjust to it but it would also mean 
everyone in the end has a 100 percent solution.

I don't have the illusion that it is very likely that this will happen - 
as already said the obstacles are high and >60 million name tags in OSM 
create an enormeous amount of inertia.  But this does not diminish the 
idea behind it and it does not change the fact that this (at least so 
far - i would be glad to learn about other ideas i failed to see) is 
the only type of approach that solves all known name representation 
problems in OSM.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] RFC - landcover clearing

[Mateusz Konieczny]

22. Sep 2018 10:16 by 61sundow...@gmail.com :


> > On 22/09/18 17:39, Mateusz Konieczny  wrote:
> > 
>> 
>>   22. Sep 2018 00:38 by >> 61sundow...@gmail.com 
>> >> :
>>   
>>   
>>> >>> On 21/09/18 23:16, Mateusz  Konieczny wrote:
>>> >>> 
    I am not sure why landcover=clearing is described as
 better than other.   
       If someone wants to leave gixme, the fixme 
 key or OSMnote is the best solution. 
    
>>> 
>>> Best solution for what?
>>>   
>>   
>>
>>   
>>   
>> For marking clearing to be mapped. Obviously, mapping itproperly
>>   
>> would be better. But fixme/notes at least in theory can beprocessed 
>> by other mappers,
>>   
>> in case of clearings - also by armchair mappers.
>> 
> 
> But then the feature is harder to find in the data base. 
> Note that clearings have already been marked as landuse=clearing. 
>




I am not sure why you believe that tagging TODO item as landcover tag rather 
than established

fixme key is preferable.

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

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Mateusz Konieczny]

26. Sep 2018 06:32 by mark+...@carnildo.com :


> On Tue, 25 Sep 2018 08:09:12 +0200
> Florian Lohoff <> f...@zz.de > > wrote:
>
>> On Wed, Sep 19, 2018 at 11:24:00AM -0700, Mark Wagner wrote:
>> > My point is that no such guarantee exists for roads without speed
>> > limit signs.  Yes, the numeric limit for something like Glenwood
>> > Road might be 50 mph, but the road was designed around farm trucks
>> > going no more than 20 mph, and has the tight curves, short sight
>> > lines, and poor surface quality you'd expect for that speed.  
>>
>> Sign posted speeds dont are not telling you "this is the speed which
>> is safe for 100% of the vehicles" but this is the maximum allowed. 
>> You are still required to drive safely.
>
> That's not what I said.  To repeat, my point is that, at least locally,
> a signposted speed limit *is* a guarantee that, for an ordinary vehicle
> traveling under ordinary conditions, the speed is reasonable. 




Note that it is true in your region and it is not generally true.




For example in Poland there are many places where signed 


speed limit is really low or really high compared  to reasonable one.

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

[Mateusz Konieczny]

building tag is supposed to contain how building is constructed. For example 
hotel ina church is building=church (with hotel tagged as usual).
Former hotel building used as a warehouse is building=hotel.

25. Sep 2018 02:54 by jo...@mac.com :


> the buildings look like a hotel (or was perhaps a hotel in the past) - but if 
> it is just a restaurant now, then it is building=retail. 
> If it is a place where you can rent a private room to sleep, it is a 
> building=hotel with a commercial landuse, a pin for the hotel, and another 
> pin for the restaurant  (the lobby restaurant in hotels is usually a separate 
> mappable place, as it’s purpose, operating hours, and access to the general 
> public is different than the hotel itself. 
> (...)
>
> the building=* tag helps define the rough purpose fo the building - but not 
> the exact purpose. The pin or other tags on the building do that. And that 
> building looks like it wants to sell food to tourists.  
>
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Draft Proposal: Default Langauge Format

[Frederik Ramm]

Hi,

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...

> 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."

Bye
Frederik

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

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Martin Koppenhoefer]

sent from a phone

> On 26. Sep 2018, at 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.)


+1, or features belonging to foreign military (e.g. American barracks, air 
bases etc.), foreign schools, foreign cultural associations. There’s also a 
significant number of names in dialects.

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Christoph Hormann]

On Wednesday 26 September 2018, Frederik Ramm wrote:
>
> Isn't it so that the new system adds zero usefulness to countries or
> areas which have and use just one language, but is useful in regions
> that have more than one? Hence, why roll it out in, say, most parts
> of Germany *at all*, and just stick to parts where several languages
> are used?

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.) and 
features which have both a German and a different language name both in 
active use locally (so the name tag would contain a combination of 
both).

Examples:

https://www.openstreetmap.org/node/240045727
https://www.openstreetmap.org/way/135310439
https://www.openstreetmap.org/node/3903774975
https://www.openstreetmap.org/way/90431650

The whole point of a concept like the one proposed here is to have a 
unified system that transparently covers all cases - both in terms of 
the geographic and cultural reality and in terms of use cases of the 
data.  Special casing countries which supposedly don't need this kind 
of defeats the whole purpose.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Frederik Ramm]

Hi,

On 26.09.2018 12:00, Christoph Hormann wrote:
> But the good news is that both the proposal of Joseph and my suggestion 
> would allow a simple an reliable fallback to the current tagging scheme 
> so once most data users are capable of interpreting the new scheme you 
> could smoothly convert the tagging feature by feature without  
> duplication and without a negative effect on usability.
> 
> The big problem of this approach however is that you would need to 
> convince data users to implement interpretation of a new tagging system 
> up-front without the database containing significant amounts of data 
> where this would be useful for.  This is not just buying the cat in a 
> sac, it is like building a home for the cat without having seen it yet.

Isn't it so that the new system adds zero usefulness to countries or
areas which have and use just one language, but is useful in regions
that have more than one? Hence, why roll it out in, say, most parts of
Germany *at all*, and just stick to parts where several languages are used?

Bye
Frederik

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

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

Re: [Tagging] Draft Proposal: Default Langauge Format

[John Willis]

> On Sep 26, 2018, at 3:36 PM, Frederik Ramm  wrote:
> 
> be amended with an identical name:xx tag just because xx is the language
> spoken in that country!

You are very lucky then to not have to deal with the documented tagging scheme 
of name= , name:en= name:ja= name:ja_rm=, and name:ja_kana= where I am, which 
is the documented way to tag things in Japan. 

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

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Paul Johnson]

On Tue, Sep 25, 2018 at 11:34 PM Mark Wagner  wrote:

> On Tue, 25 Sep 2018 08:09:12 +0200
> Florian Lohoff  wrote:
>
> > On Wed, Sep 19, 2018 at 11:24:00AM -0700, Mark Wagner wrote:
> > > My point is that no such guarantee exists for roads without speed
> > > limit signs.  Yes, the numeric limit for something like Glenwood
> > > Road might be 50 mph, but the road was designed around farm trucks
> > > going no more than 20 mph, and has the tight curves, short sight
> > > lines, and poor surface quality you'd expect for that speed.
> >
> > Sign posted speeds dont are not telling you "this is the speed which
> > is safe for 100% of the vehicles" but this is the maximum allowed.
> > You are still required to drive safely.
>
> That's not what I said.  To repeat, my point is that, at least locally,
> a signposted speed limit *is* a guarantee that, for an ordinary vehicle
> traveling under ordinary conditions, the speed is reasonable.  An
> unsigned speed limit, on the other hand, does *not* carry that
> guarantee.
>

If you're in the US, you're describing the advisory speeds (the orange
signs), which are roughly tuned to a midsize family car.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Draft Proposal: Default Langauge Format

[Jo]

I would expect Frederik to be even more disappointed if we were to first
duplicate name to name:XX and then have another round of edits to remove
name.

At some point JOSM's valdiator was telling me to add name:language, so I
did. That's where some of those Belgian entries probably come from for the
objects I had been changing for other reasons.

Polyglot

Op wo 26 sep. 2018 om 12:02 schreef Christoph Hormann :

> On Wednesday 26 September 2018, Frederik Ramm wrote:
> >
> > I added a comment on avoiding duplication - I would be very unhappy
> > if every feature on the planet that currently only has a name tag
> > would now be amended with an identical name:xx tag just because xx is
> > the language spoken in that country!
>
> Yes, this is probably the key obstacle to all attempts to abolish the
> plain name tag (with all its inherent problems) because at least
> temporarily (until a new name tagging system is fully established)
> there would be need to keep the old name tag and any adoption of the
> new system would require duplication.  There is no solution for this,
> it is an inevitable side effect of actually solving the naming problem
> in OSM instead of just doctoring around the symptoms.
>
> But the good news is that both the proposal of Joseph and my suggestion
> would allow a simple an reliable fallback to the current tagging scheme
> so once most data users are capable of interpreting the new scheme you
> could smoothly convert the tagging feature by feature without
> duplication and without a negative effect on usability.
>
> The big problem of this approach however is that you would need to
> convince data users to implement interpretation of a new tagging system
> up-front without the database containing significant amounts of data
> where this would be useful for.  This is not just buying the cat in a
> sac, it is like building a home for the cat without having seen it yet.
>
> --
> 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

Re: [Tagging] Draft Proposal: Default Langauge Format

[Christoph Hormann]

On Wednesday 26 September 2018, Frederik Ramm wrote:
>
> I added a comment on avoiding duplication - I would be very unhappy
> if every feature on the planet that currently only has a name tag
> would now be amended with an identical name:xx tag just because xx is
> the language spoken in that country!

Yes, this is probably the key obstacle to all attempts to abolish the 
plain name tag (with all its inherent problems) because at least 
temporarily (until a new name tagging system is fully established) 
there would be need to keep the old name tag and any adoption of the 
new system would require duplication.  There is no solution for this, 
it is an inevitable side effect of actually solving the naming problem 
in OSM instead of just doctoring around the symptoms.

But the good news is that both the proposal of Joseph and my suggestion 
would allow a simple an reliable fallback to the current tagging scheme 
so once most data users are capable of interpreting the new scheme you 
could smoothly convert the tagging feature by feature without  
duplication and without a negative effect on usability.

The big problem of this approach however is that you would need to 
convince data users to implement interpretation of a new tagging system 
up-front without the database containing significant amounts of data 
where this would be useful for.  This is not just buying the cat in a 
sac, it is like building a home for the cat without having seen it yet.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] How to tag a building constructed for a gastronomic purposes?

[Robert Skedgell]

On 25/09/18 12:47, Colin Smale wrote:
> On 2018-09-25 13:07, Marc Gemis wrote:
> 
>> However, I'm not sure whether gastronomic is the proper
>> British-English word to use. I think the Brits are already using
>> building=pub (perhaps only for a subclass of your 'gastronomic'.

I've tended to use building=pub where the building is "obviously" a
public house / inn, built for that purpose.

> The predicate "gastronomic" implies a certain level of quality, aimed at
> good-food-lovers. Fast-food would not be gastronomic, nor would many
> restaurants and pubs. However a modern invention is the "gastro-pub"
> where they consider their food to be of a particularly high standard,
> not just standard pub food.

For a gastro-pub, perhaps amenity=pub + food=yes + cuisine=gastropub
(where no more specific cuisine=* would be more appropriate), regardless
of what building=* contains?

-- 
Robert Skedgell (rskedgell)


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

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Andy Townsend]

On 26/09/2018 09:12, Colin Smale wrote:


On 2018-09-26 06:32, Mark Wagner wrote:


That's not what I said.  To repeat, my point is that, at least locally,
...

Sorry Mark, you are wrong. There is no guarantee, signposted or not.


I think the key point here is "at least locally".  Certain things may be 
true in certain areas; but they won't be true worldwide. That doesn't 
mean that someone is "wrong" when they say that it's locally true for 
them, but it does mean that it's not very helpful globally, where all 
sorts of different conditions exist.


Best Regards,

Andy

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

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Colin Smale]

On 2018-09-26 06:32, Mark Wagner wrote:

> That's not what I said.  To repeat, my point is that, at least locally,
> a signposted speed limit *is* a guarantee that, for an ordinary vehicle
> traveling under ordinary conditions, the speed is reasonable.  An
> unsigned speed limit, on the other hand, does *not* carry that
> guarantee.

Sorry Mark, you are wrong. There is no guarantee, signposted or not. 

Besides the speed in relation to road geometry, I know of many
situations with speed bumps which would destroy your suspension if you
drove over them with the permitted maximum speed.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Peter Elderson]

In Nederland advisory speed signs are used for this purpose. These do not
alter speed limit, but indicate the local safe speed under normal
conditions.
I do not see how this fact could help with the subject at hand, though.
Good luck with that!

Op wo 26 sep. 2018 om 06:33 schreef Mark Wagner :

> On Tue, 25 Sep 2018 08:09:12 +0200
> Florian Lohoff  wrote:
>
> > On Wed, Sep 19, 2018 at 11:24:00AM -0700, Mark Wagner wrote:
> > > My point is that no such guarantee exists for roads without speed
> > > limit signs.  Yes, the numeric limit for something like Glenwood
> > > Road might be 50 mph, but the road was designed around farm trucks
> > > going no more than 20 mph, and has the tight curves, short sight
> > > lines, and poor surface quality you'd expect for that speed.
> >
> > Sign posted speeds dont are not telling you "this is the speed which
> > is safe for 100% of the vehicles" but this is the maximum allowed.
> > You are still required to drive safely.
>
> That's not what I said.  To repeat, my point is that, at least locally,
> a signposted speed limit *is* a guarantee that, for an ordinary vehicle
> traveling under ordinary conditions, the speed is reasonable.  An
> unsigned speed limit, on the other hand, does *not* carry that
> guarantee.
>
> --
> Mark
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Draft Proposal: Default Langauge Format

[Frederik Ramm]

Hi,

On 26.09.2018 04:49, Joseph Eisenberg wrote:
> There have been a few small updates to the proposal page based on your
> suggestions in the past week.
> Please comment on the talk page if you have any further ideas or
> criticisms:

I added a comment on avoiding duplication - I would be very unhappy if
every feature on the planet that currently only has a name tag would now
be amended with an identical name:xx tag just because xx is the language
spoken in that country!

Bye
Frederik

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

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