[GRASS5] ps.map, p.map and p.map.new

  It seems to me, in my naivety, that there is extensive overlap among
ps.map, p.map and p.map.new. Is there value in combining these? How about
combining the paint category with the postscript category -- and calling the
combination the output (o.) category?

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1541
max: 0

On Wed, Apr 12, 2000 at 09:49:40PM -0700, Rich Shepard wrote:

  It seems to me, in my naivety, that there is extensive overlap among
ps.map, p.map and p.map.new. Is there value in combining these? How about
combining the paint category with the postscript category -- and calling the
combination the output (o.) category?

Hi Rich,

to make it more complex:
ps.map.new is also there!

I reordered the src structure in GRASS 5:

src/ps.map/ps.map.old
               cmd, inter, ...
src/ps.map/ps.map.new
               cmd, inter, ...

Suggestion:
- remove p.map
- remove ps.map.old

Rename p.map.new to p.map
Rename ps.map.new to ps.map

The Paint driver is required for Internet-GRASS.
(GRASSlinks etc.)

Regards

Markus Neteler

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1521
max: 0

On Thu, 13 Apr 2000, Markus Neteler wrote:

to make it more complex:
ps.map.new is also there!

Markus,

  I wondered about that, but I didn't see it.

Suggestion:
- remove p.map
- remove ps.map.old

Rename p.map.new to p.map
Rename ps.map.new to ps.map

  I don't understand the differences. But, I am curious why we cannot have a
single output/print module which encompases the variations in both p. and
ps. Another variable could determine the output device (screen, html page,
printer, plotter) and make the appropriate adjustments. In my opinion, this
makes it much easier to maintain/improve and to use.

  I've read the man pages for ps.map, p.map/p.map.new I see some differences
among them, but nothing on the man pages explains when to use one or the
other -- and why.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2156
max: 0

On Thu, Apr 13, 2000 at 09:39:04AM -0700, Rich Shepard wrote:

On Thu, 13 Apr 2000, Markus Neteler wrote:

> to make it more complex:
> ps.map.new is also there!

Markus,

  I wondered about that, but I didn't see it.

You can see in CVS, you will see in forthcoming GRASS 5 beta7.

> Suggestion:
> - remove p.map
> - remove ps.map.old
>
> Rename p.map.new to p.map
> Rename ps.map.new to ps.map

  I don't understand the differences. But, I am curious why we cannot have a
single output/print module which encompases the variations in both p. and
ps. Another variable could determine the output device (screen, html page,
printer, plotter) and make the appropriate adjustments. In my opinion, this
makes it much easier to maintain/improve and to use.

  I've read the man pages for ps.map, p.map/p.map.new I see some differences
among them, but nothing on the man pages explains when to use one or the
other -- and why.

Well, p.* and ps.* are have the same purpose, but different output
formats. If being merged, as you suggested, it should become

o.map

(new "output" command class).

A flag to select the output format would be required. Say:
-f ps
-f ppm
-f ?

That might be a good idea, if not too complicated for the export
formats.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2129
max: 0

On Thu, Apr 13, 2000 at 06:57:01PM +0100, Markus Neteler wrote:

On Thu, Apr 13, 2000 at 09:39:04AM -0700, Rich Shepard wrote:
> On Thu, 13 Apr 2000, Markus Neteler wrote:

> I don't understand the differences. But, I am curious why we cannot have a
> single output/print module which encompases the variations in both p. and
> ps. Another variable could determine the output device (screen, html page,
> printer, plotter) and make the appropriate adjustments. In my opinion, this
> makes it much easier to maintain/improve and to use.

GRASS is pretty modular so far. One module for each format sound
a good way to keep it modular.
A script or gui might run these modules more comfortably and if they
have common functions they should be moved into a library.

Other project really like output and input format plugins and even
modify their project to be able to have them.

> I've read the man pages for ps.map, p.map/p.map.new I see some differences
> among them, but nothing on the man pages explains when to use one or the
> other -- and why.

Well, p.* and ps.* are have the same purpose, but different output
formats. If being merged, as you suggested, it should become

o.map

(new "output" command class).

A flag to select the output format would be required. Say:
-f ps
-f ppm
-f ?

That might be a good idea, if not too complicated for the export
formats.

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

On Thu, 13 Apr 2000, Markus Neteler wrote:

Well, p.* and ps.* are have the same purpose, but different output
formats. If being merged, as you suggested, it should become

o.map

(new "output" command class).

A flag to select the output format would be required. Say:
-f ps
-f ppm
-f ?

  YES! And the page size should be moved from $GISENV to here, too. Put all
the pieces in one place.

  Remember the audience: it's not the 20-year veterans of GRASS, it's the
new user in every field. Especially if we want to convert Windows users (to
either the winGRASS version or to a UNIX version), we need to make it
logical, rational and with a shallow learning curve.

  You have my vote on this change. :slight_smile:

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 2085
max: 0

I've seen references to winGRASS on this list, but didn't see much on this
topic at the Baylor pages. Any pointers?

TIA,

Jonathan Byron
Assistant Professor, Geography
Jacksonville University, FL
jbyron@ju.edu, abyron@mindspring.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1356
max: 0

On Thu, Apr 13, 2000 at 11:12:39AM -0700, Rich Shepard wrote:

On Thu, 13 Apr 2000, Markus Neteler wrote:

> Well, p.* and ps.* are have the same purpose, but different output
> formats. If being merged, as you suggested, it should become
>
> o.map
>
> (new "output" command class).
>
> A flag to select the output format would be required. Say:
> -f ps
> -f ppm
> -f ?

  YES! And the page size should be moved from $GISENV to here, too. Put all
the pieces in one place.

  Remember the audience: it's not the 20-year veterans of GRASS, it's the
new user in every field. Especially if we want to convert Windows users (to
either the winGRASS version or to a UNIX version), we need to make it
logical, rational and with a shallow learning curve.

Well, Bernhard isn't wrong, but you are also right here.
The number of modules needs to be reduced a bit.

But: All modules *must* be fully scriptable.

  You have my vote on this change. :slight_smile:

But how does the job ? :slight_smile: Not me...

Cheers

markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1868
max: 0

Jonathan,

WinGRASS is at this time in the very experimental stages.

http://www/~grass/5.0winport.info.html

Has the files you need. At this time however, graphics are
not supported. If you need any additional info, feel free to
email me.

Bruce

--
Bruce Byars
GRASS Dev. Team
CAGSR - Baylor Univ.

abyron wrote:

I've seen references to winGRASS on this list, but didn't see much on this
topic at the Baylor pages. Any pointers?

TIA,

Jonathan Byron
Assistant Professor, Geography
Jacksonville University, FL
jbyron@ju.edu, abyron@mindspring.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1356
max: 0

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1854
max: 0

On Thu, Apr 13, 2000 at 08:11:20PM +0100, Markus Neteler wrote:

On Thu, Apr 13, 2000 at 11:12:39AM -0700, Rich Shepard wrote:
> On Thu, 13 Apr 2000, Markus Neteler wrote:

The number of modules needs to be reduced a bit.

Not necessarily the number, but the number the user interacts with.
Like I said it is possible to have one module per output format.
this also sounds like a healthy seperation from the developer
point of view.

There is no reason why there should not be one module which drives them
all.

  Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

On Mon, Apr 17, 2000 at 09:03:30AM +0200, Bernhard Reiter wrote:

On Thu, Apr 13, 2000 at 08:11:20PM +0100, Markus Neteler wrote:
> On Thu, Apr 13, 2000 at 11:12:39AM -0700, Rich Shepard wrote:
> > On Thu, 13 Apr 2000, Markus Neteler wrote:

> The number of modules needs to be reduced a bit.

Not necessarily the number, but the number the user interacts with.
Like I said it is possible to have one module per output format.
this also sounds like a healthy seperation from the developer
point of view.

There is no reason why there should not be one module which drives them
all.

Hi Bernhard,

this is a good idea: We can hide modules in $GISBASE/etc (there
are already several hidden modules) and call them by a
general output module.

Any volunteers out there :slight_smile: ?

Regards

  Markus

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1735
max: 0

On Mon, 17 Apr 2000, Bernhard Reiter wrote:

There is no reason why there should not be one module which drives them
all.

Bernhard,

  My point exactly. Behind the curtain, there may still be a half-dozen
function calls. But, the API is a single call which includes specifications
for the output device, size and other variables.

  This makes it much easier for the user and the developer, both.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 1762
max: 0

Markus Neteler wrote:

On Mon, Apr 17, 2000 at 09:03:30AM +0200, Bernhard Reiter wrote:
> On Thu, Apr 13, 2000 at 08:11:20PM +0100, Markus Neteler wrote:
> > On Thu, Apr 13, 2000 at 11:12:39AM -0700, Rich Shepard wrote:
> > > On Thu, 13 Apr 2000, Markus Neteler wrote:
>
> > The number of modules needs to be reduced a bit.
>
> Not necessarily the number, but the number the user interacts with.
> Like I said it is possible to have one module per output format.
> this also sounds like a healthy seperation from the developer
> point of view.
>
> There is no reason why there should not be one module which drives them
> all.
Hi Bernhard,

this is a good idea: We can hide modules in $GISBASE/etc (there
are already several hidden modules) and call them by a
general output module.

Any volunteers out there :slight_smile: ?

Well, That is my next grass project :slight_smile: A full interactive map
composer system (with a tcl/tk interface, so it can also be run
on the windows version of grass). The actual state is paper and
pencil thinking, list of desired functionnalities, and the desire
for a modular/customisable/reusable system.

In brief :

- interactive placement of the differents modules (map, legend,
  frames, lines, coordinates cross, texts, images, ...) on the map,
  with previsualisation (à la nviz) : modules can overlap like
  windows on a screen.
- layer stack for printing on the same map more than one raster,
  any number of vector files or site files in a selected order
- icon editor for sites representation
- icon size/color/orientation/type may be linked to site attributes
- line representation (width, dashed/dotted/symbols, inside/ouside
  color, non symetrical aspect) parametrable by line attributes
- area filling either with grass color, or with pattern/color
  defined in a library (like line representation or icon)
- any defined map may be resused in a frame on an other map (copy/
  cut/paste) => "map library" for mapping different places with
  the same overall aspect (region not linked to representation).
  The layout of a map can be saved, recalled and quickly modified
  for an other output. (in $LOCATION/map ?)
- automaticaly created, but customisable legend
- scale bar/north arrow as icon
- output : originaly postscript only, including the icons format,
  with the use of gs to make images, but maybe also a xfig output
  (in many files if there is rasters/images on the output) and the
  use of xfig as a graphic editor for symbols ?
- Paper coordinate system for the placement, map coordinate system
  inside each map and for the text inside it.
- Paper size... well, any + a list of well known formats (metric+US)
- The module for the map itself should be usable as a replacement
  for d.rast/vect/site... (some kind of basic Mapinfo or Arcview ?)

What else ? Anybody else interested ?

--
Michel Wurtz ENGEES - CEREG
                1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
                Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97

----------------------------------------
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 4727
max: 0

On Tue, Apr 18, 2000 at 11:37:32AM +0200, Michel Wurtz - ENGEES/CEREG wrote:

Markus Neteler wrote:

A full interactive map
composer system (with a tcl/tk interface, so it can also be run
on the windows version of grass).

If you want a portable window system python/tk or
wxpython would also be available. (www.python.org)
(alldunn.com/wxPython).

What else ?

You have to deal with fonts somehow.

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)