Name:* tags in the local language

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Name:* tags in the local language

Paul Norman
As part of my Wikimedia Foundation work, I'm working on labeling in
multiple languages using OSM data. We've run into an issue, and it's not
clear how to best solve it.

It is sometimes recommended that when you add a name in another language
you also indicate the name in the local language by adding a suitable
name:* tag at the same time. For example, if adding "name:fr=Londres" to
London, you would also add "name:en=London" if it weren't present.

This practice is not widely followed. For example, 3% of the roads with
names in multiple languages in the western US have a name:en tag.[1]
Cities are better, but still only 30% of cities and towns with names in
multiple languages have a name:en tag. For the same criteria in China
and with Chinese, it's 30% of roads and 75% of cities.[2]

This is a problem for displaying labels. Proper display of labels is
more than just showing the name in the language the user requested and
falling back to the name=* tag. It requires falling back through
multiple languages. For example, if someone requests a map in
Luxembourgish, you would show German labels where places and objects
have no Luxembourgish names. There are similar situations for French
Creoles and many regional and minority languages.

We'd like to be able to do more. Specifically, we'd like to always show
labels in the user's script if possible. For example if a French user is
viewing a map of India, they're more likely to be able to read an
English name than one in a Dravidian language, Hindi, or Bengali. The
common lack of a name:* tag for the primary language while having other
name:* tags makes this impossible.

There aren't any great solutions. Fixing this in software doesn't work
well because it requires regional processing of what are increasingly
small regions as you get to less used languages. Language detection from
the tag value is fragile and introducing magic logic. This really needs
addressing on the OSM data side.

If there's agreement that there is a problem here, I could look at
preparing a mechanical edit or MapRoulette challenge to add name:* tags,
e.g. adding name:en to objects in the US with other name:* tags, and
adding name:zh in China. As an estimate, this would be 115k changes in
China, touching 28% of roads there.

[1]: https://phabricator.wikimedia.org/T192662#4151714
[2]: https://phabricator.wikimedia.org/T192662#4147291


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Mateusz Konieczny-2
I fully agree that it is a problem. I encountered nasty issues after
implementing name rendering fallback with following language order
(order is simplified for this example):

name:pl, name:en, name:de, name

Intention was to render English name in China/Korea rather than
unreadable (for typical person from Poland) local name.

The result was rendering German names in Poland, because name:pl was
missing and name:de was present.

Somebody else also encountered this issue and places in Poland are
now partially fixed.

On Tue, 24 Apr 2018 10:23:19 -0700
Paul Norman <[hidden email]> wrote:

> preparing a mechanical edit or MapRoulette challenge

I would consider also making a quest in StreetComplete (it is on my
TODO list since a long time).

In my experience StreetComplete is working much better that
MapRoulette, though I am not sure whatever this task fits well "local
survey" model.

In case of mechanical edit - can you consider sharing script
(hopefully one working without complex environment)? I would happily run
such mechanical edit in Poland (including obtaining permission from
local community, checking whatever edits are correct and potential
cleanup of wrong edits).

Making mechanical edit is also on my TODO list since a long time, but
it never went further than vague plan and half-written explanation why
it is useful.

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Maarten Deen
On 2018-04-24 19:40, Mateusz Konieczny wrote:

> I fully agree that it is a problem. I encountered nasty issues after
> implementing name rendering fallback with following language order
> (order is simplified for this example):
>
> name:pl, name:en, name:de, name
>
> Intention was to render English name in China/Korea rather than
> unreadable (for typical person from Poland) local name.
>
> The result was rendering German names in Poland, because name:pl was
> missing and name:de was present.

I think you're opening another can of worms here. How would this work
out for me (in Dutch) where I don't want to see places in latin script
translated? I do not want to see Londen or Berlijn or Brunswijk, I also
don't want to see English translations like Cologne or Munich, but I do
want to see readable (i.e. non-Cyrillic, Kanji, Hangul, etc) names.

Maarten

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Name:* tags in the local language

