Common Cartography Engine

Work in progress based on OSGeo Cartographic Library discussion. JOIN MAILING LIST: A list is now available for discussion around these concepts/ideas: Carto list.

Goal

A high level, cross-project effort to define a cartography output specification, with an accompanying engine application or set of scripts to produce high quality printable output. Other projects could then export to this standard and share in the benefit of a common engine.

Conceptual overview

Motivation

Several GFOSS applications (both desktop and web) seek to improve hard copy print output, though approaches are often not re-usable across applications. We propose developing a common method, with reference specifications and tools, for easily pulling together high quality layout and rendering. This may occur at several levels - a Python API, command line scripts and the ability to embed functionality into an application. A central configuration file format convertor may also be developed.

This project focuses on utilities to process compliant documents. The production of a printing interchange specification/standard is needed as well. An advanced layout tool in the form of a GUI would also be very useful but for latter in the project.

Context: Mapnik

There are a variety of methods for defining printable documents and styles, etc. One well developed approach is used by the Mapnik project and will be the basis of development. Mapnik software is assumed for the base throughout the remainder of the project.

What Is Included In A Hardcopy Map?

The following components are expected to be needed, some already are defined by the Mapnik XML format, but some are not and represent new specs that are needed:

multiple layers
various symbols/styles
legends
map surrounds
graticules/grids
north areas
scale bars
inset maps
label placement
more...

General Workplan

Review existing map definition standards (e.g. from a few desktop and web applications Configuration Files)
Identify missing components from those standards.
Create new specification or make a choice of existing one. Document the primary components as necessary for other app developers to build to its specification.
Identify print-specific options/configuration (and challenges) needed for producing a hard copy. (see Potential Components below for an idea of overall concept)
Write scripts to consume a compliant document and produce a output file - e.g. postscript, PDF or raster. (See discussion below re: output formats)
If possible, write a sample GUI for one OSGeo project to use the specification.

Output Formats

These are often the tricky part when aiming for high resolution vector-based printable output. The Cairo library (that Mapnik can also use) provides several key output options that meet this need: Postscript, SVG, PDF and raster.

Postscript and PDF may be directly printable. SVG and raster output allow for post-production to be done in a 3rd party graphics editing app later in the pipeline.

End User Needs

Print to small format medium (eg 8.5in x 11in, 11in x 14in) and large format (eg 34 x 44in)
Interactive layout
High quality printing
Storage of cartographic symbolizing
Symbols library
Separate cartographic and geographic representation (eg changes to carto does not affect geo).
Generalization on-the-fly, based on current scale.
Rules based cartography stored in RDBMS (eg series 400 highways are blue with double lines)
Multiple export formats
- Geotiff
- PNG
- PDF / GeoPDF
- Postscript (need for directly sending files to printers)
- SVG
Layout Functionality
Text-based configuration file that applications can output to or humans can manually hack/script
Common, interoperable data file input options
Customizable legend with Symbology representation (textures, object symbols, etc.)

Layout Functionality

Design Modeling

Issues of layout will always be important in creating the final cartographic product. Layout templating such as that used in Natural Resources Canada's (NRCAN) Cartographic Design Specifications (http://ess.nrcan.gc.ca/pubs/carto/downloads/design_specs.pdf#page=13).

Perhaps we can learn from the desktop publishing world from the likes of the Scribus project (http://www.scribus.net/). Maybe being able to export a certain portion to scribus to handle some the major layout hurdles. A link between the cartographic library and scribus could allow for auto generation of some layout features and text such as changing declination, Projection info, and others.

Potential Components

Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal.

Style & Layout Configuration Standards

Specifications for styling of features and layout of a map composition
Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles)
Specifications to be used in map definition/configuration files

Graphical Style & Layout Editor

To create styles interactively
To define map layout
Could be stand-alone
Could be adopted as part of another application
Saves a style/layout definition document according to above standards

Graphical Map Composition Editor

Implemented by existing applications (e.g. GRASS, QGIS, etc.)
Sets up pointers to data layers
Assigns styles definitions to the layers
Applies layout definition to maps
Outputs a map composition configuration file

Rendering Engine

Stand-alone application (no GUI)
Reads standard map composition configuration file
Reads and applies the required style/layout definition documents
Outputs final graphics to specific files