Deployment for production. In a previous post, I described how to set up a local instance of a server for Geopaparazzi cloud profiles. The goal of this work is to build a robust scaleable server that can provide security, spatial data management, and a quality user interface. Following the lead of developers who know more than I do, it is built as a Docker-Compose recipe using PostGIS, Django, Caddy and several optional services.

We have been working with the geopaparazzi mobile app. This is a very interesting app with a lot of capabilities, but setting it up is a pretty daunting prospect for a casual user. The first order of business is to make the download/upload of maps and user data easier. This is done using ‘cloud profiles’ which collect all the basemap, spatialite DBs, forms and other requirements into a listing served as a JSON stream that references the download links. This approach can be satisfied with hand assembled files hosted on a cloud service, the details are described in the user manual.

A question on the R-sig-geo mailing list came up that got me thinking about how much I know about coordinate reference systems (CRS) when working with spatial data in R. Turns out I know how to do the basic stuff, but it’s hard to remember how everything works together, so to aid my memory and for anyone with the question, here are some basic methods to answer the question: How do I make sure all my data is in the same coordinate system?

Serving web pages with Django from a spatially enabled database should allow us to easily place interactive maps on our pages, and provide intelligent spatial query capabilities at the back end. The emphasis on interactive (or slippy) maps, means that we will have to have a javascript component to handle the client interaction. There are many javascript mapping libraries available today, including OpenLayers which is included with GeoDjango and Cesium which does 3D. I’ll demonstrate a map using OpenLayers here but then I want to focus on Leaflet which is very popular due to its small footprint and good performance.

This is the third in a series of posts aimed at developing a set of containers that can be quickly deployed to enable web mapping in a production environment. The previous articles dealt with

This is the second in a series of posts aimed at developing a set of containers that can be quickly deployed to enable web mapping in a production environment. At the conclusion of the first post, we had an empty PostgreSQL database container serving a django container running the development server on port 8000. The next steps are to get PostGIS for a database and enable spatial queries using GeoDjango.

The long term goal of this series of posts is to develop a set of ready to use tools that will enable the rapid setup of web mapping servers that can be prototyped, developed, and moved to production without a lot of embarrassing oversights. The key technologies that I want to use are: