Re: [gdal-dev] Question about using crop_to_cutline
Even Rouault 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 : > 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 * 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 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 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 wrote: > Hello > No I don't know where my valid pixels are. > Any alternative? > > 2012/10/25 Kyle Shannon >> >> 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 >> 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 : > Even Rouault 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 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 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\java>java -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
Re: [gdal-dev] JRE vs JDK
Hi Even, > ---Original Message--- > From: Even Rouault > To: gdal-dev@lists.osgeo.org, Ivan Lucena > Subject: Re: [gdal-dev] JRE vs JDK > Sent: Oct 26 '12 13:26 > > 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. You are right. But if one of the GDAL/OGR JNI DLL was missing, the message would be something like: java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path Exception in thread "main" java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI .AllRegister()V at org.gdal.gdal.gdalJNI.AllRegister(Native Method) at org.gdal.gdal.gdal.AllRegister(gdal.java:475) The problem seems to be the dependencies. Looking at he Process Monitor I can see that there is a lot of confusion going on between 64 and 32 bits versions of third level DLLs (GDAL -> plugin -> SDK-X -> etc. -> etc.). It is a Windows 7 64 bits machine. All I need to do is to complete isolate the PATH on my script from whatever is on the system PATH by *not* using %PATH% at all. Not either before or *after* the paths I need! Yes, not even after. That WOW64 is very strange. > > 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\java>java -cp gdal.jar;. gdalinfo > > Seems to work. Thank you so very much for doing that test. Best regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
