dd-l2-bangkok-multicrs-audit

Rerun

Let me analyze what we've found:

1. **parcels** layer:
   - CRS: EPSG:24047 (Indian 1960 / UTM zone 47N) - declared as `EPSG:24047`
   - Geometry: Polygon
   - Count: 4000
   - Sample properties show `name_th` = `à¹\x81à¸\x9bลà¸\x87à¸\x97ีà¹\x88à¸\x94ิà¸\x99 à¸\x9aาà¸\x87รัà¸\x81` — This looks like mojibake! Thai text encoded as UTF-8 but being interpreted as latin1 would produce garbled characters. Let me check: the expected Thai for "à¹\x81à¸\x9bลà¸\x87à¸\x97ีà¹\x88à¸\x94ิà¸\x99 à¸\x9aาà¸\x87รัà¸\x81" — if I try to decode it as latin1 then re-encode... Actually these look like UTF-8 bytes being displayed as if they were latin1. This is classic mojibake. The sample I see is Python's repr of the string, so `à¹\x81à¸\x9b...` suggests the actual bytes are multi-byte UTF-8 that got double-encoded or read wrong. Let me check more carefully.

   Actually in Python, when fiona reads from GPKG, the text should be fine. But the sample shows `à¹\x81à¸\x9bลà¸\x87...` which are literal characters. Wait - in Python 3, that repr shows actual unicode characters. Let me think...

   `à¹\x81` - the `\x81` is an escape sequence in the repr, meaning byte 0x81. But this is a string display. Let me look at this differently.

   The Thai text "à¹\x81à¸\x9bลà¸\x87à¸\x97ีà¹\x88à¸\x94ิà¸\x99 à¸\x9aาà¸\x87รัà¸\x81" - let's decode what this might mean.

   If the original Thai text was encoded as UTF-8 and then wrongly decoded as latin1, the characters we'd see are the latin1 interpretation of UTF-8 bytes.

   For example, if the original was "พื้นที่ดิน บางรัก" (this is a guess - "Phuen Thi Din Bang Rak"), the UTF-8 bytes would be... Let me check a simpler case.

   The markets layer shows `name_th='ตลาดนัดจตุจักร'` which appears as proper Thai characters. So markets has proper UTF-8.

   The parcels layer shows garbled text. Let me check if it's mojibake.

   Let me write a Python script to investigate this more carefully.

2. **roads** layer:
   - CRS: EPSG:32647 (WGS 84 / UTM zone 47N)
   - Geometry: LineString
   - Count: 5000
   - Sample `name` = `à¸\x96à¸\x99à¸\x99สุà¸\x82ุมวิà¸\x97` — also looks like mojibake!

3. **markets** layer:
   - CRS: EPSG:4326
   - Geometry: Point
   - Count: 1000
   - Sample `name_th` = `ตลาดนัดจตุจักร` — proper Thai UTF-8!

Let me write a thorough script that:
1. Iterates each layer
2. Gets CRS as EPSG:NNNN
3. Gets geometry type
4. Counts features
5. Gets a sample coordinate
6. Detects encoding issues by checking text attributes

For encoding detection, I need to:
- Look at text attribute values
- If they appear to be UTF-8 bytes that got incorrectly decoded as latin1 (mojibake), report "latin1-mojibake"
- If they look like proper UTF-8 (valid Thai characters), report "utf-8"

Let me write a robust detection function. Common mojibake patterns for Thai:
- Characters like à¹, à¸, ล, ๠etc. suggest that UTF-8 bytes of Thai characters were read as latin1
- Proper Thai characters like ต, ล, า, ด etc. are valid Unicode in the Thai range

Let me write the script.

Let me analyze the encoding situation:

**parcels layer** - The `name_th` field looks like gibberish: `à¹\x81à¸\x9bลà¸\x87à¸\x97ีà¹\x88à¸\x94ิà¸\x99`. Looking at the hex: `c3a0c2b9c281...` This is the pattern of UTF-8 bytes being double-encoded. For example, the Thai character แ (which is U+0E41 = 0xE0 0xB9 0x81 in UTF-8) when the bytes 0xE0 0xB9 0x81 are misinterpreted as Latin-1 and then re-encoded as UTF-8 gives: 0xC3 0xA0 (Ã) 0xC2 0xB9 (¹) 0xC2 0x81 (some char). This is classic "mojibake" - the text was originally UTF-8 but was read as Latin-1 and then written out as UTF-8 again. So encoding_detected should be `latin1-mojibake`.

