search

52North / IlwisCore

Integrated Land and Water Information System (ILWIS) is a remote sensing and GIS software. ILWIS Core is the functional center of ilwis4..
http://52north.org/communities/ilwis/
35 stars 13 forks source link

Removal of the setter for a (whole) attribute table #64

Open MartinSchouwenburg opened 10 years ago

MartinSchouwenburg commented 10 years ago

The setters for attribute table ( the explicit set and the "reference" set) are potential very dangerous and should be removed. Reason is that the linkage between a feature or classified pixel ( the only case were rasters can have attribute tables) is done by a specialized column in the attribute table. There is no guarantee that an external attribute table has such a column and even if it has such a column if it is relevant for the feature coverage. e.g. copying an attribute table of another feature coverage. It has a featureid column but its featureid's will have no relevance to featurecoverage (they come from the other coverage). So imo a featurecoverage (or classified raster) always has an implicit attribute table which you can of course access but you can never set it (the whole table). You may copy records from one table to the other (but featureid remains unaffected) . I even wonder, since we have introduced the record class, if we should move the featureid to a specialized field in the record class. For the user it is a failry opaque 64 bit unique number with which he cant do much (maybe selection?). Now it is a column and it must be protected against manipulation of the regular table value setters. If it is a field of the record class it has become seperate from the direct attributes and all tables(columns) can be handled consistently.

ridoo commented 10 years ago

I think also that the FEATURE_ID columns is just for internal use. I do not think it should be hidden, but protected against (accidental) changes which would break the integrity of a coverage.

The new record concept should offer an easy handle to protect such fields. I agree with you so :+1:

MartinSchouwenburg commented 10 years ago

Ok, then I will start making this change. It has some consequences (interface wise) but already for some time I feel this is an unwanted left-over from an Ilwis3 interface. It made sense there because of the way how domains, tables and coverages were coupled there. It is dangerous now.