OSGeo Cartographic Engine Discussion - Revision history

Wiki-Springmeyer at 21:04, 9 April 2010

2010-04-09T21:04:18Z

Wiki-Sunburned Surveyor: /* Python Prototype Rendering Engine */

2010-04-09T20:59:05Z

Python Prototype Rendering Engine

Wiki-Sunburned Surveyor at 20:56, 9 April 2010

2010-04-09T20:56:32Z

Wiki-Pagameba: /* Specification */

2010-04-07T16:37:35Z

Specification

Wiki-Sunburned Surveyor at 16:01, 7 April 2010

2010-04-07T16:01:08Z

Wiki-Sunburned Surveyor: /* Interested people */

2010-04-07T15:59:49Z

Interested people

Wiki-Sunburned Surveyor: /* Interested people */

2010-04-07T15:59:20Z

Interested people

Tmitchell: parts from refaactoring OSGeo Cartographic Engine

2010-04-06T16:01:15Z

parts from refaactoring OSGeo Cartographic Engine

New page

For more info see: [[OSGeo Cartographic Engine]]
----

== Functionality ==

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)
* parse and print map (geovisualization) description files

This paper might be worth looking at: [http://utpjournals.metapress.com/content/b584484743vk910g/ Extended Cartographic Interfaces for Open Distributed Processing]

== Programming Language ==

* C? C++?

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".

* Python bindings?

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].

== Output Formats ==

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.

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...).

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?

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.

Actually (2008) some GIS desktop allow to export the view to SVG format (QGIS, OpenJUMP, etc). While almost all software could save to SVG throughtPDF/Postscript drivers (ex PDF creator, opensurce). Implementing a complete symbology in Inkscape would be preferable and would solve many problem of compatibility between GIS desktops.
There are some proposal available on the web: GFOSS[http://wiki.gfoss.it/index.php/Vestire_una_mappa_con_inkscape_partendo_da_SVG] (in Italian).

== 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)
** PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)
* Color management:
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
** OpenJump ?

* Stylization
** Cartagen Geo Style Sheets: http://wiki.cartagen.org/wiki/show/HomePage ([http://code.google.com/p/cartagen/ more])

* Symbology
** [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
:: [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* Class breaks:
** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats different algorithms for class breaks] (GPL, C)
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Server/src/Services/Feature/FeatureNumericFunctions.cpp CalculateDistribution] (LGPL.C++)

