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

[Hamish]

Jonathan wrote:
> Incidentally, this would be a good feature to add to g.copy.

I wouldn't mind to review a g.mcopy prototype in addons svn, but
probably the reason this hasn't happened already is that usally
you can use g.mapsets to add the other mapset to the search path
so the "don't want to type @ all the time" need is avoided.
(that doesn't help if you are trying to compile a release mapset
from a bunch or working ones of course)


Hamish



  
___
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

[Nikos Alexandris]

Jonathan Greenberg wrote:
> This ALMOST works, except "from" needs to take the form
> rastern...@mapset and "to" needs the form rastername.  I can get the
> "from" setup properly by appending "-m" to the gmlist call, but how do
> I subsequently strip the @comet part for the "to" statement?

With the following (untested though):

for X in `g.mlist rast pat=ned_ca_masked_epsg3310_* mapset=comet -m` ; do
g.copy rast="${X}",`echo "${X}"|cut -d "@" -f1`
done

Nikos

> Thanks!
> 
> Incidentally, this would be a good feature to add to g.copy.
> 
> --j

-
> On Mon, May 24, 2010 at 8:40 PM, Nikos Alexandris
> 
>  wrote:
> > 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] r.grow.distance

[Glynn Clements]

fengel wrote:

> I produced an uncontinuous distance map as a result of r.grow.distance. Most
> parts of the distance map are smooth but there are some sharp edges in the
> map. This means that with a 100m resolution of the map in most parts of the
> map the distance value increases about 100 m with every pixel. At the sharp
> edges there are leaps of up to 1000m from pixel to pixel. Depending on the
> color map used for displaying the distance map you can also see these jumps
> clearly.

Can you provide a test case?

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

[GRASS-user] r.grow.distance

[fengel]

Dear list,

I produced an uncontinuous distance map as a result of r.grow.distance. Most
parts of the distance map are smooth but there are some sharp edges in the
map. This means that with a 100m resolution of the map in most parts of the
map the distance value increases about 100 m with every pixel. At the sharp
edges there are leaps of up to 1000m from pixel to pixel. Depending on the
color map used for displaying the distance map you can also see these jumps
clearly.
Has anyone experienced the same?

Cheers Falko
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/r-grow-distance-tp5100098p5100098.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
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]

This ALMOST works, except "from" needs to take the form
rastern...@mapset and "to" needs the form rastername.  I can get the
"from" setup properly by appending "-m" to the gmlist call, but how do
I subsequently strip the @comet part for the "to" statement?  Thanks!

Incidentally, this would be a good feature to add to g.copy.

--j

On Mon, May 24, 2010 at 8:40 PM, Nikos Alexandris
 wrote:
> 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] Get current location projection in a Python Script

[Nikos Alexandris]

Kim Besson:
> >>> I'm building a GRASS Python Script to automatically import a set of
> >>> data to my location. At GRASS book (chapter 3.3.3) it uses g.proj -wf
> >>> to to check current location projection. Can I use the same command in
> >>> Python to retrieve the same?

> >>> And how about calling gdalwarp in a Python-GRASS Script? can it be
> >>> called and used by a Python_GRASS Script? if so, is there any Python
> >>> example with that?
> >>> 
> >>> Regarding "g.proj -wf" command. I get a lot of information. I suppose
> >>> GDALWARP can read this right ? If not, How can I obtain current
> >>> Location EPSG code? 

Michael Barton:
> >> Use the region() command from the GRASS Python library.
> >> 

Nikos Alexandris:
> > Just for the records, a thread not _directly_ about it but close
> > (enough?):
> >  > -a- script-tc2787474.html#a2788062>
 
> The thread is for BASH and does not work for Python.

Michael, the thread started for bash but in the last posts (in it) python 
stuff are demonstrated ( I recall so). Maybe I've posted directly a post where 
no "python" is included? Hmm... let me see... ... ok, here it is:

1. http://www.mail-archive.com/grass-user@lists.osgeo.org/msg08280.html
2. http://www.mail-archive.com/grass-user@lists.osgeo.org/msg08288.html

Maybe they are outdated though (?).

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

Re: [GRASS-user] Get current location projection in a Python Script

[Michael Barton]

On May 25, 2010, at 8:25 AM, Nikos Alexandris wrote:

