> For instance, the lazy geometries patch in 4322 is way off
> track now we have support for ogr geometries.
The lazy geometries patch in 4322 is only a month old, and ten days
ago I incorporated portions of your patch in r5448. Not exactly what
I would consider "way off track" -- at least from my experience with
open source projects. Regardless, I'll concede that GDAL feature
additions have been prioritized over your patch for the reasons
enumerated below.
The addition of GDAL support was, I believe, more important for
GeoDjango than lazy geometries. To begin with, all lazy-geometry
functionality can be accomplished with existing extra instance methods
(e.g. "geomodel.objects.get_geom_geos().convex_hull"). Further, my
priorities have been aligned with what's on the wiki -- the phase 2
components with the highest priority are distance queries and GIS
dataset utilities (i.e., importing from SHP files directly into
GeoDjango models). The addition of native GDAL support is aligned
with these priorities.
As those familiar with GIS systems are aware, GIS data comes in a vast
multitude of formats (e.g. ESRI Shapefiles, MapInfo files, TIGER
files, etc.). To complicate matters, each dataset will use different
spatial reference systems -- rarely do I see a SHP file in WGS84 (for
non-GIS folks this is the system for lat/lon coordinates you get from
GPS). Fortunately, the GDAL library has an _excellent_ library for
both reading and transforming spatial data sets in these conditions.
While this may have been possible through the use of PostGIS SQL
statements such as "INSERT ... transform("POLYGON((... ))", 4326)," I
wanted to have this functionality accessible to the user, independent
of the database.
Distance queries present similar problems since the calculated
distance depends on the spatial reference system. For example,
distances calculated with coordinates in WGS84 are in units of degrees
-- hardly of use to someone looking for a store within 2km of their
home. Transforming to a projected coordinate system, with units in
meters (or miles), is more appropriate. PostGIS transformations only
accept an EPSG code (integer) associated with the spatial reference
system; giving the user access to a SpatialReference object that can
take multiple inputs (proj strings, EPSG codes, Well-Known Text, etc.)
that can then be passed to future distance routines seemed like a
better solution.
> but it helps if i can see a little way into the future
> about what other changes are planned to happen, and who is working on what.
There has been little "formal" division of duties on the GIS branch --
the only thing I can think of is that Jeremy handles the syncs to
trunk. Please be patient with our progress -- like other devs, we
have commitments outside of Django that may make commits and ticket
fixes sporadic.
Regards,
-Justin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
