[GRASS-user] Res: grass-user Digest, Vol 20, Issue 38

Angelo_Mansur_Mendes · December 21, 2007, 9:38pm

----- Mensagem original ----
De: “grass-user-request@lists.osgeo.org” grass-user-request@lists.osgeo.org
Para: grass-user@lists.osgeo.org
Enviadas: Segunda-feira, 17 de Dezembro de 2007 13:00:07
Assunto: grass-user Digest, Vol 20, Issue 38

Send grass-user mailing list submissions to
grass-user@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body ‘help’ to
grass-user-request@lists.osgeo.org

You can reach the person managing the list at
grass-user-owner@lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of grass-user digest…”

Today’s Topics:

Re: nan values by v.generalize (Hamish)
Re: How to best access hundreds of orthophotos – mapserver
as WMS server? (Ivan Shmakov)
Re: How to best access hundreds of orthophotos – mapserver
as WMS server? (Ivan Shmakov)
Re: towgs84 datum parameters for “Hong Kong 1980” (Otto Dassau)
UTM projection problems (mhall@berkeley.edu)
r.patch example in the manual (Craig Leat)
Re: r.patch example in the manual (Martin Landa)
Re: GRASS_HTML_BROWSER (Glynn Clements)
Re: Re: How to best access hundreds of orthophotos –
mapserver as WMS server? (Glynn Clements)

Message: 1
Date: Sun, 16 Dec 2007 15:46:47 -0800 (PST)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-user] nan values by v.generalize
To: Daniel Bundala <bundala@gmail.com>, Wolf Bergenheim
<wolf+grass@bergenheim.net>
Cc: grass-user@lists.osgeo.org
Message-ID: <128490.96785.qm@web45805.mail.sp1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1

Daniel Bundala wrote:

As I mentioned in my previous post, a solution is to translate
the corresponding points little bit.
…
The patch is attached. Hope it works.

May I suggest replacing 1e-12 with GRASS_EPSILON? (defined in gis.h)

=== message truncated ===>

everyone, please do.

Hamish

Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

Message: 2
Date: Mon, 17 Dec 2007 08:18:40 +0600
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [GRASS-user] Re: How to best access hundreds of orthophotos
– mapserver as WMS server?
To: grassuser@grass.itc.it
Cc: Ivan Shmakov <oneingray@gmail.com>
Message-ID: <m2r6hmjc73.fsf@cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

Hamish <hamish_b@yahoo.com> writes:

an idea: write a little script to make a vector coversheet index.

[…]

I am not sure, but I think v.patch does not clean topology so
overlap may be ok.

Ivan:

Wouldn’t it be better to save non-overlapping parts and an
intersection as separate polygons? A separate attribute will be
needed to store the list of IDs of the covering images.

see overlapping polygon example at:
http://grass.ibiblio.org/screenshots/vector.php

Thanks, I’ll check it.

store current region

g.region save=old_region

It makes me wonder each time I see such a fragile construct like
this, will GRASS ever support overriding the region
``temporarily’'? (E. g., via a command line argument, or an
environment variable.)

there is, see GRASS_REGION and WIND_OVERRIDE shell variables:
http://grass.ibiblio.org/grass63/manuals/html63_user/variables.html

This is exactly what I’ve asked for. Thanks!

but saving & restoring g.region isn’t need for this task, it is just
being nice leaving the place as you found it. The script is not
dependent on the starting region. And I fail to see how that’s
fragile?

Consider this script being interrupted in the middle (say, by
the user hitting ^C.) Will the region be restored?

No more fragile than trusting anything else written to the disk.

It looks to me that the following will be much more robust:

export WIND_OVERRIDE=tmp_region
…

no need to store current region

g.region save=old_region

…

g.region rast=“$MAP”

…

no need to reset to original region, either

g.region old_region

[…]

And, could there be something a bit more clever than storing the
region of the image as a vector feature?

the user can get as complicated as they like…

A combination of downsampling, r.mapcalc' (to obtain the fill mask), and r.contour’, may be?

r.contour is not so good for ortho photos or high resolution land use
map with many small areas. But again, up to the user…

