I agree about H2. It's great database. Only because we found H2 embedded database with good simple enough spatial capabilities (in our case based on hatbox and geotools) we were able to complete a project for a big customer with 400 of users managing 25 Gb of business critical spatial data daily!
After going deep to H2 internals and what i have heard from you, guys, we are convinced that h2gis is a way to the future that should give a performance boost comparing to current technology we are using. I am not a license guru , we are doing projects based on open source libraries, applications and tools for private customers. The core app is UDIG based and H2 lives in it as an embedded database. All dependencies and components are commercial-friendly using licenses as LGPL and others, etc. If license is an issue we can always create something simple as geodb wrapper for H2 which is with spatial data type and built spatial index support now. Anyway all profit comes more or less from JTS and it's know fact. Whether it's geodb library or H2GIS - they rely on JTS. You may of course have some advanced computational functionality, but we need really basics from spatial database. It's not for analysis , it's for storing and managing spatial features, big amounts of them, all advanced spatial analysis is anyway done in business logic. Have you ever tried H2 as a spatial database behind some GIS interface like UDig or other desktop Java GIS app? It is definitely great db with excellent performance. Coming back to the original topic of this thread I would conclude that BLOB type is absolutely unnecessary for storing geometries. 2Gb question was more like theoretical.. Vitali. On Tuesday, May 5, 2015 at 10:59:43 AM UTC+3, Nicolas Fortin (OrbisGIS) wrote: > > Hi Vitali, > > PostGIS maximum geometry field size is 1Gb[1], then i don't think its a > problem for H2 having a theoretical limit of 2.1 Gb (precisely 231-5 [2]) > . It is not very practical to have such huge geometry as it is slow to > render and process (no stream processing for vectorial geometries in jts). > > As Thomas have said you have now access to native spatial r-tree index > with the same syntax as PostGIS (&& operator): > http://www.h2database.com/html/advanced.html#spatial_features > > There is just a missing piece with spatial index is the support for sql > alias in h2. In order to link && operator with spatial predicates. > > I understand if GPLv3 license of H2GIS is a issue for you that you want to > update geotools and geodb (you don't need hatbox anymore). > > All our 744 units test of H2GIS are running fine with H2 MvStore. We > greatly appreciate the power of H2 database :) > > Regards, > > > [1]:http://www.postgresql.org/about/ > [2]: > http://stackoverflow.com/questions/3038392/do-java-arrays-have-a-maximum-size > > -- > Nicolas Fortin > IRSTV FR CNRS 2488 > GIS http://orbisgis.org > Spatial DB http://h2gis.org > Noise http://noisemap.orbisgis.org > > > > Le dimanche 3 mai 2015 21:51:09 UTC+2, Vitali a écrit : >> >> Hello. >> >> I would like to share some observations. Recently H2 got a Geometry >> type, logic around it seems is growing, also some extra tiers like H2GIS >> are under development. All together this seems as a future of spatial >> support in H2. But already for many years the spatial support was >> provided by a combination of geodb + hatbox libraries and integration in >> GeoTools world (as H2 data store interface for storing/managing spatial >> features with geometries). >> All these was done on BLOB type where a geometry WKB is stored. >> >> BLOB became completely useless as a type for handling WKB of geometries. >> Because of this change that any access of BLOB value makes a copy of it. >> HATBOX and GEODB libs based on JTS library provide functions to work with >> WKB. But any call of these functions makes a read of BLOB value which makes >> a copy in memory. Some spatial conflation operations being not-optimized >> (having polynomial complexity with applying spatial predicates between any >> combination of input geometries from 2 tables e.g.) now have a >> catastrophic performance and memory consumption. Cases where old H2 just >> worked 10 secods performing some kind of spatial operation between 2 layers >> (tables) now runs 2 hours , 3Gb of database file (instead of 400Mb >> normally) and outofmemory error finally. And long cleanings of temporary >> LOB storage on app start, app close, transaction commit after such >> operations. >> >> I understand real reasons of this BLOB copying approach. But the >> conclusion is that BLOB is not a right type for geometries. In typical GIS >> (like UDIG) thousands of records are extracted every second for multiple >> layers during rendering and other types of requests need geometries. Now >> BLOB became inefficient. >> >> Alltogether very likely I will do refactoring of geodb, hatbox and >> GeoTools to work with GEOMETRY type which is basically VARBINARY kind of >> which means WKB is just read to memory. But it is what usually is needed to >> GIS app - to get a geometry almost every time when data is read. Also >> because JTS geometry is lazily cached in ValueGeometry various logic in H2 >> (like custom spatial functions call multiple times) gets benefits. I think >> H2GIS toolkit more or less uses this approach already. >> >> The only concern is that are there any limitations for cases like "lake >> boundary" that consists from hundreds of thousands of vertices.. Isn't it >> 2Gb is a limit for binary types? Then it's fine.. But how do older >> PageStore and modern MVStore handle this type? Any performance issues? >> >> Vitali. >> >> >> -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
