date:20180503

W dniu 04.05.2018 o 02:30, Yuri Astrakhan pisze:
> Daniel, the only real difference between serving every available
> language and serving just one is cache fragmentation, and that's may
> be different in your case.

Sure, but you're talking about just one link of the chain. The WMF
vector tiles are produced from a database, rasterized somewhere down the
line, then probably written on the disk, served, cached etc, so it's not
that simple.

That's why I ask about the bottom line in this specific case. There are
many factors which will be different (like how complex the style is, for
example), but it's good to estimate the order of magnitude at least. But
all the details are also interesting to me.

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



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

[OSM-talk] Dynamic OSM - Vanuatu Ambae island of no return

2018-05-03 Thread Pierre Béland

Some of you might remember the efforts we made in early 2015 to edit Vanuatu 
islands and map in detail to support the humanitarian organizations, this just 
after the yearly Ebola response. Since then, many signals of precarious 
situations in islands in this south pacific area. Quite sad to read this time, 
the Vanuatu government orders permanent departure from Ambae island.

see 
https://www.theguardian.com/world/2018/apr/19/island-of-no-return-vanuatu-evacuates-entire-population-of-volcanic-ambae


 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

Daniel, the only real difference between serving every available language
and serving just one is cache fragmentation, and that's may be different in
your case.

The vector tiles get pre-generated the same way, and they simply contain
all languages instead of one. Disk space wise, the difference is
inconsequential.

Kartotherian dynamically picks the language during the rendering. There is
some (not yet measured, but hopefully very small) performance penalty doing
dynamic language picking, but that should not be a big impact in case of a
good caching in front of the rendering.  I would recommend simply putting a
few Varnish boxes in front of your rendering servers if you are ok with the
maps being a bit stale.

On Fri, May 4, 2018 at 2:32 AM Daniel Koć  wrote:

> W dniu 04.05.2018 o 01:17, Joe Matazzoni pisze:
>
> > b) how many server resources do you need for rendering  languages
> > that you want to support (not the software stack used)?
> >
> > ?? Are you asking about OSM resources or WMF resources?
>
> I mean WMF resources.
>
> I'm asking because we want to have localized maps in OSM too and
> rendering just one (default) raster style eats most of the resources of
> 4 servers. This would not work for (let's say) 300 language versions, of
> course.
>
> We refresh default rendering in minutes usually, but even if we use more
> relaxed times for localized maps, it's still too much - with 1 language
> per day we would refresh them all once a year...
>
> We think about vector style migration lately, so it might help here, but
> I don't think this will work like 100x times faster.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Pierre Béland

I have seen a lot of these images and I also believe that we wont need these 
static images if we can interface properly between OSM and Wikipedia. We just 
need the recipes for dynamic connections between the two systems :)

 
Pierre 
 

Le jeudi 3 mai 2018 19 h 43 min 38 s HAE, Joe Matazzoni 
 a écrit :  
 
 I found another OSM page directed at OSM-Wikimedia collaboration [1]. This one 