Actually, I meant using `r.contour’ on the downsampled fill
mask. (Meanwhile, I’ve silently switched to my own needs, which
are about the satellite data.)

[…]

Message: 3
Date: Mon, 17 Dec 2007 08:28:06 +0600
From: Ivan Shmakov <oneingray@gmail.com>
Subject: [GRASS-user] Re: How to best access hundreds of orthophotos
– mapserver as WMS server?
To: grass-user@lists.osgeo.org
Cc: Ivan Shmakov <oneingray@gmail.com>
Message-ID: <m2mysajbrd.fsf@cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

Dylan Beaudette <dylan.beaudette@gmail.com> writes:

[…]

an idea: write a little script to make a vector coversheet index.
maybe output that with the HTMLMAP driver for an interactive web brower
pull up.

[…]

And, could there be something a bit more clever than storing the
region of the image as a vector feature? A combination of
downsampling, r.mapcalc' (to obtain the fill mask), and r.contour’, may be?

Hi,

What you are asking for is starting to sound like a Mapserver driven
WMS.

Actually, I’m seeking for a some kind of cataloguing solution
for GRASS. However, setting up Mapserver is also on my TODO
list.

Here is how I have dealt with this problem in the past:

[…]

create a very simple mapfile pointing to the tile index
shapefile. I will work up an example and post it back

TIA.

fill in appropriate WMS metadata into the mapfile

use r.in.wms to import imagery into GRASS
-or-

once GDAL 1.5 is released it will be possible to an r.in.gdal and
point it to an XML file defining a WMS resource. A mini-script might
be able to construct the XML file on the fly…

Unfortunately you will still have to manage the images that are
imported into GRASS with GRASS commands, unless you constantly
overwrite a temporary set of files by always using the same names and
the --o flag.

Once you have mapserver setup WMS is quite fast and flexible - it
will even project the data on the fly to other coordinate systems.

Yes, I know. (Though I hadn’t succeed in getting it to show me
any rasters last time I’ve tried it; the software packages were
from Debian etch, if that matters.)

Message: 4
Date: Mon, 17 Dec 2007 10:55:20 +0100
From: Otto Dassau <otto.dassau@gmx.de>
Subject: Re: [GRASS-user] towgs84 datum parameters for “Hong Kong
1980”
To: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc: grass-user@lists.osgeo.org
Message-ID: 20071217105520.17c21bec@nature
Content-Type: text/plain; charset=US-ASCII

Hi Nikos and Paul

thanks a lot for your help and notes. I will test the parameters and write back
then. Maybe then, we can add the datum parameters to grass svn.

Regards,
Otto

On Thu, 13 Dec 2007 13:51:17 +0000 (GMT)
Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

On Thu, 13 Dec 2007, Otto Dassau wrote:

Hi,

I need some help to add support for “Hong Kong 1980” datum in GRASS. I
have a wkt file with following information:

PROJCS[“Hong_Kong_1980_Grid”,GEOGCS[“GCS_Hong_Kong_1980”,DATUM["D_Hong_Kong_198

0",SPHEROID[“International_1924”,6378388.0,297.0]],PRIMEM[“Greenwich”,0.0],UNIT

[“Degree”,0.0174532925199433]],PROJECTION[“Transverse_Mercator”],PARAMETER["Fal

se_Easting",836694.05],PARAMETER[“False_Northing”,819069.8],PARAMETER["Central_

Meridian",114.1785555555556],PARAMETER[“Scale_Factor”,1.0],PARAMETER["Latitude_

Of_Origin",22.31213333333334],UNIT[“Meter”,1.0]]

The datum D_Hong_Kong_1980 does not exist in GRASS yet. I found following
parameters and added them to the datum.table file:

Hong Kong Datum 1980

hk80 “Hong_Kong_1980” international dx=-156 dy=-270 dz=-189

Now I am missing the Datum Transformation Parameters to add to the
datumtransform.table.

Just to note that you do not necessarily need to add parameters to both
datum.table and datumtransform.table. If dx=-156 dy=-270 dz=-189 are
the only parameters you have, that is fine and they will be the only ones
used. An entry in datumtransform.table is only needed if you have multiple
sets of parameters for the datum, or if the only set you have available is
not a 3-parameter set.

Paul

Message: 5
Date: Mon, 17 Dec 2007 07:07:50 -0800 (PST)
From: mhall@berkeley.edu
Subject: [GRASS-user] UTM projection problems
To: grass-user@lists.osgeo.org
Message-ID:
<1378.12.74.52.211.1197904070.squirrel@calmail.berkeley.edu>
Content-Type: text/plain;charset=iso-8859-1

Hi,

I am using GRASS 6.2 on a Windows XP machine. Its the cygwin build. I
also access it from QGIS 8.1 for windows.

The problem I am noticing is reading in a satellite image (ASTER or
Landsat) and the projection and reference system I end up with. My
imagery is in Geotiff format. Reading the metadata files and the
projection info of the Geotiff of course lists the correct zone, etc.

When I load the image into GRASS via r.in.gdal and tell GRASS to create a
new location, I get a generic x,y system set-up and the UTM projection
zone is 0 (no matter where in the world I have my imagery, been tested on
several sets of images…). I go in and reset the projection, bt once I
exit GRASS, the projection defaults back. Oddly enough, the projection it
creates is consistent in terms of overlays, etc. And even odder, when I
import an image in lat-lon it creates that.

Any suggestions on what I am making a mess of?

Best, Mark Hall

Message: 6
Date: Mon, 17 Dec 2007 07:37:33 -0800 (PST)
From: Craig Leat <Craig@pid.co.za>
Subject: [GRASS-user] r.patch example in the manual
To: grass-user@lists.osgeo.org
Message-ID: <14372554.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii

Hello List

I’m trying the r.patch example given in the manual for 6.3.0RC3 and there
appears to be a problem passing the output from g.mlist to g.region. So, in
fact, I haven’t managed to try r.patch yet. I followed the example and this
is what I got back:

GRASS 6.3.0RC3 (msunduzi_lo31):~ > MAPS='g.mlist type=rast sep=,
pat=“.red"’
GRASS 6.3.0RC3 (msunduzi_lo31):~ > echo $MAPS
g.mlist type=rast sep=, pat=".red”
GRASS 6.3.0RC3 (msunduzi_lo31):~ > g.region rast=$MAPS
Sorry, is not a valid parameter
Sorry, is not a valid parameter
Sorry, is not a valid parameter

I guess I need to tell bash to evaluate MAPS rather than just expanding the
variable, but I am not sure how. Pointers are welcome…

Thanks

Craig.

View this message in context: http://www.nabble.com/r.patch-example-in-the-manual-tp14372554p14372554.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Message: 7
Date: Mon, 17 Dec 2007 16:51:01 +0100
From: “Martin Landa” <landa.martin@gmail.com>
Subject: Re: [GRASS-user] r.patch example in the manual
To: “Craig Leat” <Craig@pid.co.za>
Cc: grass-user@lists.osgeo.org
Message-ID:
<f8fe65c40712170751p4a06e4e4wc9c7f338ef444619@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2007/12/17, Craig Leat <Craig@pid.co.za>:

I’m trying the r.patch example given in the manual for 6.3.0RC3 and there
appears to be a problem passing the output from g.mlist to g.region. So, in
fact, I haven’t managed to try r.patch yet. I followed the example and this
is what I got back:

GRASS 6.3.0RC3 (msunduzi_lo31):~ > MAPS=‘g.mlist type=rast sep=,
pat=“*.red”’

Instead of ’ use ` …

