Re: [gdal-dev] Question about using crop_to_cutline
Even Rouault even.rouault at mines-paris.org writes: This is the very same topic that is discussed in http://trac.osgeo.org/gdal/ticket/3947 . There's no solution to your problem, but some background discussion that explains the current behaviour. This is close to a problem I had once with creating mosaics from individually warped orthophotos. Accurately calculated extents make pixels to slide a bit and individually warped images do not share any common canvas for their pixels. I sketched a plan for forcing the warped image to use a common canvas and found a python guy to make a program. I have been satisfied with the result. I believe that the same solution will work for you. You must widen the -te parameters that is calculated by crop_to_cutline to each direction so that they match exactly with some pixel row and line of the original image. See figures 3, 4, and 5 in http://www.scangis.org/scangis2007/papers/r3_rahkonen.pdf. The python code is there too. Without understanding anything about programming I suppose that the job is done with this: minmax = get_minmax(tm32_coords) minmax_wider = [ (int(math.floor(minmax[0][0])), int(math.floor(minmax[0][1]))), (int(math.ceil (minmax[1][0])), int(math.ceil (minmax[1][1]))), ] log(Extents (min,max): + str(minmax), outfilename) log(Widened extents (min,max): + str(minmax_wider), outfilename) -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR-VFK in 1.9
Hi, 2012/1/18 Etienne Tourigny etourigny@gmail.com: However, as your changes only affect your driver, I think it would be easier to commit them to 1.9.0 without an RFC. It would be easier if you prepare a small wiki page (similar to RFCs) describing the changes, and create at least one bug entry. I have filled the ticket for this issue [1]. If a wiki page is also required I will prepare it too. Thanks for info in advance. Best regards, Martin [1] http://trac.osgeo.org/gdal/ticket/4872 -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaltransform - output into textfile
Even Rouault even.rouault at mines-paris.org writes: For the record, unfortuanetely it won't help you much, but I don't reproduce the issues you're facing. The gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857 WGS84.txt Grid.txt command just works fine for me. Perhaps an issue with your setup ? He is not the only one. I tried the command too and it does create the grid.txt file but it remains empty, just as described. My GDAL version is development build from 24th October (MSVC2010 x64). -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Question about using crop_to_cutline
At the time I created the ticket I had created a workaround that uses gdal_translate to clip a rectangular window and gdal_rasterize to burn an inverse image of the vector. Interested folks can email me for the script (does the list take attachments?). The script makes some assumptions about your data type (e.g. 0 is assigned as nodata) but you can change those assumptions to suit your needs. I plan to make the feature request I mentioned in #3947. -marius To: gdal-dev@lists.osgeo.org From: jukka.rahko...@mmmtike.fi Date: Fri, 26 Oct 2012 09:05:06 + Subject: Re: [gdal-dev] Question about using crop_to_cutline Even Rouault even.rouault at mines-paris.org writes: This is the very same topic that is discussed in http://trac.osgeo.org/gdal/ticket/3947 . There's no solution to your problem, but some background discussion that explains the current behaviour. This is close to a problem I had once with creating mosaics from individually warped orthophotos. Accurately calculated extents make pixels to slide a bit and individually warped images do not share any common canvas for their pixels. I sketched a plan for forcing the warped image to use a common canvas and found a python guy to make a program. I have been satisfied with the result. I believe that the same solution will work for you. You must widen the -te parameters that is calculated by crop_to_cutline to each direction so that they match exactly with some pixel row and line of the original image. See figures 3, 4, and 5 in http://www.scangis.org/scangis2007/papers/r3_rahkonen.pdf. The python code is there too. Without understanding anything about programming I suppose that the job is done with this: minmax = get_minmax(tm32_coords) minmax_wider = [ (int(math.floor(minmax[0][0])), int(math.floor(minmax[0][1]))), (int(math.ceil (minmax[1][0])), int(math.ceil (minmax[1][1]))), ] log(Extents (min,max): + str(minmax), outfilename) log(Widened extents (min,max): + str(minmax_wider), outfilename) -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removing Nodata pixels from raster
you can surely identify the valid pixels with visualization software such as qgis, using the valuetool plugin, to identify the 4 corners of the valid region. Another option is to compress the gtiff with e.g. DEFLATE compression like this gdal_translate -co COMPRESS=DEFLATE in.tif out.tif Etienne On Thu, Oct 25, 2012 at 1:32 PM, katrin eggert katrineggert1...@gmail.com wrote: Hello No I don't know where my valid pixels are. Any alternative? 2012/10/25 Kyle Shannon k...@pobox.com Katrin, Do you know where you valid pixels are in the image? If so, gdal_translate with -srcwin would work: kyle@ubuntu:~$ gdal_translate -srcwin xoff yoff 60 100 in.tif out.tif where xoff, yoff are the number of pixels from the image origin that your valid region begins(pixels, lines). See http://gdal.org/gdal_translate.html for more info. On Thu, Oct 25, 2012 at 8:05 AM, katrin eggert katrineggert1...@gmail.com wrote: Greetings I have a Geotif with only one Layer with a size of 6000x5000 but from which I only have a square of 60x100 with bvalid pixels. the remaining are NOdata. The problem is that this Geotiff is a big file 90MB and without these NoData values I would have a much smaller raster. How can I generate a new Geotiff without these noValid values and with extent adjusted to the valid pixels? Thank you Regards, Katrin E. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaltransform - output into textfile
Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi: Even Rouault even.rouault at mines-paris.org writes: For the record, unfortuanetely it won't help you much, but I don't reproduce the issues you're facing. The gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857 WGS84.txt Grid.txt command just works fine for me. Perhaps an issue with your setup ? He is not the only one. I tried the command too and it does create the grid.txt file but it remains empty, just as described. My GDAL version is development build from 24th October (MSVC2010 x64). I had only tested with Linux. I've just tested with custom builds on Windows 32 bit with MSVC 7.1 and 9.0 and still don't reproduce any issue. Mysterious. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] JRE vs JDK
Hi there, I am getting this exception when loading gdal.jar: * Native library load failed. java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I * If I change the script that launch my application to use the java.exe from the JDK instead of the JRE then the problem is gone. The problem is that users usually have only JRE. Right? Anyway, It doesn't seems like there is nothing wrong with the GDAL built. I also try the same test with Tamas' binaries but got the same strange error. An by looking at swig/include/java/*.i I can see that some of the loadLibrary would issue that message before the exception. WARNING : GDAL should be compiled with thread support for safe execution in Java. But I am not getting it. So the error must be coming from loading gdalconstjni.dll or osrjni.dll but not gdaljni.dll or ogrjni.dll I haven't tried that with Linux but I will. I search for java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I on the web there are a hand full of question about that but none of the suggestions mentioned the JRE vs JDK issue. Does anybody has a clue? Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removing Nodata pixels from raster
In SAGA GIS there is a Crop to Data module (in Grid Tools module library), which performs the task. But this would require you to import your Geotif with the GDAL import module, process it in SAGA, and finally export it as Geotif again with the GDAL export module. Best regards, Volker On 10/25/2012 05:32 PM, katrin eggert wrote: Hello No I don't know where my valid pixels are. Any alternative? 2012/10/25 Kyle Shannon k...@pobox.com Katrin, Do you know where you valid pixels are in the image? If so, gdal_translate with -srcwin would work: kyle@ubuntu:~$ gdal_translate -srcwin xoff yoff 60 100 in.tif out.tif where xoff, yoff are the number of pixels from the image origin that your valid region begins(pixels, lines). See http://gdal.org/gdal_translate.html for more info. On Thu, Oct 25, 2012 at 8:05 AM, katrin eggert katrineggert1...@gmail.com wrote: Greetings I have a Geotif with only one Layer with a size of 6000x5000 but from which I only have a square of 60x100 with bvalid pixels. the remaining are NOdata. The problem is that this Geotiff is a big file 90MB and without these NoData values I would have a much smaller raster. How can I generate a new Geotiff without these noValid values and with extent adjusted to the valid pixels? Thank you Regards, Katrin E. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Is it possible to ehance input channels separately with gdal_translate ?
Hello, I have some input data where the dynamic range and offset of each channel are distinct. This means that applying the same linear enhancement based on data range to my selected RGB output bands will not produce an optimal visual enhancement. -scale smin smax dmin dmax only provides the same linear enhancement for all selected input channels (bands). Also the default causes gdal_translate to calculate the enhancement from the data which is also the wrong thing to do owing to the relative changeability of albedo from one scene to another due to the possible presence or absence of cloud, snow, or sand, vs. water or coal piles (light vs. dark) etc.. and also the relative difference in dynamic range between channels. QUESTION: Is there a way to enhance my input channels separately in a single gdal_translate call, or do I need to make multiple passes? Thanks Peter ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is it possible to ehance input channels separately with gdal_translate ?
QUESTION: Is there a way to enhance my input channels separately in a single gdal_translate call, or do I need to make multiple passes? Multiple passes. But you could also generate a VRT with a different rescaling for each channel, and translate it into the target dataset. Thanks Peter ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JRE vs JDK
Le vendredi 26 octobre 2012 17:52:18, Ivan Lucena a écrit : Hi there, I am getting this exception when loading gdal.jar: * Native library load failed. java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I * If I change the script that launch my application to use the java.exe from the JDK instead of the JRE then the problem is gone. The problem is that users usually have only JRE. Right? Anyway, It doesn't seems like there is nothing wrong with the GDAL built. I also try the same test with Tamas' binaries but got the same strange error. An by looking at swig/include/java/*.i I can see that some of the loadLibrary would issue that message before the exception. WARNING : GDAL should be compiled with thread support for safe execution in Java. But I am not getting it. So the error must be coming from loading gdalconstjni.dll or osrjni.dll but not gdaljni.dll or ogrjni.dll I haven't tried that with Linux but I will. I search for java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I on the web there are a hand full of question about that but none of the suggestions mentioned the JRE vs JDK issue. Does anybody has a clue? I'm a bit skeptical about this being a JRE vs JDK issue. I suspect that you have an issue with the supporting dll (the 4 jni ones and gdalXXX.dll and its dependencies) not being found in the PATH. I've just tried with an older release-1500-dev.zip from Tamas site and a JRE. I put gdalinfo.class (compiled from the samples in swig/java/apps) in C: \release-1500-dev\release-1500\bin\gdal\java And then, after calling SDKShell.bat, just run from there : C:\release-1500-dev\release-1500\bin\gdal\javajava -cp gdal.jar;. gdalinfo Seems to work. Regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
