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 functionalityIn 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 mapBWell, 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