Re: [GRASS-user] Problems with v.to.db after breaking with v.edit

[Daniel Torres]

Does this helps you?
v.category input=map_of_vedit output=map2 option=add layer=2
v.db.addtable map=map2 layer=2 table=table2

In that way you preserve original information in layer1, and new categories
in layer2

Hopefully that will be useful. Maybe someone has a better idea.

Daniel





>Dear list

>I break a number of features in a vector map into two pieces using
>v.edit, tool=break and specific coordinates. This results in two parts
>with identical attributes after breaking (which is what I want) but also
>the cat is identical.
>I think, this is the reason why I get exactly the same length for the
>two parts when calculating it using v.to.db, tool=length. Likewise, the
>end coordinates cannot be computed as there is more than one element for
>some categories.

>How can I update the category to unique values for each feature?

>Thanks for any suggestions,
>Mira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] grass run_command within python/grass script

[alassane toure]

Group,
I am running a grass-python script but when i replace a variable argument
within the command the script does not work

The following works...
grass.run_command('r.in.gdal',
input='/home/alassane/Data/SanbornCD/tile/newconstr_mask.tif',
output='construction')

But not this...
command="'r.in.gdal', input='"+sys.argv[5]+"', output='construction'"
print 'r.in.gdal command argument... = %s\n ' % command
grass.run_command(command)

print 'r.in.gdal command argument... = %s\n ' % command
r.in.gdal command argument... = 'r.in.gdal',
input='/home/alassane/Data/SanbornCD/tile/newconstr_mask.tif',
output='construction'


The following also works...
command ="/home/alassane/Programs/gdal/demclass1"+" "+infile1+" "+infile2+"
"+sys.argv[3]+" "+outfile
os.system(command)

Your help is appreciated.

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

Re: [GRASS-user] Error when using r.viewshed.cva

[Adam Hoffritz]

Oh, yes I forgot to mention that I'm not sure if the error is because of a
lack of space or if the files are named in the wrong way. I suppose space
is the problem, i thought I had moved everything to a location with enough
space. Maybe I didn't move the right directory.

Bestu kveðjur,
Adam Hoffritz

2016-08-10 14:39 GMT+00:00 Anna Petrášová :

> Hello,
>
> On Wed, Aug 10, 2016 at 10:32 AM, Adam Hoffritz
>  wrote:
> > Good day,
> > When trying to run r.viewshed.cva i keep getting this error (see below)
> > (This is the entire report, you can see the inputs).
> > Am I missing something obvious? I do not use Grass often, work mostly on
> > ArcGis but I am moving towards Grass.
> >
> > r.viewshed.cva input=Clip_haedarlikan@RHIVidsyni
> > vector=Grass_vidsyniPrufa@RHIVidsyni output=prufa
> > Note that the routine is constrained to points in the current geographic
> > region.
> > Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode.
> > WARNING: Illegal filename  >>. Character <
> >> not allowed.
> > ERROR: AMI_STREAM::write_item failed.
> > C:\Users\Adam\Desktop\LUK-GIS\GRASS/RHIvidsyni/RHIVidsyni/.t
> > mp/unknown/14496.0/STREAM_bX: No space left on device
>
>
> Here I can see "No space left on device". Could you please check if
> you have enough space on the disk?
>
> Best,
>
> Anna
>
> > Traceback (most recent call last):
> >   File "C:\Users\Adam\AppData\Roaming\GRASS7\addons/scripts/
> > r.viewshed.cva.py", line 174, in 
> > main()
> >   File "C:\Users\Adam\AppData\Roaming\GRASS7\addons/scripts/
> > r.viewshed.cva.py", line 159, in main
> > grass.run_command("r.viewshed", quiet = True,
> > overwrite=grass.overwrite(), flags=flagstring, input=elev,
> > output=tempry, coordinates=site[0] + "," + site[1],
> > **viewshed_options)
> >   File "C:\Program Files\GRASS GIS
> > 7.0.4\etc\python\grass\script\core.py", line 395, in
> > run_command
> > return handle_errors(returncode, returncode, args,
> > kwargs)
> >   File "C:\Program Files\GRASS GIS
> > 7.0.4\etc\python\grass\script\core.py", line 313, in
> > handle_errors
> > returncode=returncode)
> > grass.exceptions.CalledModuleError: Module run None
> > ['r.viewshed', '--q', 'observer_elevation=1.75',
> > 'input=Clip_haedarlikan@RHIVidsyni',
> > 'refraction_coeff=0.14286',
> > 'coordinates=445499.767,492499.8253', 'memory=500',
> > 'max_distance=-1', 'output=vshed_0\r',
> > 'target_elevation=1.75'] ended with error
> > Process ended with non-zero return code 1. See errors in the
> > (error) output.
> > (Wed Aug 10 13:48:32 2016) Command finished (2 sec)
> >
> > Regards,
> > Adam Hoffritz
> >
> > ___
> > 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] some questions on r.tile

