Hi, > But already for many years the spatial support was provided by a combination of geodb + hatbox libraries and integration in GeoTools world
Yes. However, those don't use the built-in R tree. Do they use an external R tree? > All these was done on BLOB type where a geometry WKB is stored. A small BLOB is stored inline, so it might not be that bad. > any access of BLOB value makes a copy of it Access is making a copy of the reference of a large BLOB. > Isn't it 2Gb is a limit for binary types? I reality the problem is the memory usage (heap memory). Regards, Thomas On Sun, May 3, 2015 at 9:51 PM, Vitali <[email protected]> wrote: > 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. > -- 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.
