Re: [Tagging] Feature Proposal - Voting - Toll Gantry

2018-09-19 Thread Daniel McCormick

That is an interesting case of a toll gantry being on the bridge. I fear though 
that adding that to the bridge that goes over the tolled highway might cause 
there to be some confusion concerning which road is actually tolled. This is 
easily worked around though by just adding a node to the tolled road very close 
to the bridge. This solution would be much cleaner then previous version of 
polygon toll gantries and is minimally invasive to the data.


> On Sep 19, 2018, at 4:40 PM, tagging-requ...@openstreetmap.org wrote:
> 
> Re: [Tagging] Feature Proposal - Voting - Toll Gantry

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


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

2018-08-10 Thread Daniel McCormick
 pe...@openstreetmap.com.br,  "Tag discussion, strategy and related
>   tools" 
> Subject: Re: [Tagging] Feature Proposal - Voting - Evacuation Routes
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> On Fri, Aug 10, 2018 at 2:01 PM, peterkrauss 
> wrote:
> 
>> 
>> * can anyone (as I) to vote?
> 
> 
> Have you registered as a user of the OSM Wiki?  Voting is a matter of
> editing the proposal page to add your vote.
> 
> 
>> I am a database OSM user/developer (PostGIS etc), not an experienced
>> mapper.
> 
> 
> If you don't already have an OSM Wiki account you can probably figure out
> how to create one. :)
> 
> -- 
> Paul
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180810/a1a21360/attachment-0001.html>
> 
> --
> 
> Message: 4
> Date: Fri, 10 Aug 2018 14:29:54 +0100
> From: Paul Allen 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual
>   names
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> On Fri, Aug 10, 2018 at 12:25 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
> 
>> 
>>> On 10. Aug 2018, at 00:42, Daniel McCormick 
>> wrote:
>>> 
>>> While the default renderer favors name=* over name:nl or name:fr that is
>> not the case for other renderers. We as contributors might think that is
>> the most prominent way to view the data but not all renderers are the same.
>> Having our data be specific in saying this is the French name, this is the
>> Flemish name and this is the German name gives the data more flexibility
>> than just having all languages thrown into one name=* field.
>> 
>> nobody questions the usefulness of name:language tags, the question is
>> only what, if anything, to put in the name tag in multilingual areas (and
>> also this is a term which can describe a lot of different realities, which
>> not necessarily have to be treated all the same).
>> 
> 
> Two things.
> 
> 1) It is said to be standard practice to render what is observable on the
> ground.  A minute's walk from where I live is
> a street sign that says:
> 
> Heol Napier
> Napier Street
> 
> That is what I observe.  See
> https://www.google.co.uk/maps/@52.0857064,-4.6583686,3a,15.4y,86.99h,96.29t/data=!3m6!1e1!3m4!1sQGH0BhhjxXX2ctr-1NxmOg!2e0!7i13312!8i6656
> I don't need to know which languages are spoken in this region, or what
> language(s) the sign is in, that is what the
> sign SAYS and that is what should be mapped (in my opinion).
> 
> 2)  Ordinary consumers (people looking at OSM and trying to figure out
> where they are) need to know what signs
> SAY.  Presenting them with half the information increases the cognitive
> load on somebody trying to figure out
> where they are when GPS is not very accurate.  If they are unfamiliar with
> the languages involved then "Heol Napier
> Napier Street" may not be the same as "Napier Street" but a separate entity
> (perhaps its a side street branching off
> Napier Street).
> 
> As it happens, I know that Heol Napier is the Welsh name of the street and
> Napier Street is the English name, but not
> everyone consuming the data will know (or want to know) that.  They are
> more likely to be concerned with
> confirming that they are where they think they are.  Having name:cy and
> name:en will perhaps permit vector
> maps to display names in a language of choice, but lacking that name=*
> should (in my opinion) show what is
> actually there.  Anything else is perverse.
> 
> As another matter, Wikipedia has an OSM-derived project that translates all
> names into as many languages as possible.
> I'm not sure this is useful.  This might make sense for the tag info that
> comes back from a query, such as the Chinese for
> "addr:street" but not so much for the name of the street itself (which is
> almost always the equivalent of an
> arbitrary label).  I'd say that for actual names, transliterations would be
> useful but translations would not (if you're
> asking a local and know the local language for "Where is" and can pronounce
> the name then that is more useful than
> knowing what the name means in your own language.
> 
> -- 
> Paul
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180810/bb4a0a8c/attachment.html>
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> --
> 
> End of Tagging Digest, Vol 107, Issue 51
> 


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


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

2018-08-09 Thread Daniel McCormick
I have to agree with Marc on the position of rendering. It would appear to me 
that the use of separators in the name=* field comes from a desire to have the 
default map renderer on opentstreetmap.org  show 
both names. This is mapping to the renderer. The best way to view OSM is not as 
the default renderer depicts it but as a repository of geospatial data that the 
renderer then assists the contributor in viewing and understanding. Even though 
it gets in the way at times. While the default renderer favors name=* over 
name:nl or name:fr that is not the case for other renderers. We as contributors 
might think that is the most prominent way to view the data but not all 
renderers are the same. Having our data be specific in saying this is the 
French name, this is the Flemish name and this is the German name gives the 
data more flexibility than just having all languages thrown into one name=* 
field. The hierarchy of what is chosen to be rendered depends on the renderer 
and therefore we should hold the same standard. When it comes to not mapping to 
the renderer we hold it to the OSM standard rather than mapping to the 
renderer. 

> On Aug 9, 2018, at 6:00 AM, tagging-requ...@openstreetmap.org wrote:
> 
> Send Tagging mailing list submissions to
>   tagging@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
>   tagging-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   tagging-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Slash, space, or spaced hyphen in multi-lingual names
>  (Marc Gemis)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 9 Aug 2018 13:23:22 +0200
> From: Marc Gemis 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual
>   names
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> ]
>>> p.s. It is not the first time this question pops up.
>> 
>> That can be a sign that something is amiss.
> 
> the previous times it popped up was not for consistency reasons, but
> to do something on carto-css for osm.org
> We do have multiple local tile sets for Belgium, where we do not have
> that problem at all.
> 
> As a Flemish person it's even annoying that software like OsmAnd
> announces the name field and not name:nl
> Nobody uses the composed FR-NL name in real live. You always use one
> of the two depending on preference or situation.
> 
> As someone suggested before, perhaps we should get rid of the usage of
> name field for the default osm.org map and let the renderer decide
> what (and how) to display names in multi-language areas based on
> name:xx fields.
> Let the local community assist in setting up those rules for carto-css
> (e.g. French before Dutch), but the separator is decided by the map
> maker.
> 
> All that seems better than starting to change the name (and
> addr:street) field of tens of thousands of objects just because
> someone does not like the rendering on the default osm.org map.
> 
> m.
> 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> --
> 
> End of Tagging Digest, Vol 107, Issue 48
> 

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


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

