Dear all,
is PostGIS as is supported by GRASS ? Is it possible to import table
with PostGIS column into Grass ? I've had some problem (the_geom is
not supported etc.). If not, exists some plans to do that ?
Thank you,
Peter
Ing.Peter Misovic wrote:
Dear all,
is PostGIS as is supported by GRASS ? Is it possible to import table
with PostGIS column into Grass ? I've had some problem (the_geom is
not supported etc.). If not, exists some plans to do that ?Thank you,
Peter
Hello,
OGR support postgis, so I think it's possible to import and export with v.in.ogr and v.out.ogr.
Laurent
Ok thank you for your information.
My original idea (or what I like to see working :)) was that Grass
could read data directly from Postgres/PostGIS database and react on
database change. Or could it be done through OGR ? Or. I'm just
aksing.
Thank you,
Peter
On 2/26/06, Laurent Courty <lrntct@gmail.com> wrote:
Ing.Peter Misovic wrote:
> Dear all,
>
> is PostGIS as is supported by GRASS ? Is it possible to import table
> with PostGIS column into Grass ? I've had some problem (the_geom is
> not supported etc.). If not, exists some plans to do that ?
>
> Thank you,
>
> Peter
Hello,OGR support postgis, so I think it's possible to import and export with
v.in.ogr and v.out.ogr.Laurent
It's my understanding that GRASS can read files from PostGIS via OGR, but it imports them into its own database structure. Since the two databases are fairly different, I don't think GRASS can read and write directly from PostGIS (although I'd love to see that). Please correct me if I'm wrong.
Tim
__________________________________________
Tim De Chant
University of California, Berkeley
Environmental Science, Policy, and Management
137 Mulford Hall #3114
Berkeley, CA 94720-3114
(510) 643-3910
On Feb 26, 2006, at 1:06 PM, Ing.Peter Misovic wrote:
Ok thank you for your information.
My original idea (or what I like to see working :)) was that Grass
could read data directly from Postgres/PostGIS database and react on
database change. Or could it be done through OGR ? Or. I'm just
aksing.Thank you,
PeterOn 2/26/06, Laurent Courty <lrntct@gmail.com> wrote:
Ing.Peter Misovic wrote:Dear all,
is PostGIS as is supported by GRASS ? Is it possible to import table
with PostGIS column into Grass ? I've had some problem (the_geom is
not supported etc.). If not, exists some plans to do that ?Thank you,
Peter
Hello,
OGR support postgis, so I think it's possible to import and export with
v.in.ogr and v.out.ogr.Laurent
HI,
the problem is that I don't know 
But probably you're right.
Peter
On 2/27/06, Tim De Chant <dechant@nature.berkeley.edu> wrote:
It's my understanding that GRASS can read files from PostGIS via OGR,
but it imports them into its own database structure. Since the two
databases are fairly different, I don't think GRASS can read and
write directly from PostGIS (although I'd love to see that). Please
correct me if I'm wrong.Tim
__________________________________________
Tim De Chant
University of California, Berkeley
Environmental Science, Policy, and Management
137 Mulford Hall #3114
Berkeley, CA 94720-3114
(510) 643-3910On Feb 26, 2006, at 1:06 PM, Ing.Peter Misovic wrote:
> Ok thank you for your information.
> My original idea (or what I like to see working :)) was that Grass
> could read data directly from Postgres/PostGIS database and react on
> database change. Or could it be done through OGR ? Or. I'm just
> aksing.
>
>
> Thank you,
> Peter
>
>
>> On 2/26/06, Laurent Courty <lrntct@gmail.com> wrote:
>> Ing.Peter Misovic wrote:
>>> Dear all,
>>>
>>> is PostGIS as is supported by GRASS ? Is it possible to import table
>>> with PostGIS column into Grass ? I've had some problem (the_geom is
>>> not supported etc.). If not, exists some plans to do that ?
>>>
>>> Thank you,
>>>
>>> Peter
>> Hello,
>>
>> OGR support postgis, so I think it's possible to import and export
>> with
>> v.in.ogr and v.out.ogr.
>>
>> Laurent
>>
Hello Tim,
On Mon, 27 Feb 2006 12:20:29 -0800 Tim De Chant
<dechant@nature.berkeley.edu> wrote:
It's my understanding that GRASS can read files from PostGIS via
OGR, but it imports them into its own database structure. Since the
two databases are fairly different, I don't think GRASS can read and
write directly from PostGIS (although I'd love to see that). Please
correct me if I'm wrong.
Thats correct. PostGIS RW-support will be a (outstanding) wish for some
time. Perhaps the OSGEO-foundation can focus on such themes...
I would like to see that done as well
Best
Stephan
--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508
Hi all,
I am trying to do a mapcalc between two maps, the first one is a dsm (digital
surface model) and the second is a dtm (digital terrain model).
The dsm is defined only where there are features on the surface and the dtm is
defined all over the region.
I would like to fill the holes in the dsm map with the correspondets values of
the dtm using a mapcalc:
r.mpacalc "new_map=if(dsm,dsm,dtm)"
Using this command I obtain a new map equal to the dsm map.
If I use these instead:
r.mpacalc "new_map=if(dsm!=null(),dsm,dtm)"
r.mpacalc "new_map=if(dsm==null(),dtm,dsm)"
I obtain two maps with all values nan.
Do someone knows the right way to do this mapcalc?
Thanks in advance...
Silvia
--
____________________________________________________________________________
HydroloGIS - Environmental Open Source Solutions
Via Siemens, 19
39100 Bolzano
www.hydrologis.com
Silvia Franceschi
Environmental Engineer
tel: +390471068066
mobile: +393384501332
email: silvia.franceschi@hydrologis.com
____________________________________________________________________________
try the function, of r.mapcalc, isnull()
it is a new function and it help solving these problems
I don't remember very well the sintax but you can check it on the man
page...
hope this help....
Il giorno mar, 28/02/2006 alle 10.06 +0100, Silvia Franceschi ha
scritto:
Hi all,
I am trying to do a mapcalc between two maps, the first one is a dsm (digital
surface model) and the second is a dtm (digital terrain model).
The dsm is defined only where there are features on the surface and the dtm is
defined all over the region.
I would like to fill the holes in the dsm map with the correspondets values of
the dtm using a mapcalc:r.mpacalc "new_map=if(dsm,dsm,dtm)"
Using this command I obtain a new map equal to the dsm map.
If I use these instead:
r.mpacalc "new_map=if(dsm!=null(),dsm,dtm)"
r.mpacalc "new_map=if(dsm==null(),dtm,dsm)"I obtain two maps with all values nan.
Do someone knows the right way to do this mapcalc?
Thanks in advance...
Silvia
--
Ivan Marchesini
Department of Civil and Environmental Engineering
University of Perugia
Via G. Duranti 93/a
06125
Perugia (Italy)
e-mail: marchesini@unipg.it
ivan.marchesini@gmail.com
tel: +39(0)755853760
fax: +39(0)755853756
I tried and it goes, the right command is:
r.mapcalc "result=if(isnull(dsm),dtm,dsm)"
Thanks to all for the help
Silvia
try the function, of r.mapcalc, isnull()
it is a new function and it help solving these problems
I don't remember very well the sintax but you can check it on the man
page...hope this help....
Il giorno mar, 28/02/2006 alle 10.06 +0100, Silvia Franceschi ha
scritto:
> Hi all,
> I am trying to do a mapcalc between two maps, the first one is a dsm
> (digital surface model) and the second is a dtm (digital terrain model).
> The dsm is defined only where there are features on the surface and the
> dtm is defined all over the region.
> I would like to fill the holes in the dsm map with the correspondets
> values of the dtm using a mapcalc:
>
> r.mpacalc "new_map=if(dsm,dsm,dtm)"
>
> Using this command I obtain a new map equal to the dsm map.
>
> If I use these instead:
>
> r.mpacalc "new_map=if(dsm!=null(),dsm,dtm)"
> r.mpacalc "new_map=if(dsm==null(),dtm,dsm)"
>
> I obtain two maps with all values nan.
>
> Do someone knows the right way to do this mapcalc?
>
> Thanks in advance...
>
> Silvia
--
____________________________________________________________________________
HydroloGIS - Environmental Open Source Solutions
Via Siemens, 19
39100 Bolzano
www.hydrologis.com
Silvia Franceschi
Environmental Engineer
tel: +390471068066
mobile: +393384501332
email: silvia.franceschi@hydrologis.com
____________________________________________________________________________
--
____________________________________________________________________________
HydroloGIS - Environmental Open Source Solutions
Via Siemens, 19
39100 Bolzano
www.hydrologis.com
Silvia Franceschi
Environmental Engineer
tel: +390471068066
mobile: +393384501332
email: silvia.franceschi@hydrologis.com
____________________________________________________________________________
Silvia Franceschi wrote:
I am trying to do a mapcalc between two maps, the first one is a dsm (digital
surface model) and the second is a dtm (digital terrain model).
The dsm is defined only where there are features on the surface and the dtm is
defined all over the region.
I would like to fill the holes in the dsm map with the correspondets values of
the dtm using a mapcalc:r.mpacalc "new_map=if(dsm,dsm,dtm)"
Using this command I obtain a new map equal to the dsm map.
If I use these instead:
r.mpacalc "new_map=if(dsm!=null(),dsm,dtm)"
r.mpacalc "new_map=if(dsm==null(),dtm,dsm)"I obtain two maps with all values nan.
Do someone knows the right way to do this mapcalc?
As Ivan suggested, you need to use isnull(). I'll elaborate on this
slightly.
The behaviour of null values in r.mapcalc is similar to the way that
floating-point arithmetic handles NaN. Almost any expression which
involves a null value will itself evaluate to null.
The easiest way to understand how null values are handled is to treat
null as representing an "unknown" value.
E.g. in the above, "dsm == null()" is interpreted as "dsm == x", where
x is unknown. As the value of x is unknown, whether or not it is equal
to dsm is also unknown. Hence, the expression "dsm == null()"
evaluates to null.
Similarly, "null() == null()" is interpreted as "x == y", where both x
and y are unknown, so again the result is null.
The only cases where expressions involving null values don't evaluate
to null are isnull() and cases where the operands which are null never
have any effect upon the result, i.e.:
1. if() expressions where the "unused" branch is null:
if(0,null,b) == b
if(1,a,null) == a
2. eval() expressions, where arguments other than the last are null:
eval(null,null,null,x) == x
In every other case, if any operand is null, the result is null.
However, there is one slight flaw in the "null means unknown"
interpretation. r.mapcalc doesn't do any arithmetic optimisations, so
you can get a null result even in specific cases where the result
isn't actually unknown, e.g. the following all evaluate to null:
null * 0
eval(x = null(), x - x)
eval(x = null(), sin(x) ^ 2 + cos(x) ^ 2 - 1)
eval(x = int(null()), y = int(null()), z = int(null()), n = int(null()), \
x > 0 && y > 0 && z > 0 && n > 2 && x ^ n + y ^ n == z ^ n)
Theoretically, all of these should evaluate to zero according to the
"null means unknown" interpretation (well, the last one probably
does). In practice, it would be trivial to make the first expression
evaluate to zero, harder for the second, much harder for the third,
and essentially impossible for the last.
--
Glynn Clements <glynn@gclements.plus.com>
On Tuesday 28 February 2006 03:24 pm, Glynn Clements wrote:
Silvia Franceschi wrote:
> I am trying to do a mapcalc between two maps, the first one is a dsm
> (digital surface model) and the second is a dtm (digital terrain model).
> The dsm is defined only where there are features on the surface and the
> dtm is defined all over the region.
> I would like to fill the holes in the dsm map with the correspondets
> values of the dtm using a mapcalc:
>
> r.mpacalc "new_map=if(dsm,dsm,dtm)"
>
> Using this command I obtain a new map equal to the dsm map.
>
> If I use these instead:
>
> r.mpacalc "new_map=if(dsm!=null(),dsm,dtm)"
> r.mpacalc "new_map=if(dsm==null(),dtm,dsm)"
>
> I obtain two maps with all values nan.
>
> Do someone knows the right way to do this mapcalc?As Ivan suggested, you need to use isnull(). I'll elaborate on this
slightly.The behaviour of null values in r.mapcalc is similar to the way that
floating-point arithmetic handles NaN. Almost any expression which
involves a null value will itself evaluate to null.The easiest way to understand how null values are handled is to treat
null as representing an "unknown" value.E.g. in the above, "dsm == null()" is interpreted as "dsm == x", where
x is unknown. As the value of x is unknown, whether or not it is equal
to dsm is also unknown. Hence, the expression "dsm == null()"
evaluates to null.Similarly, "null() == null()" is interpreted as "x == y", where both x
and y are unknown, so again the result is null.The only cases where expressions involving null values don't evaluate
to null are isnull() and cases where the operands which are null never
have any effect upon the result, i.e.:1. if() expressions where the "unused" branch is null:
if(0,null,b) == b
if(1,a,null) == a2. eval() expressions, where arguments other than the last are null:
eval(null,null,null,x) == x
In every other case, if any operand is null, the result is null.
However, there is one slight flaw in the "null means unknown"
interpretation. r.mapcalc doesn't do any arithmetic optimisations, so
you can get a null result even in specific cases where the result
isn't actually unknown, e.g. the following all evaluate to null:null * 0
eval(x = null(), x - x)
eval(x = null(), sin(x) ^ 2 + cos(x) ^ 2 - 1)
eval(x = int(null()), y = int(null()), z = int(null()), n = int(null()), \
x > 0 && y > 0 && z > 0 && n > 2 && x ^ n + y ^ n == z ^ n)Theoretically, all of these should evaluate to zero according to the
"null means unknown" interpretation (well, the last one probably
does). In practice, it would be trivial to make the first expression
evaluate to zero, harder for the second, much harder for the third,
and essentially impossible for the last.
Wow. I think that some of these little snippets of wisdom should find their
way into some of the relevant documentation... just a matter of finding the
time...
Cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
Dylan Beaudette wrote:
Wow. I think that some of these little snippets of wisdom should find their
way into some of the relevant documentation... just a matter of finding the
time...
Actually, I've written a similar explanation in a previous email; much
of that appears to have already made it into the r.mapcalc manpage
(under the heading "NULL support").
--
Glynn Clements <glynn@gclements.plus.com>
On Wednesday 01 March 2006 09:38 am, Glynn Clements wrote:
Dylan Beaudette wrote:
> Wow. I think that some of these little snippets of wisdom should find
> their way into some of the relevant documentation... just a matter of
> finding the time...Actually, I've written a similar explanation in a previous email; much
of that appears to have already made it into the r.mapcalc manpage
(under the heading "NULL support").
Indeed. I guess that I have never really read the r.mapcalc man page before!
Great job.
Cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
> > Wow. I think that some of these little snippets of wisdom should
> > find their way into some of the relevant documentation... just a
> > matter of finding the time...
Indeed a lot (many/most) of these little idiosyncrasies are not GRASS or
r.mapcalc specific. The same rules apply to the handling of numbers by
many programming languages and scientific software. Programs like Excel
will happily ignore null values, but this isn't quite correct
mathematically. Many hardcore programs (like Matlab) insist on doing
the "right thing" and will act the same way as GRASS. So it is hard to
say which bit of documentation to fit it in to. e.g. GRASS conforms
to many common UNIX conventions which many new users are not familiar
with. Some help must be given but re-documenting all of UNIX is beyond
us. This is a big reason I don't mind spending a little more time learning
how to do something in GRASS actually.. any skill I pick up is usually
transferable to other unrelated software & tasks which makes picking up
new stuff (like GMT or Matlab scripting) that much easier.
Hamish