On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> Yes, the only robust way to deal with SpatiaLite and GeoPackage geometries
> would probably be to use the duck test like our DB Query Plugin does. If the
> result is a blob that like a SpatiaLite BLOB or like a GeoPackage BLOB, then
> it probabl
Yes, the only robust way to deal with SpatiaLite and GeoPackage geometries
would probably be to use the duck test like our DB Query Plugin does. If the
result is a blob that like a SpatiaLite BLOB or like a GeoPackage BLOB, then it
probably is so.
However, it may get complicated to support this
hey Jukka,
looked a bit deeper. sqlite is not really tagging cols retrieved in the
metadata apart from known col types (eg. text,blob,...) . it obviously is is
totally ignorant of geometries.
as a workaround we could "transport" a type information in the col name which
is then used in OJ only.
well, at least spatialite works again :)) yayhh.
wrt. the issue below.
https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/com/vividsolutions/jump/datastore/spatialite/SpatialiteValueConverterFactory.java#l47
is where the column type is "detected" and it uses the column name to do s
Revision: 6555
http://sourceforge.net/p/jump-pilot/code/6555
Author: edso
Date: 2020-09-28 13:06:25 + (Mon, 28 Sep 2020)
Log Message:
---
little workaround to fetch geom coltype by using sql select as
Modified Paths:
--
core/trunk/src/com/vividsolutions
Hi,
When using Spatialite/Geopackage as data source OpenJUMP seems to check the
schema too literally. While this works
SELECT geom FROM test LIMIT 1;
the same query with a simple alias gives an error
SELECT geom AS geometry FROM test LIMIT 1;
java.lang.Exception: java.lang.Exception: Result Set