Frederik Ramm
In reply to this post by Paul Norman
Hi,

On 04/24/2018 07:23 PM, Paul Norman wrote:
> If there's agreement that there is a problem here, I could look at
> preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> e.g. adding name:en to objects in the US with other name:* tags, and
> adding name:zh in China. As an estimate, this would be 115k changes in
> China, touching 28% of roads there.

Even if there should be agreement that there is a problem here, there
are other potential solutions.

Someone once suggested to have a special tag that indicates which name
tag should be used by default. I.e. we'd have tons of "name:xx" tags
plus one tag called e.g. "language=en", that would then mean: The
default name to use is the name:en name.

I think this would be more elegant than the duplication that you are
suggesting.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Tordanik
In reply to this post by Paul Norman
On 24.04.2018 19:23, Paul Norman wrote:
> It is sometimes recommended that when you add a name in another language
> you also indicate the name in the local language by adding a suitable
> name:* tag at the same time. For example, if adding "name:fr=Londres" to
> London, you would also add "name:en=London" if it weren't present.
>
> This practice is not widely followed.

I have to say I'm not a fan of this practice, at least for
straightforward cases.

Yes, there are parts of the world where explicit language information is
necessary. But in many others, there is an obvious default, and it feels
wrong to require mappers to manually repeat this on millions of
individual elements. Don't add extra tags to German names in Germany,
for example – tag the exceptions from the rule instead.

As a less important secondary point, I also consider the specific
tagging (duplicating the name with a different key) counter-intuitive
and would prefer a "language of the name" key, with the language given
as the value. The purpose of that tag would be much more
self-documenting than with the recommendation described above.

That being said, displaying labels in the user's language is an exciting
use case, and I hope we can find a solution that allows your project to
succeed. Could you elaborate a bit more on the technical limitations
regarding regional processing?

> Fixing this in software doesn't work
> well because it requires regional processing of what are increasingly
> small regions as you get to less used languages.

You mention increasingly small regions as the obstacle. Would that still
allow for the pragmatic compromise of setting country-level defaults,
and using explicit tagging only for smaller-scale language regions?

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Mateusz Konieczny-2
In reply to this post by Frederik Ramm
On Tue, 24 Apr 2018 20:16:08 +0200
Frederik Ramm <[hidden email]> wrote:

> I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
>
> I think this would be more elegant than the duplication that you are
> suggesting.

This language=en tag would be placed on a administrative relation,
right?

Note that it would work only in places with single language, and even
in very homogeneous countries, with single culture there are some
correctly tagged objects with name tag in a different languages.

So it would be anyway necessary to supply name:en to names that are in
English to confirm that this names are really in English.

This method would also not work at all in places with more complex
language situation (multiple communities, each using local language).

On top of that it is a bit complicated to use as a data consumer.

Overall I am not convinced that it is a good replacement.

PS My comments in future will be from a [hidden email] email,
that is still me - not some impostor.

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Sarah Hoffmann
In reply to this post by Frederik Ramm
On Tue, Apr 24, 2018 at 08:16:08PM +0200, Frederik Ramm wrote:

> Hi,
>
> On 04/24/2018 07:23 PM, Paul Norman wrote:
> > If there's agreement that there is a problem here, I could look at
> > preparing a mechanical edit or MapRoulette challenge to add name:* tags,
> > e.g. adding name:en to objects in the US with other name:* tags, and
> > adding name:zh in China. As an estimate, this would be 115k changes in
> > China, touching 28% of roads there.
>
> Even if there should be agreement that there is a problem here, there
> are other potential solutions.
>
> Someone once suggested to have a special tag that indicates which name
> tag should be used by default. I.e. we'd have tons of "name:xx" tags
> plus one tag called e.g. "language=en", that would then mean: The
> default name to use is the name:en name.
>
> I think this would be more elegant than the duplication that you are
> suggesting.

That still doesn't scale. You will have a hard time to convince mappers
to repeatedly add something to objects for which there is an obvious
default. This really should be solved at least partially in software.

