Parent Directory
| 
Revision Log
| 
Revision Graph
| Links to HEAD: | (view) (download) (as text) (annotate) |
| Sticky Tag: |
- 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.
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.
#358255 by chiru - Error creating index using table prefix
Restore PostGIS functinality:
- Return PostgreSQL-supported column definitions for db_create_table in
shp2sql code
- Account for SRID's now that we have a database that notices
- Remove no-longer-supported db_* functions from postgis.inc
- Abstract field_query code in views handlers, and implement an indexed
( postgis ) and non-indexed ( mysql ) version in the backend code.
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.
- 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.
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.
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.
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.
Modified #180038: lat/lon input field. Added some more stuff like the fieldset around it... Used database methods for wkt to point conversion...
Ran geo through coder; general coding style improvements.
Muahahaha. WKT validation on CCK types.
Beginnings of mysql support, fix table prefixes.
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.
| ViewVC Help | |
| Powered by ViewVC 1.1.2 |