Re: [GRASS-user] Copying from a mapset in another data directory

[Nikos Alexandris]

Jonathan Greenberg wrote:
> Excellent -- symlinking is working properly -- now on to my next
> question -- is there a way to do some level of "batch" g.copy using a
> wildcard, e.g.:
> 
> g.copy rast=ned_ca_masked_epsg331...@comet
> 
> Or do I have to specific each raster individually, along with its
> target file name?

Jonathan, would a for loop + g.mlist + g.copy get the job done? For example:

  for X in `g.mlist rast pat=ned_ca_masked_epsg3310_* mapset=comet` ; do 
g.copy rast="${X}","${X}" ; done

Nikos

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

Re: [GRASS-user] v.split length=? in latlon

[Markus Neteler]

On Fri, May 21, 2010 at 6:59 PM, Achim Kisseler
 wrote:
> Hi,
>
> in v.split:
> I wonder what units are be used as length in a lat-lon environment?
>
> Are these degrees?

I am afraid yes since it uses Vect_line_length(). Certainly this is
rather useless.

The doxygen documentation for that function suggests:
   "For Lat-Long use Vect_line_geodesic_length() instead."

> Why isn't there an option for m, km,..?

The "easiest" way would be to manage things as done in v.distance.

Please open an enhancement report in trac for this.

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

Re: [GRASS-user] Copying from a mapset in another data directory

[Jonathan Greenberg]

Excellent -- symlinking is working properly -- now on to my next
question -- is there a way to do some level of "batch" g.copy using a
wildcard, e.g.:

g.copy rast=ned_ca_masked_epsg331...@comet

Or do I have to specific each raster individually, along with its
target file name?

--j


On Wed, May 19, 2010 at 8:30 PM, Glynn Clements
 wrote:
>
> Jonathan Greenberg wrote:
>
>> So assuming that we have duplicated the projection info from one
>> filesystem to the next (the case I'm dealing with is running out of
>> space on one filesystem, and we needed to continue work on another but
>> using the same projection info) -- if I create mapset on one of the
>> two filesystems, and then symlink it within the identical location on
>> the other filesystem, would this work to allow me to g.copy (or,
>> indeed, allow me to reference the files using @ from both
>> filesystems?)
>
> Probably.
>
> Accessing it shouldn't be a problem, although selecting the symlink as
> the current mapset *might* have issues with something expecting the
> mapset directory to actually be a directory. In the event that this
> does happen, on Linux you can use a "bind mount" to effectively move a
> directory to a different location on the file system.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.watershed multi flow direction

[Markus Neteler]

On Fri, May 21, 2010 at 1:27 PM, Kristian Foerster  wrote:
>
> Hi,
>
> I am using GRASS 6.4.0RC5+39438 (downloaded from svn server). I would like
> to obtain basins and stream segments from digital elevation data using the
> multi flow option in r.watershed as proposed in the documentation. The
> installed version of r.watershed obviously doesn't support this feature:
>
> Sorry,  is not a valid flag
> Sorry,  is not a valid parameter
>
> Is there another version of the program available supporting this function?

You need to update your 6.4 installation. It has been backported by Markus Metz
3 weeks ago:
http://trac.osgeo.org/grass/changeset/42121

A simple
svn up
in your source code directory should get all updates for you.

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

Re: [GRASS-user] r.watershed error

[Kurt Springs]

Thanks Markus,

Let me make sure I understand.  For best results I need to set the resolution 
to 10m for the 1/3 arcsec.  With the region set as it is (most of Northern New 
England) when I do this I run out of memory.  To over come this, I can set the 
region to just encompass just the NED13_01 subregion.  Would it look like 
g.region zoom=NED13_01 align=NED13_01?

Might this also solve another problem I am having with r.watershed.  When the 
various functions are run, I have the map, plus "stuff" in the NULL area out 
side the map region.

Thanks for the help.

Kurt
On May 24, 2010, at 4:37 AM, Markus Metz wrote:

