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

[Marc Gemis]

Andy,

Can you please elaborate a bit on the reason for your question ?
Is it because you want a map with a uniform syntax for multiple names ?
I assume it is not because  humans do not understand the meaning of
one of the following forms Biel / Bienne, Biel/Bienne, Biel - Bienne,
Biel (Bienne)
Or do you want a uniform system for parsing ?

The name field is just a label. If you want to know the exact name in
a certain language you look at the name:xx field.

p.s. It is not the first time this question pops up.  Not so long ago
someone proposed to have a second field that indicates the format in
which the name field is written.

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

Re: [Tagging] Missing access value (access=license / authorization?)

[Adam Franco]

On Wed, Aug 8, 2018 at 8:11 PM, Kevin Kenny 
wrote:

> I haven't forgotten. I'm just going through a crunch time at work, and
> haven't had time to draft the thing formally.
>

As mentioned by Paul earlier in this thread, it looks like you already put
together a pretty solid draft two years ago (assuming you are ke9tv in the
wiki as well):
https://wiki.openstreetmap.org/wiki/Proposed_features/access%3Dpermit

Reading through this proposal it looks like it captures most of what has
been discussed in this thread so far. Maybe it just needs a once over to
ensure that it all still fits.

Alternatively, maybe you meant drafting a formal *announcement* of the
proposal. :-)

On Wed, Aug 8, 2018 at 8:11 PM, Kevin Kenny 
wrote:

> On Tue, Aug 7, 2018 at 10:11 PM Graeme Fitzpatrick
>  wrote:
> >
> > Yep, Kevin's proposal solves a lot of problems.
> >
> > Let's try to push it along & get it approved.
>
> I haven't forgotten. I'm just going through a crunch time at work, and
> haven't had time to draft the thing formally.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Fwd: Feature Proposal - RFC - Line clamps

[Michael Patrick]

> Do you agree to currently tag this as tower:type=suspension and maybe
later according to proposal as line_clamp=suspension? Is there an opposite
of suspension in English?I only find "suspension" in IEC vocabulary

After perusing Electropedia (IEC), I noticed some of the clamp entries
referred to 'posts', so I looked at power line equipment catalogs under
insulators, and alongside Suspension Insulators, Spool Insulators, Pin Type
Insulators, there is also a Post Insulators, and some engineering
references.

>From "The transmission and distribution of electrical energy
" 3rd ed.  Cotton and
Barber, page 165: There are three types used in connection with overhead
lines, viz. :


   1. Pin-type.
   2. Suspension-type.
   3. Strain-type.( includes 'Shackle'?)

It seems the various 'clamps' are used in conjunction with the position /
orientation dictated by the major type insulator ( top, middle, spool(with
clevis)). Post Insulators seem to incorporate both support, stand-off, and
insulating functions in all orientations ( pointing up, down or slantwise
).

Probably the simplest antonym for 'suspension' conductor on bottom ) case
is 'pin' ( conductor on top ), and if you want 'spool' for the minority
conductor in the middle.

Michael Patrick



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

Re: [Tagging] Missing access value (access=license / authorization?)

[Kevin Kenny]

On Tue, Aug 7, 2018 at 10:11 PM Graeme Fitzpatrick
 wrote:
>
> Yep, Kevin's proposal solves a lot of problems.
>
> Let's try to push it along & get it approved.

I haven't forgotten. I'm just going through a crunch time at work, and
haven't had time to draft the thing formally.

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

Re: [Tagging] Points instead of areas

[Daniel Koć]

W dniu 07.08.2018 o 15:24, Christoph Hormann pisze:
> I think you have not understood the difference between measurement 
> tolerance and convergence here.

I'm not sure what do you mean by "convergence", but there's no
measurement tolerance problem, because without accepting area as a base
and without choosing centroid algorithm you don't even know what are you
measuring, in the first place.

If you followed next posts in this thread, you could see that the
"center" points are really not clear. I envisioned both choosing "right"
criteria and "right" spot problems, but I didn't know it's so well
illustrated already - Berlin center discussion shows it nicely, but Rome
shows exactly that your assumption of "social proof" fails hard in reality:

https://www.openstreetmap.org/user/dieterdreist/diary/40727