encourages OSM users to add images of OSM maps to Wikimedia wikis as static 
graphics. As such, I wonder if advances in placing dynamic dynamic maps in 
wikis (though mapframe and maplink has made this page somewhat out of date? I 
don’t feel that I have the standing in the OSM community to update such a page…
And please remember to suggest a short list of OSM Help pages that will be 
useful for Wikimedians coming to OSM for the first time to add multilingual 
names. Thanks!  
Joe


[1] https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

_


Joe Matazzoni 
 Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 

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

Re: [OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Pierre Béland

Hi Joe

These features are promizing. My observations will be focused on the
interrelations between OSM and Wikipeda and my perception that OSM contributors
need more documentation to support Wikipedians.

I was contacted recently by a Wikipedian who talked to me about the maplink
feature and was looking how to represent a river (watershed or other
possibilities). From our exchanges, we saw different possibilities but I could
not find what to do on the OSM side to use these features. It says that we can
both represent polygons or lines. Adding wikidata and waiting up to four days,
I had no success. Good examples that are working would help. I have a
Wikipeda account and also tried to use these features in a wikipedia page using
mapframe but with no success.

Should we simply add a wikidata and wikipedia will take care. Should we define
a mapframe in a wikipedia page? Or the two options are available?

The example below shows an OSM relation for a polygon that is well represented
in Wikipedia.https://fr.wikipedia.org/wiki/R%C3%A9servoir_La_Grande_4#/maplink/0

But adding a wikidata tag to a OSM waterway riverbank about four days ago, I
only see a node represented on the wikipedia maplink map.
https://fr.wikipedia.org/wiki/Rivi%C3%A8re_L'Assomption#/maplink/0
We need more infos on what type of OSM features can be represented in
Wikipedia. Also, should the wikidata be unique or not in OSM. For example, if I
represent a municipality with both a relation for the polygon borders and a
node for the OSM place, where should I place the wikidata? On the relation? on
the node? On both? Or two different wikidatga iD's? It depends if I want to
represent the polygon or the node or both?

Territories are also interesting to represent. We often see images in Wikipedia
but how to make a link to an OSM object in Wikipedia? See for example
Longueuil, Québec who has two different wikidata for polygon and node.
Wikipedia maplink shows a node, but not sure this is related to the node
wikidata.
https://fr.wikipedia.org/wiki/Longueuil#/maplink/0https://www.openstreetmap.org/relation/6948543
https://www.openstreetmap.org/node/252025539
Pierre

Le jeudi 3 mai 2018 16 h 53 min 21 s HAE, Joe Matazzoni
a écrit :

Hello OpenStreetMap community,I’m the product manager of the Wikimedia
Foundation (WMF) Collaboration Team. We’ve been working on project recently
called Map Improvements 2018 [1] that some of you will find interesting. As
most of you probably know, WMF maps are powered by OSM data. The most
significant new feature that we’ll be releasing very soon as part of this
project is map “internationalization”—which means that’s WMF maps will display
in the language of the user, rather than of the territory mapped. I wrote a
recent post describing this feature and how it works [2].
We’re also about to spread our embedded maps capability (“mapframe”) to
hundreds of Wikipedias that don’t have the feature now. The
internationalization release will follow soon after. These should be welcome
developments for the OSM community, I hope, since they will put OSM-powered
maps in front of many millions of new users.
We don’t anticipate that these new maps will put any strain on OSM performance.
The impact I do foresee—and hope for—is that the new exposure of multilingual
map data will inspire many more Wikimedians to contribute to OSM. This is
likely to happen when users start to see, as they will for the first time, that
names in their language for some features and places are not available.
I’m writing today to let you know that these changes—and possibly these new
contributors—are coming, and to ask for any guidance you think I should pass on
to Wikimedians who might like to contribute to OSM. We plan to write a Help
page on our end that will pass on some basic advice. And I will certainly link
to relevant OSM Help pages, including this"Welcome to Wikipedia users” [3]
page. I’d very much like to get your suggestions for a short list of Help links
on OSM—pages you think a user coming in to add multilingual names would find
useful. Also please send your thoughts about any information you think I
particularly should impart.
Please post your thoughts and ideas to the project talk page [4]. Thanks for
your help, and for providing the valuable service you do to Wikimedia
contributors and readers around the world.

[1]https://www.mediawiki.org/wiki/Map_improvements_2018[2]
https://www.mediawiki.org/wiki/Map_improvements_2018#April_18,_2018,_Special_Update_on_Map_Internationalization[3]
https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users[4]
https://www.mediawiki.org/wiki/Talk:Map_improvements_2018
_

Joe Matazzoni
Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum
of all knowledge."

Re: [OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Joe Matazzoni

I found another OSM page directed at OSM-Wikimedia collaboration [1]. This one 
encourages OSM users to add images of OSM maps to Wikimedia wikis as static 
graphics. As such, I wonder if advances in placing dynamic dynamic maps in 
wikis (though mapframe and maplink has made this page somewhat out of date? I 
don’t feel that I have the standing in the OSM community to update such a page…

And please remember to suggest a short list of OSM Help pages that will be 
useful for Wikimedians coming to OSM for the first time to add multilingual 
names. Thanks!  

Joe


[1] https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia 

_

Joe Matazzoni 
Product Manager, Collaboration
Wikimedia Foundation, San Francisco


"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 


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

Re: [OSM-talk] OSM and new Wikipedia map features

W dniu 04.05.2018 o 01:17, Joe Matazzoni pisze:

> b) how many server resources do you need for rendering  languages
> that you want to support (not the software stack used)?
>
> ?? Are you asking about OSM resources or WMF resources?

I mean WMF resources.

I'm asking because we want to have localized maps in OSM too and
rendering just one (default) raster style eats most of the resources of
4 servers. This would not work for (let's say) 300 language versions, of
course.

We refresh default rendering in minutes usually, but even if we use more
relaxed times for localized maps, it's still too much - with 1 language
per day we would refresh them all once a year...

We think about vector style migration lately, so it might help here, but
I don't think this will work like 100x times faster.

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



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

Re: [OSM-talk] OSM and new Wikipedia map features

W dniu 04.05.2018 o 00:33, Joe Matazzoni pisze:

> Here is the list of languages Wikimedia
> supports. https://en.wikipedia.org/wiki/Special:SiteMatrix
> 
>  .
> As to the toolchain, if you ask that question on the project page,
> some of our engineers will be able to respond.  Be sure to explain why
> you’re asking, so we can answer you fully.

It's not exactly what interests me:

a) do you want to support all these languages (not how many of them are
there)?

b) how many server resources do you need for rendering  languages
that you want to support (not the software stack used)?

Do you know it or should I ask the engineers anyway?

> That is a very interesting edge case we hadn’t thought of.  We’ll have
> to look into that one; our lead engineer just wrote a ticket to
> investigate: https://phabricator.wikimedia.org/T193815
> .
>  I know about Serbian. What other languages do this?

Belorusian has two writing systems (see http://openstreetmap.by for 4
languages demo).

Chineese has few different writing systems.

Buginese can use Lontara or Latin script.


There might be more of such cases.

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

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

Re: [Talk-at] Gipfel und Berger: Der "massif"-Tag

2018-05-03 Thread Friedrich Volkmann


On 04.05.2018 00:03, Martin Brunner wrote:

Berge sind ja meist bekannter als die einzelnen Gipfel (zB Koralm/Koralpe und
der Große Speikkogel). Apps wie Peakfinder, die ihre Daten aus der OSM beziehen,
wissen dann eigentlich nur den Gipfel.


Zwischen Bergen und Gipfeln wird im normalen Sprachgebrauch kaum 
unterschieden, und so werden auch in der Kartografie traditionell die 
Bergnamen auf die Gipfel gesetzt. Oft sind sogar die Namen für Felswände 
("...mauer", "...wand") oder für Wälder etc. auf den ganzen Berg und in der 
Folge auf den Gipfel übergegangen.


Was du meinst, ist nicht Gipfel vs. Berg, sondern Gipfel/Berg vs. Massiv 
(dieses Wort gibt es auch im Deutschen) oder Gebirgsgruppe.


Gebirge werden seit jeher als natural=mountain_range gemappt. Die 
Gebirgsgruppen in den Alpen waren, glaube ich, ebenfalls so getaggt, aber 
heute stattdessen mit place=region, was ich weniger passend finde. Beispiel: 
https://www.openstreetmap.org/relation/2450938
Noch unpassender finde ich das Tagging der Sammelrelation 
(https://www.openstreetmap.org/relation/2113486): type=classification heißt 
genau was? Dieser Relationstyp hat nicht mal eine Wikiseite. Und Namen hat 
die Relation auch keinen. Wie sollen Anwendungen so eine Relation auswerten 
können?



Wenn icht das recht verstehe, sollte der "massif"-Tag hier Abhilfe schafen. Beim
konkreten Beispiel wurde er auch schon verwendet, sonst leider eher selten:
https://www.openstreetmap.org/node/26863416

Laut Diskussion im IRC war er aber eigentlich ursprüngliche als Fläche gedacht
(was die Abfrage dann wieder schwerer macht).


Ich finde, dass es nur als Fläche Sinn macht, und das ist dann das gleiche 
wie oben für Gebirgsgruppen beschrieben, nur halt mit massif=* statt 
natural=mountain_range bzw. place=region.


Welche Gipfel-Nodes in welcher Massiv-Fläche liegen, ist für Anwendungen 
leicht auswertbar. Eine Verknüpfung mittels massiv=* -Tag ist hingegen Pfusch.



Daher nun die konkreten Fragen:
Ergibt es Sinn, diesen Tag zu verwenden, wie im oben genannten Beispiel? Das
könnte man dann ja laufend ergänzen.


Meiner Meinung nach nein.


Die zweite Frage: Wie sieht es aus, wenn das Gebirge Bezeichnungen in mehreren
Sprachen hat? Zum Beispiel Bachergebirge/Pohorje.


Wenn das Gebirge als Fläche (bzw. Multipolygon) gemappt ist, dann geht das 
ganz leicht mittels name=*, alt_name=*, name:de=*, name:sl=* usw.


Bei einem länderübergreifenden Gebirge ist nur der Streitpunkt, welcher der 
Namen als name=* genommen werden soll. Das gleiche Problem besteht z.B. auch 
bei der Donau. Möglichkeiten gibt es mehrere, aber keine davon ist befriedigend.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] OSM and new Wikipedia map features

W dniu 03.05.2018 o 23:20, Yuri Astrakhan pisze:

> I have posted in another threads about this, proposing
> "default_language" tag to be added to the admin (or smaller) regions
> to solve this. 

I like this proposition. I was talking about "official_language", but
they might be added where they are known and defined, yet most of the
time "default_language" would be the best solution.

But we need to distinguish two different cases: hint for debugging
"name" tag (or any other, like "alt_name", for that matter) and real set
of default languages, for example:

name=België / Belgique / Belgien
name:default_language=nl / fr / de
default_language=de;fr;nl

You can analyze "name" (which might be specially crafted, for example to
be shorter) or just glue proper values like name:de, name:fr and name:nl
somehow, whatever suits your needs better.

We should also think of different scripts or conventions used with the
same language. Example:

name=Norge
name:default_language=nb

name:nb=Norge
name:nn=Noreg
default_language=nb;nn

Another example (I have to use some guess work):

name=中国
name:default_language=zh

name:zh=中国
name:zh-classical=中國
name:zh-hans=中国
name:zh-hant=中國
name:zh-min-nan=Tiong-hôa
name:zh-simplified=中国
name:zh-traditional=中國
name:zh-yue=中國
name:zh_pinyin=Zhōngguó
default_language=zh

(well, probably...)

> Copying the rules:
>
> * Use the largest possible admin region to set the "default_language"
> tag to a single language code.  "default_language" does not mean the
> official language of the region. It only specifies the language of the
> "name" tag.
> * A region may contain a sub-region with a different default_language.
> * If a region uses mixed languages in all of its name tags, eg. "[name
> in en] - [name in zh]", set default_language="en - zh".  Try to keep
> it to a somewhat parsable value to help data consumers.
> * In some rare cases, additional non-admin regions might be required
> for the default_language.  Try to avoid it if possible.

I would also add "default_language=none". It's not needed until you make
the cascading definitions (inheritance). When you don't know or it's
just hard to get right, it's good to "switch off" and fallback to what
we have now.

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

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

Re: [OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Joe Matazzoni

Hi Daniel,
I’ll look for your contributions on the project talk page. Thanks. Meanwhile, 
here are answers to your questions:

> 1. The localized maps lack fallback rules (I'm speaking of Polish

> language at least). I would ask for English as a fallback for maps in

> Polish, but I don't know where should it be requested or configured? Is

> this list the right place?:

No fallback is currently defined for Polish. We’ll be happy to change that if 
you can show community consensus. Make sure your community understands that 
maps have a separate fallback list from the general language fallback list for 
the wiki, where the fallback controls things like what language UI messages are 
shown in. The two lists are identical at the moment, but having two separate 
lists means that you can change the way maps behave without having to change 
behavior for the wiki in general. So that should make getting consensus easier. 
When you have consensus, leave a request with a link to the discussion on the 
maps project page, or fill in a phabricator ticket and tag it to both “maps” 
and "Collaboration-Feature-Rollouts (Collaboration-Maps)”.

> 2. How many languages do you want to support in total and what hardware

> resources are needed for that using your toolchain?

Here is the list of languages Wikimedia supports. 
https://en.wikipedia.org/wiki/Special:SiteMatrix 

 . As to the toolchain, if you ask that question on the project page, some of 
our engineers will be able to respond.  Be sure to explain why you’re asking, 
so we can answer you fully. 

> 3. What about the same language using different scripts, do you plan to

> support them all?

That is a very interesting edge case we hadn’t thought of.  We’ll have to look 
into that one; our lead engineer just wrote a ticket to investigate: 
https://phabricator.wikimedia.org/T193815 
.
  I know about Serbian. What other languages do this? 

Best,
Joe
_

Joe Matazzoni 
Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 

> On May 3, 2018, at 2:50 PM, Daniel Koć  wrote:
> 
> W dniu 03.05.2018 o 22:49, Joe Matazzoni pisze:
> 
>> Please post your thoughts and ideas to the project talk page [4].
>> Thanks for your help, and for providing the valuable service you do to
>> Wikimedia contributors and readers around the world. 
> 
> I will try to put my thoughts there.
> 
> However I also have some questions for you:
> 
> 1. The localized maps lack fallback rules (I'm speaking of Polish
> language at least). I would ask for English as a fallback for maps in
> Polish, but I don't know where should it be requested or configured? Is
> this list the right place?:
> 
> https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json
> 
> 2. How many languages do you want to support in total and what hardware
> resources are needed for that using your toolchain?
> 
> 3. What about the same language using different scripts, do you plan to
> support them all?
> 
> -- 
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] OSM and new Wikipedia map features

I cannot speak for WMF, only about the actual Kartotherian stack behind it,
and the way they are currently using it:

On Fri, May 4, 2018 at 12:52 AM Daniel Koć  wrote:

>
> 1. The localized maps lack fallback rules (I'm speaking of Polish
> language at least). I would ask for English as a fallback for maps in
> Polish, but I don't know where should it be requested or configured? Is
> this list the right place?:
>
> https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json
>
> See also how the name tag is picked here:
https://github.com/kartotherian/babel/blob/master/lib/LanguagePicker.js#L106
It has went through several revisions recently, so this is somewhat in a
flux.

2. How many languages do you want to support in total and what hardware
> resources are needed for that using your toolchain?
>

Kartotherian itself can handle unlimited number of languages.  Vector tiles
can simply hold every possible language, and babel picks the one you want
based on the above heuristic.   My understanding is that currently WMF does
not filter out any languages, nor does it plan to, so any lang=xx would
work, where xx comes directly from the name:xx tags.

> 3. What about the same language using different scripts, do you plan to
> support them all?
>
> Babel does not actually know much about the "language". It looks at the
language codes, trying to match it to the fallbacks, and uses heuristic
when fallback fails.   E.g. it should be possible to simply have two
language codes for Serbian in Latin & Cyrillic, and say that if one is
available when the other is not, to fallback.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-at] Gipfel und Berger: Der "massif"-Tag