> On Sun, May 23, 2010 at 8:10 PM, Kurt Springs  wrote:
>> Problem was the resolution it starts working when I set it to 100m.  The dem
>> is ~69 x 27 km.
> 
> Apparently, the dem has a resolution of 1/3 arcsec (~10m), maybe
> reprojected and resampled. With these extends, there would be about
> 186 million cells in the input map which is not a lot. I have
> successfully processed regions with ~250 million cells in memory and
> ~500 million cells in segmented mode. Make sure the current
> computational region matches the resolution of the input dem and the
> extends of the current computational region do not exceed the extends
> of the input map. Setting the computational region to a smaller area
> within the dem coverage is fine, as long as g.region -p align=NED13_01
> is used after adjusting the extends. A resolution of 100m throws away
> a lot of the information present in the original dem.
> 
> 
>> Thanks
>> On May 23, 2010, at 12:00 PM, Rich Shepard wrote:
>> 
>> On Sat, 22 May 2010, Kurt Springs wrote:
>> 
>> ERROR: G_malloc: unable to allocate 18446744070980740804 bytes at ...
>> 
>>   
>> 
>> Any idea what I'm doing wrong?
>> 
>> Kurt,
>> 
>>   Look at the amount of memory your file wants to be allocated: several
>> Petabytes. How much area is covered by that DEM and at what resolution? Even
>> with GRASS compiled for large file support your file is _way_ too large.
>> 
>> Rich
>> 
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> 
>> 

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

Re: [GRASS-user] Importing Landsat images with different coordinates

[Micha Silver]

On 05/24/2010 06:26 PM, Jenny Turner wrote:

Hi

Following this topic I have tested this methodology by converting from 
UTM 29N to a specific local coordinate system (EPSG:3763) (available 
at PROJ4)

gdalwarp -t_srs "EPSG:3763" band_landsat.TIF destination.tif

With that I got a segmentation error, one TIFFReadDirectory a lot of 
TIFFWriteEncodedStrip and the destination.tif has a different size.




Can you send the output of:  gdalinfo band_landsat.TIF


Any tips of what migh be wrong?

Thank you
Jenny

On Tue, May 18, 2010 at 8:42 PM, Micha Silver > wrote:


Jenny Turner wrote:

Greetings
Firman, but imagine that I have rasters in UTM for differente
zones (e.g. huge countries like USA, etc). How can I produce
an automatic importing tool that uses gdalwarp to project an
image to WGS84 and import to GRASS?

Using gdalwarp you don't have to specify the source coordinate
system, *if* the originals have the correct projection defined in
their headers. For Landsat images, this is most likely the case,
so you should be able to get away with just setting the -t_srs
option of gdalwarp and each tile will be re-projected to the WGS84
geographic CRS.

Thanks for your help
Best regards,
Jenny

On Mon, May 17, 2010 at 11:10 PM, Firman Hadi
mailto:jalmibur...@gmail.com>
>>
wrote:

   Hi,

   As far as I know you must define the source coordinate system.
   I think it is pretty straightforward when you are using
gdalwarp.
   If there are so many images, maybe you can create a shell
script
   to run the process.

   Cheers,

>

   Firman Hadi
   Center for Remote Sensing - ITB
   Jl. Ganesha No. 10,
   Labtek IX-C, 3rd Floor
   Bandung - 40132
   INDONESIA
   Phone: +62-22-2530701
   Fax: +62-22-2530702
   Website : http://crs.itb.ac.id ; www.sigro.org
 

   Blog : http://jalmiburung.wordpress.com
   JepratJepret: http://jalmiburung.fotografer.net











This mail was received via Mail-SeCure System.


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

This mail was received via Mail-SeCure System.





-- 
Micha Silver

Arava Development Co. +972-52-3665918
http://www.surfaces.co.il




This mail was received via Mail-SeCure System.



--
Micha Silver
Arava Development Co. +972-52-3665918
http://surfaces.co.il


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

Re: [GRASS-user] conditional dissolve

[Markus Neteler]

On Mon, May 24, 2010 at 3:30 PM, A. Marcia BARBOSA
 wrote:
