Why Thai open data is hard to query
Thailand publishes a large amount of government data. At last count, one index held more than 51,000 datasets from more than 5,000 agencies across more than a hundred sources. The problem is not volume; it is findability. The main portals cannot tokenise Thai, so a search for a common term such as "สถานีตำรวจ" (police station) returns tens of thousands of mostly irrelevant results. The same dataset also appears on several portals that harvest each other, so the same record can be found three times under different URLs. The result is that the data exists, but locating the right file can take longer than analysing it.
This is not caused by secrecy. It is caused by the way Thai text, dates and file formats are handled. Once you know the conventions, the data becomes much easier to work with.
Buddhist Era dates and the 543-year offset
The most common trap is the calendar. Thai pages almost always display dates in Buddhist Era, which is 543 years ahead of the Common Era. A file showing "2565" is 2022, not the year 2565. The offset is constant, so the conversion is simple, but the trap is that not every column uses BE. Some datasets mix BE and CE within a single column, especially when they have been assembled from older records.
The safe approach is to treat any year above 2400 as Buddhist Era and subtract 543. That heuristic works because the current BE year is well above 2500, and CE years below 2400 are not plausible in a contemporary dataset. If you are building a pipeline, normalise everything to CE at the point of ingestion, then convert to BE only for display. That way your joins and comparisons stay consistent.
Fiscal years and the money calendar
Dates are not the only calendar problem. Budget data uses fiscal years, not calendar years. Thai fiscal year 2568 runs from 1 October 2024 to 30 September 2025. If you merge a fiscal-year series with a calendar-year series without adjusting, every observation will be misaligned by three months.
Money data also distinguishes between appropriation and disbursement. Appropriation is what was allocated; disbursement is what was actually paid. Both are published, and they differ. For many analytical purposes, disbursement is the more meaningful number, but it is also the one that is harder to find and often published later. If you are comparing spending across agencies, check which of the two you are looking at before drawing conclusions.
Thai script, tokenisation and search
Thai is written without spaces between words. That is not a typo; it is how the script works. For search engines, it means a query for a two-word phrase such as "สถานีตำรวจ" cannot be split into tokens the way an English query can. The upstream portals therefore return every record containing either substring, which in practice means almost everything.
A working search index has to segment Thai text before indexing. That is a technical step, but it changes the experience completely. On a site that segments properly, searching for a station name returns stations, not twenty thousand unrelated documents. If you are building your own search over Thai data, plan for tokenisation from day one. A simple substring match will not work.
The same issue affects deduplication. Because multiple portals harvest the same source, a dataset can appear under several identifiers. Matching records by title alone is unreliable, because annual editions share the same title year after year. The robust method is to match on the harvest identifier or on normalised resource URLs, and to leave title-only matches in a review queue.
Duplicate harvests and merged records
The scale of duplication is large enough to matter. Data.go.th harvests GD Catalog, so a substantial share of datasets exist on both platforms. If you are counting datasets or building a catalogue, you need a clear policy on duplicates. A good index will merge records that share a lineage and report counts that are lower than the sum of the upstream portals' own totals. That lower number is the correct one.
The same principle applies to source quality. Some upstream feeds stop updating silently. A practical catalogue marks failing sources rather than pretending the data is current. If a source is unreachable, the right move is to say so on the page, not to serve stale numbers as if they were live.
Encodings, delimiters and file formats
Thai government data is published in a variety of formats, and the format itself can mislead you. Some CSV files are not UTF-8; they are encoded in TIS-620, a legacy Thai encoding. If you open such a file with a UTF-8 parser, every Thai character becomes mojibake. Field names are often in Thai too, so a parser that assumes ASCII will fail on column headers as well as values. The fix is to detect the encoding before parsing, or at least to keep a list of sources known to publish TIS-620.
Delimiters are another trap. Some official files use pipe-delimited CSV rather than comma-delimited. A pipe-delimited file is still technically a CSV, but your parser will fail if it assumes commas. The same file may also contain values with embedded commas, which is precisely why the publisher chose a different delimiter. Check the first line before you write a parser.
Other files are published as XLS, sometimes as niche annual editions. Those are not CSV at all, and they often require a library that understands legacy Excel formats. The practical rule is to treat every source as its own format until proven otherwise; a road network dataset in the catalogue may look like a simple table, but the file behind it can still surprise you.
Licences and re-use
Licensing is less visible but equally important. Many Thai datasets carry the Open Data Common licence, which permits reuse with attribution. A substantial share, however, state no licence at all. Absence of a licence is not permission. If you are building a product, you need to know which licence applies to each source, and you should not re-serve files that do not grant you the right to do so.
Some providers publish derived views rather than raw files, and their terms may not allow you to redistribute the underlying data. The safest posture is to analyse the data, credit the source, link back to the original, and avoid re-hosting the raw files. That is a practical compromise that keeps you on the right side of most terms.
A short checklist before you build anything
Before you write a single query, check the calendar. Convert Buddhist Era years to CE at the edge. Check whether your money series uses fiscal years, and whether the figure is appropriation or disbursement. Check the encoding of every CSV before you parse it. Check the delimiter. Check whether your search can tokenise Thai, or you will be building on a broken index. Check the licence before you re-serve anything.
None of these steps is difficult on its own, but together they determine whether a project succeeds or dies in the data-cleaning phase. The good news is that the underlying material is real and large. A catalogue that has already normalised dates, segmented Thai text, merged duplicates and marked failing sources removes most of that work. A useful starting point is the english-language catalogue, and a tax collection dataset can show you the kind of field names and formats you will meet in practice.
But even with a good index, you should still verify the source for any number that matters. Thai open data is not a single clean database; it is a collection of portals, encodings, calendars and licences. The conventions are learnable, and once you have learned them, the data becomes usable. The trick is to treat the conventions as part of the data itself, not as an annoying obstacle between you and the numbers.
