Difference between revisions of "OSGeo Cartographic Engine"

From OSGeo

Latest revision as of 22:42, 6 April 2010

Summer of Code 2010: This project has been proposed for SoC 2010

JOIN MAILING LIST: A list is now available for discussion around these concepts/ideas: Carto list.

NOTE: This is not actually about building an API, rather about establishing some specifications for interaction between some common applications and a map production engine.

Conceptual overview

Motivation

To develop a common method and tools for printing high quality maps from a variety of mapping software. Starting with Mapnik as the renderer and QGIS, GRASS or others as the source application. Initial focus on building standards, then building command line tools or GUI tools.

There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The concept applies to all OSGeo projects in general as well - so high quality production can be something all projects have access to without having to code it from scratch in their own applications.

This applies to web mapping applications as well as desktop ones where high resolution, large format printing is required. But it also applies generally to smaller print jobs as well, e.g. high resolution laser printers.

The GUI part for exporting layouts, etc. could be done within the individual software projects, while this project focuses on standard libraries or command line 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.

The concepts and idea below are quite diverse and represent a broad range of input. If a SoC student takes on this project, part of their job would be to help focus on a particular part of the problem (and possible clarify some of the others into workable sized components).

Ideas for Summer of Code 2010 Project

This year the project will focus on building the capabilities using the Mapnik package due to its ability to output high quality vector maps. It supports XML based configuration files, but needs additions to handle the needs of this project. The QGIS Quantumnik plugin is an excellent example of moving toward the end goal of this project. Other applications may be considered too.

Some further ideas to consider (add your own!!):

An approach for transforming XML files from other applications into format compatible with Mapnik or this project specs
How to handle caching web services at the proper resolution for printing?
Consider icon collision handling
Tweaking Mapnik and underlying Cairo library to handle text/font exporting better
...what else....?

A workplan might look like this, but is totally open to new ideas:

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.

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. Any of these would be worth looking at, but it is not necessarily a final list. Add your ideas!

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

