Hi,
Sooner or later all data do not fit in the memory and OpenJUMP user has
troubles. Having PostGIS or Oracle datastore solves size limits, but OJ
does not support updates well. In addition, many people seem to fear
PostGIS, and for sure it is a bit heavy weight pair for OpenJUMP which
is very si
Good idea!!!
I see there's even a JDBC driver for it:
http://www.zentus.com/sqlitejdbc/
so I may take a look at it, but even if I can add SQLite support to the SISDB
plugin,
it will be read-only like any other OJ DataStore.
But the great thing would be the adoption of a light DB, such as
Thanks for this link, Paolo - I've been wondering if there's a JDBC
driver for Sqllite.
Are there any issues with using this driver with SpatialLite? Or is
SpatialLite 100% transparent from the driver point of view?
In general this seems like a nice way to go. Even nicer IMHO would be a
pure
>From the JDBC point of view any data type _should_ be equal,
so even a "geometric" data type _should_ be equal to all others,
but I don't know in which manner SpatiaLite is implemented on top of SQLite,
so it may as well not work...
Bye
Paolo Rizzi
Da: Martin
Hi
> In general this seems like a nice way to go. Even nicer IMHO would be a
> pure Java DB like H2. But someone needs to step to "spatializing" H2
> for this to be appealing for OJ. Probably a similar approach to
> SpatialLite can be taken here, except for one thing - H2 doesn't have an
> R
