[GRASS-dev] discussion: replacing ps.map

[Jachym_Cepicky]

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

[Thierry_Laronde]

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

[Jachym_Cepicky]

hi,

2007/3/27, roger@spinn.net <roger@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@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

[Jachym_Cepicky]

hi

2007/3/27, tlaronde@polynum.com <tlaronde@polynum.com>:

Hello,

On Tue, Mar 27, 2007 at 04:50:51PM +0200, Jachym Cepicky wrote:
> Hallo,
>
> [....]
>

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?

Correct me, if I'm wrong, but I would say, that currently, if you
would clue all part-developers together, you would not get more than 5
full time developers. Most of us have very small experience with C,
which is essential. GRASS has growed a bit, since the CERL times -
compared to this, I would expect, that the ratio between lines of code
and number of developers is significantly worst today.

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?

I do not know, what non-open source licence you are referring to?
MapServer has AFAIK MIT-like licence.

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

are we talking about same mapserver? http://mapserver.gis.umn.edu

        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?

Sorry, I did not study licences of all possible dependencies, which
mapserver has. I saw, mapserver is able to produce PDF, which is nice
format to me. I agree, PS would be better. If this would mean to
install non-free library, we have to find another solution and I thank
you for your information.

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.

Once, we will have half of ESRI's developers, we can start to write
everything from scratch.

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

I agree.

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

I do not understand this, sorry. My English is too poor for this.

jachym

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

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

[Soeren_Gebbert1]

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]

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

[Thierry_Laronde]

Hello,

On Tue, Mar 27, 2007 at 07:26:27PM +0200, Jachym Cepicky wrote:

hi

2007/3/27, tlaronde@polynum.com <tlaronde@polynum.com>:
>Hello,
>
>On Tue, Mar 27, 2007 at 04:50:51PM +0200, Jachym Cepicky wrote:
>> Hallo,
>>
>> [....]
>>
>
>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?

Correct me, if I'm wrong, but I would say, that currently, if you
would clue all part-developers together, you would not get more than 5
full time developers. Most of us have very small experience with C,
which is essential. GRASS has growed a bit, since the CERL times -
compared to this, I would expect, that the ratio between lines of code
and number of developers is significantly worst today.

You are wrong on the engineering side. The number of lines of code,
especially for GPL GRASS, is not the correct criterion, since there has
been a lot of duplication; you are still AFAIK shipping contributed and
moderately useful code; and since a huge portion of added code is on the
user graphical interface with several distinct and orphaned alternatives.

What I mean is that the difficulties you---as a team---are facing, are
difficulties you created. no-one can make excuses from a situation one
has created

[..]
>
>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.---;

are we talking about same mapserver? http://mapserver.gis.umn.edu

Yes from the very link you sent.

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

Sorry, I did not study licences of all possible dependencies, which
mapserver has. I saw, mapserver is able to produce PDF, which is nice
format to me. I agree, PS would be better. If this would mean to
install non-free library, we have to find another solution and I thank
you for your information.

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

Once, we will have half of ESRI's developers, we can start to write
everything from scratch.

I have read somewhere that, for example, KerGIS was a plan to rewrite
everything from scratch. That's absolutely wrong. I had planned to start
everything from last CERL made release. If I had to start from scratch,
there would be now undoubtely almost nothing to use. CERL GRASS was a
chance.

For GPL GRASS, you do not have to start everything from scratch. You
have to start from what does exist already. And if we put apart late
contributions on Imagery, that are a nightmare on themselves on a
maintenance point of view, the remaining, once a clarification and a
reorganization is made, is sufficiently sound to _evolve_. The key point
being that a developer touching the code does not introduce even more
noise, duplication, but tries to understand and strengthen the code
first. Being centripetal, not centrifugal.

GRASS GPL has already a "product". It should be organized---that was/is
the aim of the KerGIS reorganization---so that putting scarce
developers' resources on a component (once orthogonalization is done),
can lead to an evolution, part by part.

I doubt ESRI has hundreds of programmers (and tenths of developers). And
if this is the case, I suspect that a huge part is devoted to
integration of ESRI products on sites, or development of customizations.

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

