[GRASS-dev] Re: [GRASS-user] RE: Problem querying layers
other than '1' in gi s.m
Michael Barton
michael.barton at asu.edu
Wed Sep 27 12:37:49 EDT 2006
I realize that Moritz has also answered, but will add a couple thoughts here
because I'm very interested in temporal GIS at the moment. See below.
Michale
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
> From: Massimiliano Cannata <massimiliano.cannata at supsi.ch>
> Date: Wed, 27 Sep 2006 10:28:49 +0200
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Moritz Lennert <mlennert at club.worldonline.be>, Trevor Wiens
> <twiens at interbaun.com>, "''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
>
> 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.
If I understand you, I think it would work better the other way around.
Case 2. Each vector "layer" (i.e., key field) can be assigned to a different
attribute table that represents the value for a particular set of vector
objects at a given time. Each "layer" links to a table that records the
state of the objects at a different time. That is, layers allow a single
vector file to be simultaneously linked to multiple attribute tables.
Case 1. For changing geometry, however, you need to have different vector
objects. In this case, you need to link different vector files (representing
objects with changing geometry) to a single attribute table. As far as I
know, you can link any number of different vector files to a single table.
For this, you would only use a single vector "layer" (i.e., key field) to
link each vector file to the table.
Here is an ugly schematic.
Case 1 (assumes number of objects stays the same, but their geometry
changes).
vector with geometry 1 (layer 1 key) ---\
vector with geometry 2 (layer 1 key) ------ (matching key) attribute table
vector with geometry 3 (layer 1 key) ---/
Case 2 (assumes unchanging vector geometry but changing attributes over
time).
vector (layer 1 key) --- (matching key) attribute table time 1
(layer 2 key) --- (matching key) attribute table time 2
(layer 3 key) --- (matching key) attribute table time 3
>
> 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-dev
mailing list