> Hi,
>
> I'm using the shapefile of the GADM database of Global Administrative
> Areas (http://www.gadm.org), but the subdivisions of some countries
> (such as Spain, Slovenia and others) are too small. In order to get
> divisions that are more evenly sized among all countries, I need to
> dissolve sub-regions to regions, but only within some of the
> countries. Is there a way to use a "conditional dissolve" on only some
> selected countries?

In GRASS, "v.dissolve" is just a frontend to "v.extract -d ...". Since
the latter has
a "where" parameter, you could try with that.

Please report, perhaps it makes sense to add the "where" parameter to
v.dissolve then.

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

Re: [GRASS-user] Using an external hard drive as data source

[Hamish]

Hanlie  wrote:
> I'm using GRASS 6.4 on two machines in different locations
> (one Win XP,
> the other Ubuntu 10.04), so I would like to keep my
> grassdata folder
> on an external drive. However, when I try to run grass in
> Ubuntu using
> the external hard drive (NTFS file system), I get the
> following error
> as soon as I've selected the new data location and the GUI
> starts to
> load:
> -
> Execution failed: 'g.region -u -g -p -c'
> 
> Details:
> Error: MAPSET PERMANENT - permission denied
> -
> 
> To run GRASS, I use the command 'sudo grass -wx'.
> 
> GRASS works fine when I run it from the internal hard
> drive.
> 
> Is there a way to get GRASS to work from the external
> drive?


there should be a FAQ entry for this, but I can't find it on
the wiki!?

the quick answer is that you have to mount the external hard
drive so it is owned by the same user you will run grass with.
(typically your own user account and not root, as that is much
safer).

mount -o uid=[your user id]

or add this in the /etc/fstab file.

you'll have to look in /etc/passwd to see what your user
account's UID number is.


Hamish


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

Re: [GRASS-user] Warnings while importing Kompsat-2 images

[Hamish]

> Luis wrote:
> Hi thereI imported Kompsat-2 images using r.in.gdal and I gfot
> this warnings:rning 1: TIFFFetchNormalTag:ASCII value for
> tag"DocumentName" does not end in null byteWarning 1:
> TIFFFetchNormalTag:ASCII value for tag
> "ImageDescription" does not end in null byteWarning 1:
> TIFFFetchNormalTag:ASCII value for tag "Artist"does not end in
> null byteWarning 1: TIFFFetchNormalTag:ASCII value for tag
> "HostComputer" does not end in null byteProjection of input
> dataset and current location appear to match
> What is the origin of this? Or what can I do to avoid this?
> Kompsat-2 images are followed by an header txt. can that be
> useful?
> Because it has recognized projection, the resolution is the
> same and even nº of cols/rows.

I believe these are actually GDAL warning messages and not GRASS
ones. Will gdalinfo and/or gdal_translate work with the files?


Hamish




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

Re: [GRASS-user] Using an external hard drive as data source

[Jarek Jasiewicz]

Hanlie Pretorius pisze:

Hi,

I'm using GRASS 6.4 on two machines in different locations (one Win XP,
the other Ubuntu 10.04), so I would like to keep my grassdata folder
on an external drive. However, when I try to run grass in Ubuntu using
the external hard drive (NTFS file system), I get the following error
as soon as I've selected the new data location and the GUI starts to
load:
-
Execution failed: 'g.region -u -g -p -c'

Details:
Error: MAPSET PERMANENT - permission denied
-

To run GRASS, I use the command 'sudo grass -wx'.

GRASS works fine when I run it from the internal hard drive.

Is there a way to get GRASS to work from the external drive?

Thanks
Hanlie
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  
Do you have write permission on your ntfs disk? It is possible that disk 
is mounted on ubuntu as read -only.

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

Re: [GRASS-user] Georrectification using points

[Hamish]

Luisa wrote:
> I have a few very-high resolution images that I need to 
> georrectify in GRASS. Outside GRASS I created a text file with
> GCP position in the image and its real-coordinates.
> I have read this: http://grass.osgeo.org/wiki/Georeferencing
> I tried to use i.rectify but I didn't see no place to
> define/add GCP's. And the manual is not clear regarding where
> to insert the points... Can anyone help me?

you can add to the POINTS file manually (create some dummy test,
points to see the simple text file format), or maybe more easily
use gdal_translate to add the GCPs to a geotiff then import 
that.


Hamish



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

[GRASS-user] Georrectification using points

[Luisa Peña]

Greetings

I have a few very-high resolution images that I need to georrectify in
GRASS. Outside GRASS I created a text file with GCP position in the image
and its real-coordinates. I have read this:
http://grass.osgeo.org/wiki/Georeferencing
I tried to use i.rectify but I didn't see no place to define/add GCP's. And
the manual is not clear regarding where to insert the points... Can anyone
help me?

By the way: What is the difference between NEW WAY and EXTRA NEW WAY ?
Aren't they the same?

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

[GRASS-user] Warnings while importing Kompsat-2 images

[Luis Lisboa]

Hi there
I imported Kompsat-2 images using r.in.gdal and I gfot this warnings:
rning 1: TIFFFetchNormalTag:ASCII value for tag
"DocumentName" does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag
"ImageDescription" does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag "Artist"
does not end in null byte
Warning 1: TIFFFetchNormalTag:ASCII value for tag
"HostComputer" does not end in null byte
Projection of input dataset and current location appear to match

What is the origin of this? Or what can I do to avoid this? Kompsat-2 images
are followed by an header txt. can that be useful?
Because it has recognized projection, the resolution is the same and even nº
of cols/rows.

Thanks

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

Re: [GRASS-user] Importing Landsat images with different coordinates

[Jenny Turner]

Hi