I do not understand this, sorry. My English is too poor for this.

I don't know what part you did not understand.

If this is the first one: technically speaking, not a lot has to be done
to allow to create even more sophisticated maps with ps.map(1).

If this is the last one: GRASS GPL has, as it seems, a steering
committee. You---the team---should stop being short sighted and consider
every problem apart, and start designing a _global_ plan with a general
view of GRASS. A GIS is a _system_ that is a _consistent set of tools_
designed to work together.

Start by the big picture, and stop focusing on "details".

And if the answer is, every time something does not work immediately as
one expects: just throw this away and use something maintained by
someone else, I fear for the future of GPL GRASS...

I know that there are arseholes claiming that "with open source, you do
not need developers since what you need has already been developed by
someone". But if this curious sentence was to be true, there would be
absolutely no code to share, since nobody would ever have done the
work in the first place...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[Dylan_Beaudette1]

On Tuesday 27 March 2007 10:08, tlaronde@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

[Thierry_Laronde]

On Tue, Mar 27, 2007 at 11:36:39AM -0700, Dylan Beaudette wrote:

On Tuesday 27 March 2007 10:08, tlaronde@polynum.com wrote:
>
> 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 obviously answer about the proposal for the replacement of ps.map(1),
that is the PDF output from Mapserver, and the reference is the link
given by Jachim:

http://mapserver.gis.umn.edu/docs/howto/pdf-output

so:

---CITATION---
2 What is currently supported and not supported

Vector Layers

Layer Point: supported

Layer Line: supported

Note: Dashed lines are supported with PDFlib version 6 or greater.

Layer Polygon: supported

Note: Polygons filled with symbols are not supported.

Layer Circle : not supported

Layer Annotation: supported

Raster Layers

Raster layers are supported. Note that at this point all raster layers
are transformed to jpeg format before being written to the PDF file.

WMS Layers

Not yet supported

Surround components

Legend, scalebar are not supported.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Fonts

Standard PostScript fonts are supported. For use of other fonts (such as
truetype), see the pdflib documentation for use of UPR description files
(some notes on it are here).
---ENDCITATION---

Furthermore:

---BEGINCITATION---
3.1 Build the PDF Library

In order to have access to the PDF support in MapServer, you should
download and build the PDF library from
http://www.pdflib.com/products/pdflib/. Please follow the instructions
on the PDFLib site to build on your specific platforms.
---ENDCITATION---

If what I wrote was disingeneous you should post a bug report against
mapserver documentation...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[Glynn_Clements1]

Jachym Cepicky wrote:

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

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 have no experience with MapServer. I have a bit of experience with
GMT, and am subscribed to its mailing list.

I don't think that we should try to "integrate" GMT with GRASS beyond
facilitating export of GRASS data to formats which GMT supports.

I do think that we should provide our own facilities for generating
PostScript, and that ps.map isn't a particularly good tool. I would
much prefer a set of distinct tools, analogous to the d.* commands,
which output specific types of graphics as PostScript, and leave the
composing mainly to external tools such as Illustrator or psutils.

My first preference is to enhance the graphics architecture so that
d.* commands can generate PostScript. But this requires some
fundamental architectural changes which can't happen in the 6.x
timeframe.

--
Glynn Clements <glynn@gclements.plus.com>

[Roger_Miller1]

Jachym,

GRASS has never provided the capability to easily produce a high-quality end product. That is a long standing complaint. In the 9 years or so since I started using GRASS there has been improvement but the problem has never been given the attention that it needs.

ps.map is the one tool that GRASS offers that can produce what I think of as a good product. ps.map is difficult to use, but ps.map is the piece of the process that actually works. For the most part you need to look elsewhere for the cause of the problems you listed.

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

ps.map does a better job of placing labels than does d.paint.labels, which is basically broken -- at least in 6.2. ps.map makes good use of the paint labels facility. The shortcoming not that ps.map doesn't work but that there is no GUI for that allows you to place the labels graphically. GUI is late to come to GRASS and it hasn't made it yet to the task of map production. More on that later.

