Log of /contributions/modules/geo/geo.inc
Parent Directory
| 
Revision Log
| 
Revision Graph
Revision
1.15 -
(
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
CVS Tags:
DRUPAL-6--1-0-ALPHA1
Changes since
1.14: +10 -8 lines
Diff to
previous 1.14
- 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.12 -
(
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.11: +34 -2 lines
Diff to
previous 1.11
- 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.11 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sat May 30 04:21:15 2009 UTC
(5 months, 4 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.10: +39 -2 lines
Diff to
previous 1.10
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.10 -
(
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.9: +1 -2 lines
Diff to
previous 1.9
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.9 -
(
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.8: +10 -8 lines
Diff to
previous 1.8
- 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.6 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Feb 24 16:47:49 2009 UTC
(9 months ago)
by
vauxia
Branch:
MAIN
Changes since
1.5: +5 -2 lines
Diff to
previous 1.5
Adding some experimental WKB parsing, which will facilitate data manipulation
and display formatters beyond what is supported by the backend.
Adding a highly experimental / proof-of-concept SVG formatter to geo_field.
Revision
1.4 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Thu Sep 4 22:51:05 2008 UTC
(14 months, 3 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.3: +6 -2 lines
Diff to
previous 1.3
This one's pretty destructive:
Rename all of the field types ( geo_point, geo_linestring, geo_polygon ) to
just "geo". This is to reduce the confusion of chewing up the field type
selector with a whole bunch of nonsense words. It also gives us the opportunity
to document and explain the various storage types on the field settings page.
Making the available geo_types an API call, so you could theoretically have 3D
types available, and/or stick with "Point" for dumb database storage.
So, there's now 1 field type on the "Add field" form, and the avialable geo
types are on the field settings page. This setting can't be updated.
Naturally, this means the field types have gone away, and you've now got
orphan fields on your content types. Sorry :( This is presumably fixable?
Revision
1.3 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Aug 20 15:06:38 2008 UTC
(15 months ago)
by
vauxia
Branch:
MAIN
Changes since
1.2: +95 -1 lines
Diff to
previous 1.2
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.
Revision
1.2 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Aug 11 04:43:02 2008 UTC
(15 months, 2 weeks ago)
by
vauxia
Branch:
MAIN
Changes since
1.1: +16 -2 lines
Diff to
previous 1.1
- 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.
Revision
1.1 -
(
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
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.
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.
