[GRASS-dev] discussion: replacing ps.map

Tue Mar 27 14:36:39 EDT 2007

On Tuesday 27 March 2007 10:08, tlaronde at polynum.com wrote:
> 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:

Hi Jachym, thanks for bringing up this topic- this is something that I have 
spent considerably time wondering about. Your two approaches are an excellent 
start for a possible GRASS map creation roadmap. While the utility of ps.map 
should not go unnoticed- we should work on some alternatives. 

> > 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 have found both Mapserver and GMT to be invaluable in all of my GIS work- 
although I had never thought about using Mapserver as anything other than an 
online interface to map data; using it as a map rendering engine for GRASS 
would give us all sorts of benefits:

1. label placement
2. complex symbology controlls
3. antialiasing
4. numerous output formats 
etc.

It shouldn't be all that hard to programmatic construct a map file for 
mapserver, along with all of the input files needed to create it- especially 
since Mapserver can consumer any OGR/GDAL data source.

> 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?

In response to tlaronde:

these claims are mostly wrong and completely disingenuous- you have obviously 
never used mapserver to its fullest potential. I have no argument with 
the 'lets keep everything in GRASS' approach to things - but with out a huge 
pile of developers this just wont work. I do not have the time or programming 
expertise to write a replacement for ps.map- so I have turned to GMT for map 
creation. Until there is a shiny replacement I think that others can benefit 
from this approach as well.

> 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).

This is where GMT really shines -- output is to standard PostScript files, and 
I imagine that you would be excited to hear that GMT operates cohesively 
within the UNIX philosophy. I think that you are mis-understanding the 
potential uses for mapserver and GMT:

Mapserver can create great *image* output from GRASS, while GMT can create 
great *postscript* output from GRASS.

> 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...).
>

I have tried this approach- but it can be painful to attempt working on 
complex maps in an image editing application, or worse yet in xfig. It is 
possible, but not very clean. Tidying up an otherwise good map is another 
issue- and not a considerable problem.

Returning to Jachym's original call for ideas- I think that this is an 
excellent time to be discussing such issues. There is current work on adding 
GMT vector formats to OGR by Brent Wood, and there is considerable support 
from the GMT developers. Now that we have python bindings in place (although 
not complete) we have a way to setup the GMT environment and export raster 
data in a relatively simple manner. I have written a simple article for the 
next newsletter detailing some of the current approaches to integrating 
GRASS-GMT, but I think that these approaches will be superceded by python 
bindings in the near future- bringing much more power and flexibility to map 
creation.

No need to re-invent the wheel here- lets adjust our bicycle to use some 
industry standard wheels. Mapserver and GMT are not vaporware, and will only 
get better with time.

cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341