ps.map uses the same icons that are used by the GRASS vector routines. This is not a problem in ps.map, but a limitation that effects all GRASS displays. I hope that future GRASS distributions will have more comprehensive symbols sets. A symbol-editing facility would be nice, but I would rather just have a good standard symbol set.

I agree that ps.map support for legends is not very good. On the other hand, you can build a legend with other graphics software, save it as an eps file and ps.map will let you place it where you want it. I once had a simple bash script (I say "once" because I just went looking for it and couldn't find it) that created continuous color scale legends for raster maps completely through a point-and-click process using just GRASS and unix command-line facilities. It took me about 20 minutes to write that script. I'm sure someone with more skill than I have could give GRASS much better legend-building capabilities.

"Simple" is a subjective term. ps.map doesn't offer a style sheet facility but it does allow you to create and save template configurations and code blocks (e.g, for title blocks ) that can be incorporated in new products. I think that's fairly simple. I've used that ability to produce map sets with nearly 30 individual maps, all in the same basic style, and to do so over and over at an impressive rate.

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

I expect that anything you want to do will be a pain if it is to be done in a robust and internally consistent manner, but I'm not sure that it is as much of a pain as you think it is. I have a custom GUI that I've been developing for probably 6 years now, and it includes the ability to convert GRASS vector labels to paint labels configuration files, set labeling styles for entire label sets and to select and edit individual labels. It also has a configuration editing and product review capability for ps.map. It is unfortunately not consistent with the existing GRASS GUI or up to the programming standards that the GRASS developers want in submitted code.

Programming the label editing GUI probably took me a couple days work. I expect that it would take little more than that to develop a GUI for placing and editing labels in the existing GRASS GUI. One thing that probably has to be done first (if it hasn't been done yet), is to fix d.paint.labels. Either that, or the vector labeling capabilities need to be changed in revolutionary ways.

I think we agree completely that GRASS needs a better ability to produce high quality final product. I just think we are close to a good native solution and shouldn't be starting over with third-party software.

As an aside, if you need pdf output, just run postscript through ps2pdf. ps2pdf is part of the Ghostscript package.

Roger

[H_B]

Jachym Cepicky wrote:

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.

yes there is, me. (but to be honest I can only (for the most part)
justify the time to add new functions as required by my work)

2) GMT

I would welcome improved GMT import/export tools for GRASS.

I take it you are finding writing a wxPython frontend to ps.map to be a
big pain?

Hamish

[nicholas.g.lawrence]

What do you think? Any experience with some of this tools? I would
vote for MapServer.

One of the goals of OSGEO is to bring spatial projects closer
together. Could membership of OSGEO be a criterion?

nick

************************************************************
Opinions contained in this e-mail do not necessarily reflect
the opinions of the Queensland Department of Main Roads,
Queensland Transport or Maritime Safety Queensland, or
endorsed organisations utilising the same infrastructure.
If you have received this electronic mail message in error,
please immediately notify the sender and delete the message
from your computer.
************************************************************

[Trevor_Wiens2]

On Tue, 27 Mar 2007 22:22:26 +0100
Glynn Clements wrote:

Jachym Cepicky wrote:

> 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

> 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 have no experience with MapServer. I have a bit of experience with
GMT, and am subscribed to its mailing list.

I don't think that we should try to "integrate" GMT with GRASS beyond
facilitating export of GRASS data to formats which GMT supports.

I agree with this point. GMT is useful, but fairly limited. For example
right now I'm using GMT to produce a very large number of maps for a
book and it works OK, but in order to get islands to display properly I
would have to manually edit the vector file. This is poor beyond words.
As a result, I've just rendered those river sections using thicker
lines and not bothered to fill them, because it was just to much
hassle to try to find all the river islands in the GMT xy file. If we
can improve export to GMT formats, that would be nice, in the short
term, but there must be postscript generation in process colours from
directly within GRASS. As Dylan says, GMT isn't perfect (IMHO it is
pretty horrible actually) but it is the best we've got right now.

I do think that we should provide our own facilities for generating
PostScript, and that ps.map isn't a particularly good tool. I would
much prefer a set of distinct tools, analogous to the d.* commands,
which output specific types of graphics as PostScript, and leave the
composing mainly to external tools such as Illustrator or psutils.

