Difference between revisions of "OSGeo Cartographic Engine"

From OSGeo
Jump to navigation Jump to search
Line 11: Line 11:
 
* color ramps
 
* color ramps
 
* RGB and possibly CYMK support (aka color transformations) etc.
 
* RGB and possibly CYMK support (aka color transformations) etc.
−
* Algorithms for intelligent label placement
+
* 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
 
* Symbology management
 
* map surround  
 
* map surround  

Revision as of 12:10, 7 April 2008

Motivation

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.

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)

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 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 some work on the integration of GRASS and GMT in the past, with 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...).

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:

  • Label placement code:
  • Color management:
  • Stylization:
  • Postscript/PDF output:
    • GRASS ps.map (Postscript output) and PS driver
    • GeoFunctions: Geographic XML to PDF. Not sure what specific code, but the project leaders might have some insight.

End User Needs

  • Print to small format medium (eg 8.5in x 11in, 11in x 14in)
  • Interactive layout
  • High quality printing
  • Storage of cartographic symbolizing
  • symbols library
  • Seprate cartographic and geographic representation (eg changes to carto does not affect geo)
  • 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)
  • 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 vcould 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 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

  • AGG (sophisticated rendering of vector/text graphics to raster format - used by MapServer, MapGuide, Mapnik).
  • Freetype - text management and rendering library

License

It is proposed to license the OSGeo Cartographic Library under LGPL. The license needs to be GPL compliant.

Interested people

Retrieved from "http://wiki.osgeo.org/w/index.php?title=OSGeo_Cartographic_Engine&oldid=24021"