2018-05-03 Thread Martin Brunner

Folgende Frage:
Berge sind ja meist bekannter als die einzelnen Gipfel (zB Koralm/Koralpe und
der Große Speikkogel). Apps wie Peakfinder, die ihre Daten aus der OSM beziehen,
wissen dann eigentlich nur den Gipfel.

Wenn icht das recht verstehe, sollte der "massif"-Tag hier Abhilfe schafen. Beim
konkreten Beispiel wurde er auch schon verwendet, sonst leider eher selten:
https://www.openstreetmap.org/node/26863416

Laut Diskussion im IRC war er aber eigentlich ursprüngliche als Fläche gedacht
(was die Abfrage dann wieder schwerer macht).

Daher nun die konkreten Fragen:
Ergibt es Sinn, diesen Tag zu verwenden, wie im oben genannten Beispiel? Das
könnte man dann ja laufend ergänzen.

Die zweite Frage: Wie sieht es aus, wenn das Gebirge Bezeichnungen in mehreren
Sprachen hat? Zum Beispiel Bachergebirge/Pohorje.

lg
Martin

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] OSM and new Wikipedia map features

W dniu 03.05.2018 o 22:49, Joe Matazzoni pisze:

> Please post your thoughts and ideas to the project talk page [4].
> Thanks for your help, and for providing the valuable service you do to
> Wikimedia contributors and readers around the world. 

I will try to put my thoughts there.

However I also have some questions for you:

1. The localized maps lack fallback rules (I'm speaking of Polish
language at least). I would ask for English as a fallback for maps in
Polish, but I don't know where should it be requested or configured? Is
this list the right place?:

https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json

2. How many languages do you want to support in total and what hardware
resources are needed for that using your toolchain?

3. What about the same language using different scripts, do you plan to
support them all?

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



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

Re: [OSM-talk] OSM and new Wikipedia map features

P.S. example - this library [1] might be a good fit (any other
suggestions?). It does universal transliteration, yet even the author
writes this:

"transliteration supports almost all common languages whereas there might
be quirks in some specific languages. For example, Kanji characters in
Japanese will be transliterated as Chinese Pinyin. I couldn't find a better
way to distinguish Chinese Hanzi and Japanese Kanji. So if you would like
to romanize Japanese Kanji, please consider kuroshiro."

[1]: https://www.npmjs.com/package/transliteration#caveats

On Fri, May 4, 2018 at 12:20 AM Yuri Astrakhan 
wrote:

> Christoph, I agree that this would be an awesome improvement, yet I think
> there is a problem to implement it. Most languages have their own
> transliteration rules, so transliterating "name" tag without the knowledge
> of its language will produce a lot of incorrect names.
>
> I have posted in another threads about this, proposing "default_language"
> tag to be added to the admin (or smaller) regions to solve this.  Copying
> the rules:
>
> * Use the largest possible admin region to set the "default_language" tag
> to a single language code.  "default_language" does not mean the official
> language of the region. It only specifies the language of the "name" tag.
> * A region may contain a sub-region with a different default_language.
> * If a region uses mixed languages in all of its name tags, eg. "[name in
> en] - [name in zh]", set default_language="en - zh".  Try to keep it to a
> somewhat parsable value to help data consumers.
> * In some rare cases, additional non-admin regions might be required for
> the default_language.  Try to avoid it if possible.
>
>
> On Fri, May 4, 2018 at 12:09 AM Christoph Hormann  wrote:
>
>> On Thursday 03 May 2018, Joe Matazzoni wrote:
>> > [...]
>> >
>> > We don’t anticipate that these new maps will put any strain on OSM
>> > performance. The impact I do foresee—and hope for—is that the new
>> > exposure of multilingual map data will inspire many more Wikimedians
>> > to contribute to OSM. This is likely to happen when users start to
>> > see, as they will for the first time, that names in their language
>> > for some features and places are not available.
>>
>> The first and most fundamental thing you should do is add
>> automatic transliteration as a fallback for multilingual names.
>> Otherwise people will inevitably add tons of non-verifiable
>> transliterated names in a misguided attempt improve the map.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

