[GRASS-dev] discussion: replacing ps.map

[Jachym Cepicky]

hi,

if it sounded like I'm suggesting completly *remove* ps.map from GRASS
source, than I'm not. When I was talking about "replacement", I
thought on adding new module, which would be interface to some
external tool. ps.map would happy live with this new tool side by
side.

and to speak more concrete: mapserver produces IMHO much nicer outputs
with less effort, than ps.map does and that is, why I'm suggesting it.

thanks for your comments

jachym

2007/3/27, Sören Gebbert <soerengebbert at gmx.de>:
> Hello Jachym,
>
> Jachym Cepicky schrieb:
> > 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.
>
> AFAICT, there are no real maintainer for many raster and vector modules. Several
> modules should be improved/fixed (v.buffer, r.stats ...) and they produces some times wrong output.
> So should we remove those modules?
>
> I think not.
>
> >
> > Now, when new wxPython GUI is stepping forward, I'm thinking about,
> > how to write future GRASS mapcomposer.
>
> I'm not sure if you are able to implement the whole functionality of ps.map
> in short time. Why not looking at the code of ps.map and improve it?
> If the code is not maintainable then there would be a reason to implement it again.
>
> >
> > 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
>
> I see no reason why ps.map and interfaces to MapServer or GMT are not able
> coexistent together?
> Next question is: why produce additional dependencies in grass to create a simple ps map?
>
> >
> > 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.
>
> I would vote to improve ps.map and to create interfaces to GMT.
>
> Best regards
> Soeren
>
> >
> > 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