I completely disagree with your point about composition. This is the
common approach taken, but if one looks at the latest offerings from
ESRI for professional map creation, the advantage of not having to
switch formats to something that isn't geographic becomes obvious. The
level of composition required for professional map composition isn't so
demanding that if we are going to build functions to do insets,
legends, etc, that the additional functionality would be that much
further a stretch as to be unattainable.

My first preference is to enhance the graphics architecture so that
d.* commands can generate PostScript. But this requires some
fundamental architectural changes which can't happen in the 6.x
timeframe.

This brings up a point worth thinking about. There has been much
discussion about the current image rendering in GRASS, which right now,
generates an image and displays it. People have discussed direct
drawing of vectors, etc. Now as Glynn has pointed out in the past, ps
isn't designed for fast rendering, but if display ps files were kept to
low enough resolutions, the speed of display would still be pretty fast
and then there would be no need for two library options. The quality of
the basic output could be adjusted and other tools could be used to
convert the eps or ps files to images as needed. Now this may not work,
but some time tests might be worth doing to see how much of a penalty
would be paid for taking this approach.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

[Jachym_Cepicky]

hi,
2007/3/27, Hamish <hamish_nospam@yahoo.com>:

Jachym Cepicky wrote:
>
> 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.

yes there is, me. (but to be honest I can only (for the most part)
justify the time to add new functions as required by my work)

sorry, Hamish, I did not forget you, but as you are working
everywhere, I forgot, you did also big ps.map improvements.

> 2) GMT

I would welcome improved GMT import/export tools for GRASS.

I take it you are finding writing a wxPython frontend to ps.map to be a
big pain?

Hamish

I would not say, it would be more complicated for ps.map as for any
other tool in the meaning of "code GUI for configuration file
creation". I'm just thinking about what tool to choose as back end,
which would be "powerful enough". E.g. to place legend box where you
want on the page and adjust it to your needs is a problem (I allready
wrote this: you never know, how big the legend box will be, you can
not separate each legend item and place it where ever you want and how
you wont). All this should be possible with python-mapscript (I guess
at least).

Purpose of the first e-mail was to ask more skilled developers and
some advanced users, if it would be in general bad idea looking after
some exteral tool and maybe find out, what would the majority advise.

IMHO we can only hard advice a general user, that she should use e.g.
inkscape for custom legend creation.

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

[mlennert]

On 28/03/07 06:40, Trevor Wiens wrote:

On Tue, 27 Mar 2007 22:22:26 +0100
Glynn Clements wrote:

I do think that we should provide our own facilities for generating
PostScript,

+1

and that ps.map isn't a particularly good tool.

In spite of some of its shortcomings, it has always rendered me very good service...

I would
much prefer a set of distinct tools, analogous to the d.* commands,
which output specific types of graphics as PostScript, and leave the
composing mainly to external tools such as Illustrator or psutils.

I completely disagree with your point about composition. This is the
common approach taken, but if one looks at the latest offerings from
ESRI for professional map creation, the advantage of not having to
switch formats to something that isn't geographic becomes obvious. The
level of composition required for professional map composition isn't so
demanding that if we are going to build functions to do insets,
legends, etc, that the additional functionality would be that much
further a stretch as to be unattainable.

I agree with Trevor here. We should offer a composition tool in GRASS, even it is quite basic. IMO, it makes the workflow much more obvious for most people.

My first preference is to enhance the graphics architecture so that
d.* commands can generate PostScript. But this requires some
fundamental architectural changes which can't happen in the 6.x
timeframe.

Well, can't we start a 7.x branch now for experimenting such fundamental changes ? I think this is probably the most important (and necessary) change to GRASS for the near future and we should go ahead with it. (Says he who won't be able to help much in implementing...)

Thierry, I have a very vague memory that you said something about KerGIS being able to directly produce vectorized output. Is this true ? How do you do this ?

Moritz

[Thierry_Laronde]

On Wed, Mar 28, 2007 at 10:28:42AM +0200, Moritz Lennert wrote:

Thierry, I have a very vague memory that you said something about KerGIS
being able to directly produce vectorized output. Is this true ? How do
you do this ?

