Log of /contributions/modules/geo/geo.module
Parent Directory
| 
Revision Log
| 
Revision Graph
Revision
1.32 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Nov 23 20:49:25 2009 UTC
(42 hours, 43 minutes ago)
by
vauxia
Branch:
MAIN
CVS Tags:
HEAD
Changes since
1.31: +23 -7 lines
Diff to
previous 1.31
- Make geo_field_types() return an array, and use geo_field_type_names() to
return a flat array.
- Update calls to geo_field_types() to reflect this.
- Add a geo_field_names() API call, which also returns a flat array.
Revision
1.31 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Nov 23 20:35:54 2009 UTC
(42 hours, 56 minutes ago)
by
vauxia
Branch:
MAIN
Changes since
1.30: +46 -26 lines
Diff to
previous 1.30
- New API function: geo_fields(), which returns all CCK fields that contain
any type of Geo data.
- Clean up the hook_field:sanitize hackery that was appending a pre_render
hook to $node->content for nodes with geo fields. Instead, use the above
API function and declare it accordingly.
- Similarly, use geo_fields() and not field-module-maintained $node->geo_fields
array in hook_nodeapi:rss item.
Revision
1.30 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Nov 17 22:09:57 2009 UTC
(7 days, 17 hours ago)
by
vauxia
Branch:
MAIN
Changes since
1.29: +3 -39 lines
Diff to
previous 1.29
Theme function reorganization, for consistency with my other development.
MAKE SURE TO REBUILD YOUR THEME REGISTRY!
Revision
1.26 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Thu Aug 6 04:09:32 2009 UTC
(3 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.25: +36 -26 lines
Diff to
previous 1.25
Better just-in-time conversion from wkb to a format expected by theme functions.
(e.g. arrays, wkt, etc.)
Basically:
1. in hook_theme, include a 'gis input' key, with a value such as wkt, array, or some other format you'll account for.
2. Ensure that anything you render with this theme gets run through geo_set_value(). This function uses the 'gis input' value defined by the theme function
in use, and is used to translate from WKB to the requested format.
This conversion is handled automatically for node/field rendering, and for the
views fields provided by views_handler_field_geo_field.
Track me down with questions/issues!
Revision
1.25 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Aug 5 02:15:54 2009 UTC
(3 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.24: +9 -8 lines
Diff to
previous 1.24
Much better handling of inputs. CCK / Widgets functioning as they should
Still some required tweaks with exposed inputs
Revision
1.22 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Thu Jun 18 01:24:11 2009 UTC
(5 months, 1 week ago)
by
vauxia
Branch:
MAIN
Changes since
1.21: +105 -5 lines
Diff to
previous 1.21
- Some refactoring of the gis input / output mechanisms.
- Implement a crude on-the-fly conversion so that gis elements can expect one
format, backends (e.g. field storage or views filters) can expect another
and the conversion is quietly performed.
- Make elements for wkt, latlon work as both elements and views filters
- Refactor widgets to account for the changes on geo_field
- Get PostGIS distance handling working
Revision
1.20 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Jun 9 04:22:43 2009 UTC
(5 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.19: +24 -23 lines
Diff to
previous 1.19
Allow CCK Formatter modules to define expected gis inputs ( point, linestring, etc) via hook_field_formatter_info()
1. A module declares CCK formatters using the usual syntax, but includes the
"gis input" key:
function geo_field_formatter_info(
return array(
'default' => array(
'label' => t('Well Known Text'),
'field types' => $field_types,
'gis types' => array('point', 'linestring', 'polygon'),
'gis input' => 'wkt',
),
'lat' => array(
'label' => t('Latitude'),
'field types' => $field_types,
'gis types' => array('point'),
'gis input' => 'array',
),
);
}
2. Geo's CCK modules retrieve data in WKB format
3. On nodeapi:view, geo performs an on-the-fly conversion from WKB to the
expected input format ( e.g. wkt, array, and so-on)
- Implemented this for all included formatters.
Revision
1.18 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Thu Jun 4 02:02:19 2009 UTC
(5 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.17: +86 -3 lines
Diff to
previous 1.17
- Add extent handling (bounding box of an entire dataset)
- Add some 'aggregate => true''s to my function fields to keep Views in line.
- Beginnings of storage -> expected inputs for formatters.
- Beginnings of the "common language" thing I keep talking about.
- Beginnings of "selectable inputs" to switch out, say, a geocoded text field
as an exposed view input.
THIS COMMIT WILL DO MORE HARM THAN GOOD! STUFF IS PROBABLY BROKEN!
I just wanted to commit the proof-of-concept before tinkering with it on a
refactor.
Revision
1.17 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sat May 30 04:21:15 2009 UTC
(5 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.16: +74 -7 lines
Diff to
previous 1.16
YAY DISTANCE HANDLING!
- Added API functions to handle both pythagorean and spherical distance between
two geometries. (By geometries I mean points :( )
- Added an API function to calculate a bounding box based on a point + radius.
- Exposed these to Views in the form of field, filter and sort handlers.
Revision
1.15 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue May 19 18:29:12 2009 UTC
(6 months, 1 week ago)
by
vauxia
Branch:
MAIN
Changes since
1.14: +8 -1 lines
Diff to
previous 1.14
Add geo_wkb_get_data as an API function to the geo.module file. Eliminates the
module_load_include() dependency for formatters, etc.
Revision
1.14 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Mar 3 02:16:28 2009 UTC
(8 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.13: +1 -5 lines
Diff to
previous 1.13
- Adding a views field handler for geo_field, which makes way more sense than
trying to rely on a generic one. This lets you configure geo CCK fields in
views just like you're used to.
- Removing the borked SVG formatter for fields. If it's useful, we'll re-add it
- Enhancing the SVG handler for views so that it more accurately portrays
lines and points.
Revision
1.13 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Mar 1 23:43:43 2009 UTC
(8 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.12: +1 -15 lines
Diff to
previous 1.12
Moving the geo rss stuff to geo field itself. Otherwise, we risk sending
giant gobs of polygons around with geo_data and/or other uses for geo.
Revision
1.10 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Sep 9 00:31:55 2008 UTC
(14 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Branch point for:
DRUPAL-6--1
Changes since
1.9: +12 -1 lines
Diff to
previous 1.9
Updating Views API (http://www.angrydonuts.com/attention-views-api-developers).
There's a relationship bug in views RC1 that causes geo_data's views support
to break when used in conjunction with relationships. Using Views' -dev release
fixes the problem but requires updates to this module's Views API integration.
Thus, as of the time of this commit:
MUST RUN THIS VERSION WITH -dev RELEASES FOR BOTH VIEWS AND CCK
Revision
1.9 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Aug 11 03:24:22 2008 UTC
(15 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.8: +29 -97 lines
Diff to
previous 1.8
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.
Revision
1.8 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Aug 8 04:20:32 2008 UTC
(15 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.7: +5 -1 lines
Diff to
previous 1.7
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.
Revision
1.7 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Aug 6 07:05:46 2008 UTC
(15 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.6: +3 -1 lines
Diff to
previous 1.6
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.
Revision
1.6 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Aug 6 03:47:55 2008 UTC
(15 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.5: +1 -82 lines
Diff to
previous 1.5
Reorganizing prior to a D6 upgrade:
- remove unused geo_geocoding.inc (long live geocrippler!)
- remove geo_cck.inc from geo.module and create a separate field module
(geo_field)
- remove table introspection from geo.module and create a separate data
integration module (geo_data)
- move all sub-modules (the aformentioned geo_field and geo_data, plus
existing geo_gmap and geo_devel modules) into a separate modules directory.
Revision
1.3 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri May 18 17:58:49 2007 UTC
(2 years, 6 months ago)
by
mfredrickson
Branch:
MAIN
Changes since
1.2: +90 -20 lines
Diff to
previous 1.2
- Adding some new submodules and .inc files.
- 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.
Revision
1.2 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue May 15 02:49:31 2007 UTC
(2 years, 6 months ago)
by
mfredrickson
Branch:
MAIN
Changes since
1.1: +70 -77 lines
Diff to
previous 1.1
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.
Revision
1.1 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Feb 28 21:34:24 2007 UTC
(2 years, 8 months ago)
by
mfredrickson
Branch:
MAIN
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.
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
select a symbolic revision name using the selection box, or choose
'Use Text Field' and enter a numeric revision.
