Changes between Version 13 and Version 14 of GeoDjango
- Timestamp:
- Feb 25, 2007, 11:24:01 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GeoDjango
v13 v14 8 8 * [http://postgis.refractions.net/ PostGIS], the [http://www.opengis.org/docs/99-049.pdf OpenGIS SQL Types (pdf)] implementation for Postgresql 9 9 * [http://geos.refractions.net/ GEOS], low-level C++ port of [http://www.jump-project.org/project.php?PID=JTS Jave Topology Suite], used by PostGIS 10 * [http://exogen.case.edu/projects/geopy/ Geopy] calcs distances using (very accurate) [http://www.movable-type.co.uk/scripts/LatLongVincenty.html Vincenty], and uses the [http://en.wikipedia.org/wiki/World_Geodetic_System WGS 84] datum. 10 * [http://zcologia.com/news/14/python-geos-module/ PyGEOS], and shedloads more stuff on "python, geospatial, and the web" 11 * [http://exogen.case.edu/projects/geopy/ Geopy] calcs distances using (very accurate) [http://www.movable-type.co.uk/scripts/LatLongVincenty.html Vincenty], and uses the [http://en.wikipedia.org/wiki/World_Geodetic_System WGS 84] datum by default. Also has utility functions for UOM conversions. 12 * [http://gispython.org/ Python Cartographic Library] - [http://trac.gispython.org/projects/PCL actively maintained], huge GIS package, GPL. 11 13 12 14 = Questions = 13 14 = Alternatives = 15 * When dealing with points (say, degrees) from, do they need to be converted to be useful on the back-end data, assuming -that- data is in degrees? Is it enough to have the same datum and origin? (Reading the intro above is likely to answer the question.) 15 16 16 17 = Implementation = 17 18 18 19 == Phase 1 == 19 Assume existing data and fields, and that the 20 Assume existing data and columns, and that the UOM given is same as backing data. 21 Support a custom manager (and queryset) to support lookups. 20 22 21 == Custom Manager == 22 A custom manager (and queryset) to support lookups like: 23 === GeoTypes === 24 GeoTypes supports only psycopg1, which is dead. Porting it to Psycopg2 doesn't look too terrible. Upside is conversion from type params to SQL. Simplifies (avoids?) QuerySet modification. 25 26 === Geos === 27 I'm not sure how we can use GEOS without also doing something like GeoTypes down in the QuerySet. Ideas? 23 28 24 29 {{{ 25 Schools.objects.filter(geom__overlaps=bbox.geom) # &&26 30 27 Schools.objects.filter(geom__contains=bbox.geom) # ~ 28 29 Schools.objects.filter(geom__sameas=bbox.geom) # ~= 30 31 Schools.objects.filter(geom__inside=bbox.geom) # @ 31 Schools.objects.geo_near(point=x, radius=1.0) 32 Schools.objects.geo_within(bound_box=box) 32 33 }}} 33 34 34 == Field Types == 35 Field type for a geometry 35 36 == Phase 2 == 37 === Field Types === 38 * To allow update through ORM, new fieldtypes would be needed. 36 39 37 40 38 == GIS wrapper==41 === GIS utilities === 39 42 wrapper for geos, have the ability to do something like 40 43