| 3 | | * [GeoDjango#FAQ FAQ] |
| 4 | | * [GeoDjango#Implementation Implementation] |
| 5 | | * [GeoDjango#Phase1 Phase 1] |
| 6 | | * [GeoDjango#Phase2 Phase 2] |
| 7 | | * [GeoDjango#Phase3 Phase 3] |
| 8 | | * [GeoDjango#DesignIssues Design Issues] |
| 9 | | * [GeoDjango#Collaboration Collaboration] |
| 10 | | * [GeoDjango#Example Example] |
| 11 | | * [GeoDjango#GeographicModels Geographic Models] |
| 12 | | * [GeoDjango#Usingsyncdb Using syncdb] |
| 13 | | * [GeoDjango#SpatialQueries Spatial Queries] |
| 14 | | * [GeoDjango#Installation Installation] |
| 15 | | * [GeoDjango#Django GeoDjango Branch from SVN] ('''required''') |
| 16 | | * [GeoDjango#GEOS GEOS] ('''required''') |
| 17 | | * [GeoDjango#PROJ.4 PROJ.4] ('''required''') |
| 18 | | * [GeoDjango#PostGIS PostGIS] ('''required''') |
| 19 | | * [GeoDjango#GDAL GDAL] (''recommended'', required for some features) |
| 20 | | * [wiki:GeoDjangoModelAPI Model API] |
| 21 | | * [wiki:GeoDjangoDatabaseAPI Database API] |
| 22 | | |
| 23 | | = FAQ = |
| 24 | | * Place your questions '''here'''. |
| 25 | | * '''Q:''' 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.) |
| 26 | | * My (JDunck) reading indicates yes. Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion. |
| 27 | | * '''Q:''' Can this implementation work with [http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html MySQL spatial-extensions]. If not, it's planned? |
| 28 | | * No. It is (now) planned, ''see'' Phase 3 below. From the last time I (jbronn) checked, MySQL's spatial capabilities have improved. However, we're going to focus our efforts on PostGIS until things are worked out a bit more. As a spatial database PostGIS it is more standards compliant (OpenGIS consortium), more widely used, and has more features (e.g. coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables). It is definitely something I would want to implement in the future since I do ''like'' MySQL. |
| 29 | | * '''Q:''' Is this going to be a WMS Server/WMS Client/Both? OWSLib is just a WMS Client from what I have seen (from ruckc) |
| 30 | | * WMS Server first, client capability a possibility in certain situations (i.e. you want to cache data from another WMS server). Yes, OWSLib is a client, but it contains code for validating the correct parameters to send to a WMS server, thus it can be adapted into a Django view that validates whether the proper WMS parameters were given. Mapnik has an {{{ogcserver}}} module that can parse the correct parameters for WMS 1.1.1 and 1.3.0, however since it is licensed under the LGPL it cannot be easily incorporated into this branch (unlike OWSLib). |
| 31 | | * '''Q:''' Per [http://groups.google.com/group/django-developers/browse_thread/thread/9f6c70864bfa7f2e/ this discussion] in {{{django-developers}}}, "I can do spatial queries if they are directly between two models with polygon fields but I can't seem to get at the spatial queries through foreign keys." |
| 32 | | * Geographic queries require {{{GeoManager}}}, even if the model does not have a geographic field itself (in the case of a foreign key to a geo-field). The reply in the discussion gives detail into why. |
| | 53 | |
| | 54 | = FAQ = |
| | 55 | * Place your questions '''here'''. |
| | 56 | * '''Q:''' 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.) |
| | 57 | * My (JDunck) reading indicates yes. Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion. |
| | 58 | * '''Q:''' Can this implementation work with [http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html MySQL spatial-extensions]. If not, it's planned? |
| | 59 | * No. It is (now) planned, ''see'' Phase 3 below. From the last time I (jbronn) checked, MySQL's spatial capabilities have improved. However, we're going to focus our efforts on PostGIS until things are worked out a bit more. As a spatial database PostGIS it is more standards compliant (OpenGIS consortium), more widely used, and has more features (e.g. coordinate transformation, {{{geometry_columns}}} and {{{spatial_ref_sys}}} tables). It is definitely something I would want to implement in the future since I do ''like'' MySQL. |
| | 60 | * '''Q:''' Is this going to be a WMS Server/WMS Client/Both? OWSLib is just a WMS Client from what I have seen (from ruckc) |
| | 61 | * WMS Server first, client capability a possibility in certain situations (i.e. you want to cache data from another WMS server). Yes, OWSLib is a client, but it contains code for validating the correct parameters to send to a WMS server, thus it can be adapted into a Django view that validates whether the proper WMS parameters were given. Mapnik has an {{{ogcserver}}} module that can parse the correct parameters for WMS 1.1.1 and 1.3.0, however since it is licensed under the LGPL it cannot be easily incorporated into this branch (unlike OWSLib). |
| | 62 | * '''Q:''' Per [http://groups.google.com/group/django-developers/browse_thread/thread/9f6c70864bfa7f2e/ this discussion] in {{{django-developers}}}, "I can do spatial queries if they are directly between two models with polygon fields but I can't seem to get at the spatial queries through foreign keys." |
| | 63 | * Geographic queries require {{{GeoManager}}}, even if the model does not have a geographic field itself (in the case of a foreign key to a geo-field). The reply in the discussion gives detail into why. |
| 132 | | '''Note:''' The geometry columns are created outside of the {{{CREATE TABLE}}} statements by the {{{AddGeometryColumn}}}. This is done according to the OpenGIS specfication. ''See'' Open GIS Consortium, Inc., ''[http://www.opengis.org/docs/99-049.pdf OpenGIS Simple Feature Specification For SQL]'', Document 99-049 (May 5, 1999), at Ch. 2.3.8 (Geometry Values and Spatial Reference Systems, pg. 39). |
| | 113 | '''Note:''' The geometry columns are created outside of the {{{CREATE TABLE}}} statements by the {{{AddGeometryColumn}}}. This is done according to the OpenGIS specfication. |
| | 114 | * ''See'' Open GIS Consortium, Inc., ''[http://www.opengis.org/docs/99-049.pdf OpenGIS Simple Feature Specification For SQL]'', Document 99-049 (May 5, 1999), at Ch. 2.3.8 (Geometry Values and Spatial Reference Systems, pg. 39). |