[Blumentrath, Stefan]

In the meantime you could try the following as a workaround:

Create a grid (v.mkgrid) for your tiles, 
then loop over the tiles and set the region to your tile plus / minus the 
overlap you like to have at the boundaries after checking that current boundary 
does not exceed north or south limits.

It seems that g.region does not wrap latitudinal boundaries in the north, while 
it does for longitudinal limits and rounds latitudinal boundaries in the south. 

Compare output from:
g.region -p n=90 s=-90 w=-180 e=180

g.region -p n=n+1 s=s-1 w=w-1 e=e+1

g.region -p n=n s=s-1 w=w-1 e=e+1

in a lat/lon location.

Cheers
Stefan

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

Re: [GRASS-user] some questions on r.tile

[Markus Neteler]

Hi Margherita,

On Thu, Aug 11, 2016 at 10:09 AM, Margherita Di Leo  wrote:
> Ciao Markus! Thanks for your answer,
> On Wed, Aug 10, 2016 at 8:00 PM, Markus Neteler  wrote:
>> Which projection are you using?
>> I suspect latlong?
>
> yes, correct.
...
> r.tile input=bln300_mosaic output=tiled width=14400 height=9600 overlap=4 --v
> ERROR: Illegal latitude for North

I guess that the distance value must be given in degree when in
LatLong since I cannot see any geodesic support in r.tile (it does
exist e.g. in r.grow.distance). Internally it calculates with the
coordinates.

Probably r.tile is not yet suitable for LatLong?

Test case:

g.region res=1 n=90 s=-90 w=-180 e=180 -p
r.mapcalc "myarea = 1"
r.tile input=myarea output=tiled width=14400 height=9600 overlap=4
ERROR: Illegal latitude for North

Please open a ticket for this.

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

Re: [GRASS-user] some questions on r.tile

[Margherita Di Leo]

Ciao Markus! Thanks for your answer,

On Wed, Aug 10, 2016 at 8:00 PM, Markus Neteler  wrote:

> Hi
>
> On Aug 10, 2016 4:34 PM, "Margherita Di Leo"  wrote:
> >
> > ERROR: Illegal latitude for North
>
> Which projection are you using?
> I suspect latlong?
>
yes, correct.

> > How should I calculate my overlap and my tiles in order to avoid this
> problem?
>
> Please let us know more.. Perhaps also the command with parameters.
>
The data source I'm using is GMTED 2010 at 30 arc second spatial
resolution, global coverage --> created VRT --> linked via r.external -->
set g.region rast=

g.region rast=bln300_mosaic -ap
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  89:59:59.5N
south:  70:00:00.5S
west:   179:59:59.5E
east:   179:59:59.5E
nsres:  0:00:30
ewres:  0:00:30
rows:   19200
cols:   43200
cells:  82944

I wanted to try create 6 large tiles as a first tentative, to see how
r.tile works.
Then i calculate them like this:
rows: 19200 / 2 = 9600
cols: 43200 / 3 = 14400

r.tile input=bln300_mosaic output=tiled width=14400 height=9600 overlap=4
--v
ERROR: Illegal latitude for North

hm..



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

Re: [GRASS-user] Data ranges of geotiff not preserved after import to GRASS

[Markus Metz]

On Wed, Aug 10, 2016 at 10:29 PM, Bill Hudspeth  wrote:
> Hello
>
> I am trying to import a multiband geotiff into GRASS 7.0.3 (running on Ubuntu 
> 16.01). The gdalinfo output shows the 4 bands, and their data ranges. Both my 
> geotiff and my GRASS location are in the projection UTM Zone 13N, WGS84 
> (epsg:32613). My GRASS region is 0.5 meters to import a panchromatic band, 
> but the 4 bands in the multiband file are 2.0 m resolution. After I import, 
> the data ranges of the 4 new grass rasters are very different from those 
> listed in the gdalinfo output below.

