Help making the Thailand map Thai

Since the bilingual map rendering it gets more and more obvious that the map of Thailand is not much Thai at all.

To help in spotting problematic areas I set up some reports listing entries in the database where the name is suspicious.

For some elements it’s quite obvious what needs to be done. For others the value in the name tag is perfectly valid.
Refer to the discussion in this forum, especially in regard of brand names.

For easier review the entries can be opened with JOSM and JOSM-RemoteControl plugin installed and running.


Have updated a few, around Chiang Mai.

I added another report:

it lists places having problems with it’s bilingual name nearby cities.

What addition would make the reports more usable?

Having an online-Editor to directly change names on the webpage?
Or a download link to open the report in JOSM?
Or something completely different?


more improvements to are available.

  • Displays statistics
  • More reports
  • Autodetect running JOSM with RemoteControl plugin and offer edit button
  • Web-editor for direct editing of name-tags

The statistics count the number of issues for each report. So an issue might end up in multiple reports thus being counted multiple times.

The online editor uses the OAuth interface of OSM. That requires to register one time and approve the editing service.
The advantage of OAuth is that you don’t need to give away your OSM username or password to a 3rd party website.

I’m looking for some test-drivers for this editing service before enabling self-registration. Please contact me so I can create an account for you.


So one of the tasks is to migrate the non-Thai “name” tags on to name:en, right?
Could this be done via a script? Or maybe it’s more work coding than editing. The list itself looks reasonable.
(being here one may fix some names in upper-case only?)

Edit#1 I thought the list contains only items which have a latin name for “name”-tag. But there are also those which have a Thai name:th tag…
Edit #2 mentions a piece software for that task!


Hello Amai,

unfortunately it’s a bit more complicated than simply moving all non-thai from name to name:en.

We want to have local (Thai script) names in the name tag. At least for things that have a Thai name. Easy for place and street names. More difficult for other things. There is a discussion on the forum how to handle things like brand names.

As there are a lot of names which are clearly available in Thai we can keep this discussion for later.

So when moving a non-Thai to name:en the Thai name should be entered as the name. We can duplicate this also in name:th as it does no harm.
In case we agree somewhere in the future we don’t need name:th tags that are identical to name these can be removed by a script within seconds. Space in the DB is nothing to worry about, yet.

As place-names and Street names have a common spelling in Thai it’s possible for native speakers to determine the right word for a possibly “creative” English transliteration.
RTGS is some sort of official but the rule is not followed on every street sign. Not talking about the tourist maps that each have a slightly different way of transliteration.

The online editor on the reports page is still heavy beta. You can use an account created on also to edit directly from the reports page.
As I just returned from vacation it might take some days to update the online editor. I have a backlog of other things to do first.


Re. place names (in particular), if a Thai name is not available or known at the time of editing, should the name tag be entered in English or Latinised Thai - or not entered/removed?

The name:en tag does not show on all map renders - e.g. OSM and OCM - and a name, in any format, is a very important marker for navigation purposes…

If non Thai character name tags are removed, yes, queries might be used to spot them, but until that is done (which might take a very long time or never happen - possibly because Thai character names aren’t used on signs for place names in isolated, rural areas, and/or the places are not labelled on available reference material) something critical (e.g. nav’, safety, rescue uses) will be missing from maps used by many people - such as those using the majority of portable GPS navigation systems, or even those using print-offs.

I can understand and agree with the principle of wanting place name tags on Thailand area maps to be written in Thai. (Though it wouldn’t surprise me if the majority of OSM Thailand area maps users can’t read Thai, a place marker name using any characterisation is still useful.) However, I don’t agree with not entering or removal of English or Latinised name tags just to try and satisfy a principle. So, I think it better to only move a non-Thai name to name:en when a Thai name can be entered as a replacement.

I don’t think OSM is just about the attaining the most ‘correct’ data - as good data alone doesn’t necessarily produce a good (i.e., useful) map.

What’s the consensus of opinion on this matter?


Hello Chris,

thank you for pointing out this topic again. The aim of the reports is to have the data bi-lingual. So have it as English and Thai. I tried to express it in the above section in the answer to amai. Having only English script in name:en is not enough. If it would be that easy I would have done it already with a script.

The “Thai name should be entered” is a quite strong request. Technical documentation like RFC describe the meaning:

So unless there is a good reason[1] for not doing so you will always enter Thai script names in the “name” tag when moving English ones to “name:en”.

I think we’re both looking for the same. A map with labeling as useful as possible. If other mappers have a different opinion and maybe better arguments for having empty name tags I would like to hear them and discuss it.

[1] One possible reason are mappers cooperating. For example sojo entered a lot of missing Thai script using the tooling on But this is only a technical reason for easier spotting of missing names and the name tag is due to be filled with Thai script within hours or days.


Thanks for that clarification. I will refer an editor that has been moving English and transliterated name tags to name:en - without replacing Thai in the name tag, to this forum post.

