GeoPackage input support

[program--]

This PR implements support for GeoPackage input via the SQLite3 C library based on the OGC GeoPackage Encoding Standard.

(resolves #295; related: #496)

Note: the current additions are a bit of a mess, but will be cleaned up once this PR is no longer a draft.

Additions

• Adds SQLite3 as a dependency.
• Adds a simple C++ wrapper over the SQLite3 C interface (include/geopackage/SQLite.hpp).
• Adds a new sub-library geopackage that contains the primary function geopackage::read(), which returns a geojson::GeoJSON (a.k.a. std::shared_ptr<geojson::FeatureCollection>) object, like geojson::read.
• Adds a WKB reader (geopackage::wkb). [ref: OGC SFA Part 1, GEOS WKB]

Testing

• gcc (version 13.1.1)
• clang (version 15.0.7)
• icx (version 2023.0.0.20221201)

Notes

• This implementation currently depends on geojson for feature classes.
• In the future (out of scope for this PR), it may be beneficial to decouple the feature classes implementation from the GeoJSON parser, since the feature classes themselves do not require use of boost::property_tree, and so that this implementation doesn't require linking to geojson.
• If GDAL is supported in the future, this implementation can be easily refactored -- and modified to be generic for any of the GDAL/OGR vector drivers.
• Once implemented, lines 262 and 266 should be able to be modified for use with either GeoJSON or GeoPackage, since they will return the same type of object:

  ngen/src/NGen.cpp

  Lines 262 to 266 in 6ab044e

  	geojson::GeoJSON nexus_collection = geojson::read(nexusDataFile, nexus_subset_ids);
  	std::cout << "Building Catchment collection" << std::endl;
  	// TODO: Instead of iterating through a collection of FeatureBase objects mapping to catchments, we instead want to iterate through HY_Catchment objects
  	geojson::GeoJSON catchment_collection = geojson::read(catchmentDataFile, catchment_subset_ids);

Todos

• geopackage::read
  • geopackage::build_feature
  • geopackage::build_geometry
  • geopackage::build_properties
• Implement Standard WKB reader
  • Handle projections (i.e. Hydrofabric data typically is in EPSG:5070)
  • Extend reader for GeoPackage blob WKB
• Add SQLite dependency within cmake
• Unit tests
  • SQLite Wrapper
  • GeoPackage
  • WKB Reader
• Integration tests (i.e. successfully use geopackage::read in place of the geojson variant)
  • Add a geopackage integration test to the existing github actions workflows
• Documentation
• Make GeoPackage support conditional on if SQLite is found. Otherwise, fall back to GeoJSON.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Target Environment support

• Linux

[program--]

This PR is just about ready for review. The last things are adding unit tests for geopackage::read and it's used functions, as well as run the ngen integration tests using geopackage::read instead of geojson::read. I'm expecting the need to refactor quite a bit of the work I've done here (especially the WKB reader), since it is messy 😅.

[program--]

There is currently an issue in this PR that occurs when the CMake Build type is set to Release with GCC and Clang. For some reason, the boost::geometry::srs::transformation<> object throws an error when its constructor is called.

This does not occur when The build type is set to Debug, OR when ICX is used in either Debug or Release.

---

After some investigating, it seems like it might be a clang or boost bug? Compiling geometry.cpp to LLVM IR with -O1 results in recursive calls to llvm::ScalarEvolution::getRangeReg (which I'm guessing results in a stack overflow, hence the segfault?):

#12 0x00007fffefc65393 llvm::ScalarEvolution::getRangeRef(llvm::SCEV const*, llvm::ScalarEvolution::RangeSignHint) (/usr/lib/libLLVM-15.so+0x2866e98)
... repeats ...
#255 0x00007f9404c66e98 llvm::ScalarEvolution::getRangeRef(llvm::SCEV const*, llvm::ScalarEvolution::RangeSignHint) (/usr/lib/libLLVM-15.so+0x2866e98)

and emitting the .ll file, before optimization, is almost 1M lines...

EDIT: this also occurs with clang 14.0.6 so it doesn't seem like a recent regression

---

EDIT: after talking with Donald, working around this by disabling optimizations for geometry.cpp when building with gcc/clang may be the way to go. Commit c6b31e4 handles this.

[mattw-nws]

Will look at this more, but did a cursory pass and don't see any show stoppers. Interested in others' feedback. I did run the software on the test case in data/gauge_01073000 using both the geojson and geopkg inputs, which succeeded and I found no differences in the output, so that's positive.

[hellkite500]

Generally looks pretty good, but a couple things that might warrant further discussion/testing, and some minor cleanup comments.

[PhilMiller]

Would it make sense to move all of the added SQLite support code over to utilities, since nothing in it is actually specified to GeoPackage?

[program--]

Would it make sense to move all of the added SQLite support code over to utilities, since nothing in it is actually specified to GeoPackage?

@PhilMiller Maybe? Although, GeoPackage is the only portion of NGen that is using SQLite, so in that case it would also make sense to keep it together with the GeoPackage code. I think it would make sense to move it if other portions of NGen made use of SQLite.