By using the legacy RASTERLIB now called DRAWLIB in KerGIS. The
documentation about the library is misleading. It is not raster oriented
if you take juste the library that is just an API and a communication
facility to monitors. The API is a drawing API: you draw not only raster
images, but lines, polylines etc.

In KerGIS, there is only one driver: the X11 one. And it uses the X11
vector drawing XLIB functions for lines etc.

In this sense, it is not difficult to implement a psdriver.

And, as I have already wrote in another thread, once you combine
vectorial icons (in KerGIS---internal version for now---these are done
by creating a font of symbols) keeping a description of the icons in a
format that can be easily rendered to eps (I chose MetaPOST/METAFONT),
and extending simply v.digit(1) to draw the bounding box of labels
(first render via MetaPOST whatever you want in TeX and retrieve the
size of the bounding box for display), the DRAWLIB has already anything
to scale and rotate glyphes, so a simple WYSIWYG could be easily made.

In KerGIS, I have just slightly extended the legacy capabilities. The
documentation about the DRAWLIB (legacy RASTERLIB) shall be reworked,
but the code is not bas as is.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[H_B]

Jachym Cepicky wrote:

IMHO we can only hard advice a general user, that she should use e.g.
inkscape for custom legend creation.

FWIW, some time ago I added a short note in the ps.map/vlegend help page
about it being possible to make a custom legend with the rectangle,
symbol, and text tools. It's not an instant solution, but it gets the
job done if you want something custom.

Hamish

[Radek_Barton1]

Hello everyone.

If I may produce my opinion, I would tell that there should be discussion
about what features are necessary or wanted to introduce to "new" ps.map and
then consider if it is better to add these fetures to existing code or write
a new one.

I completely agree with Thierry's note about using number of code lines as a
metric and about responsibility with creation of difficulties...

ps.map implementation would be great theme for bachelor or diploma work and I
try to ask my friends who has not decided for some work yet to do this.
Actually I was planning this kind of project for my work but I decided
differently as you may notice in GAL flamewar :-).

PS: Although there is no noticeable move in GAL project since last few weeks,
project is still living and main piece of work will be done during summer. I
just have a lot of work with school theese days.

PPS: Sören: I have made some discussion proposals at GAL's discussion forum
and I'd like to know your opinion about them.

--
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz

[Glynn_Clements1]

Trevor Wiens wrote:

> My first preference is to enhance the graphics architecture so that
> d.* commands can generate PostScript. But this requires some
> fundamental architectural changes which can't happen in the 6.x
> timeframe.

This brings up a point worth thinking about. There has been much
discussion about the current image rendering in GRASS, which right now,
generates an image and displays it. People have discussed direct
drawing of vectors, etc. Now as Glynn has pointed out in the past, ps
isn't designed for fast rendering, but if display ps files were kept to
low enough resolutions, the speed of display would still be pretty fast
and then there would be no need for two library options.

PostScript data doen't have a "resolution".

The biggest performance hit for using PostScript is that there
typically isn't a "fast path" for single-pixel lines.

The general PostScript line-drawing algorithm is quite complex, as it
has to allow for dash patterns, join styles (including mitre control)
and caps. The algorithm essentially converts each dash to an area,
then fills it.

The quality of
the basic output could be adjusted and other tools could be used to
convert the eps or ps files to images as needed. Now this may not work,
but some time tests might be worth doing to see how much of a penalty
would be paid for taking this approach.

To conduct such a test, generate a PostScript representation of a
vector map using ps.map, then compare the time taken to render it to
an image with "gs" against using d.vect with direct rendering.

It might be worth trying with a line width of zero; PostScript allows
this as a special case:

  A line width of 0 is acceptable, and is interpreted as the
  thinnest line that can be rendered at device resolution - 1
  device pixel wide. However, some devices cannot reproduce
  1-pixel lines, and on high-resolution devices, they are nearly
  invisible. Since the results of rendering such "zero-width"
  lines are device-dependent, their use is not recommended.

It's conceivable that some drivers might implement a fast path for
zero-width solid lines.

--
Glynn Clements <glynn@gclements.plus.com>