Christoph, I agree that this would be an awesome improvement, yet I think
there is a problem to implement it. Most languages have their own
transliteration rules, so transliterating "name" tag without the knowledge
of its language will produce a lot of incorrect names.

I have posted in another threads about this, proposing "default_language"
tag to be added to the admin (or smaller) regions to solve this.  Copying
the rules:

* Use the largest possible admin region to set the "default_language" tag
to a single language code.  "default_language" does not mean the official
language of the region. It only specifies the language of the "name" tag.
* A region may contain a sub-region with a different default_language.
* If a region uses mixed languages in all of its name tags, eg. "[name in
en] - [name in zh]", set default_language="en - zh".  Try to keep it to a
somewhat parsable value to help data consumers.
* In some rare cases, additional non-admin regions might be required for
the default_language.  Try to avoid it if possible.

On Fri, May 4, 2018 at 12:09 AM Christoph Hormann  wrote:

> On Thursday 03 May 2018, Joe Matazzoni wrote:
> > [...]
> >
> > We don’t anticipate that these new maps will put any strain on OSM
> > performance. The impact I do foresee—and hope for—is that the new
> > exposure of multilingual map data will inspire many more Wikimedians
> > to contribute to OSM. This is likely to happen when users start to
> > see, as they will for the first time, that names in their language
> > for some features and places are not available.
>
> The first and most fundamental thing you should do is add
> automatic transliteration as a fallback for multilingual names.
> Otherwise people will inevitably add tons of non-verifiable
> transliterated names in a misguided attempt improve the map.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] come inserire una finanziaria

2018-05-03 Thread Andrea Albani

Se intendi un posto fisico dove erogano prestiti (es. Ducato, Agos, etc)
allora io userei

shop=money_lender

Non lo trovi fra tra i preset di JOSM quindi va inserito a mano assieme
almeno a name (e magari operator).

Ciao

Il giorno 3 maggio 2018 22:48, claudio duchi  ha scritto:

> salve sono alle prime armi
> uso josm per inserire i dati ma non trovo il tag adatto
> che fare?
> Claudio
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Christoph Hormann

On Thursday 03 May 2018, Joe Matazzoni wrote:
> [...]
>
> We don’t anticipate that these new maps will put any strain on OSM
> performance. The impact I do foresee—and hope for—is that the new
> exposure of multilingual map data will inspire many more Wikimedians
> to contribute to OSM. This is likely to happen when users start to
> see, as they will for the first time, that names in their language
> for some features and places are not available.

The first and most fundamental thing you should do is add 
automatic transliteration as a fallback for multilingual names.  
Otherwise people will inevitably add tons of non-verifiable 
transliterated names in a misguided attempt improve the map.

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

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

[OSM-talk] OSM and new Wikipedia map features

2018-05-03 Thread Joe Matazzoni

We’re also about to spread our embedded maps capability (“mapframe”) to
hundreds of Wikipedias that don’t have the feature now.
The internationalization release will follow soon after. These should be
welcome developments for the OSM community, I hope, since they will put
OSM-powered maps in front of many millions of new users.

We don’t anticipate that these new maps will put any strain on OSM performance.
The impact I do foresee—and hope for—is that the new exposure of multilingual
map data will inspire many more Wikimedians to contribute to OSM. This is
likely to happen when users start to see, as they will for the first time, that
names in their language for some features and places are not available.

I’m writing today to let you know that these changes—and possibly these new
contributors—are coming, and to ask for any guidance you think I should pass on
to Wikimedians who might like to contribute to OSM. We plan to write a Help
page on our end that will pass on some basic advice. And I will certainly link
to relevant OSM Help pages, including this"Welcome to Wikipedia users” [3]
page. I’d very much like to get your suggestions for a short list of Help links
on OSM—pages you think a user coming in to add multilingual names would find
useful. Also please send your thoughts about any information you think I
particularly should impart.

Please post your thoughts and ideas to the project talk page [4]. Thanks for
your help, and for providing the valuable service you do to Wikimedia
contributors and readers around the world.

[1]https://www.mediawiki.org/wiki/Map_improvements_2018

[2]
https://www.mediawiki.org/wiki/Map_improvements_2018#April_18,_2018,_Special_Update_on_Map_Internationalization

[3] https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users

[4] https://www.mediawiki.org/wiki/Talk:Map_improvements_2018

Joe Matazzoni
Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum
of all knowledge."

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

[Talk-it] come inserire una finanziaria

2018-05-03 Thread claudio duchi

salve sono alle prime armi
uso josm per inserire i dati ma non trovo il tag adatto
che fare?
Claudio
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread David Woolley


On 03/05/18 17:53, Robert Whittaker (OSM lists) wrote:

I would use a node where the van stops, tagged with
amenity="post_office", name="Over Mobile Post Office Service",



That seems to break the name is only the name rule.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSRM-talk] U-turn penalty?

2018-05-03 Thread Xavier Prudent

Dear all,

As a follow-up on my question, for anyone facing the issue:
my way out of this question of forbidding u-turns has been to get a local
version of the OSM map and to edit it using JOSM. I then applied detailed
constraints using the turnrestriction plugin.
Good luck!

Regards,

Xavier Prudent

2018-04-23 18:17 GMT-04:00 Xavier Prudent :

> Hello,
>
> I want to forbid u-turns during the routing.
> I hence played with the u_turn_penalty parameter in profiles/car.lua
>
>   u_turn_penalty = 20,
>
> then reconstructed the osrm objects using osrm-extract and osrm-contract.
> I tried values 0, 20, 240 and 1000. The routing clearly changed, but I
> keep on getting u-turns. For higher parameters I even get more u-turns.
>
> My understanding was that the higher the parameter, the less u-turn one
> should have.
>
> Did I understand correctly? How can I forbid u-turn then?
>
> Regards,
>
> Xavier
>
> --
>
> *Xavier Prudent *
>
> *Data Scientist  - Data Mining - Machine Learning*
>
> Web:* www.xavierprudent.com *
> Tel (Québec)  : (514) 668 76 46
> Skype : xavierprudent
>
>
>


-- 

*Xavier Prudent *

*Data Scientist  - Data Mining - Machine Learning*

Web:* www.xavierprudent.com *
Tel (Québec)  : (514) 668 76 46
Skype : xavierprudent
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Colin Smale

Are these additional services legally obliged, or are they offered as a
result of a commercial agreement? 

Perhaps designation=uk_post_office may be a useful addition to indicate
that the legally-obliged services are available at this location. Some
services are only available at what used to be called "Crown Post
Offices", so designation=uk_crown_post_office could be used here. 

The other stuff, like currency exchange, is almost certainly a
commercial agreement, with no obligation on a particular post office to
offer this service. In this case I would add currency_exchange=yes for
example, so one can see where it is, and is not, available. 

This would separate the legally required functions (including buying a
stamp etc) from the "options". 

Colin

On 2018-05-03 12:14, Philip Barnes wrote:

