[GRASS5] Problems with vector import, and a suggestion

GRASS GRASS developer
1

Hi GRASS developers,

I just killed 3 days to import a rather simple (86 polygons, 6 holes) shape
file into GRASS. In the process I lost some hair :-), but hopefully also
gained some insight which I would like to share with anyone who is willing to
read this...

I am using GRASS 5.0, the HEAD branch from CVS, compiled on Feb 4 2002.

1. I first tried v.in.shape (and v.in.shape.pg). v.in.shape failed for both a
line and a polygon shape files. It generated a lot of messages like:
   WARNING: line 5466 label: 217 matched another label: 455.
  Failed to attach an attribute (category 471) to a line.
but, more importantly, the geometry was completely scrambled for both line
and polygon shapes.

2. Next I tried v.in.arc (and v.in.arc.pg). I had to do some work in ARC/INFO
to convert polygon shape file to correct coverage, then UNGENERATE lines and
polygon labels. Here I got correct geometry, but polygon ids (dig_att file)
were screwed up:

  2.1 "v.in.arc type=polygon lines_in=st.lin points_in=st.lab vector_out=st"
worked for geometry, but dig_att was set up incorrectly
  
  2.2 "v.in.arc.pg" did the same thing. In addition, it segfaulted when trying
to import a dbf file. But the same dbf file was imported in Postgres with
"pg.in.dbf" with no problem at all.

3. Finally, "m.in.e00" did the job for me. It created correct geometry AND
built correct dig_att file. Together with "pg.in.dbf" for the associated
attribute file (ARC's .PAT file saved in TABLES with INFODBASE, then opened
and re-exported in ArcView) I now got a complete vector file with data. I am
finally able to map the attributes as described in the GRASS/Postgres
tutorial
(http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/src.garden/grass.postgresql/tutorial/index.html).

Resume and suggestions

It's been quite a hair-pulling experience. Of course, it's possible that I
did some things wrong, but I tried these and related commands (v.support,
etc) in many different ways and quite a few times. I am trying to think what
to do to make this sort of vector import easier...

Here are some suggestions. I apologize in advance if I missed something or
am completely off on something -- let me know.

1. My experience has been that quality of modules varies greatly. Some work
fine, some are buggy and some just do not work. What makes the situation
worse for the user is that modules seem to overlap and duplicate each other,
and it's not clear which one to use (for example in my case, besides the 5
modules mentioned above there are also v.import and v.in.arc.poly --
confusing to say the least!)

In the long run modules with similar functionality will have to be merged,
some discarded. In the meantime, it seems a useful clean-up strategy would be
to:
  (a) Establish sort of a standard (e.g. for GRASS 5.1) -- a set of
requirements that modules have to comply with (coding standards, interface,
up-to-date and detailed help page, etc.)
  (b) Select a few most useful modules and pull them up to this standard
  (c) Identify those modules that conform to the standard in the help pages.
They will be seen as reliable, get more testing, while others may be
merged/upgraded gradually.

2. Some sort of functional listing of modules in the help pages would be
nice, maybe even based on classification used for TclTk interface.

3. No specific suggestion here, just complaining :slight_smile: about handling of vector
attributes. Associating vectors with attributes through point markers used in
dig_att files just seems too difficult and unnatural to me. May be I am
missing something here... I don't know how it's done in 5.1.

Sorry for the long mail :slight_smile:

Aleksey

2

Aleksey Naumov wrote:

> Hi GRASS developers,
>
> I just killed 3 days to import a rather simple (86 polygons, 6 holes) shape
> file into GRASS. In the process I lost some hair :-), but hopefully also
> gained some insight which I would like to share with anyone who is willing to
> read this...
>
> I am using GRASS 5.0, the HEAD branch from CVS, compiled on Feb 4 2002.
>
> 1. I first tried v.in.shape (and v.in.shape.pg). v.in.shape failed for both a
> line and a polygon shape files. It generated a lot of messages like:
> WARNING: line 5466 label: 217 matched another label: 455.
> Failed to attach an attribute (category 471) to a line.
> but, more importantly, the geometry was completely scrambled for both line
> and polygon shapes.
>

v.in.shape has been till now really an experimental module whose
development has been driven by on-going attempts to deal with the many
errors in linework that is so common in most of the desktop formats that
are based on whole polygon coverages, eg. ESRI shapefile and MapInfo
MIF. That isn't to say that the errors caused in using these modules is
always or solely due to bad files. They have been hacked and hacked over
as we have found, and had to deal with, new layers of problems in the
structure of shape files, etc. (Question: should we bother with trying to fix
bad linework?). So by now the existing modules are really in an unmaintainable state. The good news is that replacements in the stable branch for the v.*.shape and v.*.mif modules are nearly ready, and should be available for the next snapshot in the pre-release sequence for GRASS5.0. These will probably at first just duplicate the errors in the current modules, but it should be much easier to debug and maintain them.

> 2. Next I tried v.in.arc (and v.in.arc.pg). I had to do some work in ARC/INFO
> to convert polygon shape file to correct coverage, then UNGENERATE lines and
> polygon labels. Here I got correct geometry, but polygon ids (dig_att file)
> were screwed up:
>

Using Arc/Info is the critical step here. Ungen' files are in a structured topological format, like GRASS files, so import should be a simple matter. Don't know why it doesn't handle atts properly. maybe we need to look at this as well.

>[...]
>
> 3. Finally, "m.in.e00" did the job for me. It created correct geometry AND
> built correct dig_att file. Together with "pg.in.dbf" for the associated
> attribute file (ARC's .PAT file saved in TABLES with INFODBASE, then opened
> and re-exported in ArcView) I now got a complete vector file with data. I am
> finally able to map the attributes as described in the GRASS/Postgres
> tutorial
> (http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/src.garden/grass.postgresql/tutorial/index.html).
>

Again a direct transfer from the A/I format which is similar to GRASS.

>
> Resume and suggestions
>
> It's been quite a hair-pulling experience. Of course, it's possible that I
> did some things wrong, but I tried these and related commands (v.support,
> etc) in many different ways and quite a few times. I am trying to think what
> to do to make this sort of vector import easier...
>
> Here are some suggestions. I apologize in advance if I missed something or
> am completely off on something -- let me know.
>
> 1. My experience has been that quality of modules varies greatly. Some work
> fine, some are buggy and some just do not work. What makes the situation
> worse for the user is that modules seem to overlap and duplicate each other,
> and it's not clear which one to use (for example in my case, besides the 5
> modules mentioned above there are also v.import and v.in.arc.poly --
> confusing to say the least!)
>

