Architecture Overview

This section provides insight about the components of GeoNode and the way they are used to create the final product.

../_images/geonode_architecture.png

Components

The main components are:

  1. The GeoSpatial Data Manager: GeoServer

    GeoServer provides an OGC compatible data store that can speak WMS, WFS, WCS and others in common formats like GML, GeoJSON, KML and GeoTiff.

    It can be connected to different spatial backends including PostGIS, Oracle Spatial, ArcSDE and others.

  2. The Catalog: GeoNetwork

    GeoNetwork provides a standard catalog and search interface based on OGC standards.

    It is used via the CSW interface to create and update records when they are accessed in GeoNode..

  3. The Website: GeoNode Django Site

    This is a Django based project that allows the user to easily tweak the content and look and feel and to extend GeoNode to build Geospatial.

    It includes tools to handle user registration and accounts, avatars, and helper libraries to interact with GeoServer and GeoNetwork in a programatic and integrated way.

    There is a wide range of third party apps that can be plugged into a GeoNode based site including tools to connect to different social networks, to build content management systems and more.

  4. The Map Composer: GeoNode Client

    The main map interface for GeoNode is the Map Composer / Editor. It is built on top of GeoExt and uses OPenLayers, GXP

    It talks to the other components via HTTP and JSON as well as standard OGC services.

  5. PostgreSQL & PostGIS/ArcSDE: Database

    The database component manages data and configuration information for Geonode/Django, GeoNetwork and GeoServer. All of these tables and data are stored within the geonode database on PostgreSQL. GeoServer can use either PostGIS or ArcSDE to store and manage spatial vector data. (Each layer is stored as a separate table.) When PostGIS is used as the spatial database for GeoServer, the layers are also stored within the geonode database.

Dependencies

Below is an list of the projects GeoNode relies on:

  • PostgreSQL
  • PostGIS (optional)
  • GeoTools
  • GeoServer
  • GeoWebCache
  • Mapfish printing module
  • OpenLayers
  • GeoExt
  • GXP
  • gsconfig.py
  • owslib
  • django-registration
  • django-avatar
  • South

And for building it makes use of:

  • Paver
  • Maven
  • Git
  • Bash

GeoNode and GeoServer

GeoNode uses GeoServer to convert geographic data between various file formats, as well as render styled map tiles. While standard GeoServer components, including its OGC-compliant web services and REST configuration API, provide the bulk of the GeoServer functionality used in a GeoNode site, there are some extensions to help GeoServer and the Django application interoperate more better.

Authentication/Authorization

GeoNode provides an extension to GeoServer to have it respect GeoNode’s user database and permissions instead of its own independent system (essentially delegating its security handling to GeoNode). This extension allows GeoServer to authenticate users by HTTP Basic auth (good for general desktop GIS applications) or Django session cookies (good for users accessing GeoServer from the Django site.) The basic strategy is for GeoServer to forward either type of credential to a Django web service which provides GeoServer with up-to-date information about the user’s permissions. Consider a request coming into some GeoServer service:

GET /geoserver/ows?request=GetFeature&typename=top_secret:data

GeoServer will first inspect the request to identify whether it contains an Authorization: header or a cookie from the Django session system. GeoServer then issues a request to Django:

GET /data/acls

Including the credentials it found on the initial request. If the Authorization: header contains the username and password for a valid user, or the session cookie corresponds to an active session for a logged-in user, then Django responds with a document describing the permissions associated with that user. If the Authorization: header or cookie is found and determined to be invalid, then Django sets a 401 status on the HTTP response. Otherwise, Django assumes an anonymous user and returns a document describing the permissions associated with anonymous users. The permissions document is a JSON object that looks like this:

{
    "is_superuser": false,
    "rw": [],
    "ro": [
        "geonode:medford_parks",
        "geonode:medford_zoning"
    ],
    "is_anonymous": false,
    "name": "foo"
}

That is, a top-level object with five keys:

is_superuser
Specifies whether the user has superuser status (as specified in the Django Database). Superusers have full permissions to all layers and maps.
rw
an array of prefixed layer names of layers which should be fully available (both read and write) to this user
ro
an array of prefixed layer names of layers which should be displayed to this user, but which he/she should not be able to modify
is_anonymous
Specifies whether the user is an anonymous (un-authenticated user).
name
Specifies the username for an authenticated user.

All layers not named in this response will be presumed fully restricted, that is, neither modifiable nor visible to the user in question.

GeoNode and GeoNetwork

Customizing the schema used in GeoNetwork

  • adapt Layer metadata in Django, analogous to Django’s usual User models

JavaScript in GeoNode

GeoNode provides a number of facilities for interactivity in the web browser built on top of several high-quality JavaScript frameworks:

  • ExtJS for component-based UI construction and data access
  • OpenLayers for interactive mapping and other geospatial operations
  • GeoExt for integrating ExtJS with OpenLayers
  • GXP for providing some higher-level application building facilities on top of GeoExt, as well as improving integration with GeoServer.
  • and a GeoNode-specific framework to handle some pages and services that are unique to GeoNode.

The following concepts are particularly important for developing on top of the GeoNode’s JavaScript framework.

  • Components - Ext components handle most interactive functionality in “regular” web pages. For example, the scrollable/sortable/filterable table on the default Search page is a Grid component. While GeoNode does use some custom components, familiarity with the idea of Components used by ExtJS is applicable in GeoNode development.
  • Viewers - Viewers display interactive maps in web pages, optionally decorated with Ext controls for toolbars, layer selection, etc. Viewers in GeoNode use the GeoExplorer base class, which builds on top of GXP’s Viewer to provide some common functionality such as respecting site-wide settings for background layers. Viewers can be used as components embedded in pages, or they can be full-page JavaScript applications.
  • Controls - Controls are tools for use in OpenLayers maps (such as a freehand control for drawing new geometries onto a map, or an identify control for getting information about individual features on a map.) GeoExt provides tools for using these controls as ExtJS “Actions” - operations that can be invoked as buttons or menu options or associated with other events.