I like real life detailed data, but even in theory it's clear for me
that while people might want some points, they are just what I've said -
generalizations. For example in my city (Warsaw, Poland) we have
touristic center (Old Town), transportation center (Central Station),
probably biggest square near it (Plac Defilad) and historically highest
building there (Pałac Kultury i Nauki)... Which one is right? Well,
different one for different purposes. For label placing square seems to
be winner, but that's just one useful purpose.

So - no, point is not better than area and even not easier to verify.
Area seems to be more neutral for me - and here is where we can start
talking about measurement tolerance. For example area like 190 or 210 is
closer to 200 than 0 and the problem stops only when we zoom out a lot,
so it's all about 0. But this is generalization on bigger scale again...

> In any case how geographical objects that can be verifiably mapped in 
> principle are best represented in the OSM database is a matter of what 
> is most efficient, most convenient and least prone to errors *for the 
> mapper* (and not the data user!) to document the verifiable information 
> available about the object in question.

Sure, tagging should not be a royal pain, but I really don't understand
why you always praise the mappers at the expense of data consumers, as
if they were separated by wall and blessed/cursed, respectively. I also
believe such lack of balance would be simply bad for the project.

> For a plain rectangular footprint bench (>99 percent of benches) there 
> is absolutely no difference in the achievable level of accuracy and 
> detail in the representation of reality between these three variants.  
> But there is an immense level of difference in efficiency and 
> convenience of these representations for the mapper.

For me as a mapper convenience means to record the outline, not
measuring angle, width etc. For me as a map style coder it's the same...
But if I would like to make statistics about bench angles, it's different.

Something is wrong with this example, if I understand what point you
wanted to prove: the wall is not between producers/consumers and your
proposition is also harder for me as a mapper.

> Any argument beyond that (like that there is something inherent about 
> benches (or populated places or continents) that makes them more 
> suitable to be represented as X in the database) is usually just stuff 
> made up to convince mappers to map in a certain way for the convenience 
> of certain data users.

You speak only about most trivial case from my list. For anything else
the outline is more correct - buildings are sometimes rectangles, but
many of them have more complex shape where making a node and adding
measures would be not possible. Ditto for cities and countries, even
pitches have different shapes.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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

Re: [Tagging] RFC - landcover clearing

[Warin]

On 09/08/18 08:47, marc marc wrote:

+1
the current proposal of the page seems to me to be a good promise to
improve the current situation while remaining realistic with the fact
that some mapper do not always have all the information or all the
knowledge to make the perfect solution.
in this sense the page is well enough to push good practices forward
while giving a scheme for imperfect v1 but allowing to have useful
information for future improvement (I can easily imagine a
StreetComplete quest that would ask a local contributor what
exactly the hole in the forest consists of)

the page only need to be moved to /Proposed_features/ :)


Opps!! Thanks. I have copied it... and placed warning on the top of the 
original page with a link.

New copied page is at 
https://wiki.openstreetmap.org/wiki/Proposed_features/landcover%3Dclearing

I am yet to contact the original HOT task for the area that I have covered as 
trees (with holes).
{Too many things to do ! :)}

It looks now to be visible 
https://www.openstreetmap.org/way/528264806#map=13/8.4987/-83.4343
Zooming out and the 'clearings' disappear but you can then see the extent of 
the trees - at least as far as I have gone.
Zoom in and you can see more detail of the 'clearings'.




Le 09. 08. 18 à 00:27, Warin a écrit :

There are some who would then say that a 'clearing' that is made by man
should not be in the key 'natural' but in the key 'man_made'.

A 'clearing' may not have ever had the surrounding vegetation - an area
of rock for example.

The 'clearing' is about a change in the land cover, not about an
absence, an absence would be 'space' - a vacuum ...there will be
something there, but arm chair mappers may not be able to identify
either the surrounding vegetation nor the areas vegetation.

On 09/08/18 02:04, Martin Koppenhoefer wrote:

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
andwood=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

Re: [Tagging] Feature Proposal - RFC - Line clamps

[François Lacombe]

Hi

2018-08-05 21:48 GMT+02:00 Paul Allen :

> Most of them have specific meanings with regard to
> electrical distribution and attachment is the only applicable one I can
> see that doesn't also have an electrical meaning
> (coupling often indicates that it transmits electrical or mechanical
> power).  So my vote is for attachment.
>

