Slashgeo

The Hobu blog has an interesting entry about MySQL spatial support for GDAL/OGR. From the blog: "Under the direction of Frank Warmerdam, I have been bringing the OGR driver up to par with the rest of the vector data drivers in OGR. [...] MySQL is known for being fast, widely deployed, and frequently used. Unlike PostGIS, however, it does not support spatial predicates and operators (for testing whether one geometry exists in another, for example) [...]"

The OSGeo-Discuss mailing list links to a short survey of geospatial databases such as MySQL, Oracle, IBM DB2 UDB and PostGIS. From the accompanying article: "For example, subjects like ‘spatial indexing’, ‘optimising approaches’, ‘spatial joining algorithms’ and ‘topology management’ may relate to very sophisticated approaches not easily condensed and described in a survey matrix box. In my first Product Survey on RDBMS in 2002 I observed that spatial-data management was traditionally supported within GIS environments. Integration with other datasets has to be organised within such environments with the aid of complementary architectures. As more and more support for spatial-data management becomes available in RDBMS, direct integration with other datasets may be organised in an increasingly flexible way. This allows for fast data access, easy product development, avoidance of duplication of spatial data etc." See numerous related articles below.

The Memory Leak blog informs us about geodata support for the upcoming Microsoft SQL Server expected in 2008. All Points Blog adds more details and links. From APB: "Spatial will be supported in the next release of SQL Server (code named Katmai) as system data types. Katmai is scheduled to ship in 2008 and will most likely be called SQL Server 2008. Katmai spatial will support two models: a “Flat Earth” planar data type and a “Round Earth” geodetic data type. The Flat Earth data type (GEOMETRY) will support the Open Geospatial Consortium (OGC) Simple Features for SQL Specification with support for approximately 70 spatial methods/functions. There will be spatial indexes for both planar and geodetic data types."

The Lin.ear th.inking blog ran an entry last month on spherical indexing schemes for PostGIS. Thought not exhaustive, the entry is still interesting and reminds us how spatial indexes are important to efficiently analyze huge spatial databases. From the entry: "Handling geodetic data in a correct and efficient way presents quite a few challenges. A major one is: how can geodetic geometry be spatially indexed? Conventional spatial indexes (such as 2D R-trees) all rely on geometry being embedded in a planar space. They don't handle data which can "wrap around", as can occur in a spherical space." See below for other (rare) stories related to spatial indexes.

The PostGIS/Refractions web site announces: "The 1.3.2 release of PostGIS is now available". This release includes bug fixes and some minor feature enhancements, such as improvements in the TIGER geocoder, fix for better OS/X support, fix to WKB parser to do simple validity checks, etc.

Kurt's Weblog links to the open source tools for SQLite named SpatiaLite and VirtualShape. From the page: "the SpatiaLite extension enables SQLite to support spatial data too [aka GEOMETRY], in a way conformant to OpenGis specifications [...] the VirtualShape extension enables SQLite to access shapefiles as VIRTUAL TABLEs"

[this is old news from July and sharing it with our users to make sure they're aware of it] Spatially Adjusted linked in July to a BostonGIS article named "Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6". Previous such comparison is over 1.5 years old, see also related stories below. From the associated blog entry: "A few people have been asking us what are the pros and cons of using SQL Server 2008 Spatial and PostGIS and as a Windows user, why would you still consider using PostGIS. Rather than simply providing some hand-waving saying "well if you just care about displaying data, then use whatever you feel comfortable with, but if you want to do real intensive sophisticated spatial analysis and geometric processing without having to purchase a bunch of expensive software, then PostGIS is probably better for you. Hell why must you think in either or propositions - just use both using the strengths of each.", we have tried really hard to quantify the similarities and differences between the 2 and to boot - we have also added in MySQL."