Re: [GRASS-user] GeoPDF into GRASS?
On Thu, May 3, 2012 at 1:11 AM, Stephen Sefick sas0...@auburn.edu wrote: Is there a way to bring a GeoPDF into GRASS? many thanks, While I have no experience with that format, I see that GDAL supports it: http://www.gdal.org/frmt_pdf.html So, r.in.gdal should do the job given a sufficiently new GDAL installation on your computer. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GeoPDF into GRASS?
Il 03/05/2012 10:37, Markus Neteler ha scritto: While I have no experience with that format, I see that GDAL supports it: http://www.gdal.org/frmt_pdf.html Stephen, it would be nice if you could provide us some sample files to test if the driver works well. Thanks. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] problems with gparser-options in python-script
Hi, I have some questions concerning the behaviour of gparser. In the attachment you can find a example-python-script. Somehow the output from gparser for X (see script) is strange: I try to use it in a if-command but somehow I fail. The output when X is set to 'A a' should be a juhuu but it isn't. I was looking for the bug in my code but somehow I couldn't find it. When I replace the options for X with A,B and C (single Letters), it seems to work...Is there a problem with spaces in the options of gparser? I am working on GRASS6.5SVN on Mac OS X 10.6.8. Can anyone try the script and reproduce the error? Does anyone have ideas where the problem in the script is located? Thank you for your help. Best regards, Johannes -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a #!/usr/bin/env python # # # MODULE: test # # AUTHOR(S): Johannes Radinger # # VERSION: V1.0 Beta # # DATE: 2011-05-12 # # #%Option #% key: X #% type: string #% required: no #% multiple: no #% key_desc: name #% description: ABC #% options: A a,B b,C c #% answer: B b #%end # import required base modules import sys import os # import required grass modules import grass.script as grass def main(): X = str(options['X']) #X = 'A a' print X print type(X) if X is 'A a': print juh sys.stdout.flush() if __name__ == __main__: options, flags = grass.parser() sys.exit(main()) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Negative raster values from i.landsat.dehaze
Ok, I have done a bit more digging and found r.univar for the stats problem - don't know how I missed that one! On the atmospheric correction I have ditched i.landsat.dehaze in favour of the presumed higher accuracy of i.atcorr. So, with this I have created a control file with the relevant values for e.g. Band-3: #- start of control file - 8 - geometrical conditions=Landsat ETM+ 3 24 08.020 35.400 32.680 - month day hh.ddd longitude latitude (hh.ddd is in GMT decimal hours) 2 - atmospheric mode=midlatitude summer 2 - aerosols model=maritime 50 - visibility [km] (aerosol model concentration) -0.080 - mean target elevation above sea level [km] -1000 - sensor on board a satellite 63 - 3rd band of ETM+ Landsat 7 #- end of control file --- When I then run i.atcorr: $ i.atcorr -r -a iimg=R3 icnd=icnd3.txt oimg=C3D ERROR: Raster map dem_float not found The error is refers to the default altitude raster-map, but the command help specifies that the ialt argument is optional and I don't have a DEM for the area. Any ideas what is going on? Thanks, Jamie From: James Travers traversja...@yahoo.ie To: grass-user@lists.osgeo.org grass-user@lists.osgeo.org Sent: Wednesday, 2 May 2012, 22:10:39 Subject: [GRASS-user] Negative raster values from i.landsat.dehaze Hi, I have been trying to get some results from GRASS for a couple of weeks now but am hitting a wall. What I am trying to do is to take an area of land from a series of Landsat 7 ETM+ images and calculate NDVI over the area for the purpose of comparison over a time-period. This obviously requires atmospheric correction, so the command sequence I am using after importing the images for a given mapset is: # Generate radiance values i.landsat.toar input_prefix=B output_prefix=R metfile=./L71174038_03820080324/L71174038_03820080324_MTL.txt sensor=tm7 # Atmospheric correction i.tasscap -7 band1=R1 band2=R2 band3=R3 band4=R4 band5=R5 band7=R7 outprefix=TC i.landsat.dehaze band1=R1 band2=R2 band3=R3 band4=R4 band5=R5 band7=R7 tasscap4=TC.4 outprefix=D # Generate NDVI map r.mapcalc 'ndvi=if((D.3 == 0 D.4 == 0), -1, (D.4 - D.3) / (D.4 + D.3))' Then I mask the NDVI map with an area raster which I already created. There is probably a better way of doing this. # Mask NDVI map with individual regions r.mapcalc 'area_ndvi = ndvi * area_mask@PERMANENT' Finally I want an average value of the NDVI over the area. There is definitely a better way of doing this but I couldn't find a grass command that spits out a single value. Instead I used r.stats to give the area of each group of values and then wrote a Perl script to average these. # Process statistics r.stats -a --q area_ndvi | ./stats.pl Ok, so here come the questions: 1) Is there a better way to simply get an average of all values over a given area to replace my stats.pl script? 2) and this is the big one. When I perform i.landsat.dehaze I get rasters with primarily negative values. This renders the NDVI calculation meaningless as they are ratios of +ve and -ve values. I am presuming this is a mistake as negative reflectance has little meaning anyway - did I use the wrong sequence of commands? Below are info outputs for the red-band after the TOAR and dehaze operations respectively: Many thanks for any help on this, Jamie ++ | Layer: R3 Date: Wed May 2 20:15:30 2012 | | Mapset: L71174038_03820080324 Login of Creator: jamie | | Location: area | | DataBase: /home/jamie/grassdata | | Title: ( R3 ) | | Timestamp: none | || | | | Type of Map: raster Number of Categories: 255 | | Data Type: DCELL | | Rows: 6961 | | Columns: 7911 | | Total Cells: 55068471 | | Projection: UTM (zone 36) | | N: 3619200 S: 3410370 Res: 30 | | E: 843630 W: 606300 Res: 30 | | Range of data: min = -0.0129146013370688 max =
[GRASS-user] Re: Pixels values are changed when the layer is exported to vector (column value in attribute tables)
Any solution? I also tried using the r.thin but keep having the same problem Thanks in advance, 2012/5/2 Marcello Benigno benigno.marce...@gmail.com Hello All, After creating my stream network with the command *r.stream.order*, I converted the result to vector, with the command *r.to.vect*, something wrong happened... the values that were associated with the pixels appear exchanged for some features (e.g., in the raster the pixel value is 1 and in the vector appears 2). I wonder if my procedure is wrong or there might be some problem related to my data (SRTM) when even a possible GRASS bug. The link below shows the two overlying layers (problem.png) and it is possible to find some places where the values of the raster layer (raster.png) does not correspond to the values of the vector layer (vector.png). http://ge.tt/4FR2l7H?c Could anyone help me? Thanks in advance *: )* -- *Marcello Benigno B. de Barros Filho* Prof. do Curso Superior de Tecnologia em Geoprocessamento - IFPB Mestre em Ciências Geodésicas e Tecnologias da Geoinformação - UFPE Doutorando em Tecnologia Ambiental e Recursos Hídricos - UFPE http://profmarcello.blogspot.com http://about.me/marcello.benigno -- *Marcello Benigno B. de Barros Filho* Prof. do Curso Superior de Tecnologia em Geoprocessamento - IFPB Mestre em Ciências Geodésicas e Tecnologias da Geoinformação - UFPE Doutorando em Tecnologia Ambiental e Recursos Hídricos - UFPE http://profmarcello.blogspot.com http://about.me/marcello.benigno ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GeoPDF into GRASS?
On Thu, May 03, 2012 at 10:37:53AM +0200, we recorded a bogon-computron collision of the nete...@osgeo.org flavor, containing: On Thu, May 3, 2012 at 1:11 AM, Stephen Sefick sas0...@auburn.edu wrote: Is there a way to bring a GeoPDF into GRASS? many thanks, While I have no experience with that format, I see that GDAL supports it: http://www.gdal.org/frmt_pdf.html So, r.in.gdal should do the job given a sufficiently new GDAL installation on your computer. Unfortunately, at the moment the GDAL support for GeoPDF treats them entirely as rasters --- the PDF data is converted to an image with the poppler library and georeferenced using the data in the GeoPDF. GDAL 2.0.0 and later support rendering only part of the image (vector, base imagery, text) rather than all at once, but even so vector data in the GeoPDF is rendered into images. It would be lovely if GeoPDF vector data could be extracted into Grass vectors, but that's not possible through gdal yet, as far as I can tell. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit! --- The Tick ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Negative raster values from i.landsat.dehaze
Hi James, On Thu, May 3, 2012 at 10:05 PM, James Travers traversja...@yahoo.ie wrote: Ok, I have done a bit more digging and found r.univar for the stats problem - don't know how I missed that one! glad you found it. If you see any potential to improve the documentation, please make suggestions. On the atmospheric correction I have ditched i.landsat.dehaze in favour of the presumed higher accuracy of i.atcorr. i.landsat.dehaze is just a simple statistical approach. So, with this I have created a control file with the relevant values for e.g. Band-3: #- start of control file - 8 - geometrical conditions=Landsat ETM+ 3 24 08.020 35.400 32.680 - month day hh.ddd longitude latitude (hh.ddd is in GMT decimal hours) 2 - atmospheric mode=midlatitude summer 2 - aerosols model=maritime 50 - visibility [km] (aerosol model concentration) -0.080 - mean target elevation above sea level [km] -1000 - sensor on board a satellite 63 - 3rd band of ETM+ Landsat 7 #- end of control file --- When I then run i.atcorr: $ i.atcorr -r -a iimg=R3 icnd=icnd3.txt oimg=C3D ERROR: Raster map dem_float not found I just tried with the example of the manual page in the North Carolina sample dataset and it worked ok. But: don't put the comment lines into the control file! I fell into this trap in the beginning and i.atcorr offered weird error messages. The error is refers to the default altitude raster-map, but the command help specifies that the ialt argument is optional and I don't have a DEM for the area. Any ideas what is going on? I suspect that you have the two comment lines in the file which unfortunately confuse i.atcorr. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GeoPDF into GRASS?
On Fri, May 4, 2012 at 12:42 AM, Tom Russo ru...@bogodyn.org wrote: ... It would be lovely if GeoPDF vector data could be extracted into Grass vectors, but that's not possible through gdal yet, as far as I can tell. I searched a bit but did not find any related email. So: This would be a wish for OGR (hence, GDAL mailing list or tracker) since GRASS relies on this library. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Displaying site_name on r.watershed output basins map
On Wed, May 2, 2012 at 10:25 PM, Margherita Di Leo direg...@gmail.com wrote: On Wed, May 2, 2012 at 8:20 AM, Micha Silver mi...@arava.co.il wrote: Have a look that you've enabled displaying of an attribute column. In the GUI, it's on the Required tab as Display selected attribute based on attrcol. On the CLI d.vect disp=shape,attr This always trips me up also. Should be a FAQ. And perhaps the Display attribute... should get enabled somehow automatically whenever an attribute column for labeling is chosen. +1 Please edit the GRASS Wiki: http://grass.osgeo.org/wiki/FAQ or send a text snippet for (which) manual page(s) to the list. Or write an enhancement ticket to trac: http://trac.osgeo.org/grass/ thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems with gparser-options in python-script
Johannes Radinger wrote: I have some questions concerning the behaviour of gparser. In the attachment you can find a example-python-script. Somehow the output from gparser for X (see script) is strange: I try to use it in a if-command but somehow I fail. The output when X is set to 'A a' should be a juhuu but it isn't. I was looking for the bug in my code but somehow I couldn't find it. When I replace the options for X with A,B and C (single Letters), it seems to work...Is there a problem with spaces in the options of gparser? I am working on GRASS6.5SVN on Mac OS X 10.6.8. Can anyone try the script and reproduce the error? Does anyone have ideas where the problem in the script is located? In 7.0, it fails because upper-case letters are not valid in option names, so it interprets an argument of the form 'X=A a' as an answer to the first option, i.e. equivalent to 'X=X=A a'. I don't know why it would fail in 6.x. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
