[OSGeo-Discuss] Proposal: OSGeo Cartographic Library

Landon Blake lblake at ksninc.com
Tue Apr 8 11:29:10 EDT 2008


I added a very short comment about using SVG as an export format and
bringing Inkscape and Scribus into the map production tool chain.
Inkscape and Scribus are both great programs and I think they are both
written in C++. (I wish they were written in Java.) :]

I'm in the process of adding functionality to OpenJUMP that will allow
the user great control over the export of vector graphics in SVG format.
The idea is to use Inkscape to style the exported SVG and Scribus to
layout the final map.

Landon

-----Original Message-----
From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Arnulf Christl
Sent: Tuesday, April 08, 2008 12:46 AM
To: OSGeo Discussions; standards at lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Proposal: OSGeo Cartographic Library

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 at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.


More information about the Discuss mailing list