The data ranges reported by GRASS exceed those reported by GDAL. Most
probably the data ranges reported by GDAL are approximations and thus
a subset of the real ranges. Try gdalinfo -mm
o10APR11180709-M2AS-02078010_01_P001.tif and check if min/max
values change.

Markus M

>
> gdalinfo o10APR11180709-M2AS-02078010_01_P001.tif
> Driver: GTiff/GeoTIFF
> Files: o10APR11180709-M2AS-02078010_01_P001.tif
>o10APR11180709-M2AS-02078010_01_P001.tif.aux.xml
> Size is 3534, 2684
> Coordinate System is:
> PROJCS["WGS 84 / UTM zone 13N",
> 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",-105],
> PARAMETER["scale_factor",0.9996],
> PARAMETER["false_easting",50],
> PARAMETER["false_northing",0],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","32613"]]
> Origin = (318626.000,3848648.000)
> Pixel Size = (2.000,-2.000)
> Metadata:
>   AREA_OR_POINT=Area
>   TIFFTAG_ARTIST=PCI
>   TIFFTAG_DATETIME=2010:04:11 18:07:09
>   TIFFTAG_SOFTWARE=PCI Geomatica
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  (  318626.000, 3848648.000) (106d58'54.51"W, 34d45'49.98"N)
> Lower Left  (  318626.000, 3843280.000) (106d58'50.35"W, 34d42'55.81"N)
> Upper Right (  325694.000, 3848648.000) (106d54'16.62"W, 34d45'54.41"N)
> Lower Right (  325694.000, 3843280.000) (106d54'12.63"W, 34d43' 0.24"N)
> Center  (  322160.000, 3845964.000) (106d56'33.53"W, 34d44'25.13"N)
> Band 1 Block=3534x2 Type=UInt16, ColorInterp=Red
>   Min=145.000 Max=473.000
>   Minimum=145.000, Maximum=473.000, Mean=286.443, StdDev=29.355
>   NoData Value=0
>   Metadata:
> STATISTICS_MAXIMUM=473
> STATISTICS_MEAN=286.44285428343
> STATISTICS_MINIMUM=145
> STATISTICS_STDDEV=29.354503358529
> Band 2 Block=3534x2 Type=UInt16, ColorInterp=Green
>   Min=150.000 Max=771.000
>   Minimum=150.000, Maximum=771.000, Mean=447.144, StdDev=61.481
>   NoData Value=0
>   Metadata:
> STATISTICS_MAXIMUM=771
> STATISTICS_MEAN=447.14438693812
> STATISTICS_MINIMUM=150
> STATISTICS_STDDEV=61.481469436348
> Band 3 Block=3534x2 Type=UInt16, ColorInterp=Blue
>   Min=116.000 Max=940.000
>   Minimum=116.000, Maximum=940.000, Mean=566.192, StdDev=92.234
>   NoData Value=0
>   Metadata:
> STATISTICS_MAXIMUM=940
> STATISTICS_MEAN=566.19172957414
> STATISTICS_MINIMUM=116
> STATISTICS_STDDEV=92.234459276031
> Band 4 Block=3534x2 Type=UInt16, ColorInterp=Undefined
>   NoData Value=0
>
>
> My outputs from r.info for the 4 imported bands are below...Why are the data 
> ranges not correct??
>
> ++
>  | Map:  o10APR11180709_M2AS_02078  Date: Wed Aug 10 14:21:20 2016
> |
>  | Mapset:   worldview2 Login of Creator: wilbur  
> |
>  | Location: PotteryMound 
> |
>  | DataBase: /home/wilbur/grass_data  
> |
>  | Title: ( o10APR11180709_M2AS_02078010_01_P001.1 )  
> |
>  | Timestamp: none
> |
>  
> ||
>  |
> |
>  |   Type of Map:  raster   Number of Categories: 0   
> |
>  |   Data Type:CELL   
> |
>  |   Rows: 2684   
> |
>  |   Columns:  3534   
> |
>  |   Total Cells:  9485256
> |
>  |Projection: UTM (zone 13)   
> |
>  |N:3848648S:3843280   Res: 2 
> |
>  |E: