In light of a recent Japanese earthquake, I am trying to translate names and tags that are in Japanese into other languages (mostly in English) so that non Japanese speakers in Japan for rescue mission, etc can use the map more effectively. This is a fairly isolated work that can be done very easily if the right tool exists.

Is there a way for me to grab all keys that are in 'ja' which do not have 'en' equivalents so that we can translate them and add 'en' equivalent? I understand that all keys have '=lang_code' such that this can be done.

I found Nominatim which seems to be a query service and does not have an edit function. Maybe, we can make such a tool quick? I am very new to osm world, but I would love to help if I can.

Thanks, Go

asked 17 Mar '11, 04:45

gostop's gravatar image

gostop
61124
accept rate: 0%

edited 22 Mar '11, 11:25

TomH's gravatar image

TomH ♦♦
3.1k83439


The most important thing to say is I consider that adding such names directly to OSM is inadvisable.

A mass update of locality information is not something that is likely to meet the Automated Edits Code of Conduct. The relative merits of ostensibly making data easier for non-Japanese speakers, is far outweighed by the immediate uses of OSM and its map renders by people directly in the zones affected by the earthquake, tsunami and Fukushima nuclear plant (see ). Crisis mapping is to help people affected by the crisis, not crisis mappers.

Also as far as I know there is no simple map render which will show either name:en or name:ja-ro as the default for names: therefore such an edit would not meet its purpose. Additionally, mass edits are notorious for breaking things because the person performing the edit either does not have enough experience of OSM; or does not rigorously check every object affected.

Other more minor points:

  • Firstly do not try and translate tag names: the default is British English. If tags have been entered in another language you may break a specific application.

  • Secondly, I imagine that in the main you wish to transliterate Japanese names to a roman alphabet (romaji) rather than provide 'English' names, which for the most part do not exist for localities in Japan.

  • Thirdly, most location names for Japan in OSM are held in the name=* tag, with many having the form Kanji (Romaji). Not all will have equivalent name:ja and name:en (or better name:ja_rm) tags. Thus for the country something like this : name=日本 (Japan) , name:ja=日本, name:en=Japan and name:ja_rm=Nihon. See http://wiki.openstreetmap.org/wiki/Japan_tagging#Names

If I was tackling this problem I would use one of the downloadable extracts (e.g., that of Honshu, refreshed hourly by Geofabrik) and load the data into a Postgres database using Osmosis. I would then create a simple table of OSM object ids with columns for the different name types, and identify absent tags. Obviously the same table could be the start of filling the gaps. If an application could be built separate from OSM to open an editor for people to add these additional tags then it might be worthwhile (see for instance Geofabrik's OSM Inspector, or OSM Locator Musical Chairs). An alternative then would be to build a separate layer of romaji names for, say, a Garmin device. See my blog for some ideas.

permanent link

answered 17 Mar '11, 10:49

SK53's gravatar image

SK53 ♦
20.2k42209322
accept rate: 20%

Thank you for your detailed response. Just to clarify one thing first: my intention is to provide a way for foreign rescue teams "on the ground" to be able to communicate with locales more effectively, so I believe it 'could' serve its mission of helping people affected by the crisis. This is an discussion for some other time.

On transliterate vs translation...it is fair to say we really need both to be accessibly easily. To pronounce (Daiichi hashi) is one thing, to realize that it is a bridge (Daiichi bridge) is another and serves different purpose.

I would like to focus on a problem at hand...Assuming we have crowd sourced ja->ja_rm AND ja->en in a bunch of csv files, what's the best way to: 1) import all that info - is to create another application that edit names (I'll ping OSM Inspector people) 2) display these three versions of a name - is to build a separate layer. Can't we just have this layer on OSM map itself?

Thanks!

(21 Mar '11, 17:26) gostop

Helping people on the ground is fine, but putting data in OSM is not the only way to do it. In general imports of data cause problems unless they are carefully planned. The risk of creating problems with existing names which are used in widely used services such as Nominatim as well as the map rendering is too high.

Take a look at how streetnames were sourced in Port-au-Prince last year (see wiki pages on Haiti), as a fairly low-tech way, or something like OSM Locator Musical Chairs for a more sophisticated approach.

(21 Mar '11, 23:17) SK53 ♦

I would have thought that a parallel map like the cycle map is parallel to OSM derived from OSM map data but labelled to suit the particular requirements

(22 Mar '11, 00:11) andy mackey
1

Also don't forget that romaji is not a sure way of getting the Japanese pronounced in English. There are a few methods to transform from Kanjis to Romaji. The most known one is Hepburn. In addition, for town name, converting from Kanji is extremely risky as you would need to know the prononciation in Hiragana in order to create some romaji names that are making sense. It is far from being trivial

(22 Mar '11, 11:27) Melaskia
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×27
×10

question asked: 17 Mar '11, 04:45

question was seen: 8,127 times

last updated: 22 Mar '11, 11:27

powered by OSQA