[OSGeo-Discuss] Proposal: OSGeo Cartographic Library
arnulf.christl at wheregroup.com
Tue Apr 8 00:45:50 PDT 2008
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:
>> 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.
> 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.
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...
> 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,
More information about the Discuss