These stem from early attempts at integration or to deal with problems arising from the polygon coverages which were a new format at the time.

> In the long run modules with similar functionality will have to be merged,
> some discarded. In the meantime, it seems a useful clean-up strategy would be
> to:
> (a) Establish sort of a standard (e.g. for GRASS 5.1) -- a set of
> requirements that modules have to comply with (coding standards, interface,
> up-to-date and detailed help page, etc.)
> (b) Select a few most useful modules and pull them up to this standard
> (c) Identify those modules that conform to the standard in the help pages.
> They will be seen as reliable, get more testing, while others may be
> merged/upgraded gradually.
>

It is timely you should raise these points. There is a plan, beginning to take shape now for GRASS 5.1, to move much of the processing functionality into library routines, and just have the 'modules' as high level interfaces that integrate these functions to perform specific tasks. It has been suggested also to have the modules written in a scripting or 'macro' language like Python, for easier development.

Standards relating to such things as options are also being developed.

> 2. Some sort of functional listing of modules in the help pages would be
> nice, maybe even based on classification used for TclTk interface.
>
> 3. No specific suggestion here, just complaining :slight_smile: about handling of vector
> attributes. Associating vectors with attributes through point markers used in
> dig_att files just seems too difficult and unnatural to me. May be I am
> missing something here... I don't know how it's done in 5.1.
>

It is, admittedly, a weak procedure. It just used to be standard, and was traditionally used by Arc/Info, which was the standard GRASS had to look to for compatibilty with its main competitors. This by the way is why you get the :

WARNING: line 5466 label: 217 matched another label: 455

warnings. The labels get muddled up with the wrong lines/points/areas if something goes wrong. And a bad line can contaminate in this way many good ones, so you can get a silent error and not notice.

GRASS 5.1 does away with this, and codes the categories (or at least indices) into the main binary file that contains the vector lines. The actual data is stored in a RDBMS. GRASS has the in-built dbmi interface that will be the default.

