On Mon, 9 Dec 2019 at 22:20, Matthias Kuhn <[email protected]> wrote: > > On 12/9/19 12:00 PM, Nyall Dawson wrote: > > On Mon, 9 Dec 2019 at 20:10, Matthias Kuhn <[email protected]> wrote: > >> Thanks for the clarification Andreas, indeed there was a misunderstanding > >> on my end. > >> > >> That's admittedly a pain point with GPKG, I hope this can be resolved in > >> future versions of the spec. > >> > >> But let's be honest, in QGIS we are not much better yet, integration of > >> additional geometry columns is not very polished. We have a "main" > >> geometry column to work with and "secondary" geometry columns which can be > >> accessed to some degree. A concept which we can tack onto GPKG (or any > >> format with no field content limitation -- guess who just dropped out of > >> the candidate formats) as well. > > Yes, this is something I think we need to work on. Secondary geometry > > fields should be exposed as geometry values, not wkt or wkb or another > > encoded format. > > > > I've submitted various PRs over the years to try to implement this, > > but none of them have been good enough to merge :P (yet!) > > > > Nyall > > I've been there too. And recently had to add yet another regex in a > project to parse EWKT :( > > Let's make sure QGIS 4 will have native geometry type attributes for pg!
Does this require QGIS 4? I don't think handling of secondary geometry values is really part of stable api (especially since every provider does it different) Nyall > > Matthias > _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
