On 10 August 2018 at 23:39, Paul Allen wrote:
> This is a different problem from which separator to use.
I wondered if anyone would remember that question!
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
Tagging mailing list
I don't see anyone trying to change your way.
Verzonden vanaf mijn Samsung Galaxy-smartphone.
Oorspronkelijk bericht Van: Jo Datum:
11-08-18 09:29 (GMT+01:00) Aan: "Tag discussion, strategy and related tools"
Onderwerp: Re: [Tagging] Slash, space, or spac
It's actually funny how these things go. Several years ago, mappers asked:
How can we map multilingual names. We told them: In Brussels we do it with
a spaced hyphen.
Oh thank you, we'll do it in a different way.
Several years later, people wonder why there are different ways for doing
things
sent from a phone
> On 11. Aug 2018, at 06:13, Marc Gemis wrote:
>
> I find it hard to understand why non-Belgians try to change a rule
> that is accepted by the Belgian community. The name field contains the
> name of the object as known by the local people. Not what an
> Englishmen or
I am not trying to change any accepted local rule.
Mvg Peter Elderson
Op 11 aug. 2018 om 06:13 heeft Marc Gemis het volgende
geschreven:
>> I find it hard to understand why some mappers do not want to map reality.
>> Unless it's because they wish the street
>> signs were really monolingual.
If I knew about usual abbrevs I would probably expand those. If I was not sure,
I would not. Usually, looking at existing names in the area tells me what to
do. If there are variants on different signs in an area/language I don’t know,
I tend to do nothing at all, but if I had to I would either
> I find it hard to understand why some mappers do not want to map reality.
> Unless it's because they wish the street
> signs were really monolingual. There are people where I live who object to
> any use of English, should I cater to
> their whims by amending all names around here to remove
On 11 August 2018 at 09:14, Jo wrote:
> What if the street sign said:
>
> St Francis St.
>
> would you be putting that exactly as is in the name tag?
>
> I would put
>
> Saint Francis Street
>
> in it.
>
> What if there are 3 signs, one with
> St Francis St.
> Saintt Francis St.
> St Francis
What if the street sign said:
St Francis St.
would you be putting that exactly as is in the name tag?
I would put
Saint Francis Street
in it.
What if there are 3 signs, one with
St Francis St.
Saintt Francis St.
St Francis Street
It may be a longer street, it may be that time passed by
On Fri, Aug 10, 2018 at 11:38 PM, Jo wrote:
> Fortunately all streets in Brussels are already mapped, based on official
> data from Urbis. So the person from Biel who would prefer to put / in those
> names doesn't need to to so anymore.
>
> There are definitely street name signs which are wrong.
On Fri, Aug 10, 2018 at 10:47 PM, Peter Elderson
wrote:
if I were a renderer I would not try to parse/interpret a free format
> string. I would parse only clearly defined sections, where the separator is
> very very unlikely to occur in text strings. Space slash space might be
> suitable, but
Fortunately all streets in Brussels are already mapped, based on official
data from Urbis. So the person from Biel who would prefer to put / in those
names doesn't need to to so anymore.
There are definitely street name signs which are wrong. It would be absurd
to copy that wrong text into the
if I were a renderer I would not try to parse/interpret a free format string. I
would parse only clearly defined sections, where the separator is very very
unlikely to occur in text strings. Space slash space might be suitable, but not
if any context is required, context such as that it’s about
On Fri, 10 Aug 2018 at 21:42, marc marc wrote:
> In the same way as in osm we defined ";" as being the separator between
> several values of the same key (with several exceptions), it would be
> useful to define a separator between several lines of the same key.
Then why not also use the
Le 10. 08. 18 à 19:28, Peter Elderson a écrit :
> If the sign shows two strings one line each, you will need
> interpretation and/or a glue character or glue string.
in fact, what's the better glue character IS the question
at the begging of this thread.
Currently, a Brussels resident reading a
Le 10. 08. 18 à 20:35, Marc Gemis a écrit :
>> If there's a street sign, that's what should be mapped in name=* even if
>> it's "wrong."
> What if there are 2 streets signs on either end of the street with
> different spelling ?
I agree with you
the name of a highway, is the name of... the
Am 10.08.2018 um 20:19 schrieb Paul Allen:
> Because if I'm in
> a strange location, looking at a map that labels a street "Foo Lane"
> that's what I expect to see on the sign. Anything
> else is misleading and unhelpful.
Couldn't agree more.
Note: we do have "official_name" for
On Fri, Aug 10, 2018 at 7:35 PM, Marc Gemis wrote:
>
> what if there are different street signs on the left and the right
> side because the street is on the boundary between 2 villages ?
>
name:left=* and name:right=* are what the wiki recommends. Local mapping
conventions might well decide
On Fri, Aug 10, 2018 at 6:38 PM, Daniel McCormick
wrote:
>
> The goal of OSM is not to create a map that renders great on the default
> renderer. The goal is to create repository that can be rendered quickly and
> easily by anyone. The default map is what we primarily interact with and
> just
> If there's a street sign, that's what should be mapped in name=* even if it's
> "wrong." Not temporarily wrong, but
> permanently "the council has decreed that's what it is, and that's how it's
> going to stay" wrong. Because if I'm in
> a strange location, looking at a map that labels a
On Fri, Aug 10, 2018 at 6:06 PM, Martin Koppenhoefer wrote:
>
> I am saying that street signs are just indications of names. Names for
> streets are usually (at least in Italy and Germany) assigned by the city
> council,
Assigned by the county council here in the UK (I'm simplifying a little
018 14:33:44 +0200
> From: Jo
> 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"
>
If the sign shows one string, name= should always be right.
If you know the string contains two language variants and a separator, sep
string, brackets or whatever, you can interpret the string and extract name:xx
substrings. I would still keep the name= tag, to serve both rendering
and other
sent from a phone
> On 10. Aug 2018, at 18:24, Paul Allen wrote:
>
> You appear to be saying that the name of the street (as on the sign) is not
> the name of the street (as in the name=*
> tag applying to the street). This appears to be a post-modernist
> interpretation of "name."
>
>
On Fri, Aug 10, 2018 at 4:23 PM, Martin Koppenhoefer wrote:
>
> > On 10. Aug 2018, at 15:29, Paul Allen wrote:
> >
> > 1) It is said to be standard practice to render what is observable on
> the ground.
>
>
> everybody can render what she deems most useful, there is not an absolute
> rule to
sent from a phone
> On 10. Aug 2018, at 15:29, Paul Allen wrote:
>
> 1) It is said to be standard practice to render what is observable on the
> ground.
everybody can render what she deems most useful, there is not an absolute rule
to render what is on the ground (e.g. if there is a typo
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
The renderers and ALL data consumers would then have to take that into
account.
Tagging for the renderer means: Using a inappropriate tag on an object such
that it renders in a colour or style the mapper prefers over correctly
tagging an object.
Putting 2 names in a name field where those 2
Maybe a possible solution to get rid of name=* tags containing names
in multiple languages would be to add the information about which
languages are spoken in a particular region to its boundary relation
(e.g. spoken_languages=de;fr to the municipality boundary of
Biel/Bienne). However, the
sent from a phone
> 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
, 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"
>
>
On 9 August 2018 at 18:03, Colin Smale wrote:
> Random example:
> https://www.google.com/maps/@50.826443,4.2963849,3a,15y,
> 217.26h,94.11t/data=!3m6!1e1!3m4!1sY2SqOf8gphVOZYqsHOKlXA!
> 2e0!7i13312!8i6656
>
Interesting, because I notice that Google (the fount of all knowledge where
it comes to
]
> > 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
On Thu, Aug 9, 2018 at 11:38 AM, Andy Mabbett
wrote:
Signs can use different fonts, text size, colours and "line breaks" to
> indicate meaning which cannot be captured in a single line of plain
> text.
A one-minute walk from me is this sign:
Heol Napier
Napier Street
It's possible to
On 9 August 2018 at 09:21, Marc Gemis wrote:
>> Also many bilingual street signs in Belgium exploit grammatical
>> differences between French and Dutch; where the significant part
>> is a proper name (X), in French it might be "Rue X", in Dutch it is
>> "Xstraat", so the sign says Rue X-straat.
On 9 August 2018 at 06:17, Marc Gemis wrote:
> Can you please elaborate a bit on the reason for your question ?
To reduce the cognitive load on mappers.
> Is it because you want a map with a uniform syntax for multiple names ?
No.
> I assume it is not because humans do not understand the
On Thu, Aug 9, 2018 at 10:09 AM Colin Smale wrote:
>
> On 2018-08-09 08:45, Martin Koppenhoefer wrote:
>
> sent from a phone
>
> On 9. Aug 2018, at 07:17, Marc Gemis wrote:
>
> 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
The OP wrote "Greater consistency would surely be advantageous?"
That is why I asked to elaborate a bit on "why / to whom".
he never mentioned "the question is about the “name in the local
language”." That was the main topic of the previous discussion on the
combined names.
m.
On Thu, Aug 9,
On 2018-08-09 08:45, Martin Koppenhoefer wrote:
> sent from a phone
>
>> On 9. Aug 2018, at 07:17, Marc Gemis wrote:
>>
>> 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.
>
> the question is about the "name in the
sent from a phone
> On 9. Aug 2018, at 07:17, Marc Gemis wrote:
>
> 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.
the question is about the “name in the local language”.
cheers,
Martin
Op do 9 aug. 2018 om 07:18 schreef 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
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
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
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
*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
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.
(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
iding 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 catalo
> 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
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
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,
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
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
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
___
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
55 matches
Mail list logo