@@ Line 1: / Line 1: @@
-== Motivation ==
+'''Summer of Code 2010:  This project has been proposed for [http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2010_Ideas#The_ideas_pages SoC 2010]'''
-There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The GUI part will be done within the individual software projects, while this project focuses on standard libraries or command line utilities.
+'''JOIN MAILING LIST''': A list is now available for discussion around these concepts/ideas: [http://lists.osgeo.org/mailman/listinfo/carto Carto list].
+-----
+'''NOTE: This is not actually about building an API, rather about establishing some specifications for interaction between some common applications and a map production engine.  '''
+-----
+[[Image:Carto_engine_v1.png | thumb | right | 300px | Conceptual overview]]
-== Functionality ==
+== Motivation ==
+To develop a common method and tools for printing high quality maps from a variety of mapping software.  Starting with Mapnik as the renderer and QGIS, GRASS or others as the source application.  Initial focus on building standards, then building command line tools or GUI tools.
-Shared functions may include
-* class breaks (various algorithms)
-* histogram analysis
-* color ramps
-* RGB and possibly CYMK support (aka color transformations) etc.
-* Algorithms for intelligent label placement -- for example, collision management based on rotated extent rectangles.  Also, collision management against line and polygon and point features.  Provision for prioritized set of text placement rules, first one to prevent collision wins.
-* Symbology management
-* map surround
-* legend
-* cartographic templates (ie. predefined map styles)
-== Programming Language ==
+There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc.  The concept applies to all OSGeo projects in general as well - so high quality production can be something all projects have access to without having to code it from scratch in their own applications.
-* C? C++?
+This applies to web mapping applications as well as desktop ones where high resolution, large format printing is required.  But it also applies generally to smaller print jobs as well, e.g. high resolution laser printers.
-Perhaps we could implement the core in C++, but provide a high level C API for applications and environments wanting to drive the library.  C++ is a strong implementation language, but presenting a C API to the outside world reduces complexity calling from other languages or compiler versions and reduces "interface fragility".
+The GUI part for exporting layouts, etc. could be done within the individual software projects, while this project focuses on standard libraries or command line 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.
-* Python bindings?
+The concepts and idea below are quite diverse and represent a broad range of input.  If a SoC student takes on this project, part of their job would be to help focus on a particular part of the problem (and possible clarify some of the others into workable sized components).
-There has been talk on the [http://gmt.soest.hawaii.edu/ GMT] mailing list about Python bindings to the core C API. Since GMT already has a wealth of routines for plotting directly to PS|EPS format files, this route may give developers a great head-start. There has been [http://casoilresource.lawr.ucdavis.edu/drupal/node/561 some work] on the integration of GRASS and GMT in the past, with [http://grass.gdf-hannover.de/wiki/GRASS_AddOns several user-submitted modules].
+== Ideas for Summer of Code 2010 Project ==
-== Output Formats ==
+This year the project will focus on building the capabilities using the [http://mapnik.org Mapnik] package due to its ability to output high quality vector maps.  It supports XML based configuration files, but needs additions to handle the needs of this project.  The QGIS [http://bitbucket.org/springmeyer/quantumnik/wiki/Home Quantumnik plugin] is an excellent example of moving toward the end goal of this project.  Other applications may be considered too.
-What output formats do we want to target.  I think at the core this question comes down to whether we want to render everything to a raster format or whether we wish to preserve linework, and text in non-raster form.  That is, whether output output is a raster format, or a raster+vector+text format like postscript/pdf.
+Some further ideas to consider (add your own!!):
+* An approach for transforming XML files from other applications into format compatible with Mapnik or this project specs
+* How to handle caching web services at the proper resolution for printing?
+* Consider icon collision handling
+* Tweaking Mapnik and underlying Cairo library to handle text/font exporting better
+* ...what else....?
-If a cartographic product is the objective, I think selection of an output format like PDF makes a lot of sense, but it does make interactive composition more complicated and it is possible we have limited pdf/postscript development expertise in our developer community (the GMT developers may be of help here...).
+A workplan might look like this, but is totally open to new ideas:
+# 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.
-What about the possibility of exporting SVG and using Inkscape for cartographic styling and design? Inkscape is written in C++ and already has a wealth of vector graphics functionality. You could also consider using Scribus for map layout. I believe Scribus is also written in C++. Why implement the great functionality that already exists in open source programs?
+== 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.  Any of these would be worth looking at, but it is not necessarily a final list.  Add your ideas!
-Coming from the Web Mapping angle it will be interesting to be able to acquire OGC WMS maps with a pixel sizes < 0.28 mm (which is the current standard of ~ 72 or 90 dpi). This option has been suggested as a change request and is currently being discussed. It will allow to compose high resolution print maps also using OGC WMS.
+'''Style & Layout Configuration Standards'''
-== Existing code to be recycled ==
-There will be code in GRASS, QGIS, the Python Cartographic Library (http://zcologia.org/cartography) and other sources which could be integrated (check license compatibility). Please indicate precisely where to find the source code, license, programming language. Please keep in mind that this is underlying library, not the graphical user interface.
-* Label placement code:
-** Mapserver [http://trac.osgeo.org/mapserver/browser/trunk/mapserver/maplabel.c labeling code] (MapServer License, C language)
-** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.label.sa v.label.sa] (GPL, C language)
-* Color management:
-** MapGuide, [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Server/src/Services/Feature/FeatureNumericFunctions.cpp CalculateDistribution] and [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
-** OpenJump ?
-* Stylization
-** ...
-* Class breaks:
-** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats different algorithms for class breaks] (GPL, C)
-* Output:
-** Postscript/PDF output:
-*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/ps/ps.map ps.map] (Postscript output) and [http://trac.osgeo.org/grass/browser/grass/trunk/lib/psdriver PS driver] (GPL, C)
-*** [http://sourceforge.net/projects/geofunctions GeoFunctions]: Geographic XML to PDF. Not sure what specific code, but the project leaders might have some insight.
-** PNG output:
-*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/pngdriver PNG driver] (GPL, C)
-*** See AGG below
-** CAIRO output
-*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/cairodriver CAIRO driver] (GPL, C)
-*** [http://cairographics.org/ Cairo Graphics Library] (LGPL or MPL)
-** [Mapnik http://mapnik.org/] is a Free Toolkit for developing mapping applications.
-== 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
-* Seprate 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
-==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.
-=== XML and PDF===
-OSGEO might be able to get behind the [http://sourceforge.net/projects/geofunctions Geo Functions] project. "Geo Functions is an open-source library of XSLT-2 / XQuery functions, templates, stylesheets and classes devoted to the processing of geographic data in XML." I understand that the original purpose of the project is to produce PDF maps from XML based data.
-==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)
+* 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 ===
+'''Graphical Style & Layout Editor'''
 * To create styles interactively
 * To define map layout
@@ Line 106: / Line 53: @@
 * Saves a style/layout definition document according to above standards
-=== Graphical Map Composition Editor ===
+'''Graphical Map Composition Editor'''
 * Implemented by existing applications (e.g. GRASS, QGIS, etc.)
 * Sets up pointers to data layers
@@ Line 113: / Line 60: @@
 * Outputs a map composition configuration file
-=== Rendering Engine ===
+'''Rendering Engine'''
 * Stand-alone application (no GUI)
 * Reads standard map composition configuration file
@@ Line 119: / Line 66: @@
 * Outputs final graphics to specific files
-=== Libraries ===
+== See also ==
-* Sets of libraries could be created to implement parts of the above sections
-* Add more here...
-== Technologies ==
-* AGG (sophisticated rendering of vector/text graphics to raster format - used by MapServer, MapGuide, Mapnik).
-* Freetype - text management and rendering library
-* [http://cairographics.org/ Cairo] graphics library - vector, text and raster input, various output including Postscript
-== Worflow ==
-By working from the end product to a workflow might let us identify specific libraries to help with each task in the workflow required to produce a map. Edit at will.
-* read geo data
-** geometries
-** projection
-** metadata (if required)
-* apply styling
-** feature to style coding
-* Cartographic edits
-** overide some of the geometry if required (eg roads don't run through lakes)
-* manual edits / retouching
-* Produce  other cartographic edits objects
-** create suround
-** create grids
-** create legend
-** create scale bar
-** create north arrow
-** Copyright notices from text file or DB
-** Licensing notices from text fiel or DB
-* Other
-** Output size
-== License ==
-It is proposed to license the OSGeo Cartographic Library under LGPL. The license needs to be GPL compliant.
-== Interested people ==
-* [[User:Neteler|Markus Neteler]] (proposer)
+* [[OSGeo Cartographic Engine Discussion]] - more (original) detailed brainstorming and ideas
-* Horst Düster
+* [[OSGeo map symbol set]]
-* [[User:Landa|Martin Landa]]
+* [[Configuration Files]]
-* [[User:MarcoHugentobler|Marco Hugentobler]]
+* PAL - A cartographic labelling library ([http://pal.heig-vd.ch website], FOSS4G2008 [http://foss4g.org/index.php/foss4g/2008/paper/view/275 abstract], [http://mistic.heig-vd.ch/taillard/articles.dir/pal_foss2008.pdf PDF])
-* Frank Warmerdam
+* [[Programming Languages Project]]
-* [[User:Adiez|Agustin Diez]]
-* [[User:mlennert|Moritz Lennert]]
-* [[User:Dsampson | Dave Sampson]]: End User, Search and Rescue Maps,
-* [http://casoilresource.lawr.ucdavis.edu/drupal/node/38 Dylan Beaudette]: Soil Science Researcher, OSGeo evangelist
-* [[User:Tmitchell|Tyler Mitchell]]
-* [[User:reholl|Robert Hollingsworth]]
-* Wolf Bergenheim
-* [[User:HamishBowman|Hamish Bowman]]: ps.map developer & evangelist
-* [[User:GAruta|Giuseppe Aruta]]: Geologist
-* [[User:Roy|Roy Braam]]: Software Engineer
-* Ionut Iosifescu
-* [[User:ajolma|Ari Jolma]]: Wants to go ahead with Cairo
-* [[User:vasile|Vasile Crăciunescu]]
-* [[User:Peterrushforth|Peter Rushforth]]
 [[Category: Software Stack]]
+[[Category: Printing]]

Difference between revisions of "OSGeo Cartographic Engine"

Latest revision as of 22:42, 6 April 2010

Contents

Motivation

Ideas for Summer of Code 2010 Project

Potential Components

See also

Navigation menu

Search