[GRASS5] Re: Vector format proposal

[Radim Blazek]

aaime wrote:
> Hi everybody,
> this evening I've found time to read GRASS 5.1 vector format proposal.
> Sounds good, but I disagree with attributes management proposal. I this
> mail will try to explain why.
> If I undestrand correctly, you proposal is to let different entities to
> have a different number of attributes, and that each entity can be linked
> to different databases. That sound very flexible, but also very complicated
> to handle in the long run.
> I don't question againt complexity per se, complex problems often have a
> complex solution, but in this case I don't see the need for such a solution
> (in the problem domain, I mean). What are the requirements that have led
> you think that such a flexiblity is necessary?
> In my opinion it may stem from the fact that a vector file can store areas,
> points and lines all togheter. I don't like much this, I would prefer to
> store different entities in different files, so that we now that a single
> file contains only areas, as an example. This would make easier to
> implement overlay commands and to make more strict control on topology
> creation (eg: no self intersecting lines, no intersections between
> different lines). 
> In my previuous proposal I said that a simple index is
> sufficient to link entities to a table, that can contain as many attributes
> as the user wants, but the same number and the same type for each entity in
> a single file. This is a quite different approach, but I think it may be
> good for three reasons:
> * it's simple, and simple software is easier to build and mantain, and more
> stable;
> * you always know to which table a file is linked, no need to interpret an
> association file like the one proposed;
> * because everybody else is doing like this (I'm thinking about Autodesk,
> ESRI and Intergraph), so it's a proven road and it's familiar to the user
> of commercial packages.
>
> Now, what are your opinions?
> Regards
> Andrea Aime
>
> PS: I've sent this mail as a private message, but if you feel (like me)
> that is worth discussing it on the developer list, forward it.


We must distinguish various aspects of new vector format and discuss each
point separately. If I understand, you don't like:
1. more types in one map
2. more features in one map (I'll use 'feature' for elements                  
                                  linked to one table for example: rivers)
3. more features for one element
4. more databases for one project
5. more db drivers for one project

So I'll try to explain some reasons for proposed solution:
(BTW, proposal for vector format was sent to grass list in autumn 2000
and no protest appeared against points 1.,2.,3. and so library is written
in this way and I expected it to be final solution)

1. more types in one map
- Mantainig networks (edges+nodes = lines+points) seems to me to be much
   easier in one map than in two separated maps (snapping is needed,
   digitising  both at the same time)
- It is probably not allowed in GIS theory, and GIS teachers will be
   terrified but in practice I found that sometimes is more efficient to have 
   one feature of more types, for example lines and areas in one map and
   linked to tha same table (I am very sorry to tell such terrible thing).

2. more features in one map
- I thing that boundary of area with attached attributes is something very
   common. Then more features in one map is very important especially 
   for creating and maintaining maps. Otherwise you must maintain geometry
   of shuch boundaries twice which I see as problem.
- For network different tables are required for nodes and edges.

3. more features for one element
- One element may be interpreted as more features. For example a river may be
   (and often is) state boundary at the same time and both may have their own
   attributes. Maintainig such features in separated maps would be problem
   again.

4. more databases for one project
- O.K., that is maybe too much, but I think that it is not so much aditional
   work. Have you looked into d.vect/main.c? There is no special code 
   for this, database  must be opened anyway and it doesn't matter if
   database A or B.
- Usage example: Large base map with attributes in Oracle (where user
   has read only privileges), regulary updated. User want to create 
   his own thematic map above that large base map with just few (100-1000)
   elements. If database is optional he can create new simple database in
   his own directory otherwise he must ask Oracle admin for privileges for
   creating tables. I think that he will not get such privileges
   on some circumstances.

5. more db drivers for one project
- similar as 4.


Radim

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'