* Data access:
** GDAL [http://www.gdal.org/frmt_wms.html WMS driver] can help grab tiles at appropriate scale/size/resolution (to what extent?)

* 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)
** [http://mapnik.org Mapnik] is a Free Toolkit for developing mapping applications, that can also output via Cairo
*** [http://trac.mapnik.org/wiki/XMLConfigReference Mapnik configure file format (XML)]
*** Many applicable utilities for handling Mapnik stuff.. [http://code.google.com/p/mapnik-utils/ here] - e.g cascadenik css for styling and nik2img for command line testing!

== 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
* [[OSGeo map symbol set|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.

=== 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.

== Technologies ==
* Examples of application [[Configuration Files]]
* 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
* [http://schemas.opengis.net/se/1.1.0/ OpenGIS Symbology Encoding Schema] A language for describing coverage and feature styles
* [http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleDoc MapFish print module]

== Workflow ==

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

=== Other Workflow Models ===
* [http://casoilresource.lawr.ucdavis.edu/drupal/node/561 Generic GRASS-GMT Workflow]
* [http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview Quality Digital Cartography with GMT and GRASS]

== 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)
* Horst Düster
* [[User:Landa|Martin Landa]]: GRASS developer
* [[User:MarcoHugentobler|Marco Hugentobler]]
* Frank Warmerdam
* [[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]]: Interested in Cairo through Mapnik
* [[User:reholl|Robert Hollingsworth]]
* [[User:Wolf|Wolf Bergenheim]]: v.label.sa developer
* [[User:HamishBowman|Hamish Bowman]]: ps.map developer
* [[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]]
* [[User:Turban|Bjorn Sandvik]]: thematicmapping.org
* [[User:JoCook| Jo Cook]]
* [[User:Mloskot|Mateusz Loskot]] (potential tester, contributor and user)
* [[User:kotzino|Dimitris Kotzinos]]
* [[User:drrho|Robert Barta]]: semantic aspects of visualisation
* Giovanni Allegri: Environmental Geologist, (Web)GIS and RS Researcher
* [[User:MaksimS|Maksim Sestic]]
* [[User:oertz|Olivier Ertz]]: PAL/JPAL project, OGC Symbology Encoding conformance
* [[User:Phdbrianlee|Brian Lee]]: cartographer,GISer.
* [[User:alf|Alessandro Frigeri]]: Researcher (geophysics, planetary sciences).
* [[User:springmeyer|Dane Springmeyer]]: Mapnik Dev, keen on addressing gap in high-res printing from OS GIS
* Allan Hollander: GIS analyst and GRASS user

[[Category: Software Stack]]
[[Category: Printing]]

@@ Line 164: / Line 164: @@
 ===Python Grapchis/Rendering===
 * [http://pictatrove.com/python-graphics.html List of 2D and 3D Graphics Modules for Python]
-* [http://pypi.python.org/pypi/nik2img/0.2.4 Python Binding to Mapnik Renderer]
+* [http://pypi.python.org/pypi/nik2img/ Python Binding to Mapnik Renderer]
 * [http://www.reportlab.com/software/opensource/ Open Source Report Lab for PDF Generation]
 * [http://pypi.python.org/pypi/Enable/3.0.2 Enable and Kiva Drawing Libraries]

@@ Line 159: / Line 159: @@
 ===Python GIS Libraries/Modules===
-* [[http://trac.gispython.org/lab/wiki/Shapely Shapely]]
+* [http://trac.gispython.org/lab/wiki/Shapely Shapely]
-* [[http://pypi.python.org/pypi/GDAL/ OGR Python Bindings]]
+* [http://pypi.python.org/pypi/GDAL/ OGR Python Bindings]
 ===Python Grapchis/Rendering===
-* [[http://pictatrove.com/python-graphics.html List of 2D and 3D Graphics Modules for Python]]
+* [http://pictatrove.com/python-graphics.html List of 2D and 3D Graphics Modules for Python]
-* [[http://pypi.python.org/pypi/nik2img/0.2.4 Python Binding to Mapnik Renderer]]
+* [http://pypi.python.org/pypi/nik2img/0.2.4 Python Binding to Mapnik Renderer]
-* [[http://www.reportlab.com/software/opensource/ Open Source Report Lab for PDF Generation]]
+* [http://www.reportlab.com/software/opensource/ Open Source Report Lab for PDF Generation]
-* [[http://pypi.python.org/pypi/Enable/3.0.2 Enable and Kiva Drawing Libraries]]
+* [http://pypi.python.org/pypi/Enable/3.0.2 Enable and Kiva Drawing Libraries]
 == Interested people ==

← Older revision		Revision as of 20:56, 9 April 2010
Line 151:		Line 151:

	It is proposed to license the OSGeo Cartographic Library under LGPL. The license needs to be GPL compliant.		It is proposed to license the OSGeo Cartographic Library under LGPL. The license needs to be GPL compliant.
		+
		+	== Python Prototype Rendering Engine ==
		+
		+	There has been discussion of putting together a prototype rendering engine that could consume the map rendering input file defined by the Carto Project to produce maps in raster (PNG, JPG) or vector (SVG, PDF) formats. This prototype rendering engine would serve as (1) an example implemenation of an open source application that uses the input file format, and (2) a test of the specificaiton for the input file format.
		+
		+	If volunteers choose to move forward with the prototype it may be implemented in Python. Here are some links that may be helpful for this implementation:
		+
		+	===Python GIS Libraries/Modules===
		+	* [[http://trac.gispython.org/lab/wiki/Shapely Shapely]]
		+	* [[http://pypi.python.org/pypi/GDAL/ OGR Python Bindings]]
		+
		+	===Python Grapchis/Rendering===
		+	* [[http://pictatrove.com/python-graphics.html List of 2D and 3D Graphics Modules for Python]]
		+	* [[http://pypi.python.org/pypi/nik2img/0.2.4 Python Binding to Mapnik Renderer]]
		+	* [[http://www.reportlab.com/software/opensource/ Open Source Report Lab for PDF Generation]]
		+	* [[http://pypi.python.org/pypi/Enable/3.0.2 Enable and Kiva Drawing Libraries]]
		+

	== Interested people ==		== Interested people ==

@@ Line 190: / Line 190: @@
 ===Specification===
 * [http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleServer MapFish YAML Page]
 [[Category: Software Stack]]
 [[Category: Printing]]

@@ Line 186: / Line 186: @@
 * Allan Hollander: GIS analyst and GRASS user
 * The Sunburned Surveyor
 [[Category: Software Stack]]
 [[Category: Printing]]