Parent Directory
| 
Revision Log
| 
Revision Graph
| Links to HEAD: | (view) (download) (as text) (annotate) |
| Sticky Tag: |
- #505572 by bec and apolzon - hadn't been fully committed :(
- 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
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.
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.
Beginnings of mysql support, fix table prefixes.
- 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.
Many, many improvements to the PostGIS interaction: - adding spatial indexes to geo columns - views integration, including fields and filters, sorts not yet working - fields include the geometry itself as WKT, GML, KML, SVG, as well as the bounding box and centroid in those formats - for lines and polygons, fields of computed length and area (sorts to follow) - filters for spatial relations (within, intersect, equals, and NOT versions of each) - other improvements here there and everywhere Next step: map integration with gmap module so that the UI is useable by humans.
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.
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 |