CVS messages for Geo

August 28, 2008

Commit #136633 by Allie Micka at 09:38

Geo: /modules/geo/geo.info 1.6
```
  No dependencies for Geo!
```
Commit #136632 by Allie Micka at 09:37

Geo: /modules/geo/modules/geo_data/geo_data.admin.inc 1.3
Geo: /modules/geo/modules/geo_data/geo_data.module 1.4
```
  fixing dupe function error, eliminating some array errors
```

August 20, 2008

  Another big commit:
   - CAN NOW PARSE AND BULK IMPORT SHAPE DATA.  I rule!
   - continuing to refactor code into geo.inc
   - Add another field module for geo_data.  In contrast with geo_field, which
     stores geospatial information, geo_data *references* geospatial information.
     Workflow being:
       1. Download shape data from any source ( census, usgs, etc. ).  For 
          example, a list of states with id, name, and polygon shapes.
       2. Import said shape data at admin/build/geo
       3. Add a geo_data field that links to the new geo_data_state table via
          key.  Thus, the field provides a nice select list of states and 
          stores an id value like 'MN' or '27'.
       4. In views, add a filter and/or an exposed filter, which limit queries
          using geo functions.  For example, using "Within" and this input:
            POINT(-94.312499886749 46.712163633385)
          the query will return all nodes tagged with "MN"
  
       See also: legislative lookups and district or precinct maps.

August 19, 2008

Commit #134995 by Allie Micka at 23:57

Geo: /modules/geo/includes/directory NONE

  Directory /cvs/drupal-contrib/contributions/modules/geo/includes added to the repository

August 11, 2008

Commit #132903 by Allie Micka at 04:43

Geo: /modules/geo/db/mysql_spatial.inc 1.8
Geo: /modules/geo/geo.inc 1.2
Geo: /modules/geo/geo.views.inc 1.3
Geo: /modules/geo/modules/geo_field/geo_field.module 1.5

  - Reinstate geo_field wkt validation, using common API instead of per-database 
    functions..
  - Begin to implement views support by tagging geo_field data and identifying it
    via geo_views_data_alter.  
  - Code cleanup, removing unused functions and updating api calls to use the new
    geo() convention.

Commit #132898 by Allie Micka at 03:24

  Attempt to clean up and consolidate some common code.
  
  Removing unused geo_fields() function from geo.module.  In fact, remove 
  everything with the exception of the new geo() callback function.  Through this,
  you can call API operations.
  
  For example, geo('add_field') adds a field to the database, as invoked 
  from geo_$backend_add_field.  However, since certain functions are common 
  to both supported databases, geo('drop_field') will actually call 
  geo_drop_field.  Call it inheritance if you want.
  
  I also removed geo_init, which was handling much of this, and created geo.inc
  to house common functionality.  Thus, none of Geo, other its 42-line module,
  is included until it's actually going to be put to use.
  
  Also, beginnings of views integration is accidentally slipping in.

August 9, 2008

Commit #132566 by Allie Micka at 00:57

Geo: /modules/geo/modules/geo_devel/geo_devel.info NONE
Geo: /modules/geo/modules/geo_devel/geo_devel.module NONE
```
  Removing geo_devel module entirely.  One less module to maintain!
```

August 8, 2008

Commit #132358 by Allie Micka at 04:20

Geo: /modules/geo/db/mysql_spatial.inc 1.6
Geo: /modules/geo/db/postgis.inc 1.8
Geo: /modules/geo/geo.module 1.8
Geo: /modules/geo/modules/geo_field/geo_field.module 1.3

  Restored field storage functionality to geo_field and updated to CCK 6.x spec.
  Rather than carefully maintaing and tracking our own tables, I'm piggybacking
  on the existing CCK table storage:
  
  - All fields are forced to 'multiple' storage
  - hook_field('database columns') returns extra fields such as lat, lon, etc.
  - After CCK creates a valid field storage table, we sneak in and drop/replace
    its geo field with a valid geometry table definition.
  
  I still need to manhandle the save operations because I couldn't get around
  query substitution issues.  However, the table structure and operations 
  behave pretty much like what you'd expect from CCK.
  
  This minimizes code duplication and allows me to fantasize about defining
  datatypes via the schema API, which would obviate all of this mincing about.

August 6, 2008

Commit #131886 by Allie Micka at 07:05

  Cleanup and progress towards a working D6 field module:
    - Renamed CCK fields with geo_ namespace ( e.g. geo_point, geo_linestring )
      to avoid collisions
    - Removed geo_backend_field functions.  These were intended to outsource 
      CCK's hook_field implementations so that the backend modules could take
      care of everything.  Good idea, but it also created a lot of duplicate
      code.  Meanwhile, I'd argue that the geo module itself - and its backends
      - should not be cognizant of CCK.  That's what an API is, right?
    - Renamed API functions to geo_db_add_field, geo_db_drop_field from 
      geo_add_geometry_column, geo_drop_geometry_column.
    - Removed geo_insert_geometry_data, and added geo_db_field_from_wkt to
      specify column insertions.  We'll leave the rest of the inserting to the
      calling function.
    - Removing references to geo_field and its table tracking.  This seemed 
      like a really good idea when we created it, but seems like needless 
      housekeeping now, as the field module is already keeping track of its geo
      fields.
    - Began updating and refactoring D5 to D6 code.

Commit #131859 by Allie Micka at 03:48

Geo: /modules/geo/geo.views.inc 1.1
```
  .... And rename geo_views.inc to geo.views.inc
```

CVS messages for Geo

August 28, 2008

August 20, 2008

August 19, 2008

August 11, 2008

August 9, 2008

August 8, 2008

August 6, 2008

User login

Search downloads

Contributor links