[GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m
Massimiliano Cannata
massimiliano.cannata at supsi.ch
Wed Sep 27 04:28:49 EDT 2006
Sorry to jump into the discussion, but I agree too.
Two different type vector time series exist:
1 - the geometry is changing in time, and this can be handled with layers
2 - the attribute change in time but the geometry is constant (e.g.:
rain gauges station)
For the second type, it is harder to manage in GRASS (or at least i
cannot see any one) and I usually manage it in an external database by
importing the selected tuples (the ones at a given time), and then
deleting the vector when is no more needed.
Of course it is time consuming and a better solution would be nice :-)
It would be nice to be able to create a connection with a selection from
a table and not just with the table itself.... but I know this was not
considered in developing phase and it will be a really hard work now.
I also want to highlight that in the GRASS wiki we open an article for
time series managment in GRASS
(http://grass.gdf-hannover.de/wiki/Time_series_in_GRASS), till now it
was focused on rater time series but vector time series should also be
considered
I think this a key factor in environmental modelling into GRASS because
a well defined data format for time series will allow the development of
related tool for time series analysis, visualization and managment.
Massimiliano
--
Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica (w3.ist.supsi.ch:8001/geomatica/)
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09
Michael Barton wrote:
> I agree.
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>
>
>> From: Moritz Lennert <mlennert at club.worldonline.be>
>> Date: Tue, 26 Sep 2006 20:27:11 +0200 (CEST)
>> To: Trevor Wiens <twiens at interbaun.com>
>> Cc: Michael Barton <michael.barton at asu.edu>, "''grassuser at grass.itc.it' '"
>> <grassuser at grass.itc.it>, GRASS-DEV <grass-dev at grass.itc.it>
>> Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
>> than '1' in gi s.m
>>
>> On Tue, September 26, 2006 15:37, Trevor Wiens wrote:
>>
>>> On Tue, 26 Sep 2006 11:32:38 +0200
>>> Moritz Lennert wrote:
>>>
>>>
>>>> Michael has already said most of what I wanted to say, but some small
>>>> additions.
>>>>
>>>> Michael Barton wrote:
>>>>
>>>>>> What seems much more natural to me is
>>>>>> leaving the attribute management to the database where more
>>>>>> elegant tools exist. Thus grass modules instead having a
>>>>>> layer option need a input key and possibly an output key
>>>>>> option depending on the module. If no key field is specified
>>>>>> (which would be an attribute in the table linked to the
>>>>>> vector file), then all objects in the vector file are
>>>>>> processed. However if a key is used to query the vector file
>>>>>> for a list of objects for processing. In the case where the
>>>>>> same vector object has two cats, the vector attribute tables
>>>>>> will have to have a one to many relationship from the vector
>>>>>> file to the attribute table. Now modules could also allow a
>>>>>> query specification to allow for complex querying across
>>>>>> multiple keys and attributes, but output would probably have
>>>>>> to be limited to a series of key fields (most likely only
>>>>>> integers)
>>>>>>
>>>>> Really, this is exactly what "layers" are now. AFAICT, the biggest
>>>>>
>>>> problem
>>>>
>>>>> is in the terminology. Each "layer" is an integer key field in
>>>>>
>>>> database
>>>>
>>>>> terminology. Multiple layers simply means multiple key fields, each of
>>>>>
>>>> which
>>>>
>>>>> can be linked with an attribute table using v.db.connect.
>>>>>
>>> No, not really. What I describe is functionality identical to current
>>> layers, but the critical distinction is that all the attribute
>>> information can be managed in the database independent of GRASS or
>>> without GRASS even running. Right now the cat values for a vector
>>> object can only be accessed through GRASS. If GRASS built a simple
>>> table for each vector object with a cat (or perhaps more clearly
>>> named an objectid) and a user defined key as well as allowing users to
>>> add other keys to that table, then there would be no need to run GRASS
>>> to update attribute information for those objects. For example, lets say
>>> you have a series of weather sites which would have a incremental
>>> objectid and a user defined key such as a stationid. If you want to
>>> be able to occasionally interpolate precipitation surfaces from these
>>> sites since all the attribute information is accessible independent
>>> of GRASS (I envision using PostgreSQL in this case) you can write you
>>> application in whatever environment you like and access the database
>>> outside of GRASS and add and edit new time data as needed. Then when it
>>> is time to create your new surface you fire up GRASS do your
>>> multi-table query without any call to v.db.connect because it is no
>>> longer needed and get the result. Done.
>>>
>> I don't really understand this argument. Why can't you do exactly this
>> with GRASS today ? First of all why do you need a separate objectid and
>> stationid if each station is represented by one object (let's say a point)
>> ? You could just use the cat value of each object. You would then have a
>> table in PostgreSQL in which you have these cat values (possibly in a
>> colum you could
>> call stationid) and all other attributes you would like in this same
>> table. If you get new data for the stations you can add it to the table
>> without having to go through GRASS. Then when you enter grass, this new
>> information is available as long as your map remains linked to that table.
>>
>> The only thing you cannot do currently (if I'm not mistaken) is use
>> aggregate queries on that table if you have more than one row for each
>> station. But I don't think that this is due to the general data model of
>> GRASS, but rather to the fact that it is not implemented.
>>
>>
>> [...]
>>
>>
>>>>> Again, except for the key fields confusingly labeled as "layers" and
>>>>>
>>>> one
>>>>
>>>>> other legacy feature from GRASS 5, all attribute management does stay
>>>>>
>>>> in the
>>>>
>>>>> database.
>>>>>
>>>> Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
>>>> = coniferous, cat 2 = broadleaved, cat 10 = pine, etc.
>>>>
>>>> The way it 'should' be used to stick with Trevor's suggestions is
>>>>
>>>> cat 1 = tree number 1
>>>> cat 2 = tree number 2
>>>>
>>>> etc.
>>>>
>>>> And then have a table with columns
>>>>
>>>> treenumber, species, etc,
>>>>
>>>> with possibly another table with
>>>>
>>>> species, type
>>>>
>>>> where type= conferous or broadleaved
>>>>
>>>> And then, if you need a map of coniferous and broadleaved trees, you
>>>> create a view:
>>>>
>>>> CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
>>>> trees.species=types.species
>>>>
>>>>
>>> Why bother with v.db.connect at all? Just allow a query to be used to
>>> select the vector object keys (cats) and let the module in question
>>> work with that list.
>>>
>> I think this is potentially possible with the current model, just not
>> implemented. The database drivers allow any kind of query you want, and it
>> should not be too complicated to rewrite modules in a way to allow more
>> arbitrary queries then just with the current 'where' option.
>>
>> Any query which returns cat values allows you to then work with these cat
>> values (I am currently reworking d.vect.chart to do just that) and
>> it should, therefore, not be too difficult to imagine modules which allow
>> you to define an arbitrary query and to the fulfill their task on the
>> basis of this query.
>>
>> According to the use you make of it you obviously can have a problem if
>> you have more than one object with the same cat value (I have that problem
>> in d.vect.cat, for example), but there are ways to work around this.
>>
>>
>>> I realize that many people not familiar with SQL
>>> will find this difficult, but surely we could consider as part of
>>> upgrading the GUI front end with a simple query builder.
>>>
>> I should also be possible to offer both solutions.
>>
>>
>>> A view would be convenient for ongoing use, but shouldn't be necessary
>>> for single time uses.
>>>
>> I agree totally.
>>
>> [...]
>>
>>
>>> Well changing the terminology would certainly help, but the fundamental
>>> problem was clearly defined by Moritz when he suggested that the
>>> problem is mixing of database concepts with GIS concepts. Thus my
>>> suggestion to keep database functions in the database.
>>>
>> Well GIS as such makes no sense if it is not understood as the link
>> between geometries and data, so you always have to mix the two in one way
>> or another. The question is more on how to do this in a way which is most
>> efficiently _and_ offers the most functionality.
>>
>>
>>
>>>> v.buffer is a very special case, and I don't know how you would solve
>>>> the question in your system: the attribute information is lost since
>>>> v.buffer fusions overlapping buffers into one single buffer. As
>>>> mentioned on the man page, there is no automatic way to know which cat
>>>> (or keyvalue) to give to this single fusioned buffer.
>>>>
>>> My solution would work in the sense that new areas created would be
>>> given a new objectid whereas areas (technically centroids associated
>>> with areas) up to the point of overlap would retain their original
>>> objectid and thus would have direct access to any associated attribute
>>> information through a simple query.
>>>
>> Well, it should be no problem to reprogram v.buffer to do just that. Its
>> current implementation works with the assumption that as you could
>> potentially have overlaps, you treat all buffers as if they were overlaps,
>> but you could obviously include some test in the code which treats buffers
>> differentially. Again, I don't see how this is a problem of the model
>> rather than of the implementation of a particular module.
>>
>>
>>> It is important to note that my objectid terminology only makes sense
>>> if this value is singular and immutable.
>>>
>> This might actually be the fundamental point in the argument. Currently
>> GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
>> a its line number as a unique identifier, this is just not visible to the
>> user). The question is whether it should enforce something like this, or
>> whether the current model doesn't allow more flexibility by allowing to
>> limit yourself to unique id's for each object, but also allowing the use
>> of non-unique id's, or multiple id's.
>>
>> Moritz
>>
>>
>
> _______________________________________________
> grassuser mailing list
> grassuser at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>
>
>
More information about the grass-user
mailing list