geo 6.x-1.0-alpha5

Git tag 6.x-1.0-alpha5
New features
Bug fixes

*Much* improved views handling for geo_data fields. This allows geo_data fields to function as one would expect, where you can relate a node to a dataset using a geo_data field, and then use that dataset for additional fields, filters, etc.

geo 6.x-1.0-alpha4

Git tag 6.x-1.0-alpha4

Three minor but important issues:

#689964: Call to undefined class GeoSQL
Suppress error ond display of a geo_data field when there is no data.
Error that prevents geo_data's fields from loading properly.

IF YOU ARE UPGRADING FROM alpha2 OR EARLIER, PLEASE REVIEW THE NOTES FOR alpha3!

geo 6.x-1.0-alpha3

Git tag 6.x-1.0-alpha3
New features
Bug fixes

Views support has been completely re-written in this version!

At this point, all of my architectural "wishlist" items are complete, and I don't expect to see many more drastic API or structural changes. We're on to new features and bug fixes, while we complete the move to the new Interface API.

IMPORTANT: These changes should not affect your CCK fields, but will likely break any views you have created using CCK fields or geo_data data. Please make a backup, recreate and test your views before using this in any production environment!

geo 6.x-1.0-alpha2

Git tag 6.x-1.0-alpha2
New features

This is an important and useful release as far as I'm concerned, but hopefully not a big change for users:

I have added an Interface class to represent the entire OpenGIS specification for geospatial features. I have also implemented classes for MySQL, PostGIS, and a strictly PHP-based class to handle basic manipulations and calculations.

This differs from the previous implementation, which had a sorta hackneyed, as-needed pile of function definitions. It was challenging and messy to draw calculations between different sources of GIS info (e.g. a point that represents the currently-logged-in user, and an area represented in a database). Now you can use the PHP-based and SQL-based backends interchangeably.

It was also not possible to tell what was working and what wasn't. How were we ever going to know which functions we can and call from the spec? Now you can use any of them; and you'll get back something helpful or an "unimplemented" error.

Right now, both implementations continue to exist, but I will be phasing out the geo() function and its related backend handlers in the next release or two, and other module developers are encouraged to do the same.

Also:

geo 6.x-1.0-alpha1

Git tag 6.x-1.0-alpha1

Current module as-is. Will add new releases as new features/bugs get completed!

geo 6.x-1.x-dev

Git branch 6.x-1.x

This is the development branch for the Geo module. It currently working well enough for most users, but may not be considered "production ready" just yet.

Subscribe with RSS Subscribe to Releases for Geo