[GRASS5] Problems with vector import, and a suggestion

[Michel Wurtz]

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 ;-) let you draw a map showing the land values with a
beautifull color ramp !

m.in.e00 attempts to be clever :) 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