Then I moved the proposal to line_attachment key as I agree with you on
wording.
And also add pole:type to be replaced the same as tower:type

This sounds like consistent

Let's note that this proposal doesn't prevent us to better describe
insulators when used on a particular attachment (give their length,
material, whatever) despite out of the scope of this document.
This should be done with more dedicated to insulators keys (insulator:*
related to power=insulator ?) than line_attachment intended for global
lines attachment on many kinds of supports.


>  To be honest, I don't think finding a web page merits
> credit so I'd be perfectly happy if you removed that mention of me.
>

No offense, I removed this credit from the page

All the best

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

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

[marc marc]

name must be only one name of course faild with bilingual area.
of course local communities have the rules that apply to this situation
and try to impose a single rule on the world will fail

but Andry's message seems imho a good idea :
having only-one rule that can be used everywhere is better than
having x rules that try to do the same thing which implies that
a contributor must discover those x rules and that the software 
concerned must code x routines to use them (try to create a QA to catch 
name to name:xx mistmatch in multilangual area... you 'll see the issue)
discussing the advantages and disadvantages of the different separators 
currently used is very useful for using the experience of different 
local communities.
afterward PROPOSING a 'global' rule would make sense, although obviously 
it would be up to each local community to choose whether or not to adopt it.


Le 08. 08. 18 à 20:51, Johnparis a écrit :
> /Daniel McCormick wrote: "I propose that only one language is used for 
> the name= tag"/
> 
> This fails immediately in bilingual countries like Belgium, and also 
> fails in countries like Morocco, where the predominant language is 
> Arabic, but the two legal languages are Arabic and Tamazight, while a 
> major language of commerce is French. The local communities in Belgium 
> and Morocco have addressed these issues to their satisfaction, with no 
> need for outsiders to impose their views of "the best way".
> 
> 
> On Wed, Aug 8, 2018 at 8:15 PM, Peter Elderson  > wrote:
> 
> My understanding was that the discussion is about when both names
> are indicated on the name signs and no definite preference is
> clear.  The method of exactly representing the sign (just copy the
> string) fails because usually the names are given as two strings or
> even as two signs.
> 
> Op wo 8 aug. 2018 om 20:02 schreef Daniel McCormick
> mailto:mccorm...@kaartgroup.com>>
> 
> (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
> 
> 
> -- 
> Vr gr Peter Elderson
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

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

Re: [Tagging] RFC - landcover clearing

[marc marc]

+1
the current proposal of the page seems to me to be a good promise to 
improve the current situation while remaining realistic with the fact 
that some mapper do not always have all the information or all the 
knowledge to make the perfect solution.
in this sense the page is well enough to push good practices forward 
while giving a scheme for imperfect v1 but allowing to have useful 
information for future improvement (I can easily imagine a 
StreetComplete quest that would ask a local contributor what
exactly the hole in the forest consists of)

the page only need to be moved to /Proposed_features/ :)

Le 09. 08. 18 à 00:27, Warin a écrit :
> There are some who would then say that a 'clearing' that is made by man 
> should not be in the key 'natural' but in the key 'man_made'.
> 
> A 'clearing' may not have ever had the surrounding vegetation - an area 
> of rock for example.
> 
> The 'clearing' is about a change in the land cover, not about an 
> absence, an absence would be 'space' - a vacuum ...there will be 
> something there, but arm chair mappers may not be able to identify 
> either the surrounding vegetation nor the areas vegetation.
> 
> On 09/08/18 02:04, Martin Koppenhoefer wrote:
>> 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 
>>> andwood=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
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

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

Re: [Tagging] RFC - landcover clearing

[Warin]

There are some who would then say that a 'clearing' that is made by man 
should not be in the key 'natural' but in the key 'man_made'.


A 'clearing' may not have ever had the surrounding vegetation - an area 
of rock for example.


The 'clearing' is about a change in the land cover, not about an 
absence, an absence would be 'space' - a vacuum ...there will be 
something there, but arm chair mappers may not be able to identify 
either the surrounding vegetation nor the areas vegetation.


On 09/08/18 02:04, Martin Koppenhoefer wrote:
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 
andwood=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



___
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] Points instead of areas

[Graeme Fitzpatrick]

Wow, thanks Martin - amazing stuff

Thanks

Graeme

On 8 August 2018 at 23:11, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 8. Aug 2018, at 05:24, Warin <61sundow...@gmail.com> wrote:
>
> The centre of a place is a little cultural, a little of frequent use and a
> little from signs.m
>
>
>
> I’ve written 2 diary entries about the centres of Rome and Berlin, maybe
> it is of interest in this context:
> https://www.openstreetmap.org/user/dieterdreist/diary/40735
>
> For historic cities the centre is typically the castle (often the same
> location) often nowadays there’s the townhall, while railway stations are
> usually at the border of the historic city, not the centre centre.
>
> Churches traditionally also tend to be at the borders, because their
> churchyard was used for burying and to reduce the risk of plagues it wasn’t
> in the centre.
>
> It depends how old the place is, obviously.
>
> Ciao, Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[SelfishSeahorse]

On Wed, 8 Aug 2018 at 20:03, Daniel McCormick  wrote:
> 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

I think it depends on whether the language of the second name on the
street sign is spoken at that place or not, i.e. if it is a bilingual
place or not. If it is not – like in Greece –, then I think your
example makes sense. However, if it is – like for example in
Biel/Bienne [^1] – then I would put both names in the name=* tag.

[^1]: 

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

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

[Johnparis]

*Daniel McCormick wrote: "I propose that only one language is used for the
name= tag"*

This fails immediately in bilingual countries like Belgium, and also fails
in countries like Morocco, where the predominant language is Arabic, but
the two legal languages are Arabic and Tamazight, while a major language of
commerce is French. The local communities in Belgium and Morocco have
addressed these issues to their satisfaction, with no need for outsiders to
impose their views of "the best way".


On Wed, Aug 8, 2018 at 8:15 PM, Peter Elderson  wrote:

> My understanding was that the discussion is about when both names are
> indicated on the name signs and no definite preference is clear.  The
> method of exactly representing the sign (just copy the string) fails
> because usually the names are given as two strings or even as two signs.
>
> Op wo 8 aug. 2018 om 20:02 schreef Daniel McCormick <
> mccorm...@kaartgroup.com>
>
>> (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
>>
> --
> Vr gr Peter Elderson
>
> ___
> 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] Slash, space, or spaced hyphen in multi-lingual names

[Peter Elderson]

My understanding was that the discussion is about when both names are
indicated on the name signs and no definite preference is clear.  The
method of exactly representing the sign (just copy the string) fails
because usually the names are given as two strings or even as two signs.

Op wo 8 aug. 2018 om 20:02 schreef Daniel McCormick <
mccorm...@kaartgroup.com>

