Create a geoparquet module and add dependencies

[bchapuis]

No description provided.

[Drabble]

Thank you for creating this draft so quickly. I just added 2 small questions to the PR.

[bchapuis]

Previous attempt #851

[bchapuis]

@sebr72 I just pushed the GeoParquetGroup interface, which I think would be a decent abstraction to access the records of a geoparquet file. It contains getters and setters for the main geopackage types. It also describes an augmented schema for the GeoPackage schema. It uses a sealed GeoParquetGroup.Schema interface that would facilitate introspection by the users of the API. It would be nice to have your feedback.

In terms of organisation, once this interface is stabilized, I can work on a postgis importer with mocks and you can work on the geopackage reader internals. Is that ok for you?

@Drabble It would be nice to have your feedback as well.

[Drabble]

I believe that INT96 is deprecated. https://stackoverflow.com/questions/55829202/unable-to-read-date-format-columns-int96-type-from-avro-parquet-schema-in-apac. Did you get some INT96 fields in the geoparquet files?

[Drabble]

We can probably discuss organising these files further into sub-directories. FileInfo and DoubleValue don't really belong together.

[Drabble]

Is this a standard way to do it?

[bchapuis]

No, this is a quick and dirty attempt at supporting wildcards. I will put a TODO ;)

[Drabble]

I did a little bit of reading on the spec of geoparquet. https://github.com/opengeospatial/geoparquet/blob/main/format-specs/geoparquet.md

I have a feeling that in our library what we do is extract the data from a generic parquet file and provide in addition the Geoparquet metadata. We don't really do Geoparquet specifc processing except from the metadata parsing.

We could provide extra functions to parse the WKB/GeoArrow binary into a Java class that loads up geometries and sets the correct CRS. For Baremaps, I don't think this is really useful as we store raw WKB in the database. But it could be useful for someone using the library. Maybe this should be considered in a second iteration?

The big question is, should we return a Logical type called Geometry instead of the binary type? This could also be valid for other logical types like STRING or Date. And should we rename the Primitive class into something else as String/Geometry are not primitives.

Regarding the geoparquet metadata, I believe we should provide this metadata with a function like geoParquetReader.getGeoParquetMetadata() instead of including it inside each GeoParquetGroupImpl object. The Geoparquet metadata should be the same for each record, as long as the files are valid.

As for writing to Geoparquet files, I think this is not useful for Baremaps. We should maybe consider it as a second or third step. I think there are a lot of question about supporting the entire specification and validating schemas if we try to implement that.

Some things to consider for support are:

• Single-geometry type encodings based on the GeoArrow specification instead of WKB.
• Validating input geoparquet files. For example in the spec, there should never be geometries inside nested objects.
• Using more complex types for GeoParquetColumnMetadata. For example the edges field could be an enum. Name of the coordinate system for the edges. Must be one of "planar" or "spherical". The default value is "planar".

[Drabble]

Do you think we will have a different Geoparquet DataTable for each subtheme?

I believe each sub theme will have a different schema. https://docs.overturemaps.org/schema/reference/

For example water inside the base theme has a is_salt property and land has an elevation property.

That would make a total of 16 tables with the current Overture Maps spec.

[sonarqubecloud]

Quality Gate failed

Failed conditions
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint