The Big Data development team at Esri is excited to announce a major performance speedup in ST_Geometry for Hive, which is part of Esri’s open-source Spatial Framework for Hadoop. The amount of performance gain depends on the type of spatial query run and on the size of the table in Hive. The biggest gain comes with relational operations such as ST_Contains and ST_Overlaps. In general, the performance gain will be greater with larger tables — exactly where it helps the most.
We are pleased to announce that the ST_Geometry aggregate functions are now available for Hive, in the Spatial Framework for Hadoop. The aggregate functions can be used to perform a convex-hull, intersection, or union operation on geometries from multiple records of a dataset.
I recently read a forum post where the question of how to change geometry storage types was raised. More specifically, the user was wondering how difficult it would be to change from using SDE Binary Storage format to the Geometry Spatial Type available in SQL Server 2008.
The good news is that this migration is pretty straight forward. We added a geoprocessing tool for this at 9.3 called Migrate Storage. The tool itself is pretty simple, taking a dataset or list of datasets that need to be migrated and also a configuration keyword which specifies which storage types to migrate to. The migration itself is then done on the input datasets in place.
As to why someone might want to migrate their geometry storage format to a spatial type? Probably the best discussion of spatial types and their benefits was a presentation given at this year’s user conference in San Diego entitled Using SQL and Spatial Types with the Geodatabase.