On 22.04.2013 04:51, Larry Reeder wrote:
> I've lost track of supported JRE versions for OpenJump. Is it 1.6 now?
yes we target 1.6 now. ..ede
--
Precog is a next-generation analytics platform capable of advanced
ana
Yep, I'll make the change shortly.
On 4/21/2013 8:22 PM, Larry Reeder wrote:
Martin, I agree that the JTS WKBReader shouldn't be hacked to support
the SpatialLite BLOB format or whatever else come along with a
slightly different interpretation of the standard, and this is a great
compromise s
Martin, I agree that the JTS WKBReader shouldn't be hacked to support the
SpatialLite BLOB format or whatever else come along with a slightly
different interpretation of the standard, and this is a great compromise
solution. Is this change something we can expect in JTS 1.14?
Thanks
> @Larry:
> could you please change
> JumpSpatialiteDbQuery.java
> so that in line 455 the new error is based on the old one
> 'SQLException(Throwable cause)', so the error stack to the root issue stays
> intact?
>
Good suggestion, Ede. Done and also part of the 0.8.2 re-release.
-lreeder
Jukka,
This is probably a problem because I built 0.8.2 with JDK 1.7 and you're
using JRE 1.6 or older. I've lost track of supported JRE versions for
OpenJump. Is it 1.6 now? Anyway, I've rebuilt to be backward compatible
with JRE 1.6, and redeployed 0.8.2 to sourceforge. Give it another tr
Hi Martin,
Your proposal to switch endianess only when the code is one of the two
specified in the standard seems fine to me. No need to introduce
specific spatialite byte value in the code.
Michaël
> Hey guys, I have been lurking on this thread...
>
> I agree that it would be bizarre to switc
Hey guys, I have been lurking on this thread...
I agree that it would be bizarre to switch endianess in the middle of a
WKB blob. I suspect that the standard did not really have the intent of
supporting this, they just provided multiple endian code items as a
side-effect of reusing the definit
On 21.04.2013 17:13, Michaël Michaud wrote:
> Hi
>> well - the SRID code is the only thing that seems to be added between JTS
>> 1.7 and 1.8.
>>
>> some more observations:
>>
>> what Larry's DBQuery actually does is stripping MBR header and end marker
>> from the spatiallite blob and handing it o
Hi
> well - the SRID code is the only thing that seems to be added between JTS 1.7
> and 1.8.
>
> some more observations:
>
> what Larry's DBQuery actually does is stripping MBR header and end marker
> from the spatiallite blob and handing it over to JTS. as Michael correctly
> discovered is the
well - the SRID code is the only thing that seems to be added between JTS 1.7
and 1.8.
some more observations:
what Larry's DBQuery actually does is stripping MBR header and end marker from
the spatiallite blob and handing it over to JTS. as Michael correctly
discovered is the endianess byte u
On 21.04.2013 15:46, Michaël Michaud wrote:
> Hi Ede,
>> ok, just dug some more into "OpenGIS Simple Features Specification for SQL"
>> http://portal.opengeospatial.org/files/?artifact_id=829
>>
>> and as far as i read on page 3-24 and later, a little bit unclear, but it
>> seems to me that endian
Hi,
In JTS revision 637, Martin took care of the successive byte order
"Fixed WKBReader to handle successive geometrys with different endianness"
http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jts/io/WKBReader.java?r1=57&r2=637
Maybe there
Hi Ede,
ok, just dug some more into "OpenGIS Simple Features Specification for SQL"
http://portal.opengeospatial.org/files/?artifact_id=829
and as far as i read on page 3-24 and later, a little bit unclear, but it seems
to me that endianess is not repeated (see the Polygon example with /two/ ri
ok,
just compared
jts-1.8.0\src\com\vividsolutions\jts\io\WKBReader.java
with it's 1.7.2 counterpart, where the error originates.
@Larry:
could you please change
JumpSpatialiteDbQuery.java
so that in line 455 the new error is based on the old one
'SQLException(Throwable cause)', so the error
ok, just dug some more into "OpenGIS Simple Features Specification for SQL"
http://portal.opengeospatial.org/files/?artifact_id=829
and as far as i read on page 3-24 and later, a little bit unclear, but it seems
to me that endianess is not repeated (see the Polygon example with /two/ rings)
but
Hi,
We do not deal now with WKB but with Spatialite native geometry BLOBs
http://www.gaia-gis.it/gaia-sins/BLOB-Geometry.html
Reason for this if that "select AsBinary" from SQLite database is possible only
through the Spatialite function. DB Query Plugin is made to work with plain
SQLite and th
regarding your interpretation below i just found the following
http://www.gaia-gis.it/spatialite-2.1/SpatiaLite-manual.html#t3.2
which states:
"
The Well-Known Binary (WKB) representation for geometric values is defined by
the OpenGIS specification.
"
and
"
Component representation is as foll
Larry Reeder gmail.com> writes:
>
>
>
> Great analysis, Michaël. Looks like the spatialite component of plugin
will need to do it's own WKB decoding instead of relying on the JTS
WkbReader, at least in part.
> -lreeder
Theoretically, if the plugin was only a Spatialite plugin, I think t
Great analysis, Michaël. Looks like the spatialite component of plugin
will need to do it's own WKB decoding instead of relying on the JTS
WkbReader, at least in part.
-lreeder
On Mon, Apr 15, 2013 at 12:44 AM, Michaël Michaud
wrote:
> Hi,
>
> Just compared both strings to the spec,
>
> Fir
well spotted.. the devil is in the details! ..ede
On 15.04.2013 08:44, Michaël Michaud wrote:
> Hi,
>
> Just compared both strings to the spec,
>
> First string follows the WKB specification
> 01 endianess
> 0600 MultiPolygon
> 0200 Number of Polygons
> 01 endianess
> 0300 Polygon
>
Hi,
Just compared both strings to the spec,
First string follows the WKB specification
01 endianess
0600 MultiPolygon
0200 Number of Polygons
01 endianess
0300 Polygon
0200 Two rings
0400 Four points
...
Second string follows the Spatialite specification
http://www.gaia-gis
e multigeometry trouble and JTS v. 1.13
On Sun, Apr 14, 2013 at 3:39 PM, Rahkonen Jukka
mailto:jukka.rahko...@mmmtike.fi>> wrote:
Hi,
I made two tests:
1) With PostGIS 2.1
select encode(ST_AsBinary(ST_GeomFromText('MULTIPOLYGON(((0 0, 10 20, 30 40, 0
0), (1 1, 2 2, 3 3, 1 1)),
(
On Sun, Apr 14, 2013 at 3:39 PM, Rahkonen Jukka
wrote:
> Hi,
>
> I made two tests:
> 1) With PostGIS 2.1
> select encode(ST_AsBinary(ST_GeomFromText('MULTIPOLYGON(((0 0, 10 20, 30
> 40, 0 0), (1 1, 2 2, 3 3, 1 1)),
> ((100 100, 110 110, 120 120, 100 100)))')), 'hex')
> Query gives the same WKB th
Hi,
I made two tests:
1) With PostGIS 2.1
select encode(ST_AsBinary(ST_GeomFromText('MULTIPOLYGON(((0 0, 10 20, 30 40, 0
0), (1 1, 2 2, 3 3, 1 1)),
((100 100, 110 110, 120 120, 100 100)))')), 'hex')
Query gives the same WKB that you used in JTS bug #3610843, that is
"0106000200010300
Appears to be a problem with JTS 1.13, unless the WKB is not conformant to
the spec, and JTS 1.12 was ignoring any problems. I opened bug # 3610843
against JTS.
-lreeder
On Wed, Apr 10, 2013 at 2:58 PM, Michaël Michaud wrote:
> Le 10/04/2013 11:12, edgar.sol...@web.de a écrit :
> > On 10.04.2
Le 10/04/2013 11:12, edgar.sol...@web.de a écrit :
> On 10.04.2013 04:51, Larry Reeder wrote:
>> While testing the new 0.8.1 version of DB Query Plugin I noticed that I
>> could not read any multigeometries nor geometry collections from Spatialite.
>> Further research revealed that with a bit old
On 10.04.2013 04:51, Larry Reeder wrote:
> While testing the new 0.8.1 version of DB Query Plugin I noticed that I could
> not read any multigeometries nor geometry collections from Spatialite.
> Further research revealed that with a bit older OpenJUMP versions there are
> no troubles at all wit
Thanks for the sample DB, Jukka. I will try to take a look this weekend.
-lreeder
On Mon, Apr 8, 2013 at 2:01 AM, Rahkonen Jukka wrote:
> Hi,
>
> While testing the new 0.8.1 version of DB Query Plugin I noticed that I
> could not read any multigeometries nor geometry collections from
> Spatia
Hi,
While testing the new 0.8.1 version of DB Query Plugin I noticed that I could
not read any multigeometries nor geometry collections from Spatialite. Further
research revealed that with a bit older OpenJUMP versions there are no troubles
at all with these geometries. For example OJ r3131 fr
29 matches
Mail list logo