> I would avoid using amenity=post_office for anything other than a proper post 
> office.
> 
> The term post office is much more than a place to send parcels or letters.
> 
> In the UK a post office offers
> Banking services
> I can tax my car
> I can apply for a passport
> I can collect my pension
> Exchange currency 
> Probably lots of other things that I've not thought of. 
> 
> Whilst post depot is useful for collecting things that an individual has 
> ordered, sending stuff by courier is a business service. DHL will not be 
> interested in sending my Christmas cards and certainly not for the price 
> Royal mail charges. 
> 
> Phil (trigpoint) 
> 
> On 3 May 2018 10:45:57 BST, Michael Collinson  wrote: 
> 
> At the risk of being pedantic, but would a "network" tag, similar to bus 
> routes, not be more appropriate? 
> 
> Here in Sweden, the post office system is now Post Nord, network=Post Nord, 
> but post offices are frequently inside and operated by supermarkets, e.g. 
> operator=ICA. These outlets often handle DHL and other services that might 
> also be considered as postal networks, network=Post Nord;DHL 
> 
> Mike 
> On 2018-05-03 11:15, Brian Prangle wrote: 
> 
> Hi Robert
> If an operator tag is added to post_office tags then your comparison tool 
> would be OK
> Regards
> Brian 
> 
> On 3 May 2018 at 10:08, Robert Whittaker (OSM lists) 
>  wrote:
> On 2 May 2018 at 19:08, David Woolley  wrote:
>> On 02/05/18 18:52, ael wrote:
>>> 
>>> I am confused:-)  How should a Royal mail local delivery office be
>>> tagged? It seems that it is not amenity=post_office. I notice that
>>> I have used post_depot once some time ago, but that doesn't seem to be
>>> in the wiki (or in the presets for josm). Yet I am sure that I got it
>>> from somewhere. Not that it seems very natural.
>> 
>> I'm fairly sure this came up a couple of months ago and the answer was
>> amenity=post_depot; operator=Royal Mail.  It's not, in principle, different
>> from Hermes or TNT.
> 
> That's certainly what I'd use. I think there's a good case for tagging
> customer-facing shop-like outlets of courier firms as
> amenity=post_office since they're places from which you can send
> stuff. But for the large warehouse-style sorting/distribution centres
> I think something else is needed. amenity=post_depot seems a good
> choice to me. It has over 400 uses worldwide, of which over 300 are in
> the UK.
> 
> The legitimate use of amenity=post_office for non-Post Office Ltd
> branches creates a slight issue for my comparison tool. I've got some
> heuristics to account for some sets of objects based on name,
> operator, and brand tagging. See:
> http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol [1]
> 
> Robert.
> 
> -- 
> Robert Whittaker
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb [2] 
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb 

Links:
--
[1] http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol
[2] https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Robert Whittaker (OSM lists)

On 3 May 2018 at 14:02, Andy G Wood  wrote:
> I know one of the unmapped post offices is still "open" in my village
> http://robert.mathmos.net/osm/postoffice/branch/110053
> however, it is basically a mobile van that turns up on the village green for
> some hours a few days a week.  How can this be mapped?

I would use a node where the van stops, tagged with
amenity="post_office", name="Over Mobile Post Office Service",
ref:pol_id="110053" and opening_hours="Mo,Th,Fr 09:30-12:30; We
09:30-11:00" (assuming they're correct). The name tag should give map
users a clue that it may not be open all the time during normal
working hours, and the opening_hours tag will let data users who look
know exactly when they'll find a Post Office there.

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-ja] 高速道路の定義について(まとめページ)

2018-05-03 Thread yuu hayashi

hayashiです

> 確認したかったのは、
> motorwayを自動車専用道路から高速道路ナンバリングされた道路へ変更することにより、歩行者・自転車・
小型二輪ユーザーが利用するであろうルーティング機能へあらわれる影響について、
> それが推定なのか、それとも事実（または事実の伝聞）なのか、です。
紛れもなく事実です。
が、仮に推定であったとしても「ルーティング機能」に影響を及ぼすことは誰でも容易に想像できることです。
逆に質問いたします。既存のルーティング機能に影響を及ぼさないとする理由を教えてください。


> motorwayを自動車専用道路から高速道路ナンバリングされた道路へ変更しても、同時にaccess=*
を正しく設定すれば影響はなさそうだと考えるようになりました。
互換性が取れないので、影響が出ます。前回のメールでも説明しました。


> あまのさんのhayashiさんへの4/24の質問についてお聞きしました。4/15分ではありません。
> 以下に引用しますので、あらためて確認いただけますか。
4月24日に既に回答済みです。
*4月 29日*の回答の中にもより詳しく回答しています。

私の意見が間違っていると思われるのでしたら、「質問」ではなく、具体的な「反証」を提示してください。
「質問」は私への個人メールでお問い合わせください。



2018年5月2日 19:02 Ras and Road :

> Ras and Road です。
>
> hayashiさん、
> まず、私の投稿で不快な思いをさせたようで、お詫びします。
> 決して挑発したり茶化すような意図はないのですが、配慮が足りていなかったようです。申し訳ありませんでした。
>
> 私が確認したかったのは、
> motorwayを自動車専用道路から高速道路ナンバリングされた道路へ変更することにより、歩行者・自転車・
> 小型二輪ユーザーが利用するであろうルーティング機能へあらわれる影響について、
> それが推定なのか、それとも事実（または事実の伝聞）なのか、です。
>
> hayashiさんとのやりとり、ならびにGraphHopperやその他のルーティング機能を試してみて、
> motorwayを自動車専用道路から高速道路ナンバリングされた道路へ変更しても、同時にaccess=*
> を正しく設定すれば影響はなさそうだと考えるようになりました。
> とは言え、所詮は十件程度の確認ですので不十分かも知れません。一人で考えていても仕方がないのでこの場で質問した経緯です。（
> 前回、ここまで書けば誤解は招かなかったでしょうか）
>
> もうひとつ、
> あまのさんのhayashiさんへの4/24の質問についてお聞きしました。4/15分ではありません。
> 以下に引用しますので、あらためて確認いただけますか。
>
> > >「自動車専用道路」は「国で最高品質の道路」とみなすことができます。
> > > また、「自動車専用道路」という言葉には２つの意味がありますが実体は同じですので、標識にアクセス制限の意味があるからと言っても道路品質が担保し
> ていないということにはなりえません。
> > > また、日本の法令上、"いわゆる「高速道路」ならば「自動車専用道路」である"という論理が成立しますので、、
> 定義が曖昧な「いわゆる高速道路」よりも、定義がはっきりしていて識別が簡単な「自動車専用道路」
> >
> > この部分が、私にはどうしてもわかりません。
> > このように成り立つ、根拠法令、施行規則、通達その他を具体的に取り上げて述べて頂けないでしょうか？
>
> ** Ras and Road **
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-talk-fr] Inscription State of the Map

2018-05-03 Thread Vincent Bergeot


Bonjour à tous,

tout est dans le titre

Quasiment à la veille de la publication du programme (S-4), une petite relance 
pour celles et ceux qui viendront, quelque soit le programme (oui toi là je le 
sais !!!).

Ce n'est pas du harcèlement, c'est car cela facilite la commande des tee-shirts, la 
réservation du nombre de repas pour les midis ou le samedi soir ! Cela fait reposer un 
peu moins de "risques" financiers sur l'association OpenStreetMap France qui 
porte le SotM.

C'est donc par ici https://sotm2018.openstreetmap.fr/inscription.html

Pour rappel, quelques mots de Vdct, copiés du premier appel à inscription !

Pour les habitués de la conférence, quelques changements cette année :
- oui, on a un nouveau site tout joli dédié au SOTM \o/
- hélas pas d'offre d'hébergement cette année, faute d'opportunités pertinentes 
(camping, campus) à des prix et distances raisonnables. Il incombe donc à 
chacun de s'occuper de son hébergement. Croyez-bien qu'on le regrette.
- le tarif reste inchangé à 10€, pour permettre un accès au plus grand nombre. 
Vous avez cependant la possibilité*sans obligation aucune*  de contribuer 
financièrement à des tarifs plus élevés, plus proches du vrai coût (45€ pour 
3j). C'est, j'insiste, absolument libre et sans obligation, et une fois sur 
place nous serons toutes et tous logés à la même enseigne
- vous avez via le même formulaire la possibilité de vous inscrire au dîner du 
samedi soir, dîner qu'on a aussi voulu d'un tarif abordable, en vous espérant 
nombreux

