The basic design of EOxServer has been proposed in RFC 1: An Extensible Software Architecture for EOxServer and RFC 2: Extension Mechanism for EOxServer. Both are worth reading, although some of the concepts mentioned there have not (yet) been fully implemented.

This is a short description of the basic elements of the EOxServer software architecture.

Architectural Layout

EOxServer is Python software that builds on a handful of external packages. Most of the description in the following sections is related to the structure of the Python code, but in this section we present the building blocks used for EOxServer.

For further information on the dependencies please refer to the Installation document in the EOxServer Users’ Guide.


EOxServer is designed as a Django app. It reuses the object-relational mapping Django provides as an abstraction layer for database access. Therefore, it is not bound to a specific database application, but can be run with different backends.


Metadata and part of the EOxServer configuration is stored in a database. A handful of geospatially enabled database systems is supported, though we recommend either PostGIS or SpatiaLite.


One of the most important components is MapServer which EOxServer uses through its Python bindings to handle certain OGC Web Service requests.


In some cases EOxServer uses the GDAL/OGR library for access to geospatial data directly (rather than through MapServer).

Software Architecture

The basic software architecture of EOxServer’s Python code is layed out in RFC 2: Extension Mechanism for EOxServer. The main intention of the design is to keep EOxServer modular and extensible.

In order to reach that goal, EOxServer relies on a central registry of classes that implement certain behaviour. The registry allows to find appropriate implementations (e.g. for certain OGC Web Service operations) according to a set of parameters.

  • Registry
  • Factories
  • Wrappers
  • Resources
  • Records