> (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
>
-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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

[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
&

Re: [Tagging] Missing access value (access=license / authorization?)

[Szem]

Other mappers and me are just an absolute minimum, negligible part of 
the whole community. Until this is not included in the wiki, it is 
hardly known by anyone.
Someone said that this is not a condition for appearance or I 
misunderstoodsg?


Szem

2018.08.07. 22:57 keltezéssel, Martin Koppenhoefer írta:


sent from a phone


On 7. Aug 2018, at 21:53, Szem  wrote:

How can I support it to make progress?


use the tag yourself and encourage other mappers to do the same.


Cheers,
Martin

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


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

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

[Peter Elderson]

>  the slash without spaces is used (e.g. Biel/Bienne), unless one of the
two names already has a space, in which case the slash is usually set
with spaces
(e.g. Bielersee / Lac de Bienne).

This I would support. It is generally used and understood like this in
Nederland as well. The remark that if the script type changes a special
separator is not needed, I second that too.

2018-08-08 19:12 GMT+02:00 SelfishSeahorse :

> I suspect that the different punctuation marks on OSM are a
> consequence of different writing habits in the respective regions,
> which i recommend to follow.
>
> For example, in English-speaking regions and in Switzerland the slash
> without spaces is used (e.g. Biel/Bienne), unless one of the two names
> already has a space, in which case the slash is usually set with
> spaces (e.g. Bielersee / Lac de Bienne).
>
> Regards
> Markus
>
> On Wed, 8 Aug 2018 at 14:21, Andy Mabbett 
> wrote:
> >
> > Please see:
> >
> >https://wiki.openstreetmap.org/wiki/Talk:Multilingual_
> names#Slash.2C_space.2C_or_spaced_hyphen.3F
> >
> > where I wrote:
> >
> > This page (and perhaps actual practice) is inconsistent in suggesting:
> >
> > * slashes: name=L'Alguer/Alghero (New Zealand, Portugal, Sardinia)
> > * spaced hyphens: name=Rue du Marché aux Poulets - Kiekenmarkt (Belgium,
> Spain)
> > * spaces: name=干諾道中 Connaught Road Central (Hong Kong)
> > * spaced slashes: name=Le Rhin / Rhein (shared boundaries)
> >
> > Greater consistency would surely be advantageous?
> >
> > --
> > Andy Mabbett
> > @pigsonthewing
> > http://pigsonthewing.org.uk
>
> ___
> 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

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

[SelfishSeahorse]

I suspect that the different punctuation marks on OSM are a
consequence of different writing habits in the respective regions,
which i recommend to follow.

For example, in English-speaking regions and in Switzerland the slash
without spaces is used (e.g. Biel/Bienne), unless one of the two names
already has a space, in which case the slash is usually set with
spaces (e.g. Bielersee / Lac de Bienne).

Regards
Markus

On Wed, 8 Aug 2018 at 14:21, Andy Mabbett  wrote:
>
> Please see:
>
>
> https://wiki.openstreetmap.org/wiki/Talk:Multilingual_names#Slash.2C_space.2C_or_spaced_hyphen.3F
>
> where I wrote:
>
> This page (and perhaps actual practice) is inconsistent in suggesting:
>
> * slashes: name=L'Alguer/Alghero (New Zealand, Portugal, Sardinia)
> * spaced hyphens: name=Rue du Marché aux Poulets - Kiekenmarkt (Belgium, 
> Spain)
> * spaces: name=干諾道中 Connaught Road Central (Hong Kong)
> * spaced slashes: name=Le Rhin / Rhein (shared boundaries)
>
> Greater consistency would surely be advantageous?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk

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

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

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 17:43, Johnparis  wrote:
> 
> Osmose generates an error if you use a slash.


Osmose could be fixed, I don’t see it has any authority on what is correct or 
not, it is just a tool to help you find situations where something might 
eventually be suspicious, nothing more. It is up to you to decide and evaluate 
the situation.


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

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 02:22, Yuri Astrakhan  wrote:
> 
> If we duplicated everything, than each part of a railroad station should have 
> duplicate web site URL, hours of operation, operator name, and tons of other 
> info.


I don’t know what situation you are referring to, and how it is currently 
mapped, but if there are different parts mapped, there will usually be a reason 
for it, and different websites, operation hours (never mapped these myself), 
operators and other info might be the reason for splitting it. Maybe the parts 
of the station shouldn’t be mapped as if they were stations on their own, but 
as parts of a station?
Usually tags go on the object they apply to, tags for a station go on the 
station, tags for a part of a station go on the part, etc.

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

Re: [Tagging] RFC - landcover clearing

[Martin Koppenhoefer]

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

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 00:35, Yuri Astrakhan  wrote:
> 
> For this specific case, the railroad stations consumer would probably want a 
> single raiway station, not multiples, so they are easier to analyze, easier 
> to query by matching it up with wikidata, etc.



For railway stations I would agree that it is desirable to have a single 
station object for a single station (ignoring for a moment double and triple 
stations and how to link them, e.g. internally connected metro stations on 
different lines). My answer is a station area for the whole station, but many 
mappers are categorically refusing this and advocate nodes only (IMHO strange 
for something as big as a station). An area would solve a lot of issues.

I am not against making our data easier to consume for others, but the priority 
should be making life easiest for mappers.


> Railroad station can have multiple parts, but so do many other things, and we 
> tend to put common things in a relation for them. Why would you want railroad 
> stations tagged differently, and duplicate the same wikidata tag on every 
> part of it?


it really depends how wikidata has the individual station represented, is it 
one or several objects? Do they have a collector object for the parts, etc.?
It’s not as if all stations are codified the same in wikidata, or are they? Has 
wikidata already found a stable structure how they represent railway stations 
or will it maybe change continuously?
Even if everything (wikidata <-> OSM) would be consistent today, tomorrow it 
would either be inconsistent or outdated ;-)

I agree there is room for improvement on all sides, but it cannot be answered 
once for all.

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

Re: [Tagging] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

[Michael Reichert]

Hi peterkrauss,

Am 08.08.2018 um 03:18 schrieb Nelson A. de Oliveira:
> On Tue, Aug 7, 2018 at 9:22 PM, Yuri Astrakhan  
> wrote:
>> Nelson, there are several places I have seen in our wiki, e.g. [1], which
>> discourage duplication of information if it can be avoided. name is a
>> special case - it helps mappers to quickly identify what the object
>> represents. If we duplicated everything, than each part of a railroad
>> station should have duplicate web site URL, hours of operation, operator
>> name, and tons of other info. Having duplicates lead to inconsistencies,
>> harder to maintain, etc.  For example, if two parts of the station have
>> different hours of operation - is that a mistake (someone forgot to update
>> both), or is it intentional? Which one of two is correct? Having a rule to
>> keep common info in a relation unless it is different makes data more
>> valuable and less error-prone.
> 
> I was talking about any object.
> And I fail to see what exactly is *wrong* in having multiple parts of
> an object with the same wikidata; it's not really duplication.
> 
> We don't create relations to avoid repeating surface, lanes, name, etc
> on every part of a highway, for example.
> Using relations also has the drawback of creating complexity for most
> of the users in OSM (and sometimes even for the data consumers),
> specially if the main objective here is to solely avoid non-unique
> wikidata values.

I second that.

Our data model is different from the data model of Wikidata.

It is common practice when mapping railway lines to add tags which refer
to a railway line (as a infrastructure, not the services using it) to
the ways.

Example: Tags of a way

railway=rail
name=Linke Rheinstrecke (English: Left Rhine Railway)
wikipedia=de:Linke Rheinstrecke
wikidata=Q…
operator=DB Netz AG

This duplication is common practice in OSM even if it does look wrong to
proponents of the pure doctrine how to design a database. OSM is not
modified by a frontend application hiding the database model from the
user. Instead, it is edited by humans how have to understand the
database model. Many of them already struggle with understanding
relations at all.

That's why we do not create a relation to collect all objects having the
same operator. Instead, we add operator= to all the objects. Such
relations are called "collective relations" and not welcome.

https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Route relations for railway lines (infrastructure, not the services) are
some of the exceptions from that rule.

OSM is a project with a lot of data. If we represented all much more of
the information which is currently "duplicated" as tags on individual
objects, processing of OSM data would become more difficult, expensive
and slower due to the many JOINs (I assume you are more familiar with
database terminology).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Tagging] Put the name in sidewalks and cycleways

