Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
On 02/18/2014 09:31 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 2:09 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 01:56 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 1:14 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 12:47 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 11:43 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Yes, r.in.gdal automatically imports whatever it finds as color tables or attribute labels. Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. GDAL does not see an attribute table in the data you sent to me, thus GRASS can not import any attributes. If there is really an attribute table, it is not recognized by GDAL. Then maybe this is a gdal problem : I'm saying this because through the command gdalinfo, it looks like gdal detects an attribute table (see below). Cheers GRASS 7.0.svn (lambert93):~/tmp gdalinfo /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 Driver: AIG/Arc/Info Binary Grid Files: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 This file is missing in the archive you sent: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml I am pretty sure that it contains the raster attribute table. Markus M Sorry about that, I just sent the landforms/test_lf4.aux.xml to you, but unfortunately it does not seem to contain the raster attribute table...: Right. Unfortunately I can not reproduce the gdalinfo output you sent previously, and as long as gdal does not see an attribute table, GRASS can not import the labels in the attribute table. I use gdal 1.10.1, if that helps. Markus M I am running GDAL 1.10.0, maybe that explains the difference. I will let you know when I will have 1.10.1 running if I still get the same gdalinfo results. Manuel GRASS 7.0.svn (lambert93):~/tmp more /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml PAMDataset SRSPROJCS[quot;RGF_1993_Lambert_93quot;,GEOGCS[quot;GCS_RGF_1993quot;,DATUM[quot;Reseau_Geodesique_Francais_1993quot;,SPHEROID[quot;GRS_1980quot;,63 78137.0,298.257222101]],PRIMEM[quot;Greenwichquot;,0.0],UNIT[quot;Degreequot;,0.0174532925199433]],PROJECTION[quot;Lambert_Conformal_Conic_2SPquot;],PARAM ETER[quot;False_Eastingquot;,70.0],PARAMETER[quot;False_Northingquot;,660.0],PARAMETER[quot;Central_Meridianquot;,3.0],PARAMETER[quot;Standard_Pa rallel_1quot;,44.0],PARAMETER[quot;Standard_Parallel_2quot;,49.0],PARAMETER[quot;Latitude_Of_Originquot;,46.5],UNIT[quot;Meterquot;,1.0]]/SRS PAMRasterBand band=1 Descriptiontest_lf4/Description Histograms HistItem HistMin1/HistMin HistMax6/HistMax BucketCount256/BucketCount IncludeOutOfRange1/IncludeOutOfRange Approximate0/Approximate HistCounts1313166|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|79933|0|0|0|0|0|0|0|0|0|0|0|0|0| 0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|110782|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|42435|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|69408|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1341719/HistCounts /HistItem /Histograms /PAMRasterBand /PAMDataset /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/hdr.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/dblbnd.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001x.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/sta.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/vat.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/log /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/prj.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/metadata.xml Size is 2504, 2089 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the GRS 1980 ellipsoid,
[GRASS-user] need ideas for an interesting query of worldclim data - longitudinal band
I am looking for suggestions on a query of worldclim data (http://worldclim.org/). I have used something similar to below for previous data extraction where I am looking for data associated with a particular site, or list of sites, where a single lon lat coordinate will return a single value. However, in this case, I need to pull an entire longitudinal band for a particular latitude. For example instead of grabbing data from a single coordinates with east_north = -92.50, 46.51”, I want to grab all the data in the longitudinal band at latitude 46.51. If it were possible something like “east_north = *, 46.51” Any suggestions on this point would be much appreciated. Thanks in advance - Kirk == if test $GISBASE = ; then echo You must be in GRASS to run this program exit fi # Use input text file for coords in the format: lon lat (easting northing) single # space between coords. Example: -98.42072 55.91481. Must use real coordinates, no blanks. # Script will create file for each $MAP in the list. g.mlist can also take the pattern # argument which takes regular expressions. For example: pattern=* returns all # maps in the database. If script fails check for hidden characters in text file, best to # use vi or emacs to eliminate them for MAP in `g.mlist type=rast pattern=“HIST_tmin*`; do r.what --verbose input=$MAP ~/Desktop/ai/coords.txt ~/Desktop/ai/$MAP.txt; echo $MAP done ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SRTM r.watershed at multiple scales
Here is what I think is strange though about your explanation, Markus: If I first mask a watershed produced with r.water.outlet and then use r.watershed to produce subbasins, it doesnt include the entire area of the watershed but leaves small areas out, although these areas belong to it. Is this a threshold problem? Tom, see image attached. Michel On 02/19/2014 04:42 PM, Thomas Adams wrote: I've been using GRASS 7 for this and have not seen a problem -- I hope I'm not overlooking the issue. Michel, can you provide an image that shows this? Thanks, Tom On Wednesday, February 19, 2014, Michel Wortmann wortm...@pik-potsdam.de mailto:wortm...@pik-potsdam.de wrote: Markus, last year you asked me whether the r.watershed output is not aligned to the r.water.outlet output in GRASS7 (s.b.). Ie. it leaves small areas out. Back then, I wasnt using GRASS7, but I can confirm now that it still does it and it is still rather annoying. Have you ever heard of the reasons or attempted to fix this? Thanks, Michel On 08/26/2013 03:25 PM, Markus Neteler wrote: On 08/22/2013 08:52 AM, Markus Neteler wrote: Hi Michel, On Wed, Aug 21, 2013 at 1:18 PM, Michel Wortmann wortm...@pik-potsdam.de wrote: ... As the r.watershed algorithm often leaves small areas at the edges uncovered, you'll have to fill those before or after patching, otherwise you'll have holes in your subbasin map. ... just curious: does this happen still in the latest GRASS 7 version? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) attachment: temp.png___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SRTM r.watershed at multiple scales
Hi, I experienced a similar point, but, if I remember right, this was because I set the computational region to the extend of the catchment produced by r.water.outlet. So maybe the MASK has a similar effect and r.watershed needs kind of buffer. Should be easy to check ... HTH, Stefan On 02/20/2014 07:11 PM, Michel Wortmann wrote: Here is what I think is strange though about your explanation, Markus: If I first mask a watershed produced with r.water.outlet and then use r.watershed to produce subbasins, it doesnt include the entire area of the watershed but leaves small areas out, although these areas belong to it. Is this a threshold problem? Tom, see image attached. Michel On 02/19/2014 04:42 PM, Thomas Adams wrote: I've been using GRASS 7 for this and have not seen a problem -- I hope I'm not overlooking the issue. Michel, can you provide an image that shows this? Thanks, Tom On Wednesday, February 19, 2014, Michel Wortmann wortm...@pik-potsdam.de mailto:wortm...@pik-potsdam.de wrote: Markus, last year you asked me whether the r.watershed output is not aligned to the r.water.outlet output in GRASS7 (s.b.). Ie. it leaves small areas out. Back then, I wasnt using GRASS7, but I can confirm now that it still does it and it is still rather annoying. Have you ever heard of the reasons or attempted to fix this? Thanks, Michel On 08/26/2013 03:25 PM, Markus Neteler wrote: On 08/22/2013 08:52 AM, Markus Neteler wrote: Hi Michel, On Wed, Aug 21, 2013 at 1:18 PM, Michel Wortmann wortm...@pik-potsdam.de wrote: ... As the r.watershed algorithm often leaves small areas at the edges uncovered, you'll have to fill those before or after patching, otherwise you'll have holes in your subbasin map. ... just curious: does this happen still in the latest GRASS 7 version? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam --- PGP Public Key: http://bit.ly/13d9Sca ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.lidar finds 0 points in GRASS 7
On Thu, Feb 20, 2014 at 2:24 AM, Michael Moore stuporg...@gmail.com wrote: Hello, I think I'm doing something wrong with importing lidar data in GRASS 7. My data is a laz file from the state of Minnesota. The complicating factor is that the EPSG code is set incorrectly -- EPSG:32715 / UTM 15 S instead of EPSG:26715/UTM 15 N. My region is set to the correct 26715. I am using the GUI, but the command that it generates is v.in.lidar -p -o --overwrite input=/data/3542-27-22.laz output=test The output is: Over-riding projection check Something is wrong here: Importing 0 points... because I get Importing 12588100 points... 100% 12588100 points imported If you compiled GRASS 7 from source, you could go to vector/v.in.lidar and run make clean make and check for any errors or warnings Building topology for vector map test@stuporglue... Registering primitives... 0 primitives registered 0 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 0 Number of primitives: 0 Number of points: 0 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 0 points imported lasinfo reports 12588100 points. I'd be happy to get this imported either through the command line or the GUI, but my goal is to understand enough about GRASS to script the creation of a state-wide DSM from LiDAR data. You can also use r.in.lidar method=min or first convert the .laz file with las2txt, then use r.in.xyz method=min. With the r.in.* modules, the region should be set first, taking particular care about the resolution. Something like # set the region extents to the lidar point cloud extents g.region n= s= e= w= # align the region again to the target resolution g.region res=target_resolution -a HTH, Markus M Thanks, Michael Moore ___ 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
[GRASS-user] Fwd: [OSGeo-Edu] ACM SIGSPATIAL contest
FYI - v.generalize comes to mind... -- Forwarded message -- From: Stefan Steiniger sst...@geo.uzh.ch Date: Thu, Feb 20, 2014 at 3:26 PM Subject: [OSGeo-Edu] ACM SIGSPATIAL contest To: edu_disc...@lists.osgeo.org Hi all, the ACM SIGSPATIAL contest this year is about a map generalization task. If someone has interest or interested students, please forward: http://mypages.iit.edu/~xzhang22/GISCUP2014/ would be interesting to see also how standard FOS desktop GIS perform on this. cheers, stefan ___ Edu_discuss mailing list edu_disc...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/edu_discuss ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SRTM r.watershed at multiple scales
On Thu, Feb 20, 2014 at 8:25 PM, Stefan Lüdtke slued...@gfz-potsdam.de wrote: Hi, I experienced a similar point, but, if I remember right, this was because I set the computational region to the extend of the catchment produced by r.water.outlet. This is correct, r.watershed need a buffer of at least one cell around the catchment, otherwise it can not find out where exactly the catchment's borders are. Markus M So maybe the MASK has a similar effect and r.watershed needs kind of buffer. Should be easy to check ... HTH, Stefan On 02/20/2014 07:11 PM, Michel Wortmann wrote: Here is what I think is strange though about your explanation, Markus: If I first mask a watershed produced with r.water.outlet and then use r.watershed to produce subbasins, it doesnt include the entire area of the watershed but leaves small areas out, although these areas belong to it. Is this a threshold problem? Tom, see image attached. Michel On 02/19/2014 04:42 PM, Thomas Adams wrote: I've been using GRASS 7 for this and have not seen a problem -- I hope I'm not overlooking the issue. Michel, can you provide an image that shows this? Thanks, Tom On Wednesday, February 19, 2014, Michel Wortmann wortm...@pik-potsdam.de mailto:wortm...@pik-potsdam.de wrote: Markus, last year you asked me whether the r.watershed output is not aligned to the r.water.outlet output in GRASS7 (s.b.). Ie. it leaves small areas out. Back then, I wasnt using GRASS7, but I can confirm now that it still does it and it is still rather annoying. Have you ever heard of the reasons or attempted to fix this? Thanks, Michel On 08/26/2013 03:25 PM, Markus Neteler wrote: On 08/22/2013 08:52 AM, Markus Neteler wrote: Hi Michel, On Wed, Aug 21, 2013 at 1:18 PM, Michel Wortmann wortm...@pik-potsdam.de wrote: ... As the r.watershed algorithm often leaves small areas at the edges uncovered, you'll have to fill those before or after patching, otherwise you'll have holes in your subbasin map. ... just curious: does this happen still in the latest GRASS 7 version? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Stefan Lüdtke Section 5.4- Hydrology Tel.: +49 331 288 2821 Fax: +49 331 288 1570 Email: slued...@gfz-potsdam.de Helmholtz-Zentrum Potsdam Deutsches GeoForschungsZentrum GFZ (GFZ German Research Centre for Geoscience) Stiftung des öff. Rechts Land Brandenburg Telegrafenberg, 14473 Potsdam --- PGP Public Key: http://bit.ly/13d9Sca ___ 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] r.in.gdal for importing categorical ArcGIS binary rasters
On Thu, Feb 20, 2014 at 9:32 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 09:31 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 2:09 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 01:56 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 1:14 PM, manuel.martin manuel.mar...@orleans.inra.fr wrote: On 02/18/2014 12:47 PM, Markus Metz wrote: On Tue, Feb 18, 2014 at 11:43 AM, manuel.martin manuel.mar...@orleans.inra.fr wrote: Hi, I just compiled grass r59073 and gave a try. I could not get the attributes imported along with the raster, but maybe am I missing something from the new revision of r.in.gdal (although from the code it looks that the import of values from the attribute table should be automatic?). Yes, r.in.gdal automatically imports whatever it finds as color tables or attribute labels. Markus, I just sent you the ESRI layer I am trying to import, in case you would like to try as well. GDAL does not see an attribute table in the data you sent to me, thus GRASS can not import any attributes. If there is really an attribute table, it is not recognized by GDAL. Then maybe this is a gdal problem : I'm saying this because through the command gdalinfo, it looks like gdal detects an attribute table (see below). Cheers GRASS 7.0.svn (lambert93):~/tmp gdalinfo /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 Driver: AIG/Arc/Info Binary Grid Files: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4 This file is missing in the archive you sent: /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml I am pretty sure that it contains the raster attribute table. Markus M Sorry about that, I just sent the landforms/test_lf4.aux.xml to you, but unfortunately it does not seem to contain the raster attribute table...: Right. Unfortunately I can not reproduce the gdalinfo output you sent previously, and as long as gdal does not see an attribute table, GRASS can not import the labels in the attribute table. I use gdal 1.10.1, if that helps. Markus M I am running GDAL 1.10.0, maybe that explains the difference. I will let you know when I will have 1.10.1 running if I still get the same gdalinfo results. I would not replace a working gdal version with a probably not working gdal version. Your gdalinfo reported a raster attribute table, not mine. You could double-check again if your gdalinfo still finds a raster attribute table, then import with r.in.gdal. Alternatively, you can get the original corine land cover as raster (the vector version is full of errors and tricky to clean up) and the legend and import these. Markus M Manuel GRASS 7.0.svn (lambert93):~/tmp more /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4.aux.xml PAMDataset SRSPROJCS[quot;RGF_1993_Lambert_93quot;,GEOGCS[quot;GCS_RGF_1993quot;,DATUM[quot;Reseau_Geodesique_Francais_1993quot;,SPHEROID[quot;GRS_1980quot;,63 78137.0,298.257222101]],PRIMEM[quot;Greenwichquot;,0.0],UNIT[quot;Degreequot;,0.0174532925199433]],PROJECTION[quot;Lambert_Conformal_Conic_2SPquot;],PARAM ETER[quot;False_Eastingquot;,70.0],PARAMETER[quot;False_Northingquot;,660.0],PARAMETER[quot;Central_Meridianquot;,3.0],PARAMETER[quot;Standard_Pa rallel_1quot;,44.0],PARAMETER[quot;Standard_Parallel_2quot;,49.0],PARAMETER[quot;Latitude_Of_Originquot;,46.5],UNIT[quot;Meterquot;,1.0]]/SRS PAMRasterBand band=1 Descriptiontest_lf4/Description Histograms HistItem HistMin1/HistMin HistMax6/HistMax BucketCount256/BucketCount IncludeOutOfRange1/IncludeOutOfRange Approximate0/Approximate HistCounts1313166|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|79933|0|0|0|0|0|0|0|0|0|0|0|0|0| 0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|110782|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|42435|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|69408|0|0|0|0|0|0|0|0|0|0|0|0|0|0 |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1341719/HistCounts /HistItem /Histograms /PAMRasterBand /PAMDataset /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/hdr.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/dblbnd.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001.adf /home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/landforms/test_lf4/w001001x.adf
[GRASS-user] color anomalies after orthorectification
Hi, I tried to orthorectify aerial photographs. That worked fine by now, until i got scans wich appear to be darker as before. At least this is the first observation I made. The effect occured with that scans is, that after rectification some of the dark areas become white (or rather null, querying that cells result in -0.722622310236638). Has anyone had similar experiences when rectifying aerial photographs. And hopefully a hint how to avoid this damages. I suspect that the orthorectified images become double precision whereas the imported scans are integer... best regards Stefan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] color anomalies after orthorectification
OK, I found a workaround. with r.mapcalc I identify all values lt 1 and gt 254 and set them to 1 resp. 254. Actually not a nice way but the result is good enough for the moment. Anyway, I still would be thankfull for an explanation of the phenomenon, moreover a better solution to avoid that behaviour. best regards Stefan Am 21.02.2014 00:26, schrieb Stefan Kiefer: Hi, I tried to orthorectify aerial photographs. That worked fine by now, until i got scans wich appear to be darker as before. At least this is the first observation I made. The effect occured with that scans is, that after rectification some of the dark areas become white (or rather null, querying that cells result in -0.722622310236638). Has anyone had similar experiences when rectifying aerial photographs. And hopefully a hint how to avoid this damages. I suspect that the orthorectified images become double precision whereas the imported scans are integer... best regards Stefan ___ 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] color anomalies after orthorectification
On Fri, Feb 21, 2014 at 12:26 AM, Stefan Kiefer st_kie...@web.de wrote: Hi, I tried to orthorectify aerial photographs. That worked fine by now, until i got scans wich appear to be darker as before. At least this is the first observation I made. The effect occured with that scans is, that after rectification some of the dark areas become white (or rather null, querying that cells result in -0.722622310236638). This should only happen with method=cubic or method=cubic_f. The other resampling methods nearest,bilinear,bilinear_f should not produce these resampling overshoots. Markus M Has anyone had similar experiences when rectifying aerial photographs. And hopefully a hint how to avoid this damages. I suspect that the orthorectified images become double precision whereas the imported scans are integer... best regards Stefan ___ 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
