[OSGeo-Discuss] Proposal: OSGeo Cartographic Library

[Arnulf Christl]

Frank Warmerdam wrote:
> 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.

Hi,
coming from boring old standards land I wanted to add that we have started a change request to WMS that allows to add a resolution parameter to request for images used in high quality prints. Current discussion is focusing on a parameter called PIXEL_SIZE which will allow to request maps that have a pixel size smaller than the standard 0.28 mm (~72dpi). We don't want to miss the rise of cartography in web mapping...

Regards, Arnulf. 

> 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,