OSM and OCM only render the name tag. Anyone know what’s the best way to make a request with OCM and OSM renderers for bilingual place names? (I.e… they start rendering not just the name tag and also the name:en or name:int(?) tag too.)

Maybe this has been done lots before or they’ve said ‘no’… What’s the situation? (Sorry, I’ve been lazy and not searched before asking.) A bilingual map would be much more useful to me - but I am limited to OSM and OCM by my GPS… Many others will have the same problem - or simply will not know of the custom renders like:

Found this while working on name tags:

Thailand OSM editors familiar with this? Don’t know about the rest of Thailand, but the level of detail (Thai script place names, etc) for the area near Chiang Rai I’ve checked is VERY high… Don’t know what source / surveying this has come from but there are place names for villages on here that are in REALLY isolated locations… Must be either using high detail mapping I don’t know about or a lot of local Thai editors contribute.

I have not seen this kind of detail (in Thai or English - or bilingual) on any other map. If some clever backend/DB/query-monkeys can figure how to draw data from this resource and match up with OSM, and the level of detail is the same throughout Thailand as what I saw, OSM Thailand could fill in those missing Th/En bits easily.

Note though, geonames is not all right - spotted some duplication and some locations were incorrect - and odd places that weren’t bilingual. Also, I’m finding places on OSM with only Thai script names - no En or Int’ names…

Also, I’ve been using int_name instead of name:en and sometimes alt_name (to keep existing names in En if it differs from En name given on geonames) - as that’s what pops up in Potlatch simple view editing. Is this OK - or should I use name:en?

Hi Chris,
I can see your really getting into this OSM now … addictive, isn’t it.
Just had a look at Geonames and what a fantastic resource, although as you say, if it could be verified then put into OSM automatically (where gaps exist) that wud be great, although way beyond my skills.
Like you, the main reason I add to OSM, is the way in which Lambertus (and others Im sure) have made the data available to use on our Garmin devices. The place names can be an issue as when viewed in Mapsource/Basecamp, in many cases the characters are become garbled.
From my understanding this is not an OSM issue, but rather how the conversion process works, HOWEVER, if someone could explain the best way to tag, to ensure the Garmin display (and Mapsource program) replicate this name accurately, I would be very grateful.

And I guess one other point to ask with Geonames, is that given they say …
“The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge.”
… does that mean we are free to use the data on OSM ???

Hi Russ. Looks free to me…


Now, for manual cross-referencing, I can see no problem with using geonames as a data resource. Realistically, how can there be?

Re. DB import and matching to OSM, anyone interested in doing this would need more details on the conditions of use Geonames established with the original name sources (this could possibly make it OK for some locations/countries - but not others) and with Geonames itself re. permission of use. A ‘creative commons attribution license’ is mentioned, but I haven’t looked into the details of this. There’s possible more info on the site - or there’s an email address for Qs.

The OSM wiki mention of geonames seems to dismiss its use with opinion after little investigation. Hardly authoritative, imo.

Hi crsCR and Russ,

CC-BY is not compatible with ODbL.

I try to summarize it:
CC-BY allows you to use it as long as you refer the source. eg: “source

ODbL requires you to state the source, eg “data: ODbL and contributors”

did you notice it already? you can’t force ODbL users to add “and”. And leaving it away violates the geonames license.
So it is not a valid source for us.

One solution would be to get a special permission for use in openstreetmap and have the attribution in the wiki, see here for some examples:


Cheers for the reply, stephankn.

I think the CC attribution licence would apply to the actual geonames rendered mapping - surely place names featured in this ‘work’ would be classed as being in the public domain. Yes, there might be issues with a direct db to db import, but adding names to OSM after manual cross-referencing shouldn’t cause any infringement, should it? You can’t copyright a general populace place name, can you?

Anyways, maybe best to leave the source tag blank then - if you just so happened to be doing a bit of casual reading of geonames prior to editing OSM data… No moral dilemma for me there!

OSM decided to play on safe size with regards to potential copyright issues.

CC-BY license certainly applies when a substantial amount of data from Geonames ends up in OSM.
If you take over a place name in a romanized form it is quite likely to be able to detect that the source of it was geonames, based on the creative way romanized ways are often created.

You are right that factual data can’t be copyrighted. A collection of facts (legally called a database) can be protected and is protected by database rights for example in Europe.

The preferred way of getting data into OSM is on-the-ground survey by a local community. That is a major benefit of OSM compared to other data providers. Only the local community can keep the data updated.

Even with it being tempting to improve OSM faster by doing imports, it has certain drawbacks we need to be aware of.
I might point to the US tiger import. This is considered to be one of the major reasons why there is no such strong OSM community than in Europe.

Have you ever spend an evening correcting spelling mistakes in Thai script? Not as rewarding as mapping a new place out of nowhere.
As of today still over 100 ways with a wrong spelling of “Soi” around:

Proper fixing would be to add name of the street as well, not just fix “Soi”. Only search/replace is not enough. I could have done that easily myself.