Skip to content

home

Jump to bottom Edit New page
Aaron edited this page Jan 19, 2015 · 20 revisions

Welcome to the soc-maps wiki!

Toward a Coherent System of Managing and Publishing Geospatial Information

Managing Spatial Data Repositories

Concept

CCCS maintains a separate geospatial data repositories for publicly-available data that can be displayed on the CCCS website and distinct from data specific to each of our client projects (which typically include a mixture of of both public and proprietary data sources). CCCS' archive of publicly-available data is currently managed via 'GitHub' at /cccs-web/soc-maps/.

Private client data is managed independently and presented on cloned version of the CCCS website. To maintain the greatest control of client data (as well as privacy with regard to our client-specific work), we managed client-project repositories on CCCS web-servers, using the 'Gitlab' software package to facilitate graphical user interface (GUI) management and of repository version-controlling. The 'Gitlab' software also includes a wiki platform to maintain meta-level discussion of the project and file system, as well as a task "ticketing" system for raising work requests ("issues") assigning these requests, and tracking request completion.

As indicated above, CCCS wishes for all work to be viewable easily within the CCCS website [https://github.com/cccs-web] as a unified "user environment" for technical writers as well as for clients.

CCCS clients have cloned versions of CCCS' data management and web-publishing infrastructure to allow for self-contained "data dumps" to be provided to clients so that they can be spun-up as unique machines.

Our first, most fundamental, challenge with regard to data management related to how to store and link GIS data (and databases) to best ensure that data are appropriately managed, version-controlled, stored and shared across projects. We wish to avoid excessive and un-tracked branching of information.

A related issue is the format for data storage. Most GIS data we receive come in the form of shapefiles. To archive these data (and to preserve along with them the associated meta-data, including 'original' file names and name of the data source), CCCS is currently using postgreSQL. Our idea is that using databases to manage shapefiles will also facilitate better interoperability and referential integration with other data types. Among other database applications, postgreSQL is arguably best suited for management of spatial data. The merits of the added efforts of database utilization, however, are not a matter about which CCCS is sufficiently informed at this moment in time.

Initial Approach and Current Standing

CCCS' online repositories

As CCCS makes greater use of geospatial analysis to support our work in the field of social impact assessment, we would like to have an easy way to showcasing our work. We therefore commissioned work to on a web mapping software application that extends our Django-based web framework, which CCCS hosts at crossculturalconsult.com, to facilitate the production of cartographic data visualizations.

CCCS' early development work utilized GitHub to version-control both the web mapping software application as well as the spatial data that we intended to referenced by that application: /cccs-web/soc-maps/. While this approach made it convenient for simultainiously sharing both spatial data and the applications' code base within one repository to our various developers and application users, both CCCS' IT expert, Paul Whipp, and our GIS consultants, Kartoza Pty., recommended against this 'combined' approach. The Git version-control system is non-optimal for management of spatial data primarily because repository size for such data tends to grow too large for Git to be effective [e.g., one tends to start encountering timeout errors when cloning and pulling larger repositories, and the system may not be able to manage any single file over 2 gigabytes in size (such as a a dump of a spatial database)].

Following the advice of our consultants, CCCS adopted an alternative system for sharing spatial data using BTSync. While this approach has the advantage of allowing us to share larger-sized repositories of spatial data outside of Git, it has the disadvantage of creating parallel data sources (i.e., the shared BTSync repository on the client side and the sever-side 'production' repository. Another disadvantage of the BTSync approach is that data are not version controlled. We therefore view the BTSync data-management approach as a 'temporary' solution.

Data Storage

With regard to the creation and management of geospatial data in database format, Kartoza Pt scripted database imports for CCCS' public repository (as well as one of our client project repositories).

The script looks for data in the folder /home/sync/cccs-maps/, which refers to the BTSync repositorty noted above.

CCCS' public data is stored in the designated sub-directory: /home/sync/cccs-maps/public [15.0 GB].

The shapefiles folder was located in /home/sync/map-app/source_material/shapefiles/

In its initial formulation, this import script loaded shapefile data into a postgreSQL that was, in turn, embeded within a Docker container [^1]

[NOTE^1: Docker is a software application that CCCS has requested be eliminated from our software application stack.]

CCCS has since dumped these databases from within Docker and imported them directly to our server's postgreSQL data—renaming them in the process to:

These copies of these database dumps are available via their respective repositories (linked above).

PLEASE NOTE: The docker-oriented shapefile data import script.

In sum: All of the previous data are in the sync drive. Much more data are added. I started moving the files to get them to correspond better to the script, but

I remain a bit behind with my local testing of the docker application. Please excuse me. I have a major deliverable to our client on Monday, so it will be hard for me to dedicate much time and concentration before then.

Overcoming Challenges—Next Steps

CCCS and Kartoza Pty continue to explore options for spatial data management. We have tentatively settled on using the 'GeoGig' platform for distributed version-control of shapefile data. The GeoGig software allows users to import raw geospatial data (currently from Shapefiles, PostGIS or SpatiaLite).

Can I add a few more moving parts into the conversation? I have had a play around with your spatial datasets and my first recommendation is that you actually don't store these in Git, but in GeoGig [1] (formerly GeoGit) for the vector datasets and as a private btsync [2] share for the raster data. The reason for my suggestion to use GeoGig is that Git doesnt make a very good platform for versioning geospatial data unless it is in some plain text format like GML (geographic markup language) or CSV. Also the raster data in your git repo is very large and makes working with git awkward. I spent a bit of time making a diagram showing how I see the high level architecture working (attached). Yes there would be a bit of pushing and pulling between repos and branches but I think that is fine and just normal modus operandi for working in Git.

As far as working against CCCSs git repo, I think that sounds just fine. We will make a fork in Github and make pull requests to your repo. Hopefully my diagram will make it clear if I understand your intention well enough and will relay what I am thinking too. Feel free to tweak it if needed using the link I have provided below [3].

Kartoza has contributed some to investigating use of the GeoGig application, though CCCS has yet to receive a briefing about the particular details of this work. Kartoza invoices to CCCS suggest that most of the work relates to embedding GeoGig into a Docker image; CCCS has requested Kartoza review of work charged to CCCS on this matter on the grounds that our request to stop all Docker-related development was prior to this work being conducted.

With regard to moving forward with 'GeoGig':

CCCS needs to create GeoGig repositories for 'public' data and for each of our our 'client' projects. The GeoGig repositories must have their 'MASTER' branch hosted on CCCS' servers.

Progress in this regard is as follows:

  1. We have installed GeoGig to our data server:
    geogig@ip-10-167-186-14:/home/aaron$ geogig version

    Project Version : 1.0-beta1 Build Time : August 14, 2014 at 17:44:46 ART Build User Name : Gabriel Roldan Build User Email : [email protected] Git Branch : r1.0-beta1 Git Commit ID : 9aae709f4f451802a09c14293c92a46372c868bd Git Commit Time : August 14, 2014 at 17:43:33 ART Git Commit Author Name : Gabriel Roldan Git Commit Author Email : [email protected] Git Commit Message : Set version to 1.0-beta1

  2. We have enabled the user 'geogig' to call the geogig application by adding the PATH variable to the user's /bashrc file/

  3. We created a DNS entry to link traffic coming in from http://geogig.crossculturalconsult.com to our desired geogig server

Remaining tasks to get the GeoGig set-up working are:

  1. We need to configure nginx appropriately to allow us to push and pull data to each GeoGig project
  2. We need to import existing data into GeoGig. While the GeoGig documentation suggests that it is possible to import postgreSQL data as well as shapefiles, it remains unclear to CCCS how such imports are to occur. That is, what happens if we import both a postgreSQL data base as well as shapefiles? Does GeoGig automatically re-structure the data and allow us to re-export these files as a single postgreSQL database, or does it keep each file entity separate? Would the GeoGig system act as the database, or is it used only to version control changes to a database? Does GeoGig also allow us to manage regular data tables, such as socio-economic and cenus data? We'd like some coaching and tutorials on how data management should occur with GeoGig as our version-control system.roject- specific requests.

Team Integration and Workflow

Another challenge that CCCS would like to resolve in the near term is the formalization of an appropriate communication protocol and team data management workflow.

Currently, Kartoza is managing CCCS-related development via a private repository hosted on GitHub. CCCS and Kartoza agreed to this approach to allow Kartoza to use maintain regular use of their waffle.io 'scrum' workflow. CCCS and Kartoza also agreed that CCCS would raise issues related to map application development on /cccs-web/soc-maps/, and that particular stylization and customization requests for our client projects would be managed via their respective, private directories hosted on GitLabs.

For tasking you can file your tickets directly on the soc-maps project and view them here on waffle:

https://waffle.io/cccs-web/soc-maps

I suggest to add as many requirements as you can currently think of into the issue tracker to start with and then we will use normal SCRUM workflows to group the work into sprints and work through the issues assigned to that sprint.

As discussed, we'd like all coding and development work related to extending and improving the application to occur on the CCCS-web GitHub master (https://github.com/cccs-web/soc-maps), and we will cascade this work down to our client project sites, including CCCS-Abadi (http://gitlab.crossculturalconsult.com/abadi/esms-maps).

Since we will need to discuss Abadi-specific issues from time to time, please instruct me about where these discussions should occur. Tim noted that waffle.io doesn't connect to GitLabs, so perhaps the solution is to invite CCCS to join your private branch of the Abadi folk?

Otherwise, we will raise issues to the CCCS-web/soc-maps/ GitHub repository (https://github.com/cccs-web/soc-maps), as previously agreed.

...

Going forward, however, I was considering just developing the mapping application on GitHub. My idea was to keep all development of the application public. To work on the Abadi Project, we would just pull and merge changes from the CCCS website (and public map application) to the private Abadi site, where we would do the work of styling / visualizing their proprietary data. In this way, CCCS could host publicly some of the work (like visualizing population data and public socio-economic indicators) while keeping private data private (like the locations site facilities).

This potentially means a bit of extra headache to pull into (and out of) the Abadi repository, but it would allow us to maintain a robust record of the application development process tied to the CCCS GitHub account.

Unfortunately, this approach has not lent itself to effective communication. The issue we assign on /cccs-web/soc-maps sometimes go unanswered for a long period of time. CCCS is not always aware of the questions being raised on /kartoza/cccs/, and activity there appears to have stalled out as of early November. Our email correspondences appear to sometimes get 'lost in the mix', which appears to have resulted in work being carried out on issues that we asked be put on hold in favor of more pressing concerns.

Going forward, CCCS hopes to channel all our development discussions through /cccs-web/soc-maps for issues related to application development, and to our respective client project repositories (e.g. /abadi/esms-maps/) for client- and project- specific requests.

===

In a previous email, Gavin raised the following:

How would you like to handle data editing, adding new data (like demographics) etc.? I see us establishing the infrastructure and SOPs (standard operating procedures) and facilitating your being able to do it yourselves. Such a workflow might be:

You obtain new data -> use tools incl QGIS and PostGIS to work the data into your local PostGIS database (your 'develop' branch) -> import changes into geogig once you're happy (= git add) -> commit -> push -> merge with 'master' -> export from geogig to PostGIS on the server such that the server database version that is supporting the web maps is always canonical.

And I propose that we have a public geogig repo that maps to the PostGIS public schema and a separate, private one for the abadi schema.

This sound very good to us, thank you. Let's please name both repos according to project, hence something like 'CCCS/soc-maps' (public) and 'Abadi/esms-maps' (private).

CCCS Web Map Publishing Application—Concept

Our second major challenge relates to how to present geospatial data in "published" formats (including publishing as text to both the web and to printed documents).

At present, we would like to engage the help of a mapping expert help us develop and deploy a web mapping application to rapidly and readily visualize geospatial information. Indicative operations include: uploading and presenting shapefiles, toggling on and off data layers, customizing colors and transparencies, ordering and editing information and data tables, and creating dynamic means of visualizing data, such as depicting relative size of village population that dynamically scale to zoom levels. Specific issues and requests will be issued via GitHub: https://github.com/cccs-web/core/. Web application development will be in the public domain, but all client data shared for this assignment is considered strictly confidential.

...

CCCS needs to present many complex annotated maps. These maps require interactive features akin to google maps where layers are shown/hidden, features are highlighted and spatial analysis may be performed.

We need to have multiple qgs projects and their datasources present as distinct, separate layered maps much as they do in QGIS desktop in a web browser. These maps will ideally be embedded in other html page content.

when clicking on 'view', the user is taken to a layered map more like the one that I believe should be presented in the QGIS-Web-Client rather than a single png tile layer of the project file.

  1. Integrate with our current Django web environment
  • INITIAL: Leaflet / OL3 * QUESTION:
  1. Allow reproducible installation for anyone cloning our repos with limited knowledge of code
  • INITIAL: primarily through ready to run docker containers and some help docs.
  • CHANGED TO: python module, virtualenv, pip install, clear documentation

  1. Load quickly on client browsers

    • Mapproxy - we would need to pretile / cache maps

  2. Allow shapefiles to be easily loaded into map application

    • Using GeoNode might be better for this requirement. Otherwise we can write a shp importer for django (based on prior code of ours

  3. PostgreSQL administration needs to be documente

    • Github wiki

  4. Layer color

  5. Layer transparency

    • SLD (Geonode) or QML (QGIS)

  6. Layer order

  • We would need to use a thicker client e.g. QGIS Web client or add some JS to OL3 / Leaflet to let user drag and drop layer order then generate a fresh request (but that will kille tilecachability)
  1. Capability to manage files
  • Again GeoNode might be better on this * COMMENT: need to clarify
  1. Group files into directories (helpful to toggle on- and off-views for multiple files)
  • Via QGIS projects
  1. Capability to support analysis
  • Custom QGIS filters / Query views and WPS are options
  1. Calculate distances from and between points
  • WPS + Javascript
  1. Capability to visualize distances (such as creating a circulate around to point to extend a certain distance, or creating a fixed line element of a specific length that can be moved and rotated like a 'measuring stick)
  • WPS + Javascript
  1. Facilitate custom queries such as "how far away from that airport is this house" or " show rings indicating distances at intervals of 10 meters from point, extending out 50 meters)
  • WPS + Javascript

From the list of requirements you have I think we need to look at maybe a hybrid solution e.g. using GeoNode for user uploaded layers which will be sortable etc. and then using QGIS for the basemap which will be precached and not sortable etc. Of course that depends on how flexible we need to be with the base mapping layers.

The QGIS 'map' as published via QGIS server is merely a collection of WMS layers. Layers, Groups or the whole project can be referenced by http GET or POST WMS GetMap requests. e.g. this fetches a single map tile:

http://map1.tracks4africa.net/cgi-bin/mapserv?map=T4A_DHL&LAYERS=africa_as_one&TRANSPARENT=true&FORMAT=image%2Fpng&REPROJECT=true&ISBASELAYER=false&VISIBILITY=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A900913&BBOX=1836214.5133937,-4061164.1260133,3695163.0409562,-2960470.9189039&WIDTH=760&HEIGHT=450 So if you can construct a valid WMS request you'll get an image. Anything fancier like overlaying or interaction - that's what Leaflet and OL are for.

CCCS Web Map Publishing Application—Progress-To-Date

CCCS' work to develop an application to publish maps to the web appears to be occurring in two silos:

Kartoza has been leading one effort to develop self-contained Docker applications that present *.qgis files to a web browser via custom port assignments. On December 01, 2014, CCCS requested that Karotza abandon the use of the Docker application. Our reasons for requesting movement away from Docker have to do with being unable to see and evaluate the system architecture within the app as well as concerns for the large size of each Docker app. We requested instead that all continued work occur within the context of our python-based Django web framework, with the mapping application being developed as a Django module.

Paul Whipp has been attempting to figure out the Kartoza software stack and to and re-create it in the context of the Django web framework. This work is currently occurring under the 'staging' branch of /cccs-web/soc-maps/. From my understanding, Paul's efforts...

I got QGIS server working under Nginx but it only seems to work for a single qgs file. I need help understanding how I can get it to serve multiple qgs projects without needing a separate server running for each one (I looked at Tim's 2012 blog entry but it does not seem to help me because the server wont serve the other files even if I were prepared to clone the client for each project).

QGIS Server

qgis-web-client

django-wms-client submitted a pull request to django-wms-client that brings its requirements up to date so that it can be installed more easily.

ELABORATE

It remains unclear how we should be integrating our teams' work on map application development. As noted, CCCS had originally envisioned that the /cccs-web/soc-maps/ repository would be used for map application development, with work from the 'soc-maps' repository being ported into the /cccs-web/core/ in much the same way as our other application modules. I would appreciate if Paul could contribute some clarification for why we chose a different path.

As we are beginning work that involves essentially two endpoints for mapping work, I decided to make a simple graphic showing our understanding of the division between 'public' (CCCS) and private (client) data.

CCCS works with a variety of clients. We hope to eventually work with Kartoza to develop tools that can facilitate participatory mapping inputs. We expect that these services can benefit a range of clients. For example, Abadi is concerned primarily with visualizing socio-economic baseline data. The World Bank (another client) is concerned about identifying which Indigenous Peoples groups inhabit particular regions in Russia.

getting the QGIS server to show in Django website

Aaron I am going to be travelling for the next few weeks. We have written a simple django application that will let you do this. @ismailsunni has joined work on this project and will support you to get it installed and running. What is your preferred approach for this? I think it will be easiest if we publish the app to pypi and then provide you with the instructions needed to deploy it in your running django project. @ismailsunni will you please take responsibility for this?

Just to be clear we built it as a complete standalone project mainly for testing, our intention was that just the wms-client app part should actually be deployed in your infrastructure (and again no need to use docker if you do not wish to).

https://github.com/kartoza/django-wms-client

Now that we have the basic mapping services in place, I have co-opted one of our developers, Ismail, (in cc and who hails from Yogyakarta). Last week we built a little django app that allows you to easily publish your QGIS Server (or any wms based) projects - its available at

​https://github.com/kartoza/django-wms-client

Its usable both as a simple standalone project (mainly for testing purposes) or as a django app that you can embed into any other django project (e.g. your mezzanine CMS).​ I've added an overview of the functionality to the README there:

https://github.com/kartoza/django-wms-client/blob/develop/README.md

Ismail is going to do some work this week to test it with mezzanine integration - we will come back with more details of best practice on how to directly embed maps into your CMS documents.

Admire will be back in action later this week and at the beginning of next month and we will work to get the GeoGIG side of things implemented.

So all the pieces of the puzzle are coming together - you will soon have a platform that allows you to easily create, upload, publish and embed your maps into your website. After that is in place we can switch our focus to providing some rich interactions for on the fly queries.

CCCS Web Map Publishing Application—A Discussion of Current Challenges and Possible Future Directions

With regards to the hosting of multiple QGIS project files, I have mentioned before that there is no limitation on how many ​project files you host. Looking over the last messages from CCCS, can I surmise that what you are looking to do is host more than one QGIS project file in the context of the QGIS web client? In that case yes, it is correct the web client is limited to one project per web client instance. This is because the web client is deeply tied into the QGIS project it renders. However in our initial planning the idea was to use a feature of QGIS that allows you to embed layers and groups from other projects to bypass this issue. So in effect we would create numerous small projects, each focused on a particular theme (e.g. infrastructure), and then nest these into projects on an ad hoc basis. With this approach you can 'pick and mix' different thematic elements into a master project and then publish that master project. There is an added benefit in that you have a canonical instance of each layer that propagates its changes into all projects where it is embedded.

I wanted to add that I had not actually thought to use the QGIS web client in your architecture - our initial discussions were centered around using a 'pure' OpenLayers3 or Leaflet implementation with some added niceties to manage layer ordering. This is the route we have been following with the wms-client django app that Ismail and myself have been building. The idea is that you would publish your projects via QGIS server and then register those projects in the wms client django app, which would then deliver them as a leaflet (or openlayers if you prefer) project. The app already does a decent job of service discovery when you point it to a WMS url, though there are plenty of things that can be done to refine it. There are two ways we can proceed here:

Option 1) If you are happy using QGIS Web Client as the platform for your map delivery, we can update the wms-client app to automatically generate and deploy the WMS client configuration files. This is not my preferred approach - the QGIS Web Client is a 'heavy' app essentially trying to replicate a read only experience of the original desktop QGIS project. Though it does have one nice feature in that it supports pdf 'print' generation on the server side which will be difficult to otherwise replicate.

Option 2) We further extend the wms-client to a) allow the inclusion of multiple WMS services into a single map and b) provide a legend widget where layers can be drag-dropped to reorder them and checkbox hidden / show. This is my preferred way as it is generic (e.g. not tied in to QGIS project files).

======

NOTES ON QGIS SOFTWARE STACK

QGIS is a tool that creates interactive map projects. The maps are presented and analysed within the QGIS tool.

​Among other functionality, correct.​

...

QGIS Server presents a single QGIS project as an image that can be presented on a web page. For CCCS purposes, this is a red herring.

​Correction - QGIS server presents a series of QGIS projects using the standard web services : Web Mapping Service (WMS) and Web Feature Service (WFS). These services can be consumed by various clients including OpenLayers, Leaflet. Within the WFS spec you can ask for available layers, and selectively display all or a subset of layers.​

...

OpenLayers (OL) is a javascript appliction that presents data from map services. It can present complex interactive maps in layers. CCCS web maps will be presented using OL3.

​Correct. Leaflet performs a similar function too.​

...

QGIS and OL are not related but they process similar data. Both deal with aggregations of maps (layers) and their associated styling.

​In terms of our architecture, QGIS Server provides a backend service, OL/Leaflet provides a client side front end to that service. They both 'speak' WMS as their interoperability layer.​

....

There are three layer aspects of interest:

Features: Vector layer features and attributes These need to be handled using a database so that the features draw on a common CCCS set and projects may extend and modify that set over time. For this we need a single online CCCS POT for features. This POT will be a PostGIS database service. ​Yes. Though in our proposed architecture you would run two databases: one for public data, one for 'private' data.​

...

Styling: Symbology The coloring, associated graphics and annotation of a layer. If developed in QGIS, this information needs to be represented within the PostGIS database service so that it can be transformed for appropriate presentation using OL.

​The styling can be store in the database by QGIS, but typically also resides in the .qgs project file. When using the WMS service, the styling defined on the server side is rendered into map images on the server and sent pre-styled to the client. When using the WFS service, the client (e.g. OL3) would be completely responsible for styling. Typically any more complex styling activities would be done server side.​

...

Layer Attributes Layer visibility, extent, precedence (for ordering). If developed in QGIS, this information needs to be represented within the PostGIS database service so that it can be transformed for appropriate presentation using OL.

​No - these are purely artifacts of the QGIS project file and or the OL/Leaflet client. For example a QGIS project may define layers A, B, C but the WMS client may request them in order A, C, B and they will be rendered as such.

Its best to think of PostGIS as a 'smart data store' and it is not it's responsibility to do any styling of data. QGIS does have the ability to store styling information in the database, but PostGIS isn't intrinsically aware of this (it considers it to be just a stored xml document).​

...

To effectively present project data as interactive maps in browsers, CCCS needs to operate at least one map service which will supply the data to browsers running javascript that extends OL.

​Correct. In our proposed architecture you would run at least two (one for public, one for private) map services. In the OL/Leaflet client you can combine any number of these services into a single map. I would expect that over time you would actually host a number of QGIS projects, separated thematically or regionally. IMHO it is better to have a number of smaller thematic projects than one massive great big one with everything in it.​

...

To prepare the data for presentation, tools such as QGIS will remain very useful. However a pipeline needs to be established to migrate the QGIS features, styling and layer attributes into the form needed to serve via the map service.

​QGIS Server does this for us. It also distributes attribute data via the 'getFeatreInfo' WMS API.​

...

Legacy QGIS projects have created shapefiles. These will need to be individually handled and imported into PostGIS. New QGIS projects should be able to create PostGIS layers via a CCCS PostGIS service. This PostGIS service will be related to the Map Service making the features immediately available over the map service.

​Correct. An update to e.g. an attribute for a kabapaten made on the database would immediately be visible on refresh of the map either in terms of styling (if styling is linked to that attribute) or in terms of the raw attribute data returned to the client.​

...

I am not yet sure how/whether it can also make the styling and layer attributes available. This is a possibility which is likely to involve some PyQGIS plugin work.

​No, QGIS Server returns rendered layers according to the style rules in the QGIS project.​

...

If this sounds good so far, I need to create a working pipeline along with a functional demonstration and supporting documentation. Once that is done, I'll be able to import existing QGIS projects and generate the required OL presentations of the maps.

​So our intention with the django-wms-client app is to provide a simple connection point between a map you have published via QGIS Server (again it may be one of many you publish) and your (or any) django application.​​​ Taking a look at the screenshots in the README.md I created over here might help to clarify this.

https://github.com/kartoza/django-wms-client/blob/develop/README.md​

​Ismail is busy squaring up this django app and will post it in PyPi. From there it will be a simpled matter of adding it to your INSTALLED_APPS, doing a django sync / migration and then ​adding in your maps using the django admin panel.

Once that is in place we would like to come back to you to define further requirements - we can add capabilities like map querying, dynamic overlays, layer switchers, whatever you need basically - ideally we would do this in a generic and re-usable way.

One other thing not touched on above is data versioning. This is where GeoGig comes in (which Admire is now working on as a follow on to his initial work doing data ingestion from shapefiles into PostGIS). So each time your datasets change we should be able to commit that change, much like a geospatial git repository - with feature level diffs.

...

Add a custom footer
Add a custom sidebar
Clone this wiki locally