Hi Ian, I checked the GeoPackage specification http://www.geopackage.org/spec/ and if I understand correctly, both DOUBLE and REAL types are considered 64-bit floating point numbers and for 32-bit - a FLOAT type should be used (Table 1. GeoPackage Data Types). However, since SQLite is a dynamically-typed engine, it's possible to keep higher precision values even if the type affinity is FLOAT. For example, QGIS doesn't differentiate between FLOAT and DOUBLE - there is only a type "Real" for GeoPackage. It's possible to save 64-bit float values, even if the GeoPackage column type in schema is a FLOAT. Therefore, this is my conclusion after gathering all the information:
First of all, currently GeoTools violate the specification when creating a new GeoPackage. Both Float.class and Double.class are mapped into a REAL, which is further (in gt-jdbc) converted into a Float and the precision is lost (because there is no override for GeoPkgDialect). However, during reading, the value returned by geoPackage.reader().next().getAttribute() is always a Double. Current type mapping is as below: Saving: Float.class -> REAL Double.class -> REAL Reading: FLOAT -> Double.class DOUBLE -> Double.class REAL -> Double.class I see two possible solutions: *1) "strongly-typed"* Types are mapped as close as possible to the Java and GeoPackage schema. It means the mapping is modified as follows: Saving: Float.class -> FLOAT Double.class -> DOUBLE Reading: FLOAT -> Float.class DOUBLE -> Double.class REAL -> Double.class This approach seems quite restrictive compared to SQLite itself and clearly not backward-compatible if someone relies on the fact that the reader will always return a Double.class. *2) "weakly-typed"* Types in SimpleFeature schema are mapped closely to GeoPackage but reading is left as a Double: Saving: Float.class -> FLOAT Double.class -> DOUBLE Reading: FLOAT -> Double.class DOUBLE -> Double.class REAL -> Double.class This would allow to ensure backward compatibility while keeping a flexibility of loaded data. This is a solution I personally consider better. Please let me know what you think about it and whether I missed anything during this analysis. Regards, Piotr pt., 16 paź 2020 o 10:07 Ian Turton <ijtur...@gmail.com> napisał(a): > It looks like that has been there since the beginning of the module, if > you added a Float.class -> Real as well as Double.class -> Double would > that work? Also are we still able to read back existing geopackages? > Anyway feel free to add a PR with some additional tests. > > Ian > > On Thu, 15 Oct 2020 at 23:57, Piotr Marcińczyk <piomar...@gmail.com> > wrote: > >> Hi all, >> >> I created this ticket: >> https://osgeo-org.atlassian.net/browse/GEOT-6722 >> and I'd like to find a solution for this problem. >> However, I'm not sure why the mapping Double -> REAL was created in the >> first place. I was thinking about simply changing the mapping into Double >> -> DOUBLE. >> The tests are passing but I'm not sure about the consequences of such >> change. >> >> Any hints would be appreciated. >> >> Best regards, >> Piotr Marcińczyk >> _______________________________________________ >> GeoTools-GT2-Users mailing list >> GeoTools-GT2-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users >> > > > -- > Ian Turton >
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