We should retain an ability to remain compatible with older versions and still have the ability to apply area points and their attributes, as the idea is that an `area point' is a representative point of the interior region of a polygon. Say v.in/out.atts.

The lamest choice of all however would be to go down the road of co-sequencing as MIF/MID and shapefile do. This is unstable as a means for transferring data (ie an interchange format), and disastrous when used as the main method of data storage in your application.

David

3

Aleksey Naumov wrote:

3. Finally, "m.in.e00" did the job for me. It created correct geometry AND
built correct dig_att file. Together with "pg.in.dbf" for the associated
attribute file (ARC's .PAT file saved in TABLES with INFODBASE, then opened
and re-exported in ArcView) I now got a complete vector file with data. I am
finally able to map the attributes as described in the GRASS/Postgres
tutorial

A feature of m.in.e00 (probably not enough explained in the man page)
is that m.in.e00 imports also the attribute in .PAT and put them in
dig_cat : each attribute is in a category file named after the created
vector file name followed by a dot and the name of the attribute (so you
have as many categories file than attributes in the arc/info coverage.

Ex : if you extract the file land.e00, and that the .PAT file has the user
defined attributes OWNER and VALUE, m.in.e00 will create :
  $LOCATION/dig/land (the vector file itself)
  $LOCATION/dig_att/land (attribute file)
  $LOCATION/dig_plus/land (topology)
  $LOCATION/dig_cats/land.owner (first attribute)
  $LOCATION/dig_cats/land.value (second attribute)

If you want draw the file according to one of the attributes, you will
have to put a symbolic link on the cats file. Ex: If you want have for
the category the second attribute, run
  ln -s $LOCATION/dig_cats/land.value $LOCATION/dig_cats/land

After that, d.area (or whatever its name, this a little bit confusing
thoses days :wink: let you draw a map showing the land values with a
beautifull color ramp !

m.in.e00 attempts to be clever :slight_smile: so if there is only one attribute in
the arc/info coverage, the dig_cats file created is only named after
the vector file name (no dot, no suffix)

Some other feelings, not all related... :

I know, some people would like a m.in.e00.pg program, but i am a little
reluctant to do that : there is far too many functions in grass. I'm
afraid that this will confuse beginners. Grass is too much stucked in
the early implementation choice, mainly the display system : it's a
hack on a hack on an old system designed before the standardisation of
windows systems (X-windows + MSWindows + MacOS cover actually more
than 99% of the GUI market). So I am working on an graphic
interface like ArcView or Mapinfo for Grass. Curently, I have finished
the specs but hesitate for the implementation between tk (nice,
portable, but what about performances ?), kde or at least the Qt lib
(portable on windows, but not enough gpl for many peoples) and Gnome
(very gpl, but yet instable, and what about windows ?). If there is
a nice and user friendly user-interface, it is important to have it
working on Windows.

I don't want a (once again) long thread about the comparative merits
of Tcl/Tk, Gtk and Qt, but if some of you have some experience with
more than one of those tools, I will be happy to have comments in my
private mailbox. I will summarise and reveal the choice I finaly made
in this mailing list !

On the other hand, I believe much in postgis, which could be a nice
"container" for all vector and site stuff in grass, with only an
import/export function for the actual vector and site format,
leaving only rasters in flat files. I will be specialy interested
by what Radim think about that and the possible impact on grass51
vector format.

Another solution is a "unified" interface for databases : not only for
postgresql, but also dbf or simple ascii tables (like site files)...

Well, I was long, sorry...

Regards,

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

4

Michel Wurtz wrote:

I know, some people would like a m.in.e00.pg program, but i am a little
reluctant to do that : there is far too many functions in grass. I'm
afraid that this will confuse beginners. Grass is too much stucked in
the early implementation choice, mainly the display system : it's a
hack on a hack on an old system designed before the standardisation of
windows systems (X-windows + MSWindows + MacOS cover actually more
than 99% of the GUI market). So I am working on an graphic
interface like ArcView or Mapinfo for Grass. Curently, I have finished
the specs but hesitate for the implementation between tk (nice,
portable, but what about performances ?), kde or at least the Qt lib
(portable on windows, but not enough gpl for many peoples) and Gnome
(very gpl, but yet instable, and what about windows ?). If there is
a nice and user friendly user-interface, it is important to have it
working on Windows.

I don't want a (once again) long thread about the comparative merits
of Tcl/Tk, Gtk and Qt, but if some of you have some experience with
more than one of those tools, I will be happy to have comments in my
private mailbox. I will summarise and reveal the choice I finaly made
in this mailing list !

Some comments:

1. Have you considered using WxWindows? This provides a layer on top
of the platform's native toolkit(s). This may provide better
integration than a toolkit which is built from scratch on top of the
platform's lowest-level components.

2. Qt requires C++, which is a disadvantage from a portability
standpoint. Also, I still don't quite understand TrollTech's licensing
position.

3. The most recent version of XDRIVER can use a window supplied by the
application, rather than creating its own (via the XDRIVER_WINDOW
environment variable). This won't work for the libW11 port, but
Windows should really have a native driver anyway.

4. By GUI, I hope you're talking about a front-end (in the sense of
tcltkgrass), and not a monolithic program. I've previously outlined
the serious problems with the latter, but can clarify/elaborate if
necessary.

5. Right now, the most useful GUI tool would, IMHO, be something to
manage display "layers".

Each layer would effectively be a d.* command. Layers could be added,
removed, re-ordered, temporarily disabled and re-enabled, and changed.
The program would automatically refresh the display when the state
changes. Other features could include:

+ Save/load the current state
+ Render to an image, via the PNG driver
+ Print, via ps.map (although that has some limitations)
+ Zoom/pan, i.e. change the current region

This could be either be a standalone program, or added to tcltkgrass.

6. I'm looking into replacing the display architecture eventually;
PostScript is the main contender, with SVG and OpenGL as alternative
options. This won't happen soon, but I'd welcome comments regarding
the design of any future display architecture.

--
Glynn Clements <glynn.clements@virgin.net>

5

Glynn Clements wrote:

1. Have you considered using WxWindows? This provides a layer on top
of the platform's native toolkit(s). This may provide better
integration than a toolkit which is built from scratch on top of the
platform's lowest-level components.

Well, I've heard of, but have not studied it in details...

2. Qt requires C++, which is a disadvantage from a portability
standpoint. Also, I still don't quite understand TrollTech's licensing
position.

It's quite complicated, and to be honest, I don't understand all :slight_smile:

3. The most recent version of XDRIVER can use a window supplied by the
application, rather than creating its own (via the XDRIVER_WINDOW
environment variable). This won't work for the libW11 port, but
Windows should really have a native driver anyway.

4. By GUI, I hope you're talking about a front-end (in the sense of
tcltkgrass), and not a monolithic program. I've previously outlined
the serious problems with the latter, but can clarify/elaborate if
necessary.

5. Right now, the most useful GUI tool would, IMHO, be something to
manage display "layers".

Each layer would effectively be a d.* command. Layers could be added,
removed, re-ordered, temporarily disabled and re-enabled, and changed.
The program would automatically refresh the display when the state
changes. Other features could include:

+ Save/load the current state
+ Render to an image, via the PNG driver
+ Print, via ps.map (although that has some limitations)
+ Zoom/pan, i.e. change the current region

This could be either be a standalone program, or added to tcltkgrass.

In fact, I started by looking at something less frustrating than ps.map.
I consider actualy that two modules are necesary : the first is a kind
of enhanced tcltkgrass (use external functions, except for drawing) ;
the second is a map manager (maps, legend, title, text, images, order of
drawing (so it's easy to make overlays), and probably some recusrive
feature (map in a map). You should naturally be able to load/save
a map (layout, content, and definition), and output the final result as
a ps file, an image (albeit this may be managed externally by ghostscript),
or an xfig file.

A short list of what I'm dreaming of as a display tool :
+ manage layers (add, remove, re-order)
+ save/load "view" created (list of layer, legend and extent)
+ enhanced drawing capabilities:
  - color transparency for raster,
  - style for lines (including parallel lines for roads)
  - fill area with color or patterns, and transparency
  - style for sites (pixmap or vectorized symbols, the later being orientable)
+ view created usable in the map manager for output
+ query on the map (raster and vector) and (eventually with an
  external function) manage the attribute of selected object(s)
+ mesure on the image
+ draw line on it and pass it to external application (profil in a DEM,...)
+ at a second time, add point/line area digitizing
+ map manager must work with mouse, but let you fix all positions or
  dimensions with figure (this ensures a perfect map)

everything else should be done by external modules (import/export,
analysis, raster, area/line/point style edition, etc...)

6. I'm looking into replacing the display architecture eventually;
PostScript is the main contender, with SVG and OpenGL as alternative
options. This won't happen soon, but I'd welcome comments regarding
the design of any future display architecture.

Well, I like the idea of postscript. The only drawback I see is that
poor performance in redrawing are to be expected if you have a lot of
lines to draw, and that you must include a postscript interpreter (or
call an external one, which is also not very good for performances)

In the meantime, I don't have any time (all this was dreamed when I
woke up during the night and hesitate to get off the bed :wink:

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

6

Michel,

First of all, thanks for the good work on m.in.e00, it is the only import
module that consistently worked for me. I am sure glad I can see my soil map
now :slight_smile:

A feature of m.in.e00 (probably not enough explained in the man page)
is that m.in.e00 imports also the attribute in .PAT and put them in
dig_cat : each attribute is in a category file named after the created
vector file name followed by a dot and the name of the attribute (so you
have as many categories file than attributes in the arc/info coverage.

Ex : if you extract the file land.e00, and that the .PAT file has the user
defined attributes OWNER and VALUE, m.in.e00 will create :
  $LOCATION/dig/land (the vector file itself)
  $LOCATION/dig_att/land (attribute file)
  $LOCATION/dig_plus/land (topology)
  $LOCATION/dig_cats/land.owner (first attribute)
  $LOCATION/dig_cats/land.value (second attribute)

If you want draw the file according to one of the attributes, you will
have to put a symbolic link on the cats file. Ex: If you want have for
the category the second attribute, run
  ln -s $LOCATION/dig_cats/land.value $LOCATION/dig_cats/land

No, I think it's explained fine in the help page. Maybe include an example
like the one above, to make it more concrete. Also, maybe mention the 'ln -s'
as an alternative to 'cp'.

Another question on the help page. It says:

"...
The attribute of each "vector" object (points, line, and polygon) is the
Arc/Info coverage-ID (and not the coverage-#)."

but:

"...
Flags:

-i
        Use the "feature-ID" of the arc info objects to link geometry and
attribute's tables. The default is to use the "feature-#" field (which is an
internal link, but you should not rely on it for linking Arc/Info objects to
an external database. (GRASS 5.0 option)"

Sounds inconsistent, maybe just not clearly stated. Can it be made more clear
in the help page?

After that, d.area (or whatever its name, this a little bit confusing
thoses days :wink: let you draw a map showing the land values with a
beautifull color ramp !

Yes, it works. However you still need to supply "d.area" with "catnum"s in
order to color areas by category. If you have 80 soil polygons and
you want to color them according to the value in the "muid" attribute you'd
have (after 'ln -s statsgo.muid statsgo') to list all the catnums explicitly,
like:

d.area -f statsgo catnum=2,5,7,8,11,12,23

after looking them up in 'dig_cat/statsgo', right?
Is there a command to color areas (or lines) according to unique value of
category label? So far I can only do it one category at a time using PgSQL:

d.vect.pg -f key=statsgo_id table=statsgo where="muid = 'NY126'"

map=statsgo col=blue

I actually like how this (GRASS/Pg) works, just thought there may be a
built-in module that does that. Is there?

m.in.e00 attempts to be clever :slight_smile: so if there is only one attribute in
the arc/info coverage, the dig_cats file created is only named after
the vector file name (no dot, no suffix)

I think m.in.e00 behaves just fine in this respect. In the future I think
'dig_cat' should be retired in favor of a real database, but for now it's
valuable to extract all attributes like m.in.e00 does.

Best regards,

Aleksey

7

On Feb 7, Glynn Clements wrote:
> 3. The most recent version of XDRIVER can use a window supplied by the
> application, rather than creating its own (via the XDRIVER_WINDOW
> environment variable). This won't work for the libW11 port, but
> Windows should really have a native driver anyway.

Glynn,

This is fabulous! I'm really glad you mentioned this.

I've been meaning to compose a message for some time concerning GRASS
and user-interface issues. I had been wrestling with the fact that I
very much like the modular structure in GRASS, but I was bothered by
the lack of functionality in the (intentionally) dumb monitors.

I have been wanting to be able to do things such as registering
geographic regions for context-sensitive popup menus. But I did not
want to extend the display protocol arbitrarily until it became as
sophisticated as, say, X, for example.

So, hopefully, I can simply use the XDRIVER_WINDOW feature to code up
the application I need. And if I'm careful, I'd like to have
something of fairly general use when I'm done, (eg. the first thing I
need is layer management, so I'll be starting with that).

-Carl

8

On Feb 7, Michel Wurtz wrote:
> A short list of what I'm dreaming of as a display tool :
> + manage layers (add, remove, re-order)
> + save/load "view" created (list of layer, legend and extent)
> + enhanced drawing capabilities:
> - color transparency for raster,
> - style for lines (including parallel lines for roads)
> - fill area with color or patterns, and transparency
> - style for sites (pixmap or vectorized symbols, the later being orientable)
> + view created usable in the map manager for output
> + query on the map (raster and vector) and (eventually with an
> external function) manage the attribute of selected object(s)
> + mesure on the image
> + draw line on it and pass it to external application (profil in a DEM,...)
> + at a second time, add point/line area digitizing
> + map manager must work with mouse, but let you fix all positions or
> dimensions with figure (this ensures a perfect map)

This looks like a pretty good list to start with, (although not all of
those features must be "builtin" to the GUI -- several will work just
fine as external programs called by the GUI).

I've been needing a nice GUI for a while, and fortunately just wrapped
up some other projects here, so I should be able to dedicate myself to
GRASS GUI development.

One of the first things I would like to do is to enhance the driver
protocol as needed for the "enhanced drawing capabilities" you
suggested above, (including arbitrary RGBA colors for all drawing
operations). And for that I have a couple of questions:

How can we efficiently manage map symbols, (ie. pixmaps), with a
stateless monitor and protocol? The same question applies, (to a
lesser extent to passing colors

How hard would it be to extend raster maps to 4 channels? (RGB +
alpha).

As far as toolkits go, I'm a big fan of X, especially some of the
recent features in X such as the Xft support and the RENDER extension,
(which allows for translucent image composition). So, I'm competent
and happy to code the necessary driver pieces in Xlib.

As for the rest of the GUI, I'd be willing to look at wxWindows,
(although it might be hard to get at the resource needed for the
XDRIVER_WINDOW variable. I assume I need to set that to the XID of the
window of interest, no? I can't imagine any mechanism for getting at
something like that in a cross-platform toolkit. Ideas?

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

9

On Thu, Feb 07, 2002 at 06:35:06PM +0000, Michel Wurtz wrote:

> 1. Have you considered using WxWindows? This provides a layer on top
> of the platform's native toolkit(s). This may provide better
> integration than a toolkit which is built from scratch on top of the
> platform's lowest-level components.

Well, I've heard of, but have not studied it in details...

I also recommend wxwindows, especially in the wxpython case,
because you do not have to use the C++ interface.

> 2. Qt requires C++, which is a disadvantage from a portability
> standpoint. Also, I still don't quite understand TrollTech's licensing
> position.

It's quite complicated, and to be honest, I don't understand all :slight_smile:

Only the version for X11 is Free Software.

All other versions are proprietory,
you can also get a proprietory version of X11.
This pretty much renders QT useless for cross platform Free Software.

  Bernhard

10

On Thu, 7 Feb 2002, Michel Wurtz wrote:

A short list of what I'm dreaming of as a display tool :
+ manage layers (add, remove, re-order)

This doesn't seem like it would be that difficult.

+ save/load "view" created (list of layer, legend and extent)

d.save does the "save" part now, the "load" would be done by running the
script created by d.save.

+ enhanced drawing capabilities:
  - color transparency for raster,
  - style for lines (including parallel lines for roads)
  - fill area with color or patterns, and transparency
  - style for sites (pixmap or vectorized symbols, the later being orientable)

I'd love to see this happen. ps.map offers some of these capabilities
now. I very much appreciate having ps.map but ps.map is difficult to
learn and use.

+ view created usable in the map manager for output
+ query on the map (raster and vector) and (eventually with an
  external function) manage the attribute of selected object(s)

Of course we can query now (d.what.sites, d.what.rast, d.what.vect), but
it would be nice to be able to select objects and manage their attributes
interactively.

+ mesure on the image

d.area, d.measure.

+ draw line on it and pass it to external application (profil in a DEM,...)

That seems like it could be difficult to do.

+ at a second time, add point/line area digitizing

This sounds like v.digit, integrated more completely into the environment.

I guess I have a shorter list of things I'd like to see done in the near
future.

From the command line--at least as of pre2--when the user creates a
monitor window, the focus is passed to the monitor (or is this just a
characteristic of the window manager?). The monitor window is never
initialized in a state where it's ready to accept input. That behavior is
annoying because it's always necessary to get the focus back to an
interactive shell before you can go on with whatever you are doing.

Is there some way to keep a newly-created monitor from grabbing the focus?

Even better, could we give the monitor windows a default action in
response to mouse clicks, double clicks, drags and so on? I'd like it if
the monitor came up with the functionality of d.where, d.zoom, d.erase or
d.what.* already running and available with just a mouse action on the
monitor.

I'd also like it if the active monitor were alway "on top" of the display
and if it were possible to select a monitor (as with d.mon select=x*) with
the mouse just by clicking it to give it the input focus. That is, the
"top" monitor is always selected, and the selected monitor is always "on
top". Again, this may be behavior specific to the window manager. If so,
then too bad.

Roger Miller

11

Roger Miller wrote:

On Thu, 7 Feb 2002, Michel Wurtz wrote:

> A short list of what I'm dreaming of as a display tool :
> + manage layers (add, remove, re-order)

This doesn't seem like it would be that difficult.

there is also d.dm to do that (thanks to Radim)

> + save/load "view" created (list of layer, legend and extent)

d.save does the "save" part now, the "load" would be done by running the
script created by d.save.

> + enhanced drawing capabilities:
> - color transparency for raster,
> - style for lines (including parallel lines for roads)
> - fill area with color or patterns, and transparency
> - style for sites (pixmap or vectorized symbols, the later being orientable)

Some nice capabilities for displaying sites, including diagrams for multiple
attributes are in SG3d - maybe some of that code could be re used:
see examples in this document:
http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/ccsoil2.html

http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/img/hor1texp.gif
http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/img/hor1textusda.gif

I'd love to see this happen. ps.map offers some of these capabilities
now. I very much appreciate having ps.map but ps.map is difficult to
learn and use.

> + view created usable in the map manager for output
> + query on the map (raster and vector) and (eventually with an
> external function) manage the attribute of selected object(s)

Of course we can query now (d.what.sites, d.what.rast, d.what.vect), but
it would be nice to be able to select objects and manage their attributes
interactively.

> + mesure on the image

d.area, d.measure.

> + draw line on it and pass it to external application (profil in a DEM,...)

That seems like it could be difficult to do.

> + at a second time, add point/line area digitizing

This sounds like v.digit, integrated more completely into the environment.

some of these capabilities were also in xgrass, xdigit, but I guess that is dead
now -
I am not sure whether any of the code could be used to save some effort.

Helena

I guess I have a shorter list of things I'd like to see done in the near
future.

From the command line--at least as of pre2--when the user creates a
monitor window, the focus is passed to the monitor (or is this just a
characteristic of the window manager?). The monitor window is never
initialized in a state where it's ready to accept input. That behavior is
annoying because it's always necessary to get the focus back to an
interactive shell before you can go on with whatever you are doing.

Is there some way to keep a newly-created monitor from grabbing the focus?

Even better, could we give the monitor windows a default action in
response to mouse clicks, double clicks, drags and so on? I'd like it if
the monitor came up with the functionality of d.where, d.zoom, d.erase or
d.what.* already running and available with just a mouse action on the
monitor.

I'd also like it if the active monitor were alway "on top" of the display
and if it were possible to select a monitor (as with d.mon select=x*) with
the mouse just by clicking it to give it the input focus. That is, the
"top" monitor is always selected, and the selected monitor is always "on
top". Again, this may be behavior specific to the window manager. If so,
then too bad.

Roger Miller

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

12

Michel Wurtz wrote:

In fact, I started by looking at something less frustrating than ps.map.
I consider actualy that two modules are necesary : the first is a kind
of enhanced tcltkgrass (use external functions, except for drawing);

I'd suggest using external programs for drawing as well. Otherwise
you'll be re-implementing half of src/display.

the second is a map manager (maps, legend, title, text, images, order of
drawing (so it's easy to make overlays), and probably some recusrive
feature (map in a map). You should naturally be able to load/save
a map (layout, content, and definition), and output the final result as
a ps file, an image (albeit this may be managed externally by ghostscript),
or an xfig file.

A short list of what I'm dreaming of as a display tool :
+ manage layers (add, remove, re-order)
+ save/load "view" created (list of layer, legend and extent)
+ enhanced drawing capabilities:
  - color transparency for raster,
  - style for lines (including parallel lines for roads)
  - fill area with color or patterns, and transparency
  - style for sites (pixmap or vectorized symbols, the later being orientable)

Translucency is awkward. Many display systems don't support it
directly. PostScript *can't* support actual translucency, as the
framebuffer is write-only; although you can provide some form of
emulation with halftones, you need to be careful when dealing with
multiple layers.

As for new features generally, they would belong in the general
display architecture, where they are available to all programs. Adding
functionality which is only available through an interactive
application is bad idea.

My main concern is that, rather than extending GRASS, you may end up
simply forking off a lot of code into a self contained application.

> 6. I'm looking into replacing the display architecture eventually;
> PostScript is the main contender, with SVG and OpenGL as alternative
> options. This won't happen soon, but I'd welcome comments regarding
> the design of any future display architecture.

Well, I like the idea of postscript. The only drawback I see is that
poor performance in redrawing are to be expected if you have a lot of
lines to draw, and that you must include a postscript interpreter (or
call an external one, which is also not very good for performances)

Well, obviously the interpreter would be either Ghostscript (for
screen display, image creation, and printing to non-PostScript
printers), or the one which is built into a PostScript printer.

As for performance, the overhead of sending PostScript to an external
process is trivial compared to the actual processing and rendering
(which occurs regardless of whether the interpreter is external).
Rendering complex geometry is expensive however you do it.

--
Glynn Clements <glynn.clements@virgin.net>

13

On Feb 7, Roger Miller wrote:
> >From the command line--at least as of pre2--when the user creates a
> monitor window, the focus is passed to the monitor (or is this just a
>
> Is there some way to keep a newly-created monitor from grabbing the
> focus?

You'll have to configure your window manager for this.

> I'd also like it if the active monitor were alway "on top" of the display
> and if it were possible to select a monitor (as with d.mon select=x*) with
> the mouse just by clicking it to give it the input focus. That is, the
> "top" monitor is always selected, and the selected monitor is always "on
> top". Again, this may be behavior specific to the window manager. If so,
> then too bad.

The notions of focus and stacking are controlled by the window
manager. While it is technically possible that some X-aware GRASS
program could search up and down the window stack to find the top-most
monitor and draw to it, this would be a very bad idea for several
reasons, (including the fact that many window managers allow "active"
windows that are under other windows).

> Even better, could we give the monitor windows a default action in
> response to mouse clicks, double clicks, drags and so on? I'd like it if
> the monitor came up with the functionality of d.where, d.zoom, d.erase or
> d.what.* already running and available with just a mouse action on the
> monitor.

I think something like this would be a great idea. As far as
implementation, it probably makes sense to leave the monitors as "dumb
displays", but a new program could be written that provides a window
for a GRASS monitor and also provides this kind of functionality.

I plan to start experimenting with such programs right away.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

14

Hi,

just a reminder: there is also the OGR library from Frank Warmerdam
which supports:

dgn
generic
gml
mitab
ntf
ogdi
pg
s57
sdts
shape
tiger

... a v.in.ogr comes to my mind. Perhaps efforts can be bundled
to extend OGR with E00, DXF and Ungenerate and build v.in.ogr
on top of that (I like the r.in.gdal very much).

Just an obvious suggestion,

Markus

15

On Feb 7, Glynn Clements wrote:
> Translucency is awkward. Many display systems don't support it
> directly. PostScript *can't* support actual translucency, as the
> framebuffer is write-only; although you can provide some form of
> emulation with halftones, you need to be careful when dealing with
> multiple layers.

*sigh*. In my book, this is a strong vote against the choice of
PostScript as a display technology then. Translucency is a very
compelling feature, (and it does not demand too much of the display
system -- nothing more than the ability to read the current state).

> As for new features generally, they would belong in the general
> display architecture, where they are available to all programs. Adding
> functionality which is only available through an interactive
> application is bad idea.

I agree. The real question is where does state go? What would you
recommend as a mechanism for efficiently implementing layers for
example? I know the current GRASS monitor redraw system is a hack, but
where does the layer state belong? If the monitor is to operate
efficiently, much of the rendering result needs to be cached
somewhere.

> As for performance, the overhead of sending PostScript to an external
> process is trivial compared to the actual processing and rendering
> (which occurs regardless of whether the interpreter is external).
> Rendering complex geometry is expensive however you do it.

I have some particular interests regarding performance. I need to do
some real-time visualization of dynamic geographical information
(> 1 fps and the faster the better). And to make things even more
interesting, I'm implementing this on handheld computers without
hardware floating-point, (iPAQs running Linux). GRASS seems like a
good fit for storing my geographical data. And I could easily pull off
all of my real-time display requirements as long as I had efficient
layer support. For example, I'd like to render several raster and
vector maps into the background layer, then loop over my dynamic data,
(which is mostly just moving sites with changing attributes), erasing
and drawing. I wouldn't mind having to take a hit in my frame rate for
large-ish pan or zoom operations.

The other thing that's missing is database locking at a
finer-level. The current user-level lock is extremely coarse, (and
frustrating), and doesn't solve the problem I have a one process
updating site information while another one sits in a display
loop. But, granted, I am probably going in directions with GRASS that
it was never designed to go --- but no reason it can't be fixed to get
me there either. :wink:

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

16

Carl Worth wrote:

> A short list of what I'm dreaming of as a display tool :
> + manage layers (add, remove, re-order)
> + save/load "view" created (list of layer, legend and extent)
> + enhanced drawing capabilities:
> - color transparency for raster,
> - style for lines (including parallel lines for roads)
> - fill area with color or patterns, and transparency
> - style for sites (pixmap or vectorized symbols, the later being orientable)
> + view created usable in the map manager for output
> + query on the map (raster and vector) and (eventually with an
> external function) manage the attribute of selected object(s)
> + mesure on the image
> + draw line on it and pass it to external application (profil in a DEM,...)
> + at a second time, add point/line area digitizing
> + map manager must work with mouse, but let you fix all positions or
> dimensions with figure (this ensures a perfect map)

This looks like a pretty good list to start with, (although not all of
those features must be "builtin" to the GUI -- several will work just
fine as external programs called by the GUI).

I've been needing a nice GUI for a while, and fortunately just wrapped
up some other projects here, so I should be able to dedicate myself to
GRASS GUI development.

One of the first things I would like to do is to enhance the driver
protocol as needed for the "enhanced drawing capabilities" you
suggested above, (including arbitrary RGBA colors for all drawing
operations). And for that I have a couple of questions:

I discuss some of the specifics below, but I'd caution against
extending the monitor protocol unless you can get a lot of benifit
from a small change.

Bear in mind that the underlying architecture is far from ideal. It's
future probably involves being thrown away and replaced with something
completely different, rather than incremental improvement.

How can we efficiently manage map symbols, (ie. pixmaps), with a
stateless monitor and protocol? The same question applies, (to a
lesser extent to passing colors

The monitor isn't stateless.

How hard would it be to extend raster maps to 4 channels? (RGB +
alpha).

Raster maps are single channel, and are likely to stay that way
forever. Colour images are best handled as separate R/G/B layers;
quantisation degrades colour resolution, and results in raster layers
which are largely useless for anything other than rendering (because
the resulting categories have no significance beyond their colour).

The issue is what's involved in implementing a "d.rgba" program (i.e.
d.rgb + alpha), which translates to what's involved in extending the
display protocol to support alpha information.

The first issue is that it is impossible to perform translucent
rendering on write-only devices. This includes all PostScript devices;
on many (most?) laser printers, the framebuffer is physically
write-only (i.e. the framebuffer RAM's data-in lines connect to the
CPU, while the data-out lines connect to the print engine).

You can obtain a similar effect with halftones, but you need to be
careful when handling multiple layers. If you draw two halftoned
layers with the same halftone offsets, the first one is completely
overwritten by the first. If you draw enough halftoned layers, the
original layers are eventually obscured completely.

In short, don't assume that it's just a matter of blending each layer
with the output so far using linear interpolation. It helps if you
know at the start how many translucent layers are involved, along with
the alpha factors.

Personally I feel that, compared to translucency, there are other
things which would be significantly more useful and also less work
(adding something as significant as translucency to the display
architecture would kick the 5.0 release into the long grass).

E.g. a simple display layer manager would leverage what already exists
in terms of src/display/d.*, without introducing any system-wide
complications.

As far as toolkits go, I'm a big fan of X, especially some of the
recent features in X such as the Xft support and the RENDER extension,
(which allows for translucent image composition). So, I'm competent
and happy to code the necessary driver pieces in Xlib.

Don't overlook the significance of the term "extension". Core
functionality should work on any X server.

As for the rest of the GUI, I'd be willing to look at wxWindows,
(although it might be hard to get at the resource needed for the
XDRIVER_WINDOW variable. I assume I need to set that to the XID of the
window of interest, no? I can't imagine any mechanism for getting at
something like that in a cross-platform toolkit. Ideas?

I'm fairly sure that you can get at toolkit-specific information.

--
Glynn Clements <glynn.clements@virgin.net>

17

On Feb 7, Glynn Clements wrote:
> Carl Worth wrote:
> I discuss some of the specifics below, but I'd caution against
> extending the monitor protocol unless you can get a lot of benifit
> from a small change.

The current 13-color fixed palette for drawing commands is extremely
limiting. IMHO, extending that to arbitrary RGB colors would be a lot
of benefit from a small change. Similarly for line styles, (which
nearly all display types support to some extent natively), and more
generalized sites rendering than the current 5 fixed shapes, (why not
support a scaled and rotated vector map for rendering on sites as well
as pixmaps).

> Bear in mind that the underlying architecture is far from ideal. It's
> future probably involves being thrown away and replaced with something
> completely different, rather than incremental improvement.

I'd be open to that too. Bear in mind, I'm not throwing out lots of
feature requests here hoping someone will do it. I'm planning on
dedicating a lot of full-time effort to improve GRASS, (primarily in
terms of display and user-interface --- it already has a tremendous
amount of capability "under the hood" and far beyond my expertise).

> > How can we efficiently manage map symbols, (ie. pixmaps), with a
> > stateless monitor and protocol? The same question applies, (to a
> > lesser extent to passing colors
>
> The monitor isn't stateless.

I guess I was referring to the monitor as "stateless" in terms of your
recent post suggesting the monitor should remain a "dumb" display
device that ideally knew nothing about GRASS.

The question is how to efficiently reduce repeatedly rendering
redundant information, (eg. drawing hundreds of identical sites all
over a map). This gets a bit complicated in that the sending side of
the protocol might be many d.* display commands, (meaning separate
invocations with no shared state between them). So, it's probably fair
to say that caching belongs on the other end of the protocol,
(whether in the monitor or in a new stateful object that gets inserted
between the receiving end of the pipe and the monitor I don't know).

> > How hard would it be to extend raster maps to 4 channels? (RGB +
> > alpha).
>
> Raster maps are single channel, and are likely to stay that way
> forever. Colour images are best handled as separate R/G/B layers;

That's fine. Adding a new alpha layer is then quite easy in this
respect.

> The issue is what's involved in implementing a "d.rgba" program (i.e.
> d.rgb + alpha), which translates to what's involved in extending the
> display protocol to support alpha information.

exactly.

> The first issue is that it is impossible to perform translucent
> rendering on write-only devices. This includes all PostScript
> devices;

I'm confused Glynn. There is currently no PostScript display driver
is there? (I see cell, png, htmlmap, and xdriver in my docs). And even
if one were created, it would still be possible to do composition of
translucent layers prior to outputting the postscript would it not?

In any case, I am personally very interested in translucent rendering
and am willing to do the work to make it possible.

> > I can't imagine any mechanism for getting at something like that
> > in a cross-platform toolkit. Ideas?
>
> I'm fairly sure that you can get at toolkit-specific information.

Thanks. I'll look deeper.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

18

Carl Worth wrote:

> Translucency is awkward. Many display systems don't support it
> directly. PostScript *can't* support actual translucency, as the
> framebuffer is write-only; although you can provide some form of
> emulation with halftones, you need to be careful when dealing with
> multiple layers.

*sigh*. In my book, this is a strong vote against the choice of
PostScript as a display technology then. Translucency is a very
compelling feature, (and it does not demand too much of the display
system -- nothing more than the ability to read the current state).

I didn't say that you can't do it; I said that you have to be careful
about what halftone patterns you use and how they're aligned.
Basically, this means that you get better results if you take it into
account what's coming next.

Also, you can't avoid the issue when it comes to producing hardcopy.
Of course, you could always compose the layers in software, but then
you either have to generate a 300+ dpi image, or choose a resolution
below the printer's capability.

For purely electronic output (e.g. image files), you may be better of
just generating individual layers and composing them with image
processing tools (e.g. ppmmix).

> As for new features generally, they would belong in the general
> display architecture, where they are available to all programs. Adding
> functionality which is only available through an interactive
> application is bad idea.

I agree. The real question is where does state go? What would you
recommend as a mechanism for efficiently implementing layers for
example? I know the current GRASS monitor redraw system is a hack, but
where does the layer state belong? If the monitor is to operate
efficiently, much of the rendering result needs to be cached
somewhere.

The simple solution is to simply keep a list of commands, and run
through the list to perform a redraw. The more efficient solution is
to use the PNG driver to turn everything into images. In that regard,
a simple extension to allow e.g. d.erase to clear to transparent might
provide a significant benefit without requiring too much work.

> As for performance, the overhead of sending PostScript to an external
> process is trivial compared to the actual processing and rendering
> (which occurs regardless of whether the interpreter is external).
> Rendering complex geometry is expensive however you do it.

I have some particular interests regarding performance. I need to do
some real-time visualization of dynamic geographical information
(> 1 fps and the faster the better). And to make things even more
interesting, I'm implementing this on handheld computers without
hardware floating-point, (iPAQs running Linux). GRASS seems like a
good fit for storing my geographical data. And I could easily pull off
all of my real-time display requirements as long as I had efficient
layer support. For example, I'd like to render several raster and
vector maps into the background layer, then loop over my dynamic data,
(which is mostly just moving sites with changing attributes), erasing
and drawing. I wouldn't mind having to take a hit in my frame rate for
large-ish pan or zoom operations.

That could be implemented with R_panel_{save,restore}. These
operations could be made more efficient (e.g. by storing the data
either within the X server or in memory within XDRIVER) without any
changes to the protocol.

Unfortunately, there's always tension between performance and
flexibility. Specific applications with performance requirements might
be better served by a dedicated program. But that doesn't help the
rest of GRASS much.

Right now, I'm thinking mainly about being able to "leverage" what's
already there by making it easier to use.

--
Glynn Clements <glynn.clements@virgin.net>

19

Roger Miller wrote:

> + save/load "view" created (list of layer, legend and extent)

d.save does the "save" part now, the "load" would be done by running the
script created by d.save.

For a GUI, the format should probably be more amenable to editing than
is the case for a shell script. Also, d.save doesn't allow for
temporarily disabling commands; i.e. the command is still
"remembered", but won't actually be run unless re-enabled.

> + view created usable in the map manager for output
> + query on the map (raster and vector) and (eventually with an
> external function) manage the attribute of selected object(s)

Of course we can query now (d.what.sites, d.what.rast, d.what.vect), but
it would be nice to be able to select objects and manage their attributes
interactively.

> + mesure on the image

d.area, d.measure.

The modal interaction style of d.what.*, d.measure etc is more akin to
the behaviour of pre-GUI programs than the event-driven model more
common nowdays.

It might be better if the programs which currently call
R_get_location_with_{pointer,box,line} were redesigned so as to allow
other programs to feed them coordinates.

From the command line--at least as of pre2--when the user creates a
monitor window, the focus is passed to the monitor (or is this just a
characteristic of the window manager?).

Yes.

Note that the monitor doesn't grab the "focus" in the strict sense
(i.e. keyboard focus).

The monitor window is never
initialized in a state where it's ready to accept input. That behavior is
annoying because it's always necessary to get the focus back to an
interactive shell before you can go on with whatever you are doing.

Is there some way to keep a newly-created monitor from grabbing the focus?

Probably not in a portable manner. There may be tricks which will
affect how individual WMs respond. Also, with some WMs, you can
configure behaviour according to various window properties (e.g.
title, resource name/class).

Even better, could we give the monitor windows a default action in
response to mouse clicks, double clicks, drags and so on? I'd like it if
the monitor came up with the functionality of d.where, d.zoom, d.erase or
d.what.* already running and available with just a mouse action on the
monitor.

This is going in the wrong direction, IMHO. The actual monitor
shouldn't do any of this. It should be a dumb "slave" to a GUI
program, which can then provide this sort of behaviour.

The mouse handling should probably go altogether. It doesn't fit into
the overall architecture (the GET_LOCATION_WITH_* opcodes are empty
stubs on everything other than XDRIVER), and the modal behaviour
doesn't sit well with the event-driven model used by GUI programs.

I'd also like it if the active monitor were alway "on top" of the display
and if it were possible to select a monitor (as with d.mon select=x*) with
the mouse just by clicking it to give it the input focus. That is, the
"top" monitor is always selected, and the selected monitor is always "on
top". Again, this may be behavior specific to the window manager. If so,
then too bad.

Half of it is WM specific. The other half seems to be too heavily
based upon interactive use. E.g., if a script is composing an image on
the PNG driver, the selected monitor shouldn't suddenly change.

AFAICT, XDRIVER was never intended to comprise a GUI. Unfortunately,
enough interactive features have been tacked on at various points that
people are starting to mistake it for one. However, the less it
behaves like a dumb slave, the harder it will be to implement a real
GUI.

The only function which the monitors need to have in common with GRASS
is G_sock_get_fname(), so that GRASS and the monitors can
communicate[1]. Beyond that, while GRASS needs to know about the
monitors, the monitors really shouldn't need to know anything about
GRASS.

[1] However, the function should probably be provided by the monitor
subsystem and used by GRASS, rather than the other way around.

--
Glynn Clements <glynn.clements@virgin.net>

20

Carl Worth wrote:

> Carl Worth wrote:
> I discuss some of the specifics below, but I'd caution against
> extending the monitor protocol unless you can get a lot of benifit
> from a small change.

The current 13-color fixed palette for drawing commands is extremely
limiting. IMHO, extending that to arbitrary RGB colors would be a lot
of benefit from a small change.

At the code level, you can use other colours for drawing; you just
have to define them with R_reset_color(), then use R_color() instead
of R_standard_color(). I'm told that the documentation isn't
particularly clear on this, though.

Similarly for line styles, (which
nearly all display types support to some extent natively), and more
generalized sites rendering than the current 5 fixed shapes, (why not
support a scaled and rotated vector map for rendering on sites as well
as pixmaps).

Line styles (dash patterns) alone shouldn't present too much of a
problem.

Line thickness is more complex. Some application code assumes that a
line is one pixel wide (e.g. the raster drawing code used to fill
areas of constant colour by drawing horizontal lines; I changed it to
use 1-pixel high rectangles). Also, different graphics APIs may have
different semantics when dealing with line styles and "wide" lines
(e.g. for a dashed line with rounded caps, is each dash rounded?).

> Bear in mind that the underlying architecture is far from ideal. It's
> future probably involves being thrown away and replaced with something
> completely different, rather than incremental improvement.

I'd be open to that too. Bear in mind, I'm not throwing out lots of
feature requests here hoping someone will do it. I'm planning on
dedicating a lot of full-time effort to improve GRASS, (primarily in
terms of display and user-interface --- it already has a tremendous
amount of capability "under the hood" and far beyond my expertise).

Right; my point is that it's not worth doing too much work on a
graphics architecture whose days are numbered. But 5.0 is going to
have to either use the existing architecture or be postponed
indefinitely.

> > How hard would it be to extend raster maps to 4 channels? (RGB +
> > alpha).
>
> Raster maps are single channel, and are likely to stay that way
> forever. Colour images are best handled as separate R/G/B layers;

That's fine. Adding a new alpha layer is then quite easy in this
respect.

> The issue is what's involved in implementing a "d.rgba" program (i.e.
> d.rgb + alpha), which translates to what's involved in extending the
> display protocol to support alpha information.

exactly.

> The first issue is that it is impossible to perform translucent
> rendering on write-only devices. This includes all PostScript
> devices;

I'm confused Glynn. There is currently no PostScript display driver
is there? (I see cell, png, htmlmap, and xdriver in my docs).

No, but I'm thinking about the future.

The way I see it, 5.0 gets released with (more or less) the existing
display architecture. Once that's done, a new display architecture can
be created, starting with a blank slate.

I would very much hope that any future architecture would support
screen display, image creation and printing, and that it would do a
reasonably good job of all of them, in spite of their differences. It
would be less than ideal if translucency was implemented in a way that
didn't work well for printing.

And even
if one were created, it would still be possible to do composition of
translucent layers prior to outputting the postscript would it not?

Consider the case where you wish to overlay translucent vector area
(filled polygon) maps on an opaque raster background. If you simply
composite the layers into a raster, then convert that to PostScript,
you either have chunky pixels or a massive PostScript file.

This is basically the reason why I didn't write a PostScript driver.
The current display architecture is far too oriented towards pixels.

Any vectors would have to have been rasterised at the same resolution
as bitmaps (which are scaled to the display resolution by the client),
otherwise the results wouldn't "line up". So, you may as well just use
the PNG driver, and convert the resulting image.

A *worthwhile* PostScript driver would draw rasters at their source
resolution (typically much lower than the printer's resolution), but
vectors and text at the printer's resolution.

--
Glynn Clements <glynn.clements@virgin.net>