(MML)"
>> à : OpenJump develop and use , Larry
>> Reeder
>> objet : Re: [JPP-Devel] Run datastore query too tied to schema with
>> Spatialide DS
>>
>>
>> Hi,
>>
>> Michaël must remember this better, but JTS did not understand the ISO codes
>
Hi Jukka,wrt. z/m reading, the patch I had submitted to JTS has been included in locationtech repo just before the 1.5 release. So you're right, with our 1.14 vividsolutions version, we probably can't read both forms of WKB. Hopefully, it will be easier after our migration to OJ
On 29.09.2020 19:45, Rahkonen Jukka (MML) wrote:
> select AsGPB(casttoxy(castautomagic(geom))) from test limit 1;
right
select casttoxy(castautomagic(geom)) from random_points
works for my test gpkg data set. wrt. DBQuery
..ede
___
Jump-pilot-devel
: tiistai 29. syyskuuta 2020 17.36
Vastaanottaja: jump-pilot-devel@lists.sourceforge.net; Larry Reeder
Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS
On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> We have the robust DB Query that works fine (despite with
On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> We have the robust DB Query that works fine (despite with XYZ geometries but
> that's another thing).
yeah, noticed that DBQuery choked on some geometries from a gpkg test file.
Jukka, would you mind providing some test files for geometry blobs
On 9/29/2020 14:22, Michaud Michael wrote:
> Ede,
>
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.
>
> >well, in theory it can. the model as is merely limits geometry to be _only
> one_ of the attributes. as Geometry is a proper attribute type we
Ede,OJ can't support multiple geometries and it would be a difficult task to makethis change.>well, in theory it can. the model as is merely limits geometry to be _only one_ of the attributes. as Geometry is a proper attribute type we can easily add more than one, they won't be displayed though
On 9/29/2020 13:00, Michaud Michael wrote:
> Hi,
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.
well, in theory it can. the model as is merely limits geometry to be _only one_
of the attributes. as Geometry is a proper attribute type we can
Hi,OJ can't support multiple geometries and it would be a difficult task to make this change.Object type can be used- to preserve original data as much as possible, but will generally not survive a complete roundtrip (maybe a more specific serialization format could achieve this goal, but with
Hi,>>what about the multiple geometry column issue? what would be a use case
for that and how would you suggest to present those in OJ? ..edeFor postgis, as far as I remember, we read the first geometry column as geometry and following geometry columns as String or Object (don't remember).In
On 9/29/2020 12:14, Rahkonen Jukka (MML) wrote:
> edgar.sol...@web.de wrote:
> 29.9. 2020 13.01
>
> On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>>> select geom,
>>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1;
>
>> do we currently warn/err out if someone actually selects two
edgar.sol...@web.de wrote:
29.9. 2020 13.01
On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>> select geom,
>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1;
> do we currently warn/err out if someone actually selects two geometry
> columns? should we auto-convert to WKT additional
On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>> morning Jukka,
>> On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
There would be still some corner cases left (select geom as geometry1,
ST_Centroid(geom) as geometry2...
>>> in theory our features may hold multiple geometries. just one
edgar.sol...@web.de wrote
29.9. 2020 11.57
> morning Jukka,
> On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
>>> There would be still some corner cases left (select geom as geometry1,
>>> ST_Centroid(geom) as geometry2...
>> in theory our features may hold multiple geometries. just one can be
morning Jukka,
On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
>> There would be still some corner cases left (select geom as geometry1,
>> ST_Centroid(geom) as geometry2...
> in theory our features may hold multiple geometries. just one can be shown
> though and the second would be like some
at.
-Jukka-
..ede
>
> -Jukka-
>
> -Alkuperäinen viesti-----
> Lähettäjä: edgar.sol...@web.de
> Lähetetty: maanantai 28. syyskuuta 2020 20.44
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with
> Sp
ukka-
>
> -Alkuperäinen viesti-
> Lähettäjä: edgar.sol...@web.de
> Lähetetty: maanantai 28. syyskuuta 2020 20.44
> Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
> Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide
> DS
>
> hey Jukka,
&g
: edgar.sol...@web.de
Lähetetty: maanantai 28. syyskuuta 2020 20.44
Vastaanottaja: jump-pilot-devel@lists.sourceforge.net
Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS
hey Jukka,
looked a bit deeper. sqlite is not really tagging cols retrieved in the
metadata
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
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
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
21 matches
Mail list logo