Following this topic I have tested this methodology by converting from UTM
29N to a specific local coordinate system (EPSG:3763) (available at PROJ4)
gdalwarp -t_srs "EPSG:3763" band_landsat.TIF destination.tif

With that I got a segmentation error, one TIFFReadDirectory a lot of
TIFFWriteEncodedStrip
and the destination.tif has a different size.

Any tips of what migh be wrong?
Thank you
Jenny

On Tue, May 18, 2010 at 8:42 PM, Micha Silver  wrote:

> Jenny Turner wrote:
>
>  Greetings
>> Firman, but imagine that I have rasters in UTM for differente zones (e.g.
>> huge countries like USA, etc). How can I produce an automatic importing tool
>> that uses gdalwarp to project an image to WGS84 and import to GRASS?
>>
> Using gdalwarp you don't have to specify the source coordinate system, *if*
> the originals have the correct projection defined in their headers. For
> Landsat images, this is most likely the case, so you should be able to get
> away with just setting the -t_srs option of gdalwarp and each tile will be
> re-projected to the WGS84 geographic CRS.
>
>  Thanks for your help
>> Best regards,
>> Jenny
>>
>> On Mon, May 17, 2010 at 11:10 PM, Firman Hadi > jalmibur...@gmail.com>> wrote:
>>
>>Hi,
>>
>>As far as I know you must define the source coordinate system.
>>I think it is pretty straightforward when you are using gdalwarp.
>>If there are so many images, maybe you can create a shell script
>>to run the process.
>>
>>Cheers,
>>
>>>
>>
>>Firman Hadi
>>Center for Remote Sensing - ITB
>>Jl. Ganesha No. 10,
>>Labtek IX-C, 3rd Floor
>>Bandung - 40132
>>INDONESIA
>>Phone: +62-22-2530701
>>Fax: +62-22-2530702
>>Website : http://crs.itb.ac.id ; www.sigro.org 
>>
>>Blog : http://jalmiburung.wordpress.com
>>JepratJepret: http://jalmiburung.fotografer.net
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> This mail was received via Mail-SeCure System.
>> 
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>>
>>
>
>
> --
> Micha Silver
> Arava Development Co. +972-52-3665918
> http://www.surfaces.co.il
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] conditional dissolve

[A. Marcia BARBOSA]

Hi,

I'm using the shapefile of the GADM database of Global Administrative
Areas (http://www.gadm.org), but the subdivisions of some countries
(such as Spain, Slovenia and others) are too small. In order to get
divisions that are more evenly sized among all countries, I need to
dissolve sub-regions to regions, but only within some of the
countries. Is there a way to use a "conditional dissolve" on only some
selected countries?

Cheers
Márcia
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Using an external hard drive as data source

[Hanlie Pretorius]

Hi,

I'm using GRASS 6.4 on two machines in different locations (one Win XP,
the other Ubuntu 10.04), so I would like to keep my grassdata folder
on an external drive. However, when I try to run grass in Ubuntu using
the external hard drive (NTFS file system), I get the following error
as soon as I've selected the new data location and the GUI starts to
load:
-
Execution failed: 'g.region -u -g -p -c'

Details:
Error: MAPSET PERMANENT - permission denied
-

To run GRASS, I use the command 'sudo grass -wx'.

GRASS works fine when I run it from the internal hard drive.

Is there a way to get GRASS to work from the external drive?

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

Re: [GRASS-user] r.watershed error

[Markus Metz]

On Sun, May 23, 2010 at 8:10 PM, Kurt Springs  wrote:
> Problem was the resolution it starts working when I set it to 100m.  The dem
> is ~69 x 27 km.

Apparently, the dem has a resolution of 1/3 arcsec (~10m), maybe
reprojected and resampled. With these extends, there would be about
186 million cells in the input map which is not a lot. I have
successfully processed regions with ~250 million cells in memory and
~500 million cells in segmented mode. Make sure the current
computational region matches the resolution of the input dem and the
extends of the current computational region do not exceed the extends
of the input map. Setting the computational region to a smaller area
within the dem coverage is fine, as long as g.region -p align=NED13_01
is used after adjusting the extends. A resolution of 100m throws away
a lot of the information present in the original dem.


> Thanks
> On May 23, 2010, at 12:00 PM, Rich Shepard wrote:
>
> On Sat, 22 May 2010, Kurt Springs wrote:
>
> ERROR: G_malloc: unable to allocate 18446744070980740804 bytes at ...
>
>   
>
> Any idea what I'm doing wrong?
>
> Kurt,
>
>   Look at the amount of memory your file wants to be allocated: several
> Petabytes. How much area is covered by that DEM and at what resolution? Even
> with GRASS compiled for large file support your file is _way_ too large.
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user