Closed boonen closed 13 years ago
Hi Jan,
How is the data/geometry being inserted into the table? Any chance you could provide a quick test case to reproduce the issue? With that we should be able to quickly fix. And if you want to whip up a patch even better :)
Hi Justin,
Let me get back to you next week with a test. I'm willing to supply a patch, but before I do so, I'd like to discuss the impact with you (I don't plan to destroy the existing codebase ;-)
Cheers,
Jan
On 11 March 2011 17:32, jdeolive reply@reply.github.com wrote:
Hi Jan,
How is the data/geometry being inserted into the table? Any chance you could provide a quick test case to reproduce the issue? With that we should be able to quickly fix. And if you want to whip up a patch even better :)
Hi Jan,
Thinking more about this issue... by default new geometries should be written in EWKB. The only case in which they are not is when an older version of JTS is being used. I had to patch JTS mid 1.12 in order to support writing of the SRID.
Can you confirm which version is being used in the hibernate spatial case? Thanks.
When doing a query, using ST_SRID(), the result is always 0. Since Hibernate Spatial uses this method in its test queries (see below an example query), the GeoDB dialect cannot be made compatible.
A possible solution would be to always store geometries as EWKB, but this probably break the current support for WKB/WKT methods.
Hibernate Spatial query (from test suite): select geomentity0_.id as col_00, STWithin(geomentity0.geom, ST_GeomFromText(?, 4326)) as col_10 from GEOMTEST geomentity0_ where STWithin(geomentity0.geom, ST_GeomFromText(?, 4326))=1 and STSRID(geomentity0.geom)=4326