Changes between Version 64 and Version 65 of GeoDjango


Ignore:
Timestamp:
04/10/2007 10:12:29 AM (8 years ago)
Author:
jbronn
Comment:

answered and placed wms question into faq

Legend:

Unmodified
Added
Removed
Modified
  • GeoDjango

    v64 v65  
    5656 * [https://svn.greenpeace.org/projects/custard/browser/doc/geodata GeoRosetta], CC-BY-SA licensed, quality-controlled, collection of geocoding data.  Not yet released to public(?).
    5757 * [http://mapserver.gis.umn.edu/ MapServer]: University of Minnesota (UMN) "open source development environment for building spatially-enabled internet applications."
    58  * [http://www.mapnik.org/ MapNik]: C++ and Python toolkit for developing mapping applications.  Claimed benefits over MapServer: "It uses the AGG library and offers world class anti-aliasing rendering with subpixel accuracy for geographic data. It is written from scratch in modern C++ and doesn't suffer from design decisions made a decade ago." ''See'' [http://www.mapnik.org/faq/ MapNik FAQ].
     58 * [http://www.mapnik.org/ Mapnik]: C++ and Python toolkit for developing mapping applications.  Claimed benefits over MapServer: "It uses the AGG library and offers world class anti-aliasing rendering with subpixel accuracy for geographic data. It is written from scratch in modern C++ and doesn't suffer from design decisions made a decade ago." ''See'' [http://www.mapnik.org/faq/ MapNik FAQ].
    5959 * Ruby on Rails
    6060   * [http://www.ivygis.org/ IvyGIS]: Google-maps type displays with RoR and UMN's MapServer
     
    7171 * '''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?
    7272   * 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.
    73 
     73 * '''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)
     74   * 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).
    7475
    7576= Implementation =
     
    105106 * WMS Server
    106107   * I'm not satisfied with any of the current WMS/WFS implementations.   One implemented in Django would be desirable, e.g., {{{django.contrib.gis.wms}}}.  Thoughts anyone?  (OWSLib looks good, see below)
    107    * Is this going to be a WMS Server/WMS Client/Both?  OWSLib is just a WMS Client from what i have seen
    108108   
    109109
Back to Top