Si le lien ci-dessus vous fait des misères, voici le lien direct vers la page 
d'inscription sur Assoconnect :
https://openstreetmap.assoconnect.com/billetterie/offre/70626-a-state-of-the-map-france-2018

à très bientôt à Pessac !

Vincent (pour l'équipe d'organisation)


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Germanenstaffel in Tübingen

Am 3. Mai 2018 um 17:08 schrieb dktue :

> ein besserer Name für dieses Eck (gegenüber) wäre m.E. „Neckartor“, weil
>> dort früher besagtes Stadttor stand und der Name weiterhin benutzt wird.
>
>
> Ist korrigiert. "Germanen-Eck" ist nun alt_name und "Neckartor" name.




wobei, wenn man pingelig ist, das Germaneneck die nord-östliche Ecke der
Kreuzung ist (am Verbindungshaus), und das Neckartor auf der anderen Seite
der Straße lag (unter der Mühlstraße läuft noch der eingedohlte
Mühlengraben, der war früher ausserhalb der Stadt(mauer)). Vielleicht eher
ein Thema für die lokale Liste, hier sind wir auf talk-de und trotz der
Massenabwanderung ins Forum lesen hier sicherlich immer noch einige, die
dazu keinen Bezug haben ;-)

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Germanenstaffel in Tübingen

Am 3. Mai 2018 um 17:05 schrieb dktue :

> Am 03.05.2018 um 14:55 schrieb Martin Koppenhoefer:
>
>> Ich möchte gerne die einzelnen Ways zu einer sinnvollen Relation
>>> zusammmenfassen [2]. Was wäre aus eurer Sicht das korrekte Tagging?
>>>
>> m.E. reicht es, wenn die highway Stücke verbunden sind und alle denselben
>> Namen tragen.
>>
> So handhabt man das ja beispielsweise mit Straßen auch. Aber wie könnte
> ich eintragen, dass die gesamte Treppe 209 Stufen hat?




was ist denn "die gesamte Treppe"? M.E. an die einzelnen Abschnitte jeweils
die Anzahl der Stufen, dann hat man auch die Gesamtangabe implizit. Die
Treppe ist sowieso nicht ganz sicher definiert in Anfang und Ende, gehört
das obere Stück noch dazu oder nicht, z.B.?
Zusätzlich würde ich die Richtung angeben (incline=up), das hatte ich
anfangs immer implizit gemacht, aber im Laufe der Zeit festgestellt, dass
manche Leute "die natürliche Richtung" unterschiedlich sehen.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Germanenstaffel in Tübingen

2018-05-03 Thread dktue


Am 03.05.2018 um 15:07 schrieb Martin Koppenhoefer:

sent from a phone


On 3. May 2018, at 14:55, Martin Koppenhoefer  wrote:

locality hast Du nun ja schon für das angrenzende „Germaneneck“ verwendet, das 
wäre natürlich eine ziemliche Häufung ;-)
Und meiner Meinung nach wäre das auch eine Überbewertung dieser Verbindung.


bisschen OT für Deine Frage hier, aber dieselbe Stelle:
ein besserer Name für dieses Eck (gegenüber) wäre m.E. „Neckartor“, weil dort 
früher besagtes Stadttor stand und der Name weiterhin benutzt wird.

Ist korrigiert. "Germanen-Eck" ist nun alt_name und "Neckartor" name.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Germanenstaffel in Tübingen

2018-05-03 Thread dktue


Am 03.05.2018 um 14:55 schrieb Martin Koppenhoefer:

sent from a phone


On 3. May 2018, at 14:19, dktue  wrote:

in Tübingen gibt es die sogenannte Germanenstaffel [1]. Diese ist in OSM als 
vielzahl einzelner Ways getaggt. Insgesamt besteht die Treppe aus 209 Stufen.

Ich möchte gerne die einzelnen Ways zu einer sinnvollen Relation 
zusammmenfassen [2]. Was wäre aus eurer Sicht das korrekte Tagging?

m.E. reicht es, wenn die highway Stücke verbunden sind und alle denselben Namen 
tragen.
So handhabt man das ja beispielsweise mit Straßen auch. Aber wie könnte 
ich eintragen, dass die gesamte Treppe 209 Stufen hat?


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-ja] 高速道路の定義について

2018-05-03 Thread Ras and Road

Ras and Road です。

[提案1]に関して総論の議論を交わしているところですが、各論でのチェックも必要と思い、
法令上の自動車専用道路と高速道路ナンバリングされた道路の違いを整理し、実際の道路例を挙げてみました。　※検討経緯のまとめではありません。
賛否判断の一助になるかわかりませんが参考になれば、と思い、共有します。
https://imgur.com/ve7bl55

歩行者・自転車・原付を含む125cc未満のオートバイが通行できない道路を列挙し、それを法令上の自動車専用道路と高速道路ナンバリングされた道路に分類しました。
そして、それぞれの道路の具体例と自動車専用道路標識の設置有無を挙げ、そのうえで、現状のJapan
Taggingに基くタグ付けと提案1-1に基づくタグ付け想定を並べました。
※現在の議論は大きく分けて「Japan
Taggingの変更不要」「高速道路ナンバリングされた道路に変更」に収斂していると理解しており、相違する道路を黄色で塗りつぶしています。

関連性がありますので、[提案1-1-1], [提案4], [提案5]に関することも併せて記載しています。
できる限り正確を期すべく念入りに確認したつもりですが、もし誤り・疑義ありましたら指摘ください。

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-cz] Poštovní schránky - import do telefonu

2018-05-03 Thread majka

Data na importu  se zdají z minulého
měsíce, už vidím na stránkách ČP
 nová.

Ale v podstatě pokud tě zajímá gpx nebo geojson soubor - ty "veřejně"
nemáme. Předpokládám že Marián by to uměl do gpx vcelku jednoduše dát,
obdobně jako máme rozcestníky. Podle dep bych to nedělila - v některých
místech ty hranice dep budou nepraktické, bude se jich tam potkávat víc.
Pokud budeme dávat, prosím přidat tag description s popisem pošty (kvůli
tomu geokódování, co se dělalo).

V současné chvíli je pro běžného uživatele asi nejjednodušší z toho
přehledu importu vzít konkrétní depo, tag missing - např. depo 37071
 a
vykopírovat tuhle tabulku, a převést si to ručně.

Majka

On Thu, 3 May 2018 at 15:34, Václav Kubíček  wrote:

> Ahoj,
>
> možná jsem to přehlédl, ale kde se dá stáhnout export schránek české pošty?
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] Poštovní schránky - import do telefonu

2018-05-03 Thread Václav Kubíček


Ahoj,
možná jsem to přehlédl, ale kde se dá stáhnout export schránek české pošty?
 
Případě nebylo by možno udělat odkaz na stránkách 
http://josm.poloha.net/cz_pbox/ odkazy ke stažení pro jednotlivá depa? Nejlépe 
schránky co chybí.
 
Díky moc
 
Vašek

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Germanenstaffel in Tübingen

sent from a phone

> On 3. May 2018, at 14:55, Martin Koppenhoefer  wrote:
> 
> locality hast Du nun ja schon für das angrenzende „Germaneneck“ verwendet, 
> das wäre natürlich eine ziemliche Häufung ;-)
> Und meiner Meinung nach wäre das auch eine Überbewertung dieser Verbindung.

bisschen OT für Deine Frage hier, aber dieselbe Stelle:
ein besserer Name für dieses Eck (gegenüber) wäre m.E. „Neckartor“, weil dort 
früher besagtes Stadttor stand und der Name weiterhin benutzt wird.

Gruß,
Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Andy G Wood

Hi Robert,