[Paul Johnson]

On Mon, Aug 6, 2018, 03:32 Martin Koppenhoefer 
wrote:

Generally properties on the main highway are often a more useful
> representation than dedicated ways, but if you go into details it can be
> better to have a dedicated way (or you will have to split the main highway
> into lots of tiny fragments just because of properties of the sidewalks
> changing).


I tend to feel dedicated ways has a lot more to offer in terms of detail
and flexibility, particularly for pedestrian and cycling routing.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jo]

It's mostly our names did have hyphens, but none had hyphens with spaces
around them. Annoyingly we still get in trouble for those cases where both
sides of the street have different names... They exist, but they are rare
enough not to cause real headaches.

Op wo 8 aug. 2018 om 17:44 schreef Johnparis :

> Osmose generates an error if you use a slash. I don't see consistency as
> an advantage. It's a local decision.
>
> If the names use different writing systems (as in the HK example) a space
> is sufficient.
>
> Slashes do occur in names, but surely more rarely than embedded hyphens. I
> think the spaced hyphen is an effort to emulate the dash, which is not an
> ASCII character. A spaced double hyphen is better in that regard -- as in
> this sentence.
>
> On Wed, Aug 8, 2018, 17:22 Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 8. Aug 2018, at 14:19, Andy Mabbett 
>> wrote:
>> >
>> > Greater consistency would surely be advantageous?
>>
>>
>> I prefer the slash, because hyphens occur in names, while I haven’t yet
>> encountered a name with slashes
>>
>> cheers,
>> Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Johnparis]

Osmose generates an error if you use a slash. I don't see consistency as an
advantage. It's a local decision.

If the names use different writing systems (as in the HK example) a space
is sufficient.

Slashes do occur in names, but surely more rarely than embedded hyphens. I
think the spaced hyphen is an effort to emulate the dash, which is not an
ASCII character. A spaced double hyphen is better in that regard -- as in
this sentence.