I'd like to point to https://wiki.openstreetmap.org/wiki/Nominatim/Country_Codes
again. This list is a good place to start when you want to guess the
language a name tag is in and solves the case for monolingual coutries.
Multilingual countries tend to be more sensitive to the language issue
so that coverage with name:* tags tends to be better.

Also don't mix up the issue of languages and scripts. name:zh is
a point in case where knowing the language doesn't help you if you
want to present the users the map in their favourite script. name:zh
will normally contain Pidgin but may also have traditional Chinese
from time to time.

I strongly recommend to have a look into Sven's work on the German
mapnik style, which has been trying to address a lot of issues with
localized maps: https://github.com/giggls/mapnik-german-l10n

Sarah

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Mateusz Konieczny-3
In reply to this post by Maarten Deen
24. Apr 2018 20:03 by [hidden email]:

I think you're opening another can of worms here. How would this work out for me (in Dutch) where I don't want to see places in latin script translated? I do not want to see Londen or Berlijn or Brunswijk, I also don't want to see English translations like Cologne or Munich, but I do want to see readable (i.e. non-Cyrillic, Kanji, Hangul, etc) names.


Simple fallback would not work here but something like that may work

if name tag has only latin characters use name tag

otherwise fallback through following name tags:

name:nl, name:de, name:en...

With such scheme missing name:nl would not cause problems here (except
cases where dutch name has characters beyond latin script, I have no
idea whatever it may happen).


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Richard Fairhurst
In reply to this post by Paul Norman
Paul Norman wrote:
> If there's agreement that there is a problem here, I could look
> at preparing a mechanical edit or MapRoulette challenge to add
> name:* tags, e.g. adding name:en to objects in the US with
> other name:* tags, and adding name:zh in China. As an
> estimate, this would be 115k changes in China, touching 28%
> of roads there.

This is pretty fragile too, though. Two minutes after the mechanical edit, a
newbie will come along and change the name= tag on a random American road
from MLK Boulevard to Martin Luther King Boulevard, without knowing they now
have to change the name:en= tag as well. Bang, inconsistent data. Fast
forward two years and a bunch of history-losing way splits, and it's no
longer clear which is the accurate street name and which is the original,
mistaken TIGER-imported one.

In theory you could bake support for this into editing software (at the
expense of complicating the interface), but even if JOSM, iD, Vespucci and
P2 all add support, the name= tag is probably the most likely to be changed
by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
they'll all add the same logic.

Mateusz Konieczny wrote:
> This language=en tag would be placed on a administrative
> relation, right?

If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag, though putting it on admin relations is an
interesting idea.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Christoph Hormann-2
In reply to this post by Frederik Ramm
On Tuesday 24 April 2018, Frederik Ramm wrote:
>
> Someone once suggested to have a special tag that indicates which
> name tag should be used by default. I.e. we'd have tons of "name:xx"
> tags plus one tag called e.g. "language=en", that would then mean:
> The default name to use is the name:en name.

I think that someone was me. :-)

Details on:

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

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

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Jo-2
In reply to this post by Richard Fairhurst
I thought we were already indicating which language name is in, with the name:language=:iso tag?


Polyglot

2018-04-24 21:29 GMT+02:00 Richard Fairhurst <[hidden email]>:
Paul Norman wrote:
> If there's agreement that there is a problem here, I could look
> at preparing a mechanical edit or MapRoulette challenge to add
> name:* tags, e.g. adding name:en to objects in the US with
> other name:* tags, and adding name:zh in China. As an
> estimate, this would be 115k changes in China, touching 28%
> of roads there.

This is pretty fragile too, though. Two minutes after the mechanical edit, a
newbie will come along and change the name= tag on a random American road
from MLK Boulevard to Martin Luther King Boulevard, without knowing they now
have to change the name:en= tag as well. Bang, inconsistent data. Fast
forward two years and a bunch of history-losing way splits, and it's no
longer clear which is the accurate street name and which is the original,
mistaken TIGER-imported one.

