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

Angelo Mansur Mendes angelomansur at yahoo.com.br
Fri Dec 21 16:38:20 EST 2007


----- Mensagem original ----
De: "grass-user-request em lists.osgeo.org" <grass-user-request em lists.osgeo.org>
Para: grass-user em 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 em 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 em lists.osgeo.org

You can reach the person managing the list at
    grass-user-owner em 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:

  1. Re: nan values by v.generalize (Hamish)
  2. Re: How to best access hundreds of orthophotos --    mapserver
      as WMS server? (Ivan Shmakov)
  3. Re: How to best access hundreds of orthophotos --    mapserver
      as WMS server? (Ivan Shmakov)
  4. Re: towgs84 datum parameters for "Hong Kong 1980" (Otto Dassau)
  5. UTM projection problems (mhall em berkeley.edu)
  6. r.patch example in the manual (Craig Leat)
  7. Re: r.patch example in the manual (Martin Landa)
  8. Re: GRASS_HTML_BROWSER (Glynn Clements)
  9. 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 em yahoo.com>
Subject: Re: [GRASS-user] nan values by v.generalize
To: Daniel Bundala <bundala em gmail.com>,    Wolf Bergenheim
    <wolf+grass em bergenheim.net>
Cc: grass-user em lists.osgeo.org
Message-ID: <128490.96785.qm em 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 em gmail.com>
Subject: [GRASS-user] Re: How to best access hundreds of orthophotos
    --    mapserver as WMS server?
To: grassuser em grass.itc.it
Cc: Ivan Shmakov <oneingray em gmail.com>
Message-ID: <m2r6hmjc73.fsf em cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

>>>>> Hamish  <hamish_b em 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 em gmail.com>
Subject: [GRASS-user] Re: How to best access hundreds of orthophotos
    --    mapserver as WMS server?
To: grass-user em lists.osgeo.org
Cc: Ivan Shmakov <oneingray em gmail.com>
Message-ID: <m2mysajbrd.fsf em cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

>>>>> Dylan Beaudette <dylan.beaudette em 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:

[...]

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

    TIA.

> 6. fill in appropriate WMS metadata into the mapfile

> 7. use r.in.wms to import imagery into GRASS
> -or-
> 7. 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 em gmx.de>
Subject: Re: [GRASS-user] towgs84 datum parameters for "Hong Kong
    1980"
To: Paul Kelly <paul-grass em stjohnspoint.co.uk>
Cc: grass-user em lists.osgeo.org
Message-ID: <20071217105520.17c21bec em 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 em 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 em berkeley.edu
Subject: [GRASS-user] UTM projection problems
To: grass-user em lists.osgeo.org
Message-ID:
    <1378.12.74.52.211.1197904070.squirrel em 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 em pid.co.za>
Subject: [GRASS-user] r.patch example in the manual
To: grass-user em lists.osgeo.org
Message-ID: <14372554.post em 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, <type> is not a valid parameter
Sorry, <sep> is not a valid parameter
Sorry, <pat> 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 em gmail.com>
Subject: Re: [GRASS-user] r.patch example in the manual
To: "Craig Leat" <Craig em pid.co.za>
Cc: grass-user em lists.osgeo.org
Message-ID:
    <f8fe65c40712170751p4a06e4e4wc9c7f338ef444619 em mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2007/12/17, Craig Leat <Craig em 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, <type> is not a valid parameter
> Sorry, <sep> is not a valid parameter
> Sorry, <pat> is not a valid parameter

Martin

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


------------------------------

Message: 8
Date: Mon, 17 Dec 2007 17:05:01 +0000
From: Glynn Clements <glynn em gclements.plus.com>
Subject: Re: [GRASS-user] GRASS_HTML_BROWSER
To: Craig Leat <Craig em pid.co.za>
Cc: grass-user em lists.osgeo.org
Message-ID: <18278.44093.56346.971962 em 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 em gclements.plus.com>


------------------------------

Message: 9
Date: Mon, 17 Dec 2007 17:09:44 +0000
From: Glynn Clements <glynn em gclements.plus.com>
Subject: Re: [GRASS-user] Re: How to best access hundreds of
    orthophotos --    mapserver as WMS server?
To: Ivan Shmakov <oneingray em gmail.com>
Cc: grassuser em grass.itc.it
Message-ID: <18278.44376.912469.193779 em 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 em gclements.plus.com>


------------------------------

_______________________________________________
grass-user mailing list
grass-user em 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!
http://br.mail.yahoo.com/
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20071221/cc9c2389/attachment-0001.html


More information about the grass-user mailing list