> Kim Besson:
>>> I'm building a GRASS Python Script to automatically import a set of data
>>> to my location. At GRASS book (chapter 3.3.3) it uses g.proj -wf to to
>>> check current location projection. Can I use the same command in Python
>>> to retrieve the same?
>>> 
>>> 
>>> And how about calling gdalwarp in a Python-GRASS Script? can it be called
>>> and used by a Python_GRASS Script? if so, is there any Python example
>>> with that?
>>> 
>>> Regarding "g.proj -wf" command. I get a lot of information. I suppose
>>> GDALWARP can read this right ? If not, How can I obtain current Location
>>> EPSG code?
> 
> Michael Barton: 
>> Use the region() command from the GRASS Python library.
>> 
> 
> Just for the records, a thread not _directly_ about it but close (enough?):
>  script-tc2787474.html#a2788062>
> 
> Nikos

The thread is for BASH and does not work for Python.

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

Re: [GRASS-user] Get current location projection in a Python Script

[Nikos Alexandris]

Kim Besson:
> > I'm building a GRASS Python Script to automatically import a set of data
> > to my location. At GRASS book (chapter 3.3.3) it uses g.proj -wf to to
> > check current location projection. Can I use the same command in Python
> > to retrieve the same?
> > 
> > 
> > And how about calling gdalwarp in a Python-GRASS Script? can it be called
> > and used by a Python_GRASS Script? if so, is there any Python example
> > with that?
> > 
> > Regarding "g.proj -wf" command. I get a lot of information. I suppose
> > GDALWARP can read this right ? If not, How can I obtain current Location
> > EPSG code?

Michael Barton: 
> Use the region() command from the GRASS Python library.
> 

Just for the records, a thread not _directly_ about it but close (enough?):


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

Re: [GRASS-user] Get current location projection in a Python Script

[Michael Barton]

On May 25, 2010, at 1:29 AM, grass-user-requ...@lists.osgeo.org wrote:

> Date: Tue, 25 May 2010 08:50:10 +0100
> From: Kim Besson 
> Subject: [GRASS-user] Get current location projection in a Python
>   Script
> To: grass-user@lists.osgeo.org
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Greetings
> 
> I'm building a GRASS Python Script to automatically import a set of data to
> my location. At GRASS book (chapter 3.3.3) it uses g.proj -wf to to check
> current location projection. Can I use the same command in Python to
> retrieve the same?
> 
> 
> And how about calling gdalwarp in a Python-GRASS Script? can it be called
> and used by a Python_GRASS Script? if so, is there any Python example with
> that?
> 
> Regarding "g.proj -wf" command. I get a lot of information. I suppose
> GDALWARP can read this right ? If not, How can I obtain current Location
> EPSG code?
> 
> Thanks
> 
> Best regards,
> Kim

Use the region() command from the GRASS Python library. 


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

Re: [GRASS-user] Multi-scale Segmentation

[Nikos Alexandris]

Pedro Roma: 
> I'm planning on using GRASS to do some landcover classification and I
> wanted to know if anyone has developed, for GRASS, a multi-scale
> segmentation algorithm? or integrated on GRASS a similar segmentator from
> other software.

Probably of your interest:
- 
- 

Regards, Nikos
___
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]

Sorry Micha

My original Landsat image:
Driver: GTiff/GeoTIFF
Files: L71203033_0332601_B10.TIF
   L71203033_0332601_B10.aux
   L71203033_0332601_B10.rrd