MAPS=g.mlist type=rast sep=, pat="*.red"

GRASS 6.3.0RC3 (msunduzi_lo31):~ > echo $MAPS
g.mlist type=rast sep=, pat=“*.red”
GRASS 6.3.0RC3 (msunduzi_lo31):~ > g.region rast=$MAPS
Sorry, is not a valid parameter
Sorry, is not a valid parameter
Sorry, is not a valid parameter

Martin

–
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

Message: 8
Date: Mon, 17 Dec 2007 17:05:01 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-user] GRASS_HTML_BROWSER
To: Craig Leat <Craig@pid.co.za>
Cc: grass-user@lists.osgeo.org
Message-ID: <18278.44093.56346.971962@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii

Craig Leat wrote:

If I click: Help → GRASS help on the tcl/tk gui, GRASS tries to launch
konqueror when what I want is firefox. g.manual -i on the commandline gives
me firefox. I have set GRASS_HTML_BROWSER in two places (see below), but I
guess I still need to set the variable some place else?

GRASS 6.3.0RC3 (msunduzi_lo31):~ > more .grass.bashrc
export GRASS_HTML_BROWSER=firefox
GRASS 6.3.0RC3 (msunduzi_lo31):~ > g.gisenv
GISDBASE=/home/craig/GIS/grassdata
MAPSET=sewer
LOCATION_NAME=msunduzi_lo31
GRASS_HTML_BROWSER=firefox
GRASS_GUI=tcltk
GRASS 6.3.0RC3 (msunduzi_lo31):~ >

Any ideas on what I’m missing?

GRASS_HTML_BROWSER is an environment variable rather than a GRASS
variable, so setting it via g.gisenv won’t help.

Also setting it in ~/.grass.bashrc will only affect the GRASS shell
and programs launched from it. If you have gis.m launched at startup,
it won’t be affected.

You can set it in ~/.bash_profile (etc) to have it apply everywhere,
but that won’t affect any shells which are already running. For an
existing shell, type “export GRASS_HTML_BROWSER=firefox” before
starting GRASS.

–
Glynn Clements <glynn@gclements.plus.com>

Message: 9
Date: Mon, 17 Dec 2007 17:09:44 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-user] Re: How to best access hundreds of
orthophotos – mapserver as WMS server?
To: Ivan Shmakov <oneingray@gmail.com>
Cc: grassuser@grass.itc.it
Message-ID: <18278.44376.912469.193779@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii

Ivan Shmakov wrote:

Also the “for MAP in ``” method would need to be changed if there are
thousands of maps?

I don’t think so. Since the `for’ command is internal to the
Shell, there’s no command line to be passed to any other
process, and so there’re no command line length limits in force.

Still, using COMMAND | while read VARN ; do …; done looks more
clean to me.

The while/read approach saves keeping the list of maps in memory. Once
upon a time, that might have mattered; with modern systems, you would
need millions of maps before it became an issue.

–
Glynn Clements <glynn@gclements.plus.com>

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

End of grass-user Digest, Vol 20, Issue 38

Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!