[GRASS5] Re: Vector Manipulation

[Radim Blazek]

We were discussing for a while outside the list v.mapcalc,
some mails are: http://mpa.itc.it/radim/v.mapcalc.mails.txt
What others think about, plese join the discussion,

On Friday 14 June 2002 05:00 pm, Christoph Simon wrote:
> > > > Simple for points, but for lines, we have to work with some buffers,
> > > > will not be simple implementation.
> > >
> > > Doesn't Grass have already something to solve this? It sounds to me
> > > like a very basic, omnipresent problem.
> >
> > No, grass at present is very weak in vector manipulations, here the most
> > important work must be done. Unfortunately, AFAIK, it is not easy.
> > We are still fighting with shapefile import and cleaning utilities.
> > You are writing program, based on nonexisting functionality :)
>
> In this case, I think we must wait and keep the door open to do it
> later. These things are probably universally needed, and have to be
> solved in another place (either grass modules or grass libraries).
>
> > > Hm. There might always be some numerical values which a user might
> > > want to use symbolically rather than in digits. Probably I chose a bad
> > > example. Another example might be some kind of threshold the user
> > > wants to use to discriminate between objects, maybe after some
> > > arithmetic computation.
> >
> > But why to calculate in v.mapcalc? Should depend on results of other
> > operations? It is not probable. I know in grass about hundreds of
> > problems well defined and urgent, here we are looking for solution
> > for may be not existing problem - but of course you are totaly free
> > and coding - I am just telling what I think about that.
>
> Hm. v.mapcalc is thought to be a calculator, right? The idea of
> variables, where you can hold anything, is something which is always
> useful in a calculator. Actually,
>
> 	map = map1 op map2
>
> makes "map" certainly already a variable. Why not allow also to hold a
> numeric value? it's not so much of a problem and I think it can prove
> useful.
>
> > PROJ4 library is GRASS, that is true, but not yet any Vect_* function.
> > We have v.proj, so first should be written Vect_proj()?
>
> My perception of this is this: First we plan as if it already
> existed. When we reach the point of actually using it, we can choose
> (at least) one of two solutions: Either, it's possible to write that
> function, than we can contribute this to the general vector
> library. Or, we use some placeholder until the library function is
> available, maybe with a sensitive error message, and put it in
> later. Not so much of a problem. But I wouldn't limit the
> functionality of a generic tool like v.mapcalc because of a temporary
> limitation.
>
> > Such functions do not exist, most of work is done by modules, it is how
> > GRASS is written. Seems to me that you want to do everything what is
> > done in grass shell, in v.mapcalc. I'am not sure if it is best.
>
> Hm. I've the impression that you think that I want to duplicate
> work. This is not my goal. I pretend to create a generic vector map
> calculator which has access to just anything. True, you could do
> certain things also in a shell script, etc. But is there anything in
> Unix you can do only in one way? What I suggested wasn't an interface,
> one by one, to each grass tool, but sort of a gateway, which gives you
> access and which can be done with one single function. What is the
> difference of using a grass module interactively, from tclgrass, from
> a shell script, or from within another grass tool?  We just open one
> more possibility to take advantage of the existing modules.
>
> > v.in.shape has 13 parameters and prints various messages, do you to put
> > everything in v.mapcalc. I prefer
> > v.in.shape output=mapA
> > v.in.shape output=mapb
> > v.mapcalc mapC = mapA AND mapB
>
> Well, I guess I also prefer this, if I have one shape file. But if I
> find a site where I can download 500 shapefiles (I did actually find
> such a site), are you going to type this 500 times or would it be
> better to import them in a script. Now, if you know that you want
> certain transformations as well as integrate those file into your
> existing dataset, why not be able to write a script for v.mapcalc
> doing all this. Then you can import the whole stuff with one or at
> least with a few commands. Why is this useful? Because also geographic
> data are not really static. They can be maintained by another
> organization, and this approach will give you a very simple way to
> prepare for updates and grant the consistence of your derived dataset.
>
> > OK, but temporary map should be created in some tmp directory and
> > deleted immediately once not needed.
>
> If you have the formula:
>
> 	mapR = (map1 op1 map2) op2 map3
>
> then the result of "map1 op1 map2" should go to a temporary directory
> and be cleand as soon as possible. This is, why it get's lost even if
> it took ages to compute, when an error pops up later. But the
> resulting "mapR" should be a regular map in the regular directories,
> even if it is used in later commands in the same v.mapcalc
> session. And, of course, it should not be deleted. That's at least how
> I am seeing it.
>
> > But what should be conditionals used? I think that conditionals for maps
> > are logicaly built into spatial operators like AND or NOT.
>
> I don't know. That's why I ask. I've seen that r.mapcalc supports
> this, but I never got so far to use it or try to understand how it is
> used. Is there any analogy possible with v.mapcalc? How does this work
> in r.mapcalc?
>
> > Grass51 sql connection is based on DBMI library as interface to any
> > database, for which you have a driver.
>
> I haven't had time to get a closer look, but I think to recall that
> they split the select statement, such that you specify the tables and
> column on one end, and the WHERE clauses on the other. Actually I do
> like this idea. Even simpler than using the DBMI library might be
> using the actual grass modules. But we can see these details later.
>
> > User should not need to take care about how table is linked to map.
> > He knows of course table structure, but if he once defined which table
> > is used and by which column, it should not be necessary to define it in
> > each module.
> > GRASS50: d.vect.pg map= key= tab= where=
> > GRASS51: d.vect map= where=
>
> This is what I thought to remember. The problem is, that it doesn't
> allow for aggregate functions. You've seen, that I'm bad constructing
> examples, but I'll try once more.
>
> 	SELECT (sum pop) as prov_pop FROM locations GROUP BY province;
>
> (incomplete statement) The column pov_pop doesn't really exist, but
> can be provided thanks SQL. There might not be a choice, as actually
> creating such a table can be very huge and difficult to maintain
> (i.e., you have to recreate that second table each time you update the
> first). Most of the time, this won't be the case, but I think Grass5.1
> should not exclude this possibility. SQL is something extremely
> powerful. It would be a pitty if we couldn't use it.

Radim