> There's still a lot to do though. In particular, there are around 3800
> branches in the official list that are not currently mapped in OSM,
> and around 1000 amenity=post_office objects that correspond to
> branches that are probably now closed. How may of these can we survey
> and fix in the next two months?

I know one of the unmapped post offices is still "open" in my village
http://robert.mathmos.net/osm/postoffice/branch/110053
however, it is basically a mobile van that turns up on the village green for 
some hours a few days a week.  How can this be mapped?

Andy.




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] Germanenstaffel in Tübingen

sent from a phone

> On 3. May 2018, at 14:19, dktue  wrote:
> 
> in Tübingen gibt es die sogenannte Germanenstaffel [1]. Diese ist in OSM als 
> vielzahl einzelner Ways getaggt. Insgesamt besteht die Treppe aus 209 Stufen.
> 
> Ich möchte gerne die einzelnen Ways zu einer sinnvollen Relation 
> zusammmenfassen [2]. Was wäre aus eurer Sicht das korrekte Tagging?

m.E. reicht es, wenn die highway Stücke verbunden sind und alle denselben Namen 
tragen.

Gibt es da mittlerweile Schilder mit diesem Namen? (frage mehr aus Interesse, 
den Namen kann ich bestätigen, auch wenn ich nicht wusste dass er offiziell 
ist).

Als area könnte man evtl. ein (multi)Polygon machen, z.B. mit place=locality? 
Ggf. was spezifisches?
locality hast Du nun ja schon für das angrenzende „Germaneneck“ verwendet, das 
wäre natürlich eine ziemliche Häufung ;-)
Und meiner Meinung nach wäre das auch eine Überbewertung dieser Verbindung.

Eine route relation sehe ich hier nicht gegeben, type=street ist auch nicht so 
super passend (ginge evtl zur Not, aber das ist eher ein aussterbender Typ). 
site Relations stehen vor dem gleichen Problem wie die anderen auch: man 
braucht einen guten tag. Wie willst Du es klassifizieren, Treppenanlage? 

Gruß,
Martin 

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Germanenstaffel in Tübingen

2018-05-03 Thread dktue


Hallo,

in Tübingen gibt es die sogenannte Germanenstaffel [1]. Diese ist in OSM 
als vielzahl einzelner Ways getaggt. Insgesamt besteht die Treppe aus 
209 Stufen.


Ich möchte gerne die einzelnen Ways zu einer sinnvollen Relation 
zusammmenfassen [2]. Was wäre aus eurer Sicht das korrekte Tagging?


Viele Grüße
dktue

[1] http://www.tuepedia.de/wiki/Germanenstaffel
[2] https://www.openstreetmap.org/relation/8267329

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Mark Goodge




On 03/05/2018 11:25, SK53 wrote:
Can we please avoid changing the meaning of post office by extending it 
to courier offices, and restrict it to those places which offer not only 
a full service mail offering (aka Universal Postal Service), but the 
traditional other services available at post offices (some banking, 
government forms, etc). Extending the meaning of the tag would make OSM 
data immediately intrinsically less useful in cities where courier 
offices exist. Such a change would a) require every post office to be 
suitably tagged with an indication of which service it belongs to; and 
b) require every data consumer to change.


I agree. "Post Office" has a specific legal meaning in the UK, and 
applying the tag to things that are not actually Post Offices would be 
confusing at the very least.


I think it would be helpful to have a suitable tag for things like 
Amazon lockers and Hermes drop-off points. But they're not Post Offices. 
They're not even close to being Post Offices. They fulfil a different 
role, and need to be identified as such.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread SK53

Can we please avoid changing the meaning of post office by extending it to
courier offices, and restrict it to those places which offer not only a
full service mail offering (aka Universal Postal Service), but the
traditional other services available at post offices (some banking,
government forms, etc). Extending the meaning of the tag would make OSM
data immediately intrinsically less useful in cities where courier offices
exist. Such a change would a) require every post office to be suitably
tagged with an indication of which service it belongs to; and b) require
every data consumer to change.

At the very least discuss this on the tagging mailing list: such a change
in meaning for a widely used tag needs to be treated with caution and
consensus in more than just the UK.

Jerry

On 3 May 2018 at 10:08, Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> On 2 May 2018 at 19:08, David Woolley  wrote:
> > On 02/05/18 18:52, ael wrote:
> >>
> >> I am confused:-)  How should a Royal mail local delivery office be
> >> tagged? It seems that it is not amenity=post_office. I notice that
> >> I have used post_depot once some time ago, but that doesn't seem to be
> >> in the wiki (or in the presets for josm). Yet I am sure that I got it
> >> from somewhere. Not that it seems very natural.
> >
> > I'm fairly sure this came up a couple of months ago and the answer was
> > amenity=post_depot; operator=Royal Mail.  It's not, in principle,
> different
> > from Hermes or TNT.
>
> That's certainly what I'd use. I think there's a good case for tagging
> customer-facing shop-like outlets of courier firms as
> amenity=post_office since they're places from which you can send
> stuff. But for the large warehouse-style sorting/distribution centres
> I think something else is needed. amenity=post_depot seems a good
> choice to me. It has over 400 uses worldwide, of which over 300 are in
> the UK.
>
> The legitimate use of amenity=post_office for non-Post Office Ltd
> branches creates a slight issue for my comparison tool. I've got some
> heuristics to account for some sets of objects based on name,
> operator, and brand tagging. See:
> http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Philip Barnes

I would avoid using amenity=post_office for anything other than a proper post 
office.

The term post office is much more than a place to send parcels or letters.

In the UK a post office offers
Banking services
I can tax my car
I can apply for a passport
I can collect my pension
Exchange currency 
Probably lots of other things that I've not thought of. 

Whilst post depot is useful for collecting things that an individual has 
ordered, sending stuff by courier is a business service. DHL will not be 
interested in sending my Christmas cards and certainly not for the price Royal 
mail charges. 

Phil (trigpoint) 




On 3 May 2018 10:45:57 BST, Michael Collinson  wrote:
>At the risk of being pedantic, but would a "network" tag, similar to
>bus 
>routes, not be more appropriate?
>
>Here in Sweden, the post office system is now Post Nord, network=Post 
>Nord, but post offices are frequently inside and operated by 
>supermarkets, e.g. operator=ICA. These outlets often handle DHL and 
>other services that might also be considered as postal networks, 
>network=Post Nord;DHL
>
>Mike
>
>
>On 2018-05-03 11:15, Brian Prangle wrote:
>> Hi Robert
>>
>> If an operator tag is added to post_office tags then your comparison 
>> tool would be OK
>>
>> Regards
>>
>> Brian
>>
>> On 3 May 2018 at 10:08, Robert Whittaker (OSM lists) 
>> > > wrote:
>>
>> On 2 May 2018 at 19:08, David Woolley > > wrote:
>> > On 02/05/18 18:52, ael wrote:
>> >>
>> >> I am confused:-)  How should a Royal mail local delivery
>office be
>> >> tagged? It seems that it is not amenity=post_office. I notice
>that
>> >> I have used post_depot once some time ago, but that doesn't
>> seem to be
>> >> in the wiki (or in the presets for josm). Yet I am sure that I
>> got it
>> >> from somewhere. Not that it seems very natural.
>> >
>> > I'm fairly sure this came up a couple of months ago and the
>> answer was
>> > amenity=post_depot; operator=Royal Mail.  It's not, in
>> principle, different
>> > from Hermes or TNT.
>>
>> That's certainly what I'd use. I think there's a good case for
>tagging
>> customer-facing shop-like outlets of courier firms as
>> amenity=post_office since they're places from which you can send
>> stuff. But for the large warehouse-style sorting/distribution
>centres
>> I think something else is needed. amenity=post_depot seems a good
>> choice to me. It has over 400 uses worldwide, of which over 300
>are in
>> the UK.
>>
>> The legitimate use of amenity=post_office for non-Post Office Ltd
>> branches creates a slight issue for my comparison tool. I've got
>some
>> heuristics to account for some sets of objects based on name,
>> operator, and brand tagging. See:
>>
>http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol
>>
>
>>
>> Robert.
>>
>> -- 
>> Robert Whittaker
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-gb
>> 
>>
>>
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Michael Collinson

