My name is Tara, and I’m writing to you on behalf of Open Maps Microsoft team regarding administrative boundaries of districts in Thailand.
There were several discussions here on forum regarding sources for these and we’ve noticed that the question of missing administrative division on OSM is an important one for your community.
We’ve came across a dataset from geoBoundaries where ADM 2 represents districts. Since geoBoundaries confirmed that their CC by 4.0 license can be used for OSM (see Contributors - OpenStreetMap Wiki ), this data can be used if accurate.
We’ve compared it to some of the other mentioned dataset found in the comments of your forum (for example GISTDA portal; for districts of Bangkok data.go.th and Wiki information) and noticed that in most cases this data seems useful. Some geometries may be simplified.
Could you please take a look at the dataset from geoBoundaries- download here and give your opinion on whether this data is good enough to be used for mapping districts in Thailand?
Something to note is that geoBoundaries dataset contains only English names. If we were to map this data in OSM, it would require manual editing, verification and mapping names solely as name:en=* tag. This would require community/local knowledge effort to add name=* and name:th=*.
Take a look and hopefully we’ll be able to use it and enrich OSM data in Thailand together.
Thank you for your interest in supporting with administrative boundaries.
As these are usually very hard to map from “the ground”, they tend to be very hard to verify. We have to rely on sort of official data sources where often the license has compatibility issues.
License needs further checks.
geoBoundaries seems to just collect boundaries from various sources. The ADM2 of Thailand contains this note:
Boundary Source(s): Royal Thai Survey Department, OCHA ROAP
Canonical Boundary Type Name: districts
License: Creative Commons Attribution 3.0 Intergovernmental Organisations (CC BY 3.0 IGO)
Under the CC BY-IGO license, you are free to share (copy and redistribute the material in any medium or format) and or adapt (remix, transform, and build upon the material) for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms. The license terms are that you must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. Additionally, you may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. When the Licensor is an intergovernmental organization, disputes will be resolved by mediation and arbitration unless otherwise agreed.
I am no lawyer. I would guess that we might be able to fulfill the attribution requirements by linking it on the Contributors page. Would be nice if someone more knowledgable about the CC-BY-IGO license could comment on the specific requirements and compatibility.
I have a tendency to say we should fetch the data then from the main source.
Hi Tara, thanks for bringing this up with the Thai OSM community!
I’ve put in a lot of effort searching for official sources in Thailand that are OSM-compatible, so I was really excited to hear you found one we have permission to use.
But the mention of the ‘Royal Thai Survey Department’ gave me pause, as government agencies typically don’t grant permissions. You’ll need to verify this with Geolab first.
I checked the data in QGIS, and it’s noticeably more precise than what we currently have. I think this is because most of our boundaries were roughly drawn manually from official Royal Gazette PDFs, which also use a different projection.
The only concern is the usual discrepancies along the northern border near Arunothai and Fang.
If we can move forward with this dataset, how do you plan to import it and handle the existing country and province boundaries? Personally, I think we could recreate the provinces based on district imports, but we should keep the existing OSM country boundary.
It’s not a major issue; it can be filled in later.
Thank you for your welcome and extensive information.
In terms of licensing, I agree there is room to question it. We’ve seen different sets where sometimes under adequate licensing, organizations can make a ‘new product’ derived from segments of primary sources, enriching, combining or modifying them. If they comply with respective licensing/legal agreements with primary sources, this ‘new product’ could be used/modified/distributed further as a separate dataset (and can, depending on legal agreements with primary sources, be licensed differently). I am not familiar with how geoLab processed and collected this dataset, but to avoid any misunderstanding I believe they should be contacted for further confirmation.
About using primary/original sources (mentioned Thailand - Subnational Administrative Boundaries - Humanitarian Data Exchange (humdata.org)) this dataset seems to contain more information and could be more useful in those terms. From our previous experiences with other humdata.org OCHA sets, they stated that for clearing up licensing they would need to contact the primary source (usually government institutions) that are not always disposable for these types of interpretations. We could try going through this process ourselves for this set, but it is probably a lengthy one with smaller chances of success.
There is a possibility that geoLab already went through that process and received direct licensing for partial information or all of it. To make sure, I will write to geoLab to clarify the licensing a bit more for the particular set referring to districts and will share the answer here when I receive it.
First, thank you for your quick response and insights.
Regarding editing we would map districts as relation and would map district by district, province by province with manually checking and adjusting each geometry boundary to existing OSM data (making sure there are no overlapping or doubled ways, following and using already mapped boundaries and natural features if they seem to represent the boundary). Relations of districts would be mapped as admin_level=6 with name:en=* and “fixme= Please add Thai name for this district” tags. Once all the geometry is consolidated for each district and tags are added and checked, only then would we upload the relation of the district.
As you can see the process requires manual adjustments and checks. Any other type of automatization would leave the map with chaotic imported data and heavy clean up would be necessary. We’ve already used this type of manual editing/verification in editing of different missing admin boundaries, national parks etc. around the world, and it has proven to be the most efficient and respective to existing OSM data. Of course, we are happy to hear any suggestions, especially ones that would make this process more accurate or faster.
In terms of disputed zones/areas, when the time comes, we would be happy to follow your guidance. There is an option to map out the difference in official or non-official boundaries using boundary=administrative or boundary=disputed. This can be tricky, but in other territories, this is always based on community consensus and OSM guidelines on how to map or not map them.
Regarding questions related to boundaries of provinces, it would make sense to realign them since they seem to currently have more simplified boundaries (understandably so) and districts and province boundaries should be consolidated. We could potentially try to recreate (adapt existing province boundaries to the suggested geometry of districts so these share ways). In case of counties, I believe we would need more information/sources to significantly change them, so unless there is a specific, logical change that should be made (clear natural boundary, overlapping ways etc.) then we would avoid editing these boundaries. For both provinces and additional information on editing, I would still wait for confirmation on whether we can use the specified dataset before setting a finalized guideline on how to process them.
The geoBoundaries dataset is attributed to originate from OCHA, which then has the above stated license terms.
They state red cross aquired it and it is licensed as CC BY-IGO.
I do not find further details about license compatibility with OpenStreetMap ODbL. As with many licenses, the attribution requirement might be the critical aspect. Can we provide this in the requested way?
I did not see references to this in the wiki. I had hope that someone clarified this before.
Thai names look available on all data of the nearly 8k tambons.
These geo-boundaries for provinces are already visible in ID-editor before you zoom in to edit. A data-import for province-boundaries (without district-boundaries) should not be a problem I believe.
I have seen province boundary import by some group long ago. Look like they use hand drawn map from wikipedia as source. It then appear to not follow any marcation line describe from Ratchakitcha document. My guese is only around 20 percent have been fix Mostly part that use river as marcation point, as i have seen in northeast region. central region seem like to have one user finish the work, both regional adminstrative and local adminstrative.
for shapefile download from OCHA they are fit well and seem to follow marcation line describe by Ratchakitcha, ministry of interior document (Title: ประกาศกระทรวงมหาดไทย เรื่อง การกำหนดเขตตำบลในท้องที่อำเภอ…) seem like description took from Royal thai survey department map series, but i’m not sure. Look like description use MGRS grid system.
I think, if we can import district boundary, then we can fix province boundary later.
Forgot to add opinion on that website, which someone mention above (google). province and district are fine, but subdistrict and municipality they mess up (wrong shape or misalign several metres), as i currently know they not allow you to use their data outside their website, and OSM did not encourage us to use data that not have acceptable license (which they don’t have).
