[GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other than
'1' in gi s.m
Moritz Lennert
mlennert at club.worldonline.be
Fri Sep 22 10:56:20 EDT 2006
Trevor Wiens wrote:
> We went through all this before in March. My suggestions are two
> fold:
> 1. If we retain 'layers' then change the name. The name is confusing
> and inappropriate. I don't care about OGR or other abuses of the term.
> Suggestions such as 'link' or 'key_field' make sense.
I have no opinion on what is better here, so no objections either.
>
> 2. Is it possible by allowing attribute based queries to provide vector
> object identification in the system to replicate all the existing
> functionality. I can not think of a case where this wouldn't work,
This is why it would be interesting to get some feedback about how
layers are used.
In the March threads you mentioned, there were some responses highly in
favour of the layer model (independent of its naming).
> and
> since there is effort to move to SQLite and better attribute
> management, now is a natural time to consider this option.
agreed
> Vector
> objects should IMO have one and only one cat value. This shouldn't
> change, but instead attributes should identify feature themes.
Now I am getting bitten by the vocabulary: what are "feature themes" ? ;-)
> I
> realize that this is a major change and since I don't have the time to
> do it myself, I doubt anyone else is going to take this on.
I unfortunately agree.
> Thinking long term however, it has been amply demonstrated that the
> vector library although a big improvement for the old days, still needs
> a lot of work. Memory management issues periodically arise on the
> dev list with large data streams and that data streams will continue to
> swamp memory and swap space so proper caching is required for optimal
> processing.
I'm not sure that this is directly linked to the database question,
though, or ?
> Something for the GRASS steering committee to consider is
> if we should be thinking of updating the raster library in the next
> major revision of GRASS, or instead fixing the vector library.
I think the response is not as much in the hands of the steering
committee but rather in who could work on this.
> I really
> wish I had the time to put into this, but I just don't. I'm trying to
> get something working to explore some new ideas for a new wxPython GUI,
> but haven't got very far past the drawing board yet, so I can't take
> anything on until I can get that out the door.
cqfd
>
> Still, the 'layer feature' is largely not used.
Are you sure about this ? Let's here what others say.
> If we are going to
> consider replacing it, there needs to be serious thought into how a
> database attribute based system would be implemented so that it would
> actually be easy and obvious, rather then cryptic and confusing.
Exactly, and this is why I am pushing you to give us your ideas. ;-)
I would like to come to a point where we are not only speaking about how
bad the current system is, but how _concretely_ a new system should look
like.
> If we
> can't come up with a replacement that is clearly superior then we need
> to focus efforts in renaming and documenting.
agreed.
Moritz
More information about the grass-dev
mailing list