Design
Architecture
Geotrek-admin, the web application
Convertit, a Web API to convert document and image formats (.odt to .doc, .svg to .png)
Screamshotter, a Web API to perform Web pages screenshots (map image exports).
Main components
The whole project is built on top of mapentity.
A generic application in charge of:
Menus and models registry
List/Detail/Create/Update/Delete views
Filtering
Map images exports
File attachment
Document export
Shapefile/GPX/CSV serializers
For a Django model, we use the registry to activate all views and menus:
Business specific notions are implemented in Geotrek-admin respective applications:
common: shared concepts between all applications (Organism, utils, …)
authent: groups, user, profile and structure notions. Optional external authent backend.
core: elevation, paths, snapping, spatial referencing (topologies)
land: static cities/districts/restricted areas layers, physical types, competence, signage and work management
infrastructure: buildings, signages, equipements
maintenance: interventions (on paths or on infrastructures) and projects
trekking: POIs and treks
Django conventions twists
We have a couple of Django conventions infringements:
SQL triggers everywhere: since Geotrek-admin database is to become the central storage component of all park organisation data, it has to behave consistently whether data is modified through the Web application or raw access tools (pgadmin, QGIS). (For example, insertion & update timestamps, geometry computation or DEM wrapping.)
Safe delete: update field
deleted = Trueinstead of performing actual delete in table. Requires every querysets to be filtered on deleted. (TODO: use dango-safedelete, issue 813)
Main roles of PostgreSQL triggers
Automatic computation of fields :
Date insert/update
Geometry computation of linear referencing (topologies)
DEM elevation wrapping (3D length, slope, etc.)
Topological path network :
Split paths at intersection
Snap paths extremities