create branch 'DRUPAL-5'.

Sprout from master 2007-11-08 23:20:59 UTC Brandon Bergren <bdragon@rtk0.net> 'Modified #180038: lat/lon input field.'
Delete:
    geo_admin.inc
    geo_cck.inc
    geo_geocoding.inc
    geo_gmap.info
    geo_gmap.module
    geo_views.inc

Added some more stuff like the fieldset around it... Used database methods for wkt to point conversion...

Thanks!

Thanks, all!

WKT validation on CCK types.

Bring cck support up to current revision of install file
Fix install file for mysql.

Checking in the new geo_devel module, for geo developers. This module is the wildwest. Put whatever you need here.
Also checking in srid.inc, which holds a giant array of SRIDs and some useful labels for them. This was generated using geo_devel.

- Significant refactoring of how views table definitions are generated. Now, one can call a function to generate views tables with geo fields. Very cool.
- Started on the spatial table views link system, where we can link existing spatial tables into current data. Prompted need for refactoring of views code.
- Added a geo_gmap module to manage all gmap interactions and keep geo.module clean.

- adding spatial indexes to geo columns
- views integration, including fields and filters, sorts not yet working
- fields include the geometry itself as WKT, GML, KML, SVG, as well as the bounding box and centroid in those formats
- for lines and polygons, fields of computed length and area (sorts to follow)
- filters for spatial relations (within, intersect, equals, and NOT versions of each)
- other improvements here there and everywhere

Next step: map integration with gmap module so that the UI is useable by humans.

Initial saving and loading of GIS data in postgis working. I need to factor out some of the SQL I'm using so that I can work with other db backends. Future work: using gmap to select points/lines, etc. Views queries to gather spatial data from the db. Add indexes to geometry columns.

The geo module is an incubator for other geo* related modules (* geography, geometry, geocoding, and others)

Some current plans include:

- hook_geocode: allow modules to expose geocoding functionality. Right now, other modules require hardcoded calls to specific geocoding functions.

- Geometry field and PostGIS integration: Location.module does a good job of handling discrete points; however it cannot express larger geometries. Good tools exist to help with this functionality (e.g. PostGIS extensions on Postgresql) and could be leveraged to meet use cases location does not support.

There will be inevitable overlap between geo and other modules with similar functionality. Geo will fill the niche of an arbitrator among them. It is our goal that geo will both take over some functionality currently spread across multiple modules, as well as farm off functionality to more appropriate modules when possible.

Initially, geo requires location and gmap. It's only functionality so far is to allow administrators to use specific location fields in a Google maps geocode process.