Place name tags

The map is acquiring quite a few village names and I think we should make some consistent format. One possible form is:

place = town, village, hamlet
name = (Thai name)
name:en = (English name in syllables ex: Ban Tha Gat)
Moo = (#)
Tambon = (Tambon name in Thai)
Amphoe = (Amphoe name in Thai)
Chenwat = (Province name in Thai)
Postal code (?) = #####

The general form for an address seems to be:

#/#, Village (or Road)
Moo (หมู)#,Tambon (ตำบล)
Amphoe (อำเภอ)
Province (จังหวัด), Postal Code

This looks like a lot of work, but if you do a few villages in the same area, you should be able to type ‘r’ and then just change a few values. You can sometimes find a red mailbox, which has the postal code.
Out of laziness, I’ve just been doing name, name:en and place. As the map is getting better, may be time to be more careful!
Any preferences in the spelling of Amphur/Amphoe?

I don’t think we should invent tags which would be applicable only to Thailand. Your proposal to include tambon, amphoe and changwat tags for each place node seems rather similar to the is_in=* scheme, which I understand has somewhat been superseded by boundary polygons for the overlying areas. In places where the boundaries have been mapped, the system seems to work nicely enough. For example, Nominatim is able to correctly parse the address for CentralPlaza Chaengwattana to “Chaeng Watthana Road, Bang Talat Subdistrict, Pak Kret District, Nonthaburi Province, 11120, Thailand”. This, however, of course depends on already having the relevant boundary relations for the tambon and amphoe, which isn’t the case in most of the country.

Your proposal could serve as a semi-temporary fix until the boundaries are created. However, instead of inventing new tags like tambon and amphoe, they should be incorporated into the is_in scheme. (Tagging for provinces (changwat, to use the official spelling) shouldn’t be necessary since we already have boundary relations for those.) However, I’m not sure which language would be preferable for the tags. Using is_in:tambon=* and is_in:amphoe=* seems unlikely to be supported by most software, while is_in:subdistrict=* and is_in:district=* already have several thousand uses.

Moo (official spelling mu), aka muban, are a somewhat different matter. They should correspond to each individual village (place=hamlet), but in actuality they often don’t, since many villages are further divided into several administrative muban. The numbers are effectively ref numbers for the villages, but are used in lieu of the actual village names in the official addressing system. In cases where the muban corresponds with a single village, Using the ref=* tag to note the moo number seems like a logical choice, but I’m not sure if we should actually split up villages to show the different moo, where that is the case.

Official spellings of names in the Latin alphabet usually follow the Royal Thai General System of Transcription. There are online tools to generate this but they don’t work well for some names (esp. those with Pali/Sanskrit roots). It would be useful to note alternative spellings in the alt_name field, of course. (BTW, I prefer the official spelling for amphoe.)

As noted in this thread, I’ve been using the name:th_latn tag to distinguish between the transliterated Thai name and the English name with English-language terms. For example, Nonthaburi Province is tagged

name:en=Nonthaburi Province
name:th_latn=Changwat Nonthaburi

This could also be applied to individual places.

A related note: I suggested in this thread that villages (muban) should probably be tagged as place=hamlet, rather than place=village, since it better matches the OSM definition for the former. The place=village tag should be used for subdistrict administration organisations (o bo to), which are the local government units usually corresponding to each tambon. Quite a lot of places still need to be updated in order to fit this system.

Certainly the boundary relations are the right way long-term.

For a mid-term solution the is_in:* namespace might be the best way to go as it’s parsed by nominatim.

Willi tagged a lot of places with addr:district and addr:subdistrict. nearly 30.000 uses of that:

It might be worth considering to do a mechanical edit to add the is_in keys where not existing using the addr:* values.

While having the full information, at present I see so many unlabeled places that I’d just be happy to have some name…
But any case, if you come across something labeled “Ban ?”, I just put this as temp label there with the intention that its name should be placed there at some point. Reason is that not all viewers show the Village/hamlet/ etc. marker, but only the name.

I strongly advise against using “placeholders”.
I will explain why it’s a bad idea so you will understand it better.

If you just put it up like this, it’s tagging for the renderer. If your specific renderer (which is it? a Garmin?) does not show places without a name, then it’s a problem with the ruleset of the given renderer. Simply add a rule there saying “if no name given, print ‘Ban x’ on that place”.

But please: Do not put false information into the database. “name=Ban x”, “name=fixme”, “name=no name” all fall into this category.

edit: Currently there are 123 “Ban ?” places in Thailand. But over 2.000 place=village features with neither name, name:en or int_name. Better fix the renderer.
The majority of these unnamed places are in the Isaan. It makes me wonder: Where does the information come from that these are actually independent villages? From aerials you can’t say whether two clusters of buildings are the same village or separate ones…

Sorry if the use of a placeholder is a bad idea. the idea was to alert other mappers that these villages should be given names. it seems also unlikely that anybody would misinterpret it. I presume all the ban ? are from me, and quite a number of the empty name ones as well.
As to renderers, well as far as I can see none of the ones I use have a ruleset that allows me to visualize unnamed villages, i.e. openstreetmap itself (not in edit mode or potlatch), or MapsWithMe in the iphone. The Potlatch and the GoMap!! (iphone) editors do render the point marker though, but potlatch does not show the thai names, so you cant see if it has been named or not.

As to what are villages, I am rather conservative. around large towns, it is very clear that it is impossible to distinguish between communities without having access to the precise borders. But in issan many are clearly delineated. Of course that doesnt mean they have all separate names, and some hamlets may have no name at all. Most must be separate villages, though, otherwise you will never get the numbers that are listed, i.e. for example the Phon Thong District in Roi Et alone has 190 villages (according to wiki), and Roi Et province 2311 villages. There are no way 2311 villages listed in Roi Et yet. The distances in average between villages that have already been given names in Thai are similar to the distances observed between unnamed distances. So, overall, I think there is no worry in that respect at this point.

I too discourage the use of placeholders for hamlets and villages. It’s very tempting to use such tricks to force POIs to show up on our GPS units and much of this discussion as well as others I’m involved in have to do with the imperfect rendering of POIs in the Garmin downloaded maps we obtain from Lambertus. My conversation with EndlessRoundabout concerning stupas being rendered as radio towers is one several that spring from this issue.

One of OSM’s golden rules is “do not tag for the renderer” but we see this being done often. I think the best approach would be to create a Thailand style sheet that would help Thailand mappers but not compromise or influence the basic rules of OSM. Were the learning curve not so steep for learning how to modify styles and TYP files I would try it myself.

If this seems a workable approach, is anybody willing to attempt this. Stephan, I know you have considerable experience here. What do you think?

I very much like the idea of placeholders. Many many times I’ve gone off on a 150 km bicycle ride to map an area, but have no idea where to go when I get there. So it is hit or miss. If my Garmin said ‘Ban’ here, and ‘Ban’ there, I would have a destination. Countless times I come back and noticed I missed many villages near my route. This would be a gross error in Germany or the Netherlands, but the map here needs a lot of work, and some leniency to encourage and help mapping should be allowed.

In the past I intentionally disconnected unknown roads just so I could find them. Worked fine.

Maybe some computer guru could write a script to delete them after a few months.

I use these placeholders also for mapping, you see where you have to trace roads. As Tom Layo said, the map is so imperfect at this point, that any useful info should be used. I mean what’s the harm having Ban show up? whoever finds the right name, simply replaces it. as the map gets denser, they will all disappear.

Endless, Tom,
I’m glad some of you are speaking up on this issue…
I plot long off road tracks, especially in Laos, and North east Thai, and when we go thru isolated un-named villages, I waypoint them.
When the data goes onto OSM, I often don’t have a name, so they get tagged~

place=village (or hamlet)

2 months ago in Laos, a mate leaves the road, vertically drops 10 mts with the bike - and we need a long rope, lots of people, & pickup truck to retrieve it. So where’s the nearest village?
Fortunately I had tagged as above when I went that way before, and we cud make an informed decision, but ONLY because in my Garmin, the name=village tags show up.

I appreciate that we can say its the fault of the conversion process Lambertus uses (and I love that Guy for his site), and that OSM data shud be pure & correct … but this is the real world, that was a real situation, and I’m damn happy I broke some tagging rules that day.

I see some pretty horrendous crimes from new mappers out there, … but I don’t see using an otherwise empty name tag, is quite in that category.
And before Stephan & Dave berate me, I contribute thousands of hours to this project, and all I ask is to be able to use the map in a manner that is useful to me, (and others who use OSM on their Garmin devices) - we don’t all have the luxury of laptops out in the wilds.

I’m going to continue to consistently use placeholders to name the strategically important villages (and Fuel, and medical facilities, and “Bike repair shop” etc, as such).
And OK, Im sure a script can be written one day, to take them all out in one fell swoop … but I hope sense prevails until a better solution is found.

Cheers, Russ.

I don’t object to the use of these village placeholders as much as you think. I only worry about it being a slippery slope that will lead to so many other “customizations” that the map will become a chaos of conflicting tags. This will, in the end, make it difficult to locate POIs in a straightforward way.

That was my motivation for trying to standardize the use “drummed fuel”, “barreled fuel”, “mom & pop fuel”, etc. It’s gets gummy when in one case the custom value is applied to the name tag, and on another one, the operator tag, etc. Luckily they all use the top level amenity=fuel tag so they are always visible.

There are many issues like that one needing clarification and structure. That’s what is foremost in my mind when I speak out about rendering “tricks”. Please don’t be offended when I use such terms. We all put in a lot of time on this project and every hour spent on it is fun for me. Let’s keep working on these issues the way we have in the past and eventually it will all be good.

So there is disagreement on most of these issues. “is_in:subdistrict=" and "is_in:district=” seem to be favored, and I will use that format if this is agreeable. The province name is not necessary. My goal now is to save the information on the signs rather than wasting it.

Placeholders like “Ban x” and “place” and “need name” are unacceptable. I would like to make a case for name=Ban under limited circumstances: when a user has at least a tentative plan to visit the area and needs the map directions to find the missing names.

BTW, Autohotkey is a way to avoid typos. You can enter common Thai words like school, hospital and an English shortcut, like sc or hos and it will write the Thai (you have to set this up). I can spell these words, but the font is so small it’s hard see errors.

Also, the tilda changes the keyboard from Th to EN.

@Tom - Of course, you can continue to use your placeholder scheme if you wish; nobody can tell you not to. The method I use doesn’t map places needing work on OSM. Instead, I create waypoints in Basecamp (or Mapsource) and work from those when I’m out in the field. One of the nicer features of Basecamp is that I can create special purpose folders for those WPs and load them along with my “standard” WP file when I want to. I have a folder named Temp Lampang, another named Temp Nan, for example, and I work through the points when in the area. Later, after I add data to OSM I delete the WPs from their folder. I know you’re working with Mapsource and the 60CSx and such folders are not available. You could, however, make simulated “work folders” and save them to disk as GPX files that contain the WPs of interest for each area. But whatever works best for you is cool.

Thanks to your suggestion I’m now using Autohotkey constantly. It does those text expansions you mention, as well as the hard to remember province abbreviations, with ease. It is also a nice spell checker that works in all programs. I frequently misspell Chiang Mai as Chaing Mai. Not any more.

I also developed Autohotkey shortcuts that apply my custom presets in JOSM. That was my main reason for wanting it in the first place. Now, after drawing a new way, I type [Alt]+r and Autohotkey swings into action first typing “s” to return to Select mode, then mousing over to the Preset Menu to select my preset for residential highway. I’m a happy camper. Saves a lot of time.

I certainly can’t stop you using “temporary” markers. And I don’t want to start an edit war by writing a bot to remove it.

But please: As a software engineer I can assure you that it will add a lot of extra work if the data is filled up with temporary elements of any kind.

to find all place=village without a name is a single-line query. Easy to show on a “todo” list or on a reports page or any other quality improvement tool.
To find all these temporary values is a lot more work. What to select? “Ban ?”, “village”, “no name”, …
That list is endless. And in the end some human must browse through a list of thousands of village names to spot something we might have forgotten.

Keep in mind: Thailand has only limited numbers of mappers. Don’t make it harder as it needs to be.

So if you can’t refrain from entering such things in the database: I beg you to add at least a “fixme” key with a value explaining that the real name or whatever you temporarily added is still missing.

If nobody objects I would do a mechanical edit to add this to the actually unnamed places I can find…

Good idea. The fixme tag is standard for this purpose. Also, if the edit is done automatically, you can use identical values in it, for example, “This is a placeholder for a populated place that needs a name.” or something similar. Better to have consistent wording as well so all such places can be readily identified in the future.

I think that’s why it would be useful to have a convention sheet, it would be a simple guide to newcomers how to tag things. If everybody would agree to use, e.g. “Ban X”, then it’s also a simple query.

As to
“And in the end some human must browse through a list of thousands of village names to spot something we might have forgotten.” Actually, this is substantially easier than scanning satellite images for missed villages. Although it does sound extremely tedious, sometimes a control like that is not a bad idea, since you probably will uncover lots of other kinds of issues. In the scientific databases that I work with, you can find many things wrong when you check details, even though they are supposedly done to high standards :wink:

And yes, if you can add that fix-it to the unnamed places, it would be great, thanks.

The discussion was never about adding the villages, the discussion was whether or not it was okay to give them a fake names like “Ban X”. It have always been allowed to add a village with no name tag.

My argument have been that people relying on the data for other uses than maps would have to make code to specifically ignore all those fake names, which could be different from user to user and region to region.

An example of an application using data like that could be a site where you have to submit your address, and it will suggest names based on OSM data.

“The discussion was never about adding the villages, the discussion was whether or not it was okay to give them a fake names like “Ban X”. It have always been allowed to add a village with no name tag.
My argument have been that people relying on the data for other uses than maps would have to make code to specifically ignore all those fake names, which could be different from user to user and region to region.”

Yes, I understand that’s what we have been discussing is the fake names. My suggestion was to agree on one single fake name, so it could easily be search for in the future. And it’s not really a complete fake name if it start with Ban.
As to the second part, no, the whole idea is not for the renderers to remove them. The reason for using the fake names is to force the renders to show the villages. So, nobody would be happy if they are filtered out again.

I think at present we have to live with the fact that the renders are not perfect, and work around until it gets better.

I have added a fixme tag to the fake names I was able to detect. I would have loved to delete the fake name as well but I respect the edits of others.

Still I highly encourage you to contact the developer of the specific application which is not displaying the data in a way you wished for to fix that instead of manipulating the data to match your desired result.

Stephan this is not literally a rendering problem they’re talking about. They tag the hamlets while home using an OSM editor and Bing imagery so that later on when they drive around in the area with only a GPS the towns will be visible. The GPS shows only white space if there is no “Ban ?” or “village” or “needs name” placeholder present. Until such time as we can use quality satellite imagery in our GPSs, it’s going to be easier to see features you want to tag from your desktop.

I still maintain that a better way to add such a reminder is to simply make waypoints for places you want to investigate in the areas you plan on visiting. Before going into the field one simply loads those waypoints into a GPS to find the towns, (or roads, junctions, etc.), needing names. Of course, that’s quite a bit more tedious than simply adding the placeholder to OSM while it’s right in front of you on the screen.