On Wed, Aug 8, 2018, 17:22 Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 8. Aug 2018, at 14:19, Andy Mabbett 
> wrote:
> >
> > Greater consistency would surely be advantageous?
>
>
> I prefer the slash, because hyphens occur in names, while I haven’t yet
> encountered a name with slashes
>
> cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 14:19, Andy Mabbett  wrote:
> 
> Greater consistency would surely be advantageous?


I prefer the slash, because hyphens occur in names, while I haven’t yet 
encountered a name with slashes 

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

Re: [Tagging] undersea tourist route

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 02:12, Warin <61sundow...@gmail.com> wrote:
> 
> Humm
> 
> highway=path
> 
> layer=-1
> 
> surface=water


-1 to surface water, because surface is about the surface of the path.
I would also go with location=underwater


cheers,
Martin

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

Re: [Tagging] Points instead of areas

[Martin Koppenhoefer]

sent from a phone

> On 8. Aug 2018, at 05:24, Warin <61sundow...@gmail.com> wrote:
> 
> The centre of a place is a little cultural, a little of frequent use and a 
> little from signs.m


I’ve written 2 diary entries about the centres of Rome and Berlin, maybe it is 
of interest in this context:
https://www.openstreetmap.org/user/dieterdreist/diary/40735

For historic cities the centre is typically the castle (often the same 
location) often nowadays there’s the townhall, while railway stations are 
usually at the border of the historic city, not the centre centre.

Churches traditionally also tend to be at the borders, because their churchyard 
was used for burying and to reduce the risk of plagues it wasn’t in the centre.

It depends how old the place is, obviously.

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

Re: [Tagging] undersea tourist route

[Lionel Giard]

I also agree with the location tag as it say it is underwater, while the
other method say that the path is made of "water" (as it would be made of
gravel or asphalt in other places).

Note that the tag layer=-1 don't mean anything by itself (if there is no
other data at the same location) as it is a relative tag (layer -1 means
below other element with layer 0 or above). And as you are not below the
water but in it, you can't technically use that to indicate underwater
element.  One example of feature below the water is the "Channel Tunnel"
between France and England, where it is technically in the rocks below the
sea, that's not the same thing that you want here. :-)

2018-08-08 11:18 GMT+02:00 Javier Sánchez Portero :

> I think that location=underwater is more exact that surface=water. With
> the second I expect to walk over the water like Jesus.
>
> Javier
>
> El mié., 8 ago. 2018 a las 1:13, Warin (<61sundow...@gmail.com>) escribió:
>
>> On 08/08/18 09:01, marc marc wrote:
>> > Le 08. 08. 18 à 00:26, Warin a écrit :
>> >> A scuba or snorkel route - some concrete drums with a chain between
>> then
>> >> and signs for people to follow. Like an under sea path.
>> > highway=path + location=underwater ? :)
>>
>> Humm
>>
>> highway=path
>>
>> layer=-1
>>
>> surface=water
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Mabbett]

Please see:

   
https://wiki.openstreetmap.org/wiki/Talk:Multilingual_names#Slash.2C_space.2C_or_spaced_hyphen.3F

where I wrote:

This page (and perhaps actual practice) is inconsistent in suggesting:

* slashes: name=L'Alguer/Alghero (New Zealand, Portugal, Sardinia)
* spaced hyphens: name=Rue du Marché aux Poulets - Kiekenmarkt (Belgium, Spain)
* spaces: name=干諾道中 Connaught Road Central (Hong Kong)
* spaced slashes: name=Le Rhin / Rhein (shared boundaries)

Greater consistency would surely be advantageous?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Points instead of areas

[Marc Gemis]

> The centre of a place is a little cultural, a little of frequent use and a 
> little from signs.
> In Europe I suspect it is the railway station ..lots of signs pointing there.
> In rural Australia I would go with the post office, though the pub is quite 
> popular. :)

In Belgium I would assume it's the church, not the railway station.

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

Re: [Tagging] undersea tourist route

[Javier Sánchez Portero]

I think that location=underwater is more exact that surface=water. With the
second I expect to walk over the water like Jesus.

Javier

El mié., 8 ago. 2018 a las 1:13, Warin (<61sundow...@gmail.com>) escribió:

