[gdal-dev] crunch lib
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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] CMAKE [ 89%] Built target gcore_mdreader *** target pattern contains no '%'
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 dispensed with other recalcitrant drivers (MrSid), can I do the same with target 'gcore' without the world collapsing upon me and would my functionality be greatly reduced.? Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] CMAKE poppler c++17
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: /usr/local/lib/libpoppler.so.119.0.0
-- Up-to-date: /usr/local/lib/libpoppler.so.119
-- Set runtime path of "/usr/local/lib/libpoppler.so.119.0.0" to
"/usr/local/lib"
which in the context of the patch 089f84b:
if ("${POPPLER_VERSION_MINOR}" MATCHES "0?[0-9]+")
string(REGEX REPLACE "0?([0-9]+)" "\\1" POPPLER_VERSION_MINOR
${POPPLER_VERSION_MINOR})
endif ()
if (POPPLER_VERSION_MAJOR GREATER 21)
target_compile_features(gdal_PDF PRIVATE cxx_std_17)
endif ()
target_compile_definitions(gdal_PDF PRIVATE -DHAVE_POPPLER
-DPOPPLER_MAJOR_VERSION=${POPPLER_VERSION_MAJOR}
-DPOPPLER_MINOR_VERSION=${POPPLER_VERSION_MINOR})
endif ()
and happily, 119 remains > 21, so poppler patch 089f84b worked.
Thereafter, MrSid driver cratered on some 2004 Lizardtech defines in
lt_platform.h that defined possible GCC compilers topping out at <= 5
(rather than a future unimaginable 9 or 12). Removing a desire for MrSid,
in this instance through ccmake,
Re-clone gdal and we get to this, new, somewhat indecipherable, not quite
there, but achingly close:
[ 89%] Building CXX object
gcore/mdreader/CMakeFiles/gcore_mdreader.dir/reader_spot.cpp.o
[ 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 from there I guess I will attempt to chug along.
Losing MrSid is a disappointment as the earliest USGS experimental
photogrammetry data available, albeit without sufficient viable GPCs (for
local areas as many were lost through time), was predicated on coastal
overflights related to beach erosion control efforts/federal expenses from
100 years ago. To my view, sufficient GPCs still exist within and across
the dataset, that it could serve as an historic measure, with an
appropriate eye toward the geographic basis that remaining GPCs indicate.
But it will no longer be local area, though that is what a certain client
wants.
Happily, or unhappily, my above error reveals some 8 google responses, with
none censored to show most relevant.
And, as CMAKE is our fate, and gdal is our best tool, we will endeavor to
persevere, so we can also get sf in R to load again.
Chris
On Thu, Mar 3, 2022 at 3:26 PM Jeff McKenna
wrote:
> 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 the Windows / MS4W community) I had to patch GDAL 3.4.1
> for this, but in your case you might want to grab GDAL-master from git
> as that will be easier to handle the new poppler.
>
>
> -jeff
>
>
>
> --
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
>
>
>
>
> On 2022-03-03 4:03 p.m., chris english wrote:
> > 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 feeble
> > understanding of build process requirements.
> >
> > Recklessly editing lines in CMakeLists.txt:
> > 41 # check compiler and set preferences.
> > 42 set(CMAKE_CXX_STANDARD 17)
> > [ 44%] Built target gdal_STACIT
> > [ 44%] Building CXX object
> > frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o
> >
> > but further along we run across c++17 be contra-indicated as to
> >
> > [ 49%] Built target gdal_PostGISRaster
> > [ 49%] Building CXX object
> > frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o
> >
> > from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38:
> > /usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not
> > allow dynamic exception specifications
> >114 | RCReader() throw(Error);
> >
> > which leads to a set by individual target approach as is said to be
> > available
> >
> > set_property(TARGETtgtPROPERTYCXX_STANDARD17)
> > set_property(TARGETtgtPROPERTYCXX_STANDARD11)
> >
> > and were this the solution, what would it look like and where might it
> > reside in say
> >
> > CMakeCache.txt, or have I just gotten this all wrong, as I expect I have.
> >
> > Ubuntu 20.04, gcc-9.3.0, and happy to have broken through to 49%, but
> > wouldn't
> >
> > that's 99% good news.
> >
> > Chris
> >
> >
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
Re: [gdal-dev] CMAKE poppler c++17
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 the Windows / MS4W community) I had to patch GDAL 3.4.1 for this, but in your case you might want to grab GDAL-master from git as that will be easier to handle the new poppler. -jeff -- Jeff McKenna GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of FOSS4G http://gatewaygeo.com/ On 2022-03-03 4:03 p.m., chris english wrote: 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 feeble understanding of build process requirements. Recklessly editing lines in CMakeLists.txt: 41 # check compiler and set preferences. 42 set(CMAKE_CXX_STANDARD 17) [ 44%] Built target gdal_STACIT [ 44%] Building CXX object frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o but further along we run across c++17 be contra-indicated as to [ 49%] Built target gdal_PostGISRaster [ 49%] Building CXX object frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38: /usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not allow dynamic exception specifications 114 | RCReader() throw(Error); which leads to a set by individual target approach as is said to be available set_property(TARGETtgtPROPERTYCXX_STANDARD17) set_property(TARGETtgtPROPERTYCXX_STANDARD11) and were this the solution, what would it look like and where might it reside in say CMakeCache.txt, or have I just gotten this all wrong, as I expect I have. Ubuntu 20.04, gcc-9.3.0, and happy to have broken through to 49%, but wouldn't that's 99% good news. Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] CMAKE poppler c++17
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 feeble understanding of build process requirements. Recklessly editing lines in CMakeLists.txt: 41 # check compiler and set preferences. 42 set(CMAKE_CXX_STANDARD 17) [ 44%] Built target gdal_STACIT [ 44%] Building CXX object frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o but further along we run across c++17 be contra-indicated as to [ 49%] Built target gdal_PostGISRaster [ 49%] Building CXX object frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38: /usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not allow dynamic exception specifications 114 | RCReader() throw(Error); which leads to a set by individual target approach as is said to be available set_property(TARGET tgt PROPERTY CXX_STANDARD 17) set_property(TARGET tgt PROPERTY CXX_STANDARD 11) and were this the solution, what would it look like and where might it reside in say CMakeCache.txt, or have I just gotten this all wrong, as I expect I have. Ubuntu 20.04, gcc-9.3.0, and happy to have broken through to 49%, but wouldn't that's 99% good news. Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VRT dataset to text in-memory?
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 *poSrcDS, *poVRTDS; > poSrcDS = (GDALDataset *) GDALOpenShared( pszSourceFilename, GA_ReadOnly ); > poVRTDS = poDriver->CreateCopy( "", poSrcDS, FALSE, NULL, NULL, NULL ); > // > > Is there a way to obtained the VRT XML text representing poVRTDS without > writing to an actual file? Check what the https://gdal.org/programs/gdalbuildvrt.html does: https://github.com/OSGeo/gdal/blob/master/apps/gdalbuildvrt_bin.cpp#L192-L196 which is this call https://github.com/OSGeo/gdal/blob/master/apps/gdalbuildvrt_lib.cpp#L1691 which uses this builder class https://github.com/OSGeo/gdal/blob/master/apps/gdalbuildvrt_lib.cpp#L1769 which is/can be built as a library and linked against. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning
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. Therefore the tables that you will have are not identical with the source tables by their schemas. The foreign key constraints between the tables are dropped any way, ogr2ogr does not try to transfer them ever. I think you can answer your question yourself by making a test with your own data. If all of the tables that have a composite PK get a new PK field in Spatialite (I guess it will of type "integer autoincrement") and if the row counts in source and target tables match I believe that the data has been transferred right. When it comes to question "is it safe to assume that db relations won't get mixed up" you do not have any constrained relations left in Spatialite. The data integrity is OK immediately after the conversion but at that stage there is nothing in Spatialite that prevents you from making edits that you should't do. But you can add similar constraints that you have in PostGIS afterward into SQLite https://sqlite.org/foreignkeys.html. I am not sure that all type of constraints that you can have in PostGIS are supported in SQLite but foreign key should behave in the same way. SQLite driver https://gdal.org/drivers/vector/sqlite.html supports prelude_statements but if you want to re-create constraints you would need something like postlude_statements. It means that ogr2ogr cannot do the whole job but you must run the required SQL statements with ogrinfo or some SQLite client. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: gdal-dev Puolesta DUTRIEUX Loic Lähetetty: torstai 3. maaliskuuta 2022 13.56 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning 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 primary keys. When I run ogr2ogr I get a warning saying that Multi-column primary key are not supported. Should I be worried of that warning for my use case or is it safe to assume that db relations won't get mixed up. Thanks and kind regards, Loïc ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning
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 primary keys. When I run ogr2ogr I get a warning saying that Multi-column primary key are not supported. Should I be worried of that warning for my use case or is it safe to assume that db relations won't get mixed up. Thanks and kind regards, Loïc ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] VRT dataset to text in-memory?
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( pszSourceFilename, GA_ReadOnly ); poVRTDS = poDriver->CreateCopy( "", poSrcDS, FALSE, NULL, NULL, NULL ); // Is there a way to obtained the VRT XML text representing poVRTDS without writing to an actual file? Sorry if this is obvious, haven't been able to find an example that does what I want. I've seen examples using GetMetadataItem from a band for parts of the XML, but can't see how to get the entire thing. Thanks for your help. Best, Mike -- Michael Sumner Software and Database Engineer Australian Antarctic Division Hobart, Australia e-mail: mdsum...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
