(just submitted to OSGeo-Discuss)
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
On Mon, Apr 7, 2008 at 4:34 AM, Markus Neteler <neteler@osgeo.org> wrote:
(just submitted to OSGeo-Discuss)
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
Thanks for starting this Markus -- I was just thinking about
formalizing some GRASS-GMT integration with the new python bindings
available in both packages. I will forward this information to the GMT
folks and see if they are interested.
Dylan
Markus Neteler wrote:
(just submitted to OSGeo-Discuss)
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.
Personally, I don't think it's practical to design such a large and
complex system at a theoretical level.
It makes more sense to start by writing what you need, structuring the
code in such a way as to make it re-usable (i.e. avoid tying it to any
particular architecture).
When you find existing code which performs a useful task, try to use
it. This will tell you whether it actually managed to meet the
re-usability critieria. If it didn't, you have concrete information
about how to improve it.
GRASS' display architecture is a prime example.
In theory, you have an abstract interface which allows you to provide
multiple different back-ends. In practice, writing a PostScript driver
demonstrates several places where the architecture isn't actually as
flexible as it needs to be, and how the interface needs to change in
order to accomodate vector back-ends.
--
Glynn Clements <glynn@gclements.plus.com>