> On 08/08/18 09:01, marc marc wrote:
> > Le 08. 08. 18 à 00:26, Warin a écrit :
> >> A scuba or snorkel route - some concrete drums with a chain between then
> >> and signs for people to follow. Like an under sea path.
> > highway=path + location=underwater ? :)
>
> Humm
>
> highway=path
>
> layer=-1
>
> surface=water
>
>
> ___
> 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] Points instead of areas

[djakk djakk]

For cities there must be a point associated to the polygon to tell where
the center is (maybe 2 if the city is poly centric, like Budapest maybe ?)


djakk

Le mer. 8 août 2018 à 05:25, Warin <61sundow...@gmail.com> a écrit :

> On 08/08/18 12:52, Bill Ricker wrote:
>
>
>
> On Tue, Aug 7, 2018 at 6:41 PM, Graeme Fitzpatrick 
> wrote:
>
>>
>>
>>
>> On 7 August 2018 at 21:56, Daniel Koć  wrote:
>>
>>>
>>> For example nobody would say that a city is a point
>>
>>
>> I'm not disagreeing with you, but people do refer to them, & somehow even
>> measure them, as points!
>>
>> I'm sure that you have the same situation in your country but an e.g. is
>> my State capital, Brisbane: https://en.wikipedia.org/wiki/Brisbane,
>> which
>>
>> covers an area of 15842 km2, but is still apparently found exactly at:
>> ...
>>
>>
> Quite so.
> To measure distances between towns/cities, some point is needed.
> While in theory someone wishing to do so could query for the Admin level
> outline and compute the centroid, when a government entity has declared a
> named point to match the Admin level boundary, it's convenient if everyone
> uses the same one.
> If there are countries which for which open-licensed town centers aren't
> available, the local mapping communities can decide what is right for them.
> Postoffice, Town Hall, Centroid, Flagpole, whatever.
>
>
> The centre of a place is a little cultural, a little of frequent use and a
> little from signs.
> In Europe I suspect it is the railway station ..lots of signs pointing
> there.
> In rural Australia I would go with the post office, though the pub is
> quite popular. :)
> ___
> 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] Part/whole confusion with Wikidata tag, and the need for enveloping parts into a whole

[Christoph Hormann]

On Wednesday 08 August 2018, peterkrauss wrote:
>
> > has been an important point of
> > critique of the whole 'adding wikidata IDs to OSM' movement.  You
> > can read this up in the previous discussion here and in talk.
>
> Can you send the main links?

No, i can't.

There is a large number of discussions on the topic of adding Wikidata 
IDs in OSM (which is significantly less invasive than this attempt to 
shape OSMs data model to the needs of Wikidata) in several channels and 
i did not keep track of all of them.  You can find quite a bit of 
discussion by searching for subjects containing 'wikidata' in talk in 
the second half of 2017.  Most of this was ultimately non-productive 
because the Wikidata supporters in the discussion did not make any 
serious attemts to actually take into account the fundamental critique 
of their intentions.

In most cases the discussion progressed in a similar way as here with 
Wikidata proponents being firmly set in their world view and having no 
perception of the fundamental differences between that and the way OSM 
handles things and as a result attempting to bulldoze over OSM with 
euphemisms like "pragmatical view".

If any Wikidata fan really wants to engage in a productive and balanced 
discussion on the interrelationship between the projects you would need 
to approach this on a very basic level and accept that none of the 
fundamental assumptions Wikidata is founded on is necessarily shared by 
OSM.

And as Martin Koppenhoefer said - if you ignore these things you only 
have two options:  Trying to forcefully change OSM to adjust to the 
Wikidata world view or adjusting Wikidata to adopt OSMs views.  Even if 
one of those options seems feasible (which i would not necessarily 
disagree with) it would be an act of imperialism with all the 
consequences this usually brings with it.

> PS: ideal is to summarize a list of topics and its "agreement vs
> under-discussion" status...
> something like
> https://wiki.openstreetmap.org/wiki/Wikidata/Critical_topics

I would strongly suggest you do not try to imply that what you state 
there represents an agreement of any kind.  What you have written there 
seems to indicate a lack of understanding of how OSM works and 
therefore seems to form an attempt to impose working principles you 
find desirable onto OSM.  Don't do that.

If you want to create such a wiki page to describe your subjective 
perception of the situation that is fine - but you should indicate it 
as such.

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

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