Size is 8161, 7141
Coordinate System is:
PROJCS["WGS 84 / UTM zone 29N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","32629"]]
Origin = (521999.9941792,4414200.000)
Pixel Size = (30.000,-30.000)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  522000.000, 4414200.000) (  8d44'33.81"W, 39d52'39.24"N)
Lower Left  (  522000.000, 4199970.000) (  8d44'58.57"W, 37d56'49.39"N)
Upper Right (  766830.000, 4414200.000) (  5d52'54.42"W, 39d50'9.31"N)
Lower Right (  766830.000, 4199970.000) (  5d57'53.91"W, 37d54'29.39"N)
Center  (  644415.000, 4307085.000) (  7d20'4.58"W, 38d54'2.83"N)
Band 1 Block=8161x1 Type=Byte, ColorInterp=Gray
  Min=0.000 Max=255.000
  Minimum=0.000, Maximum=255.000, Mean=60.374, StdDev=43.530
  Overviews: 2041x1786, 1021x893, 511x447, 256x224, 128x112, 64x56
  Metadata:
STATISTICS_MINIMUM=0
STATISTICS_MAXIMUM=255
STATISTICS_MEAN=60.374122874202
STATISTICS_MEDIAN=8.5986839406512e-287
STATISTICS_MODE=1.7801025473311e-306
STATISTICS_STDDEV=43.529818998446
LAYER_TYPE=athematic

And the obtained file:
Driver: GTiff/GeoTIFF
Files: destination.TIF
Size is 8229, 7218
Coordinate System is:
PROJCS["ETRS89 / Portugal TM06",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221010042,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",39.668258],
PARAMETER["central_meridian",-8.1331084],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","3763"]]
Origin = (-54187.411212536622770,23417.314857349840167)
Pixel Size = (30.006036956002887,-30.006036956002887)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  -54187.411,   23417.315) (  8d45'59.52"W, 39d52'38.78"N)
Lower Left  (  -54187.411, -193166.260) (  8d44'57.96"W, 37d55'35.73"N)
Upper Right (  192732.267,   23417.315) (  5d52'51.29"W, 39d51'26.27"N)
Lower Right (  192732.267, -193166.260) (  5d56'29.99"W, 37d54'28.07"N)
Center  (   69272.428,  -84874.473) (  7d20'4.40"W, 38d54'3.73"N)
Band 1 Block=8229x1 Type=Byte, ColorInterp=Gray

Hope this helps you (and mee :D )

Thank you
Jenny

2010/5/25 Micha Silver 

>  On 05/25/2010 11:17 AM, Jenny Turner wrote:
>
> Yes Sure :)
>
>  Attached to this email you can find the log
>
>
> I was thinking of just the results of gdalinfo. This way we can see if the
> tiff is being recognized, and if its CRS is is available in the tiff header.
>
> Here's an example:
>
> ~>gdalinfo geodata/DSASC/landsat/p174r038_7t20020308_z36_nn10.tif
> Driver: GTiff/GeoTIFF
> Files: geodata/DSASC/landsat/p174r038_7t20020308_z36_nn10.tif
> Size is 8577, 7573
> Coordinate System is:
> PROJCS["WGS 84 / UTM zone 36N",
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]],
> PROJECTION["Transverse_Mercator"],
> PARAMETER["latitude_of_origin",0],
> PARAMETER["central_meridian",33],
> PARAMETER["scale_factor",0.9996],
> PARAMETER["false_easting",50],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","32636"]]
> Origin = (603487.500,3623062.500)
> Pixel Size = (28.500,-28.500)
> Metadata:
>   TIFFTAG_XRESOLUTION=72
>   TIFFTAG_YRESOLUTION=72
>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
>   AREA_OR_POINT=Point
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  (  603487.500, 3623062.500) ( 34d 6'16.43"E, 32d44'25.92"N)
> Lower Left  (  603487.500, 3407232.000) ( 34d 4'54.01"E, 30d47'37.09"N)

[GRASS-user] Rectify images without coordinates

[Gilbert Ferrara]

Greetings

I have a couple of images, without any coordinates information, that I need
to georrectify using GRASS. My main concern is regarding r.in.gdal with -o
option: If I do this, will I loose some image resolution or extent?

Thank you
Gilbert
___
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/25/2010 11:17 AM, Jenny Turner wrote:

Yes Sure :)

Attached to this email you can find the log


I was thinking of just the results of gdalinfo. This way we can see if 
the tiff is being recognized, and if its CRS is is available in the tiff 
header.


Here's an example:

~>gdalinfo geodata/DSASC/landsat/p174r038_7t20020308_z36_nn10.tif
Driver: GTiff/GeoTIFF
Files: geodata/DSASC/landsat/p174r038_7t20020308_z36_nn10.tif
Size is 8577, 7573
Coordinate System is:
PROJCS["WGS 84 / UTM zone 36N",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",33],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",50],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","32636"]]
Origin = (603487.500,3623062.500)
Pixel Size = (28.500,-28.500)
Metadata:
  TIFFTAG_XRESOLUTION=72
  TIFFTAG_YRESOLUTION=72
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Point
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  603487.500, 3623062.500) ( 34d 6'16.43"E, 32d44'25.92"N)
Lower Left  (  603487.500, 3407232.000) ( 34d 4'54.01"E, 30d47'37.09"N)
Upper Right (  847932.000, 3623062.500) ( 36d42'38.00"E, 32d41'25.66"N)
Lower Right (  847932.000, 3407232.000) ( 36d38'1.81"E, 30d44'49.94"N)
Center  (  725709.750, 3515147.250) ( 35d22'58.18"E, 31d44'58.41"N)
Band 1 Block=8577x1 Type=Byte, ColorInterp=Gray





Thanks for your help

On Mon, May 24, 2010 at 8:46 PM, Micha Silver > wrote:


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 mailto:mi...@arava.co.il>> 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

[GRASS-user] Multi-scale Segmentation

[Pedro Roma]

Hi there,

I'm planning on using GRASS to do some landcover classification and I wanted
to know if anyone has developed, for GRASS, a multi-scale segmentation
algorithm? or integrated on GRASS a similar segmentator from other software.

Thanks

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

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

[Hanlie Pretorius]

Thanks for all the replies.

I reformatted the external drive as FAT and let Ububtu mount it
itself, without editing fstab.

Then I started GRASS without the sudo option and by selecting the data
folder using the /media/volume_name/grassdata path.

2010/5/24, Glynn Clements :
>
> Hanlie Pretorius wrote:
>
>> I'm using GRASS 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?
>
> You must be the owner of the directory for the current mapset.
>
> If you're mounting a FAT filesystem, you can use the uid= mount option
> to set the ownership of the files. However, I don't know what the
> situation is with NTFS, as it has its own permission model.
>
> --
> Glynn Clements 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Get current location projection in a Python Script

[Kim Besson]

Greetings

I'm building a GRASS Python Script to automatically import a set of data to
my location. At GRASS book (chapter 3.3.3) it uses g.proj -wf to to check
current location projection. Can I use the same command in Python to
retrieve the same?


And how about calling gdalwarp in a Python-GRASS Script? can it be called
and used by a Python_GRASS Script? if so, is there any Python example with
that?

Regarding "g.proj -wf" command. I get a lot of information. I suppose
GDALWARP can read this right ? If not, How can I obtain current Location
EPSG code?

Thanks

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

Re: [GRASS-user] v.split length

[Hamish]

Markus wrote:
> I just though: if v.distance can do it (also fractal
> perhaps), then v.split could be enriched...

( v.distance, v.to.db, and v.what all (conditionally) use 
Vect_line_geodesic_length() when the location is lat/lon )

ok, so maybe in future we could have a Vect_line_length2() which called either
Vect_line_cartesian_length() or Vect_line_geodesic_length() depending
on the result of (G_projection() == PROJECTION_LL), much like G_distance()
does already.

then less if/else coding in the modules, right?


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

[Luis Lisboa]

Hello Hamish


On Mon, May 24, 2010 at 6:50 PM, Hamish  wrote:
>
>
> I believe these are actually GDAL warning messages and not GRASS
> ones. Will gdalinfo and/or gdal_translate work with the files?
>
>
> Yes they do work...
___
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]

Kurt Springs wrote:
> Thanks Markus,
>
> Let me make sure I understand.  For best results I need to set the resolution 
> to 10m for the 1/3 arcsec.

That's not enough, the current computational region must be aligned to
the dem, otherwise you might have the same resolution, but the
computational grid can be shifted against the dm grid. Further on, if
the dem resolution is 1/3 arcsec, the resolution of the computational
region should be 1/3 arcsec as well, unless you have reprojected the
dem to a real projection.

> 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?

g.region rast=NED13_01

does that too.

>
> 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.

That is what I meant with that the extends of the computational region
must be within the extends of the dem, otherwise large areas with NULL
are loaded to memory, this only increases memory demands but nothing
is (should be) calculated for NULL cells.

Recommended reading:
http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html
here the first part explaining the computational region

and the g.region manual
http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html

HTH,

Markus

>
> 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] v.split length=? in latlon

[Achim Kisseler]

Am 24.05.2010 23:35, schrieb Markus Neteler:

Please open an enhancement report in trac for this.


I'll do.

Thanks for response, Markus!

Achim
___
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]

Oops,

>
> Recommended reading:
> http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html
> here the first part explaining the computational region
>
> and the g.region manual
> http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html

http://grass.osgeo.org/grass64/manuals/html64_user/g.region.html

of course

>
> HTH,
>
> Markus
>
>>
>> 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