distinction between H2 GEOMETRY and BLOB types in geodb

84 views
Skip to first unread message

Raif S. Naffah

unread,
Apr 11, 2016, 10:10:39 PM4/11/16
to geodb
hi Justin,

over the past weekend i downloaded the geodb sources (based on the 0.8 tagged release) and modified the POM to use the latest stable H2 (1.3.176) and hatbox (1.0.b9).  i then used this version w/ GeoTools (14.3) to build a gt-jdbc-h2 for use w/ GeoServer (2.8.3).  all 325 tests (in gt-jdbc-h2) pass after i modified the SQL in 3 H2xxxTestSetup classes to use BLOB instead of GEOMETRY in the CREATE TABLE ... statements.

looking in the 'geodb.sql' used to initialize geodb i see aliases for GEOMETRY and its (JTS) sub-types as BLOBs.  this to me indicates an issue in my test environment to do w/ proper initialization of the tests' environment.

this also made me realize that geodb is not using the H2 (native) GEOMETRY type which would be, theoretically at least, more performant since it would require less conversion from/to WKT.  is this correct?

if it is, are there any reasons preventing geodb from supporting this H2 type?


TIA + cheers;
rsn

Raif S. Naffah

unread,
Apr 11, 2016, 11:29:23 PM4/11/16
to geodb
i think i can answer these questions!  it looks like hatbox only supports BLOB, BINARY or VARBINARY for columns to be used as geometries :-(

Justin Deoliveira

unread,
Apr 12, 2016, 8:23:06 AM4/12/16
to geodb
Hi Raif,

You’re indeed correct, the geodb “environment” pre-dates the h2 native geometry type. Using the native H2 type would be really great except last I looked it didn’t have any notion of a spatial index. I haven’t looked in quite some time though. 

-Justin

--
You received this message because you are subscribed to the Google Groups "geodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geodb+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raif S. Naffah

unread,
Apr 12, 2016, 10:12:14 PM4/12/16
to geodb
hi Justin,

thanks for confirming!

looking at this (http://h2database.com/html/advanced.html#spatial_features) however it seems that H2 now has spatial indexing capabilities out-of-the-box.  i'm wondering how difficult it would be to build on that and have a GeoTools JDBC data-store that takes advantage of it?  thoughts?

Justin Deoliveira

unread,
Apr 13, 2016, 8:29:40 AM4/13/16
to geodb
Aha, look at that. That’s great to see. So it looks like this latest version makes geodb kind of obsolete, or at least really simplifies it. Updating the geotools datastores is a bit of work, not huge but not trivial. Most of the SQL specifics live in the H2Dialect class… so really we would be looking at changing that for the most part. 

Raif S. Naffah

unread,
Apr 13, 2016, 9:25:47 PM4/13/16
to geodb
hi Justin,

yes, i see how geodb would be simplified to contain the implementation of (part of) Simple Feature Access - Part 2: SQL Option through JTS 1.13+ over H2 1.3.173+.

i had a quick look at the H2Dialect in gt-jdbc-h2 and i do see what you mean by 'not trivial' !

i'll try playing around w/ these 2 projects in my free time and see what i can come up w/.
Reply all
Reply to author
Forward
0 new messages