In theory you could bake support for this into editing software (at the
expense of complicating the interface), but even if JOSM, iD, Vespucci and
P2 all add support, the name= tag is probably the most likely to be changed
by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
they'll all add the same logic.

Mateusz Konieczny wrote:
> This language=en tag would be placed on a administrative
> relation, right?

If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag, though putting it on admin relations is an
interesting idea.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Yuri Astrakhan-2
Adding a language=xx to each feature seems excessive, and will be forgotten most of the time, unless there is some extensive tool support for it.  Adding it to admin regions seems like a better approach.  Some utility could then calculate a clean translation map, using admin_level number as the deciding factor in case of multiple values.

On a side note, a validation tool can than be used to check if "name" has the same value as "name:xx", where xx is taken from that calculated map.  (I'm sure in many cases it won't match because some places use "lang:local - lang:en" style of naming for the name tag.

On Tue, Apr 24, 2018 at 10:48 PM, Jo <[hidden email]> wrote:
I thought we were already indicating which language name is in, with the name:language=:iso tag?


Polyglot

2018-04-24 21:29 GMT+02:00 Richard Fairhurst <[hidden email]>:
Paul Norman wrote:
> If there's agreement that there is a problem here, I could look
> at preparing a mechanical edit or MapRoulette challenge to add
> name:* tags, e.g. adding name:en to objects in the US with
> other name:* tags, and adding name:zh in China. As an
> estimate, this would be 115k changes in China, touching 28%
> of roads there.

This is pretty fragile too, though. Two minutes after the mechanical edit, a
newbie will come along and change the name= tag on a random American road
from MLK Boulevard to Martin Luther King Boulevard, without knowing they now
have to change the name:en= tag as well. Bang, inconsistent data. Fast
forward two years and a bunch of history-losing way splits, and it's no
longer clear which is the accurate street name and which is the original,
mistaken TIGER-imported one.

In theory you could bake support for this into editing software (at the
expense of complicating the interface), but even if JOSM, iD, Vespucci and
P2 all add support, the name= tag is probably the most likely to be changed
by minority editors (e.g. mobile or 'quick fix' apps) and it's unlikely
they'll all add the same logic.

Mateusz Konieczny wrote:
> This language=en tag would be placed on a administrative
> relation, right?

If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag, though putting it on admin relations is an
interesting idea.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk



_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Mateusz Konieczny-3
In reply to this post by Richard Fairhurst

24. Apr 2018 21:29 by [hidden email]:
If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag


Interesting idea, I like it. Is there already a page on the OSM wiki describing this proposal?


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Darafei "Komяpa" Praliaskouski
Hi,

maps.me took approach similar to Nominatim's: each map region has "default language" in metadata, and in case the name:<default_language_here> is needed but is missing, just name tag is taken.

Similar approach was used when making a map for Wargaming's World of Tanks, looking at the country's iso code. A list used there is available on github,

(Translations that OSM lacks were performed by professional translators and also published under ODbL, https://github.com/wgnet/globalmap/blob/master/data/wgnl_localizations.csv, and for non-critical map labels we've trained anything-to-latin and anything-to-cyrillic neural networks, results https://github.com/wgnet/globalmap/tree/master/data/rnn).

ср, 25 апр. 2018 г. в 9:23, Mateusz Konieczny <[hidden email]>:

24. Apr 2018 21:29 by [hidden email]:

If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag


Interesting idea, I like it. Is there already a page on the OSM wiki describing this proposal?

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Jo-2
In reply to this post by Mateusz Konieczny-3
2018-04-25 8:21 GMT+02:00 Mateusz Konieczny <[hidden email]>:

24. Apr 2018 21:29 by [hidden email]:
If I read Frederik's proposal right, the language=en tag would be placed on
the object with the name tag


Interesting idea, I like it. Is there already a page on the OSM wiki describing this proposal?

Hi Mateusz, 

There is this proposal:


Apparently it failed.

Polyglot


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Christoph Hormann-2
On Wednesday 25 April 2018, Jo wrote:
>
> There is this proposal:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Language_information_for_name

That was a very different idea to what Frederik mentioned - this was
meant to specify the language of the name=* tag.  This was intended to
solve a very specific problem but was mostly rejected because it would
add a lot of complexity to only solve that problem but not affect most
of the other language related issues in mapping.

Lukas had made another proposal ultimately rejected that is somewhat
more generic but is still doing things 'the other way round', i.e. by
providing language information for the name tag:

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


I don't think the idea of specifying the local name by reference to the
local language has so far been elaborated on in the OSM wiki.

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

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Janko Mihelić
In reply to this post by Darafei "Komяpa" Praliaskouski


sri, 25. tra 2018. u 08:51 Darafei "Komяpa" Praliaskouski <[hidden email]> napisao je:
Hi,

maps.me took approach similar to Nominatim's: each map region has "default language" in metadata, and in case the name:<default_language_here> is needed but is missing, just name tag is taken.

I think this is the best solution with the least amount of work for mappers. But we put default languages in regions instead of an external database, as someone before me already mentioned.

Tag the default language on the whole country (official_language=hr). If a region of a country has two official languages and the labels are, for example, Rovinj/Rovigno, then put a official_language=hr/it. And on the safe side, tag all the other subregions with official_language=hr, if the data renderer chooses to download only one region.

After that, no other changes are needed.

Janko Mihelić


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Mateusz Konieczny-3
It is not handling
- regions with more than one widespread language
- features that have name tag in an atypical language

26. Apr 2018 10:04 by [hidden email]:



sri, 25. tra 2018. u 08:51 Darafei "Komяpa" Praliaskouski <[hidden email]> napisao je:
Hi,

maps.me took approach similar to Nominatim's: each map region has "default language" in metadata, and in case the name:<default_language_here> is needed but is missing, just name tag is taken.

I think this is the best solution with the least amount of work for mappers. But we put default languages in regions instead of an external database, as someone before me already mentioned.

Tag the default language on the whole country (official_language=hr). If a region of a country has two official languages and the labels are, for example, Rovinj/Rovigno, then put a official_language=hr/it. And on the safe side, tag all the other subregions with official_language=hr, if the data renderer chooses to download only one region.

After that, no other changes are needed.

Janko Mihelić


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Daniel Koć
W dniu 26.04.2018 o 11:51, Mateusz Konieczny pisze:
> It is not handling
> - regions with more than one widespread language
> - features that have name tag in an atypical language

In my opinion there's no single solution for atypical cases, yet it's
sane to start with defaults. It can be used on many levels and region
can have more than one language defined, just like Janjko has shown:

Country A - official_language=hr
Region B - official_language=hr;it
City C - official_language=it

When a data consumer tries to find what is the official language for
street D, she finds that city C uses "it", so it's enough to know that
the street should be also in "it". Speaking of regions this is the
proper handling in my opinion - in region B you can for example use both
languages or choose the one you prefer, it's up to you.

But we don't have to stop with level 2, 4, or 6. If - for some reason -
part of the city is different and we have no way to show the borders of
the area, one can add official_language=* for the streets or objects in
this particular area. Of course instead of official_language we may use
default_language=* or common_language=* tag or something similar, the
same as the users have to choose common name for name=*.

This way we can always assume some language for the (administrative)
area, but if it's not true locally, we can be more specific, up to the
single objects.

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



_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: Name:* tags in the local language

Daniel Koć
W dniu 26.04.2018 o 13:53, Marc Gemis pisze:
> Do you now assume that names in region B outside city C have a
> namehr;nameit in the name tag?

Yes, unless stated otherwise for cities E, F and G.

To be clear: I assume only that if they name:hr=* and name:it=*, both
are official, but that doesn't mean both need to be tagged (one or more
name tag may be just missing).

> That's not how we have done it for Belgium or any street in Brussels.

Isn't it like this:

Country Belgium - official_language=de;fr;nl
Region Brussels-Capital - official_language=fr;nl
City Eupen - official_language=de

What would be wrong with this scheme?

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



_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
12