|Version 14 (modified by 10 years ago) (diff),|
The gis branch intends to add a contrib app implementing geographic support.
- Series of blog posts giving intro to GIS; choice quote from an early post: "If you feel like ending a conversation with a developer then simply bring up the topic of character encodings ... [o]r ... coordinate systems. ... So in the spirit of Tim Bray's and Joel Spolsky's wonderful writeups of character encodings, I thought I'd put together a basic survival guide to coordinate systems over my next few posts and then tie it back to Google Maps."
- More on map projections, including why people can't agree on just one (utf-8).
- PostGIS, the OpenGIS SQL Types (pdf) implementation for Postgresql
- GEOS, low-level C++ port of Jave Topology Suite, used by PostGIS
- PyGEOS, and shedloads more stuff on "python, geospatial, and the web"
- Geopy calcs distances using (very accurate) Vincenty, and uses the WGS 84 datum by default. Also has utility functions for UOM conversions.
- Python Cartographic Library - actively maintained, huge GIS package, GPL.
- 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.)
Assume existing data and columns, and that the UOM given is same as backing data. Support a custom manager (and queryset) to support lookups.
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.
I'm not sure how we can use GEOS without also doing something like GeoTypes down in the QuerySet. Ideas?
Schools.objects.geo_near(point=x, radius=1.0) Schools.objects.geo_within(bound_box=box)
- To allow update through ORM, new fieldtypes would be needed.
wrapper for geos, have the ability to do something like
from django.contrib.gis import area area(bbox.geom)