[gdal-dev] crunch lib

2022-03-03 Thread chris english
https://github.com/DaemonEngine/crunch appears to be a better source to point to for crunch, as it builds, whereas crunch link in docs doesn't. And builds for the hapless, as I believe I've demonstrated. Chris ___ gdal-dev mailing list

[gdal-dev] CMAKE [ 89%] Built target gcore_mdreader *** target pattern contains no '%'

2022-03-03 Thread chris english
This subject line is a mash up of this: [ 89%] Built target gcore_mdreader CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'. Stop. make[1]: *** [CMakeFiles/Makefile2:4871: CMakeFiles/GDAL.dir/all] Error 2 and hereafter I have no idea of how to proceed. I've previously

Re: [gdal-dev] CMAKE poppler c++17

2022-03-03 Thread chris english
Thanks Jeff. Process details matter, I missed that Poppler source was actually at gitlab rather than my github based clone, so rebuilt poppler, using CMAKE this time. [100%] Built target poppler-render Install the project... -- Install configuration: "Release" -- Installing:

Re: [gdal-dev] CMAKE poppler c++17

2022-03-03 Thread Jeff McKenna
Hi Chris, I'm not sure if this is exactly related to your issue, but here are my thoughts: I do know that the recent poppler release relies on the C++17 standard, and there was a recent change in GDAL to accommodate this (see https://github.com/OSGeo/gdal/issues/5071 ). In my case (for

[gdal-dev] CMAKE poppler c++17

2022-03-03 Thread chris english
Hi, I am a weak link when it comes to CMAKE. Geos-3.10.2 and PROJ-8.2.1 were a breeze nonetheless. A source build of libpoppler.so.119 via ./configure went smoothly. I have consistently failed at ogrpdflayer (well, only four times so far) on 'optional', that is a C++17 thing. <- an example of a

Re: [gdal-dev] VRT dataset to text in-memory?

2022-03-03 Thread Mateusz Loskot
On Thu, 3 Mar 2022 at 11:16, Michael Sumner wrote: > > Hello, reading the raster VRT tutorial > > https://gdal.org/drivers/raster/vrt.html#creation-of-vrt-datasets > > with this code: > > // > int nBand; > GDALDriver *poDriver = (GDALDriver *) GDALGetDriverByName( "VRT" ); > GDALDataset

Re: [gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning

2022-03-03 Thread Rahkonen Jukka (MML)
Hi, If you have a table with multi-column primary key (composite key) then the target table in Spatialite obviously will not have the same PK. I would guess that none of the columns in the composite is unique and usable as PK so the only possibility is to create a new unique column for the PK.

[gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning

2022-03-03 Thread DUTRIEUX Loic
Hi everyone, Quick question, I'm using ogr2ogr to clone a postGIS database to a spatialite file database (by the way, very convenient that ogr2ogr handles the transfer of non-spatial tables too). The database contains many-to-many relations and as a consequence association tables with multiple

[gdal-dev] VRT dataset to text in-memory?

2022-03-03 Thread Michael Sumner
Hello, reading the raster VRT tutorial https://gdal.org/drivers/raster/vrt.html#creation-of-vrt-datasets with this code: // int nBand; GDALDriver *poDriver = (GDALDriver *) GDALGetDriverByName( "VRT" ); GDALDataset *poSrcDS, *poVRTDS; poSrcDS = (GDALDataset *) GDALOpenShared(