Addresses - OpenStreetMap Wiki states that " Tags such as addr:country=, addr:city= are often redundant as features inside administrative boundaries (when mapped) “inherit” their attributes as supported by software such as Nominatim or Photon." You could consider avoiding the addition of higher-level administrative divisions in the tagged address.
You could consider avoiding the addition of higher-level administrative divisions in the tagged address.
Neither the San Kamphaeng District or the On Tai Subdistrict has been mapped as a proper administrative boundary at the moment, so I suppose they are still needed for now?
Official addresses in Thailand don’t include the municipality or SAO. For the village, it should be tagged as addr:place=*, using the numeric name rather than the word name. (such as หมู่ที่ 2 / Mu 2)
Because the official house numbering is associated with either the street (usually in urban areas) or the village (usually in rural areas), the user must be aware of whether the addr:housenumber is associated with the street or the village. For this reason, the official address of any house or building recorded in the registration would never include both the street and the village simultaneously.
The wiki Key:addr:place - OpenStreetMap Wiki description exactly matched with how Thai house numbers, which are associated with villages, work.
I have updated addr:place according to your spelling above.
I have removed addr:province, addr:province:en and addr:country as they are redundant.
I am reluctant to remove addr:village as I think it is fairly important to know that my house is in Ban Pong. I also find that addr:street is fairly important as it tells you from which street you can enter my house. Is this really information we would like to discard?
Because the house number 110 is associated with the village, not the street. Adding addr:street=* leads to confusion. The wiki Addresses - OpenStreetMap Wiki and Key:addr:place - OpenStreetMap Wiki explicitly states that addr:place=* should not be used alongside with addr:street=*.
I understand that your concern is about data loss, but the fact that the house is accessible via which street has nothing to do with the address tag. (For example, the registered street address can sometimes not using the name of the nearest road, but rather a main road in the area.) The address tag, however, should be tagged in accordance with the house registration that the house owner has, as given by the Department Of Provincial Administration. This is the same address as what you write on the postal envelope.
For the village name, Ban Pong is actually an alternate name for Mu 8, therefore it’s also redundant. What we can do to make people knows is to add Mu 8 as an alt_name=* in the place=village node. I also usually do this when I’m mapping villages. (Adding Ban Pong as an alt_name=* in the boundary=administrative is also useful, but I know that village boundaries are rarely mapped right now.)
In addition, I’m still unsure whether addr:subdistrict=* and addr:district=* should be removed, even if their boundaries are completely mapped. There will be issues with some places near the boundary line because boundary mapping in Thailand is likely to be poor, even on the “official” map used by the authorites. However, for the addr:province=*, it can be removed because if the addr:district=* is tagged, we can determine which province it belongs to. Districts with the same name are rare in Thailand, and when they do occur, they are far apart and not in close proximity.
The numeric name is more convenient to use and specific to each village, and it is preferred in official documents. For administrative purposes, certain single settlements can be divided into multiple villages, so their word names can be the same. For example, Ban Pong will probably be the word name for both Mu 8 and Mu 9. Furthermore, the village’s word name can sometimes be inconsistent, but the numeric name is always stable.
Thanks for all the explanations.
When you drive along the street you see the name of the village and not the number. Especially in our region all the villages get now a place name sign but no number. That’s why I prefer to add the number as alt_name=*
Good point. On the maps, I would also expect to see ‘Ban Pong’ as the main village name tag instead of ‘Mu 8.’ However, for official addresses, I understand that ‘Mu 8’ should be used in the addr:place:en field.
@nitinatsangsit, just curious, for place nodes, how about putting ‘Mu 8’ in the official_name field instead of alt_name?
Interesting. I’m not against it; I simply feel that Ban Pong is not an unofficial name. Simply said, Mu 8 is more commonly used in official documents. Does anyone have an opinion?
Ban Pong is the official village name and Mu 8 is the official village number. Both are equally official.
For the village node I would use:
admin_level=10
alt_name=หมู่ 8;หมู่ที่ 8 (Both variants are used, หมู่ 8 is probably optional)
alt_name:en=Mu 8
name=บ้านปง
name:en=Ban Pong
name:th=บ้านปง
place=village
And some thoughts for the address:
Official address:
110 Mu 8
On Tai Subdistrict
San Kamphaeng District
Chiang Mai Province 50130
On envelopes people often write additional information:
110 Mu 8 Ban Pong
Highway 5127
On Tai Subdistrict
San Kamphaeng District
Chiang Mai Province 50130
Good point. I believe most regular mappers do not use iD, or those who do, like me, prefer to use the Tags section instead. However, I agree that the current fields could be improved for new mappers.
The good news is that OSM software is not static and can be improved with minimal effort. For instance, the iD address fields are fully customizable by country. Here is an example submitted for New Zealand:
I put the "street" field on its own line as it is optional.
Alternatively, combining "street" and "place" is possible with field "street+place"
All fields are free-text, so I expect "subdistrict", "district", and "province" to have errors and mismatches. However, they can always be replaced with a script using "postcode," or later derived from administrative boundaries (currently, only "province" has been consistently added).
Any comments or suggestions for changing the form structure/keys? Once we are happy with a solution, I will submit the pull request to the iD repository.
I still believe it should be only either ["housenumber", "place"] or ["housenumber", "street"].
I see @Mark_B’s point about the useful additional information that individuals sometimes write on envelopes, but I’m concerned that unofficial addressing can lead to another issue. For example, I can write Highway 5127 as Rural Road 5127, Ban xx–Mueang xx Road, or something like, because the registration does not specify the exact name of the road to put in the address. This can result in data inconsistencies and ambiguity (or even edit wars). For this reason, I keep believing that the fact that which road is in front of the house has nothing to do with addressing. (And, if necessary, querying for the nearest road using geolocation coordinates should be the way to go.)
In addition, I’d like to suggest adding the option to include addr:housename (for the building name), addr:floor, and addr:unit. This is for a large commercial building with a single owner who leases out a portion of the building to multiple tenants. In this situation, there would be only one housenumber issued by the Department of Provincial Administration for the entire building, and this informations is required for registering a business address with the Department of Business Development. So this is another kind of official address.
