[GRASS-dev] discussion: replacing ps.map

[tlaronde at polynum.com]

Hello,

On Tue, Mar 27, 2007 at 04:50:51PM +0200, Jachym Cepicky wrote:
> Hallo,
> 
> while ps.map is nice tool for creating hard copy maps in GRASS, it is
> not sufficient for some more complicated tasks and correct me if I'm
> wrong, there is no _real_ maintainer of it's code, who would be able
> to write new functions for it.
> 
> Now, when new wxPython GUI is stepping forward, I'm thinking about,
> how to write future GRASS mapcomposer.
> 
> I see two interesting tools in today's FOSS4G world, which could be
> used as back end for new Mapcomposer, and which would so replace
> functionality of ps.map:
> 
> 1) UMN MapServer
> 2) GMT
> 
> MapServer
> -------------
> UMN MapServer is far known tool, which has well documented
> configuration file and large community. I suppose, most of the
> GRASS-users are already familiar with it. MapServer produces nice
> graphical output in desired resolution and format. I is possible to
> use PDF as output format:
> http://mapserver.gis.umn.edu/docs/howto/pdf-output Tasks, like label
> placement and so on are already solved in MapServer. GRASS would
> became also a GUI for MapServer configuration file. It is possible to
> access GRASS (vectors and rasters) from MapServer (both are using
> gdal).
> 

I'd like the developers of my dear sibling project to explain me a
couple of things.

1) How can you constantly repeat that you are not sufficiently numerous
to maintain GRASS when the CERL team was mainly, as it seems from the
copyrights, 4 men. How can you explain that KerGIS has kept everything,
does not plan to throw out things, has added things, while there is only
_1_ developer (part time developer since I have other products to
develop too ; and progress is slow, but constant)? Do you simply
claim---that would be valid---that open source is simply not efficient?


2) How can the voiced majority claims "GPL rules", while at the very
same time hurrying to "port" GRASS to Windows and trying to introduce
(see below) other dependencies on not open source licences?

3) How can you propose to drop ps.map(1) while the MapServer
alternative:
	a) does not provide the same features as ps.map(1)---no legend, no
	scalebar etc.---;
	b) relies on PDFlib Lite, that is a stripped down version of the
	commercial PDFlib, whose licence would be suddenly acceptable while
	you frown at OpenMotif or QT?

4) How can you plan to "outsource" even more things, while what has made
ESRI the leader, compared to the second in position, is the consistancy
of the offer, that is components that fit together. 

If there was such thing as a standard format for interchange (there
is one: STEP that is not very popular in the field), one could
imagine the Unix approach:  combine several tools that do only
"one" thing but do it well. GRASS would be the analysis workhorse,
delegating map creation to another tool, and hardcopy creation to
another one. Unfortunately, creating/modifying maps is not independant
from the native format and the analysis (one has usage for
interactively and in real time modifying a map when things are not
what they are expected to be), that is these tools have to be
integrated with GRASS.

And if there is such a thing as a standard for hardcopy, this is not
the interface but the language, that is PostScript (interfacing with
other tools being made via this language).

The needs in hardcopy for GRASS/KerGIS do not require the full power of
PS being implemented in the components, since one can always relieve on
other really free programs to create specialized images (MetaPOST for
example), and the GRASS tool has only to be able to include these images
(eps) (and mind you, one solution of the MapServer PDF output is simply
to embed a PNG rendering in a PDF wrapper...).


As I have already wrote, KerGIS has strictly no interest in GRASS GPL
going right against a wall. Unfortunately, I have sometimes the feeling,
reading your mailing list, that you behave like a cloud of flies hitting
the Windows(TM)...

-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C