Changes between Version 13 and Version 14 of GeoDjango


Ignore:
Timestamp:
02/25/07 23:24:01 (8 years ago)
Author:
Jeremy Dunck <jdunck@…>
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v13 v14  
    88 * [http://postgis.refractions.net/ PostGIS], the [http://www.opengis.org/docs/99-049.pdf OpenGIS SQL Types (pdf)] implementation for Postgresql
    99 * [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.
    1113
    1214= 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.)
    1516
    1617= Implementation =
    1718
    1819== 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.
    2022
    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?
    2328
    2429{{{
    25 Schools.objects.filter(geom__overlaps=bbox.geom)   # &&
    2630
    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)  # @
     31Schools.objects.geo_near(point=x, radius=1.0)
     32Schools.objects.geo_within(bound_box=box)
    3233}}}
    3334
    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.
    3639
    3740
    38 == GIS wrapper ==
     41=== GIS utilities ===
    3942wrapper for geos, have the ability to do something like
    4043
Back to Top