[GRASS-dev] discussion: replacing ps.map

Jachym Cepicky jachym.cepicky at gmail.com
Tue Mar 27 13:12:29 EDT 2007


hi,

2007/3/27, roger at spinn.net <roger at spinn.net>:
>
> What capability are you looking for that ps.map can't provide?  I've been
> able to produce some fairly sophisticated maps with ps.map, and the more
> recent revisions increase its capability quite a bit.

just few examples:  better label placement, easy icons creation,
better support for legends, simple style definition

>
> Neither of the packages you're talking about is a drop-in replacement for
> ps.map.  If any of them requires work then I'm not sure why that work
> shouldn't be done on ps.map.  Why throw away the work already done with
> ps.map and add additional dependencies?

because someone else did this job allready and IMHO better

GRASS great analytical tool. Map creation is pain even if we would
script any gui around it (which would be pain too).

jachym

>
>
> Roger
>
> Jachym Cepicky writes:
>
> > 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).
> >
> > Size (ubuntu package): 7548kB + python-mapscript 1500 kB
> >
> > GMT
> > ------
> > Sorry, I do not know much about GMT. I just know, this is a tool,
> > which is able to create nice maps and there are already some bindings
> > for GRASS. I would say, it has not as large community as MapServer
> > has.
> >
> > Size (ubuntu package): 9904 kB
> >
> > Both solutions are introducing new dependency. The benefit would be
> > "outsourcing" of our efforts. Why to reinvent a wheel, if there are
> > already tools, which are able to produce nice maps, tested and used?
> >
> > What do you think? Any experience with some of this tools? I would
> > vote for MapServer.
> >
> > Jachym
> > --
> > Jachym Cepicky
> > e-mail: jachym.cepicky gmail com
> > URL: http://les-ejk.cz
> > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub




More information about the grass-dev mailing list