aboutsummaryrefslogtreecommitdiffstats
path: root/common_gdal.py
Commit message (Collapse)AuthorAgeFiles
* MVT: Don't clip features manually.Guilhem Moulin14 days1
| | | | | | | | | | | | | | | | | | | | | | It's done automatically by the MVT driver. Also we don't want to clip at the extent boundaries, but instead leave som headroom so the clipped polygon border is not visible on the map. The MVT driver does that. It seems that GDAL 3.6.2 from Debian Bookworm generates too many tiles though. It yields the following tile counts for group ‘ren’: no manual clipping, BUFFER=32: 83718 tiles [min=33 B, max=117.70 kiB, sum=15.73 MiB, avg=197 B] no manual clipping, BUFFER=0: 83676 tiles clip at extent, BUFFER=32: 76256 tiles GDAL 3.10.3 from Debian Trixie yields less surprising tile counts: no manual clipping, BUFFER=32: 75972 tiles [min=33 B, max=128.16 kiB, sum=15.10 MiB, avg=208 B] no manual clipping, BUFFER=0: 75939 tiles clip at extent, BUFFER=32: 75972 tiles (Interesting to see that the largest tile — 0/0/0.pbf — is over 10kiB larger with the more recent GDAL version, also.)
* Factor out densification logic from getExtent() into own function.Guilhem Moulin14 days1
| | | | | | And only densify if needs be. Most sources are already in SWEREF 99 (modulo axis mapping strategy) so in pratice we can use mere rectangles as spatial filters.
* common_gdal: Replace remaining generic Exception with RuntimeError.Guilhem Moulin14 days1
|
* common_gdal.py: Use OGR_TZFLAG_UTC rather than hardcoding its value 100.Guilhem Moulin2025-04-231
| | | | Cf. https://gdal.org/en/stable/api/vector_c_api.html#c.OGR_TZFLAG_UTC .
* webmap-import: Break down into separate modules.Guilhem Moulin2025-04-211