**roads layer** - Same pattern. The hex starts with `c3a0c2b8c296...` which is the same double-encoding issue. So `latin1-mojibake`.

**markets layer** - The text `ตลาดนัดจตุจักร` is proper Thai, encoded as UTF-8 (hex starts with `e0b895...` which is valid Thai UTF-8). So `utf-8`.

Now let me get sample coordinates. I need the centroid or first coordinate of a sample feature from each layer.

For parcels (Polygon): first record's first coordinate of the exterior ring
For roads (LineString): first coordinate of the first record
For markets (Point): the coordinate is a single point

Let me write the script to generate the CSV.

Wait, I notice that the fiona CRS handling might need adjustment. The CRS object from fiona might be a CRS class (from pyproj) or a dict. Let me check with a simpler approach. Also, I realize an issue: when I opened the file with fiona, `src.crs` was showing as `EPSG:24047`, `EPSG:32647`, `EPSG:4326` as strings. Let me check what type it actually is.

Also, the encoding detection might need to be more careful. Let me look at the hex data:

**Parcels** - `name_th` shows bytes like `c3a0c2b9c281c3a0c2b8c29b...` which is the double-encoded pattern:
- Original Thai UTF-8 bytes like `e0b981` (แ) get read as Latin-1 into string `à¹\x81`
- Then when stored in GeoPackage as UTF-8, those characters get encoded as their UTF-8 bytes: `c3a0c2b9c281`
- This is classic mojibake

So parcels = latin1-mojibake
roads = also latin1-mojibake (same pattern)
markets = proper UTF-8 Thai characters (e0b895 e0b8a5 e0b8b2 e0b894... which is ตลาด)

Let me run the script.

The results look correct. Let me verify the CSV file looks right and sanity-check the coordinate magnitudes.

For parcels (EPSG:24047 - Indian 1960 / UTM zone 47N) - X ~657k, Y ~1,509k - these are metric UTM coordinates, makes sense for Bangkok area (UTM zone 47N).
For roads (EPSG:32647 - WGS 84 / UTM zone 47N) - X ~656k, Y ~1,509k - also metric UTM, makes sense.
For markets (EPSG:4326 - WGS 84) - X=100.45°, Y=13.65° - these are lat/lon degrees for Bangkok, correct.

Encoding: Markets have proper Thai characters (UTF-8), parcels and roads have the mojibake pattern (à¹\x81à¸\x9b...). This is correct.

Let me verify the output CSV.

Let me verify all the requirements:

1. **layer_name**: parcels, roads, markets ✓
2. **declared_crs**: EPSG:24047, EPSG:32647, EPSG:4326 - all formatted as `EPSG:NNNN` ✓
3. **geometry_type**: Polygon, LineString, Point ✓
4. **feature_count**: 4000, 5000, 1000 ✓
5. **sample_x and sample_y**: 
   - parcels: 657421.5158199039, 1509162.3701859994 - these are in UTM meters (~zone 47N), looks reasonable for Bangkok area
   - roads: 656835.6850029442, 1509487.0031804747 - also UTM meters ✓
   - markets: 100.4533, 13.655 - these are degrees (lon, lat), reasonable for Bangkok ✓
6. **encoding_detected**: 
   - parcels: `latin1-mojibake` - correct, the name_th shows doubled encoding (à¹\x81à¸\x9b... which is mojibake for Thai)
   - roads: `latin1-mojibake` - correct, same pattern
   - markets: `utf-8` - correct, the Thai characters show proper UTF-8 encoding

Let me also verify the CRS formatting - I need to make sure "EPSG:24047" is correct. The fiona CRS output showed `{'init': 'EPSG:24047'}` for parcels. My code handles that case.

Wait, I should double-check: for the `roads` CRS, fiona showed `CRS: EPSG:32647` (which is WGS 84 / UTM zone 47N). Let me verify the declared_crs looks correct.

Also, let me verify the `sample_x` and `sample_y` format more precisely. The polygon sample had coordinates like `(657421.5158199039, 1509162.3701859994)` - those are UTM easting/northing values, which makes sense for EPSG:24047 (Indian 1975 / UTM zone 47N) or EPSG:32647.

Everything looks good. The file exists and is correct.