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,
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
