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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
