[OSGeo-Discuss] Proposal: OSGeo Cartographic Library

[Frank Warmerdam]

Markus Neteler wrote:
> Dear OSGeo,
> 
> I would like to launch the idea of an "OSGeo Cartographic Library" to
> share concepts, source code and regression tests:
> 
> http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library
> 
> GRASS, QGIS and others are in the need of own map printing tools
> for high quality output but these projects should not start from scratch.
> There is a wealth of underlying code already in Mapserver, Mapguide etc
> which could be re-used in the terms of their respective licenses and
> certainly of programming language compatibility.
> 
> Please hack the wiki page and post your ideas.

Markus,

There is definitely a need for better cartographic quality output options.

The wiki page did not seem to touch on cartographic surround and "map
composition" which I think is really a major whole currently.  That is
putting together a product suitable for printing as a map with titles,
legends, and map surround components all appropriately and professionally
styled.  I have added a brief note on this.  Is this an objective of the
proposed effort?

Also, I think, it is a very important question to decide what output
format is the primary target.  That is, whether the objective is to produce
products in postscript/pdf with the vector and text preserved in a
non-rasterized format.  The alternative is to produce a raster product,
with us using something like AGG+freetype to render all vector and
text content as part of the process.

While I generally think making postscript/pdf our primary target
would give the most professional product, it will also likely be
harder work, and will require skills that are less common in our
developer community.  If we did the direct-to-raster approach we can
build on quite a bit of AGG rendering expertise in the mapserver,
mapguide and mapnik communities for instance.

I've also suggested under programming languages that the library be
implemented in C++ but with a C API for external interface to the
library.  This model has proven valuable for GDAL as a way to present
a less fragile interface to the outside world, making it easier to
keep the library less tightly bound to the calling application.

BTW, would it be an objective to be able to show the map to the user
as it is being composed?  Knowing this may well affect above decisions.
For instance, if the library produces PDF this could be pretty challenging
to use in an interactive map composer application.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org