(I switched to devel list.)
On Tuesday 01 October 2002 08:20 pm, Michel Wurtz wrote:
The first implementation of m.in.e00 was using feature-ID, and I agree with
you. The problem comes from the info tables, where feature-# is used for
linking graphic objects and attributes. So you can have multiple entries
for one feature-ID (where some fields, like perimeter or surface,
different). It is then safer to use feature-#,
Yes.
except when the feature-# is
just what you want in dig_att (like Z value of contour lines...)
This i don't understand. I would understand: "except when the feature-ID is
...".
How is the feature-ID used in Arc/Info if it is not the link to attributes?
Are attributes (other then surface etc.) synchronized somehow
if two objects have the same feature-ID?
Here you can see that the design of Grass and Arc/Info is different,
If feature-# is used as category in GRASS and feature-ID is stored as
one attribute in an attached table, it seems to be the same to me.
and that Grass lacks a good attribute management system for vectors...
Do you mean Grass 5.0 or 5.1? Please send me some comments for GRASS 5.1
vectors if you know about any sensible data model we cannot use in GRASS 5.1.
Radim
> and that Grass lacks a good attribute management system for vectors...
I believe that Michel is talking about GRASS5.0 here. Michel, did you get a
chance
to try out GRASS5.1 vectors?
see http://grass.itc.it/grass51/index.html
Your comments will be greatly appreciated.
Helena
Do you mean Grass 5.0 or 5.1? Please send me some comments for GRASS 5.1
vectors if you know about any sensible data model we cannot use in GRASS 5.1.
Radim
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Helena Mitasova wrote:
and that Grass lacks a good attribute management system for vectors...
I believe that Michel is talking about GRASS5.0 here. Michel, did you get a
chance
to try out GRASS5.1 vectors?
You're right, I was talking about 5.0. I have a up-to-date cvs copy of 5.1,
but never had enough time to compile it. I just had a look at the doc
because I wanted to adapt m.in.e00 as soon as the 5.1 vector model will be
stable enough.
I think it's time since a couple of month, but was a little busy this summer
because I moved (my job is the same, but we migrate from Montpellier to Toulouse,
while the project I'm working on is just growing faster 
BTW, I plan to introduce GPL software in the administration I'm working for :
We use Mapinfo as vector based GIS, and MapX to put GIS functions in
existing applications, but I hope to use grass for all raster based analysis,
with a MapBasic development to include a user-friendly interface inside
MapInfo menus. This will even work better if we can add a plugin to Mapinfo,
for a direct reading of grass raster format. It seems to be possible (it was
done for Mr SID and ECW raster format, before their recognition was included
in the core program.
In the meantime, I will have a closer look at 5.1 vector and adapt m.in.e00
as soon as possible.
Anyway, thank for the reminder,
Michel.
Radim Blazek wrote:
(I switched to devel list.)
On Tuesday 01 October 2002 08:20 pm, Michel Wurtz wrote:
The first implementation of m.in.e00 was using feature-ID, and I agree with
you. The problem comes from the info tables, where feature-# is used for
linking graphic objects and attributes. So you can have multiple entries
for one feature-ID (where some fields, like perimeter or surface,
different). It is then safer to use feature-#,
Yes.
except when the feature-# is
just what you want in dig_att (like Z value of contour lines...)
This i don't understand. I would understand: "except when the feature-ID is ...".
Ooops, you're right. I thinked feature-ID and wrote feature-# ...must be tired 
How is the feature-ID used in Arc/Info if it is not the link to attributes?
Are attributes (other then surface etc.) synchronized somehow if two objects have the same feature-ID?
feature-ID is an "external" identifier, which remind after saving and restoring
data, cleaning, etc... So it is used to link an Arc/Info coverage to some
external table (RDBMS, Excel, etc...)
feature-# in an "internal" identifier used to ensure the coherence between the
Arc (graphic) and the Info (attribute tables) parts.
Practicaly, using same feature-ID for different objects is not common.
It can be used for polygons with islands, when you don't want an unique object,
because you want to be able to display the surface of each island, but ensure
that all other attributes are the same.
There is probably other examples...
Michel.