At the risk of being pedantic, but would a "network" tag, similar to bus 
routes, not be more appropriate?

Here in Sweden, the post office system is now Post Nord, network=Post 
Nord, but post offices are frequently inside and operated by 
supermarkets, e.g. operator=ICA. These outlets often handle DHL and 
other services that might also be considered as postal networks, 
network=Post Nord;DHL

Mike

On 2018-05-03 11:15, Brian Prangle wrote:

Hi Robert

If an operator tag is added to post_office tags then your comparison 
tool would be OK

Regards

Brian

On 3 May 2018 at 10:08, Robert Whittaker (OSM lists) 
> wrote:

On 2 May 2018 at 19:08, David Woolley > wrote:
> On 02/05/18 18:52, ael wrote:
>>
>> I am confused:-)  How should a Royal mail local delivery office be
>> tagged? It seems that it is not amenity=post_office. I notice that
>> I have used post_depot once some time ago, but that doesn't
seem to be
>> in the wiki (or in the presets for josm). Yet I am sure that I
got it
>> from somewhere. Not that it seems very natural.
>
> I'm fairly sure this came up a couple of months ago and the
answer was
> amenity=post_depot; operator=Royal Mail.  It's not, in
principle, different
> from Hermes or TNT.

That's certainly what I'd use. I think there's a good case for tagging
customer-facing shop-like outlets of courier firms as
amenity=post_office since they're places from which you can send
stuff. But for the large warehouse-style sorting/distribution centres
I think something else is needed. amenity=post_depot seems a good
choice to me. It has over 400 uses worldwide, of which over 300 are in
the UK.

The legitimate use of amenity=post_office for non-Post Office Ltd
branches creates a slight issue for my comparison tool. I've got some
heuristics to account for some sets of objects based on name,
operator, and brand tagging. See:
http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Wikimedia Maps deployment

2018-05-03 Thread James

also i believe a multi-lingual map will require vector tiles to be dynamic,
which is being worked on as well

On Thu, May 3, 2018, 3:36 AM Eugene Alvin Villar,  wrote:

> On Thu, May 3, 2018 at 2:50 PM, Daniel Koć  wrote:
>
>> It's also good that they were able to deploy multiple language versions
>> - we would hit this problem anyway, sooner or later, and I hope that
>> eventually we will be able to provide them too.
>>
>
> FWIW, multi-language maps is one of the Top Ten Tasks defined by the
> Engineering Working Group of the OSM Foundation.
> https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Localized_map_rendering
>
> There's also the ongoing thread on this same mailing list:
> https://lists.openstreetmap.org/pipermail/talk/2018-April/080560.html
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Morton Bay National Park should have it's ID numbers under ref=

2018-05-03 Thread Michael Collinson

I also agree. Putting other info into a name is not good practice. 
Separation allows map renderer and search functionality to decide what 
to do rather than being forced into something.


I personally like to tag in a generic way as possible and therefore 
would use the "ref" tag as my choice. However other folks around the 
world like to preserve/present info about who/what is actually doing the 
reference index so you might want to consider something like (I am 
making this up):


npsr_qld:ref = MNP05

Mike


On 2018-05-03 06:01, Joel H. wrote:

Hello, I'm just noticing around Moreton Bay Marine Park. Many
nature_reserves are currently formatted as follows:

name= Honeymoon Bay (MNP05)

Shouldn't this be:

name= Honeymoon Bay

ref= MNP05

?


-Joel



___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Brian Prangle

Hi Robert

If an operator tag is added to post_office tags then your comparison tool
would be OK

Regards

Brian

On 3 May 2018 at 10:08, Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> On 2 May 2018 at 19:08, David Woolley  wrote:
> > On 02/05/18 18:52, ael wrote:
> >>
> >> I am confused:-)  How should a Royal mail local delivery office be
> >> tagged? It seems that it is not amenity=post_office. I notice that
> >> I have used post_depot once some time ago, but that doesn't seem to be
> >> in the wiki (or in the presets for josm). Yet I am sure that I got it
> >> from somewhere. Not that it seems very natural.
> >
> > I'm fairly sure this came up a couple of months ago and the answer was
> > amenity=post_depot; operator=Royal Mail.  It's not, in principle,
> different
> > from Hermes or TNT.
>
> That's certainly what I'd use. I think there's a good case for tagging
> customer-facing shop-like outlets of courier firms as
> amenity=post_office since they're places from which you can send
> stuff. But for the large warehouse-style sorting/distribution centres
> I think something else is needed. amenity=post_depot seems a good
> choice to me. It has over 400 uses worldwide, of which over 300 are in
> the UK.
>
> The legitimate use of amenity=post_office for non-Post Office Ltd
> branches creates a slight issue for my comparison tool. I've got some
> heuristics to account for some sets of objects based on name,
> operator, and brand tagging. See:
> http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UK Quarterly Project: Post Offices

2018-05-03 Thread Robert Whittaker (OSM lists)

On 2 May 2018 at 19:08, David Woolley  wrote:
> On 02/05/18 18:52, ael wrote:
>>
>> I am confused:-)  How should a Royal mail local delivery office be
>> tagged? It seems that it is not amenity=post_office. I notice that
>> I have used post_depot once some time ago, but that doesn't seem to be
>> in the wiki (or in the presets for josm). Yet I am sure that I got it
>> from somewhere. Not that it seems very natural.
>
> I'm fairly sure this came up a couple of months ago and the answer was
> amenity=post_depot; operator=Royal Mail.  It's not, in principle, different
> from Hermes or TNT.

That's certainly what I'd use. I think there's a good case for tagging
customer-facing shop-like outlets of courier firms as
amenity=post_office since they're places from which you can send
stuff. But for the large warehouse-style sorting/distribution centres
I think something else is needed. amenity=post_depot seems a good
choice to me. It has over 400 uses worldwide, of which over 300 are in
the UK.

The legitimate use of amenity=post_office for non-Post Office Ltd
branches creates a slight issue for my comparison tool. I've got some
heuristics to account for some sets of objects based on name,
operator, and brand tagging. See:
http://robert.mathmos.net/osm/postoffice/osm-unmatched.html#non-pol

Robert.

-- 
Robert Whittaker

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Wikimedia Maps deployment

2018-05-03 Thread Eugene Alvin Villar

On Thu, May 3, 2018 at 2:50 PM, Daniel Koć  wrote:

> It's also good that they were able to deploy multiple language versions
> - we would hit this problem anyway, sooner or later, and I hope that
> eventually we will be able to provide them too.
>

FWIW, multi-language maps is one of the Top Ten Tasks defined by the
Engineering Working Group of the OSM Foundation.
https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Localized_map_rendering

There's also the ongoing thread on this same mailing list:
https://lists.openstreetmap.org/pipermail/talk/2018-April/080560.html
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Morton Bay National Park should have it's ID numbers under ref=

2018-05-03 Thread Warin


+ 1
name is for the name only.

On 03/05/18 15:52, Andrew Harvey wrote:

I agree.

On Thu., 3 May 2018, 2:02 pm Joel H.,  wrote:

Hello, I'm just noticing around Moreton Bay Marine Park. Many
nature_reserves are currently formatted as follows:

name= Honeymoon Bay (MNP05)

Shouldn't this be:

name= Honeymoon Bay

ref= MNP05

?


-Joel



___
Talk-au mailing list
Talk-au@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-au



___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au



___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk] Wikimedia Maps deployment