field value.

functionality.

  class.  This mean that you can instantiate a geo object using WKB or WKT,
  run functions on it, and return it in any desired format.  It also means that
  you can do basic data manipulations without any database interaction at all!

  You can now do stuff like:

  $geo = geo_load();
  $g = $geo->geomFromWKB($wkb);
  $wkt = $g->asText();

- Completely deprecate the geo() function and the remaining sub-fuctions that
  were still in use:
    geo('rss_item')
    geo('wkt_validate')
    geo('wkt_from_point')

defined.  This allows developers to use code such as:

 $geo = geo_load();
 $point = $geo->point(1, 2);
 ...

geo_sql_load();

Removing geo_supported_types() - this is now being handled through the interface.

All of the functionality required for Geo should be accessed through the new
class interface.

- Using the above function name rather than the original geo() callback
  mechanism on the geo_field settings forms.

is created, which means we can simply rely on the views data that already exists
for the target geo_tables.

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.

match location coords exactly

separate where group called 'geo'.  This will permit us to convert Geo's filters
from AND to OR.

For example, you can filter a view based on an event's location OR the location
of a facility that an event is node-referenced to.

Or, you could find your statewide representative whose state overlaps yours OR
a representaive whose district overlaps yours... thus returning all
representatives for a particular user.

And so-forth.

- Add an api function to convert between 'gis type' and 'geo type'.
- Add a sqlColumnDefinition() to the GeoSQL class, which can be overridden by
  subsequent classes.  This moves more of the API functionality into the
  current API structure, and also allows it to be overridden by say, a lat/lon
  handler.
- Also includes fix for #681756 by jerdavis - SQL error when adding a new
  Geospatial data field to new content type.

filter values.  So, for example, a user can add an exposed value for a distance
filter, and see the calculated distance as a field in the results.

- Update geo_data field load operation to support the new Geo API.

sprint! http://groups.drupal.org/node/39240

- Added drupal_load() for Content module prior to calling content_notify() in geo_field.install

in views:  Correctly setting up the 'select a target' form as a helper function
for each of these.

Basically, this means you can display your field as a numerical distance from
a fixed point, sort by distance from that point, etc.

The next step is to rely on existing views data, such as the already-selected
filter values, so that we can fix the regression I created by removing the
distance-specific views handlers.  Then we roll alpha3!

Correcting issue with allowed value select following previous commit.  Added trim() call to option list

Correcting issue with use of parent::value_form() to properly pull the form elements into the correct tree within the $form

Value handling was not working correctly within the exposed filter. By always checking against the default, the form_state did not contain the value passed from the exposed form.

configurations

not correctly identify which GIS format it expects to receive.