| Commit message (Collapse) | Author | Age | Files |
| |
|
| |
|
|
|
|
| |
This enables proper filtering by level etc. (incl. journald coloring).
|
|
|
|
| |
(Commented out for now since Bookworm has only GDAL v3.6.)
|
|
|
|
|
|
| |
Despite using gdal.UseExceptions() a failed call doesn't raise an
exception, so we need to check the return value to avoid missing
features.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The extent is expressed in config['SRS'] in traditional GIS order
(easting/northing ordered: minX, minY, maxX, maxY), but the destination
layers might be pre-existing and use other SRS:es or mapping strategy.
|
| |
|
|
|
|
|
|
| |
The configured extent is always expressed in the destination SRS, so it
needs to be transformed into the source SRS. Like apps/ogr2ogr_lib.cpp,
we segmentize it to make sure it is sufficiently densified.
|
|
|
|
| |
(Commented out in config.yml for now since Bookworm has only v3.6.)
|
| |
|
|
|
|
| |
And getFieldSubTypeCode() to parseSubFieldType().
|
|
There is still a few things to do (such as reprojection and geometry
changes) but it's mostly working.
We roll out our own ogr2ogr/GDALVectorTranslate()-like function version
because GDALVectorTranslate() insists in calling StartTransaction()
https://github.com/OSGeo/gdal/issues/3403 while we want a single
transaction for the entire desination layer, including truncation,
source imports, and metadata changes.
Surprisingly our version is not much slower than the C++ one. Importing
the 157446 (of 667034) features from sksUtfordAvverk-2000-2015.shp takes
14.3s while
ogr2ogr -f PostgreSQL \
-doo ACTIVE_SCHEMA=postgis \
--config PG_USE_COPY YES \
--config OGR_TRUNCATE YES \
-append \
-fieldmap "0,-1,-1,-1,-1,1,2,3,4,5,6,7,8,9,10,11,12,13" \
-nlt MULTIPOLYGON -nlt PROMOTE_TO_MULTI \
-gt unlimited \
-spat 110720 6927136 1159296 7975712 \
-nln "sks:UtfordAvverk" \
PG:"dbname='webmap' user='webmap_import'" \
/tmp/x/sksUtfordAvverk-2000-2015.shp \
sksUtfordAvverk-2000-2015
takes 14s.
Merely opening /tmp/x/sksUtfordAvverk-2000-2015.shp and looping through
its (extent-filtered) features results in a runtime of 4.3s.
|