2018-08-08 Thread Daniel McCormick
(I think I did something wrong and I have been corrected hopefully this is the 
correct way to contribute to this list)

I wanted to add my input here as I have done work in several different 
countries with several different naming schemes. 

It is my interpretation that the goal of this discussion is to determine the 
best way to distinguish different translations of the name of roads.

I propose that only one language is used for the name= tag. This will help to 
create a standard for naming that will bring clarity and consistency. If 
multiple languages are used in the area, place the most commonly used language 
in the name=* field and then the other languages in the appropriate name:en=*, 
name:fr=*, and so on. This will ensure that the data is specifically catalogued 
for routing software, while providing the opportunity for users of data to 
specify the language they desire to read the map in. In the end I suppose it 
would just be a matter of seeing both all the time or not but if we use the 
name:(insert whatever desired language here)=* we ensure a more specific and 
catalogued database for OSM globally. 

An example of this the Greek method where they have 
name=Μητροπόλεως 
name:el=Μητροπόλεως
name:en=Mitropoleos street

In Greece if I use a routing software, I can easily tell it to show me name:en 
or name:el for whatever I need to see at the time. Rather then using hyphen, 
slash or space I propose we use this method for distinguishing different 
translations in our naming scheme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-08-08 Thread Daniel McCormick

> On Aug 8, 2018, at 11:28 AM, tagging-requ...@openstreetmap.org wrote:
> 
> Send Tagging mailing list submissions to
>   tagging@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
>   tagging-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   tagging-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: RFC - landcover clearing (Martin Koppenhoefer)
>   2. Re: Part/whole confusion with Wikidata tag,  and the need for
>  enveloping parts into a whole (Martin Koppenhoefer)
>   3. Re: Slash, space, or spaced hyphen in multi-lingual names
>  (Martin Koppenhoefer)
>   4. Re: Slash, space, or spaced hyphen in multi-lingual names
>  (SelfishSeahorse)
>   5. Re: Slash, space, or spaced hyphen in multi-lingual names
>  (Peter Elderson)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 8 Aug 2018 18:04:21 +0200
> From: Martin Koppenhoefer 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] RFC - landcover clearing
> Message-ID: <50850ab9-8dd2-4960-b6a2-d039bf66c...@gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> what about natural=clearing? I don’t see “clearing” as a landcover value that 
> suits. Landcover is about what is there physically, “clearing” is about the 
> absence of what was there before.
> 
> Cheers,
> Martin
> 
> 
> 
> sent from a phone
> 
>> On 6. Aug 2018, at 02:11, Warin <61sundow...@gmail.com> wrote:
>> 
>> Hi,
>> I have been looking at the values used with the landuse key to try and stop 
>> land covers becoming regarded as a legitimate use of the key landuse. 
>> 
>> 
>> One strange value I came across was 'clearing'. No OSM wiki document. 
>> 
>> I resolved this to mean a change in land cover usually from trees to a 
>> 'clear' area. 
>> 
>> Most of these look to be from HOT mapping. 
>> 
>> 
>> Other instances of the value 'clearing' are natural=clearing and 
>> wood=clearing.
>> 
>> So I am thinking that these would best combined into the one tag  
>> landcover=clearing
>> 
>> A proposal page is ready for comments - link - 
>> https://wiki.openstreetmap.org/wiki/Landcover%3Dclearing
>> 
>> The basics are : 
>> 
>> Definition: An area where surrounding larger vegetation, such as trees,  
>>  are not present. This provides more light than the surrounding area. It may 
>> have lower vegetation growing, or it may be an outcrop of rock. 
>> 
>> Rationale:
>> Defines use of already existing value and suggest better ways of mapping 
>> these features. It is meant to encourage better mapping and suggest that 
>> this tag is a last resort. 
>> 
>> Key
>> The key landcover is use as the 'best fit' as it marks the lack of a 
>> surrounding land cover, so it is directly related to a land cover. 
>> The area could all ready have a land use - part of a forestry area for 
>> example. The area could have been made by man or nature so neither of the 
>> keys natural or man_made would suit all situations. 
>> 
>> How to map
>> The section on 'how to map' gives 4 options of how to map a clearing; map 
>> what is there, map what is surrounding, map both what is there and 
>> surrounding or map with landcover=clearing. 
>> Asking a mapper not to map this feature is not a good idea, mappers should 
>> be encouraged to map not discouraged. If a mapper has found this tag page 
>> then it is best to document better ways to tag the feature with this tag 
>> being the lest desirable result that maps the information rather than not 
>> mapping the information. 
>> The listed order is a compromise. The better mapping ones come before 
>> landcover=clearing to discourage it use. The simplest option first - map 
>> what is there - as that is the easiest option. If they cannot determine what 
>> is there then the next option - map the surrounds. Then the combination of 
>> the first two. Then finally the last option and least desirable. Hopefully 
>> this causes some though on what they are mapping, rather than just using the 
>> tag. 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 2
> Date: Wed, 8 Aug 2018 18:44:14 +0200
> From: Martin Koppenhoefer 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Part/whole confusion with Wikidata tag,and the
>   need for enveloping parts into a