[gdal-dev] GSOC
Hello, I am a student that I am trying to find a mentor related to gdal programming and image enhancement. Is there anyone who wants to mentor such a project? Regards, -- Nikos Ms Student Software Engineering Cal State Fullerton ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Uint16 geotiff
gdal translate can not add the TIFFTAG_MINSAMPLEVALUE TIFFTAG_MAXSAMPLEVALUE the specific tag are readonly see: http://www.gdal.org/frmt_gtiff.html On Wed, Sep 10, 2014 at 10:36 AM, Frank Warmerdam warmer...@pobox.com wrote: Gdalwarp generally does not propagate metadata from the source(s) to the output file. One approach is to use gdal_translate after to re-add desired metadata. Alternatively you could precreate the output file and populate it with metadata. I often do this part in python. Best regards, Frank On Sep 10, 2014 10:17 AM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: Dear All, so I have an RGB image in tiff format with uint16 when I use gdalwrap the TIFFTAG_MINSAMPLEVALUE and TIFFTAG_MAXSAMPLEVALUE are magicaly disappearing from the result image WHYYY??? --Nikos ___ 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] l1b to grid
Does anyone know how to grid a level1b swath image from satellites to a gridded projection? Best, --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GCTP projection -s_srs=???
I have this projection for my nasa hdf file: Coordinate System is: LOCAL_CS[GCTP projection number 97, UNIT[Meter,1]] Origin = (-17334194.000,7344784.82500186265) Pixel Size = (25067.525334417932754,-25067.525298634809587) I tried to reporject my image using gdalwrap and I got: ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. I am reading this: http://www.gdal.org/ogr/classOGRSpatialReference.html#a04ab13a2ec4ceffd6f802422f95e8f15 from the array I understand: 9 Transverse Mercator 7 FN how I have to define my -s_srs=? --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GCTP projection -s_srs=???
thanks for the respond, Yes you are right it is +proj=cea I got confused with the GCTP codes about the datum=WGS84 I am not quite sure the specs that I find from HDFview are: Projection=GCTP_CEA ProjParams=(6371228,0,0,0,0,3000,0,0,0,0,0,0,0) SphereCode=-1 --Nikos On Wed, Jan 23, 2013 at 10:57 AM, Frank Warmerdam warmer...@pobox.comwrote: Nikos, I see that GCTP Projection 97 is Cylindrical Equal Area. This can have a standard parallel and a central meridian (from http://www.remotesensing.org/geotiff/proj_list/cylindrical_equal_area.html ). Without knowing what these are it is hard to do much, but you might try it assuming they are zero and zero in which case you would use something like: -s_srs +proj=cea +datum=WGS84 If you examine the HDF metadata more carefully you might find more information. Initially see what metadata makes it through GDAL with gdalinfo. If that doesn't show anything, perhaps try low level HDF tools. If you make the datasource available, and filed a bug it might be possible for us to fix ogr_srs_usgs.cpp to handle CEA. In the comments I see: // FIXME: CEA --- Cylindrical Equal Area skipped (Grid corners set in meters for EASE grid) Best regards, Frank On Wed, Jan 23, 2013 at 10:20 AM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: I have this projection for my nasa hdf file: Coordinate System is: LOCAL_CS[GCTP projection number 97, UNIT[Meter,1]] Origin = (-17334194.000,7344784.82500186265) Pixel Size = (25067.525334417932754,-25067.525298634809587) I tried to reporject my image using gdalwrap and I got: ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. I am reading this: http://www.gdal.org/ogr/classOGRSpatialReference.html#a04ab13a2ec4ceffd6f802422f95e8f15 from the array I understand: 9 Transverse Mercator 7 FN how I have to define my -s_srs=? --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GCTP projection -s_srs=???
I got it: http://nsidc.org/data/atlas/epsg_3410.html On Wed, Jan 23, 2013 at 11:46 AM, Nikolaos Hatzopoulos nhat...@gmail.comwrote: thanks for the respond, Yes you are right it is +proj=cea I got confused with the GCTP codes about the datum=WGS84 I am not quite sure the specs that I find from HDFview are: Projection=GCTP_CEA ProjParams=(6371228,0,0,0,0,3000,0,0,0,0,0,0,0) SphereCode=-1 --Nikos On Wed, Jan 23, 2013 at 10:57 AM, Frank Warmerdam warmer...@pobox.comwrote: Nikos, I see that GCTP Projection 97 is Cylindrical Equal Area. This can have a standard parallel and a central meridian (from http://www.remotesensing.org/geotiff/proj_list/cylindrical_equal_area.html ). Without knowing what these are it is hard to do much, but you might try it assuming they are zero and zero in which case you would use something like: -s_srs +proj=cea +datum=WGS84 If you examine the HDF metadata more carefully you might find more information. Initially see what metadata makes it through GDAL with gdalinfo. If that doesn't show anything, perhaps try low level HDF tools. If you make the datasource available, and filed a bug it might be possible for us to fix ogr_srs_usgs.cpp to handle CEA. In the comments I see: // FIXME: CEA --- Cylindrical Equal Area skipped (Grid corners set in meters for EASE grid) Best regards, Frank On Wed, Jan 23, 2013 at 10:20 AM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: I have this projection for my nasa hdf file: Coordinate System is: LOCAL_CS[GCTP projection number 97, UNIT[Meter,1]] Origin = (-17334194.000,7344784.82500186265) Pixel Size = (25067.525334417932754,-25067.525298634809587) I tried to reporject my image using gdalwrap and I got: ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. I am reading this: http://www.gdal.org/ogr/classOGRSpatialReference.html#a04ab13a2ec4ceffd6f802422f95e8f15 from the array I understand: 9 Transverse Mercator 7 FN how I have to define my -s_srs=? --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Combine aerial images
put a second server and have the 1400 image to the one and the other 1400 to the other :) -- Nikos On Fri, Oct 12, 2012 at 8:00 AM, Frank Broniewski b...@metrico.lu wrote: Hi, I have a directory with appr. 2800 aerial images, each 1kmx1km. I'm using this source for a Mapserver WMS layer. Unfortunately the amount of data to process is way too much for a Mapserver WMS service. Now I want to create larger overview images where the aerial images are combined together. The route I wanted to was 1) build a VRT from the images 2) use gdal_translate to get a new geotiff with a smaller size (pixel wise) Is this a valid route to go? Many thanks, Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu __**_ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/gdal-devhttp://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] GSoC Image Correlator
I see the code: CPLErr GDALSimpleSURF::ConvertRGBToLuminosity const double forRed = 0.21; const double forGreen = 0.72; const double forBlue = 0.07; question: if you have a sensor with more than this three channels probably it will not work you need to have an RGB image. how about have an option how many channels to choose. Probably this process is working for one channel as well. --Nikos On Mon, Aug 27, 2012 at 9:12 AM, Frank Warmerdam warmer...@pobox.comwrote: On Mon, Aug 27, 2012 at 11:50 AM, Even Rouault even.roua...@mines-paris.org wrote: Making algorithm work with imagery that is piece-wise loaded can be very complicated indeed. And if you try to correlate images that are taken by sensors that have very different angles, then you could need to correlate parts that are not at all at the same position in the 2 images. Even, I think it will actually not be too hard to remove this problem with loading the whole image. It seems that the reference point objects (the somewhat poorly named GDALFeaturePoint) stores a descriptor representation of the point with it and so after these are collected from one of the images it is not necessary to keep the original image in memory. I'm still not sure how to handle the image scaling and conversion to a luminosity image more smoothly. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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] gdalenhance -config file how you do linear interpolation of the colors?
How you define the min max from this documentation: http://www.gdal.org/gdal_vrttut.html --Nikos On Thu, Feb 9, 2012 at 10:59 PM, Chaitanya kumar CH chaitanya...@gmail.comwrote: Nikolaos, The gdalenhance utility is not really recommended. I don't know the config file format. GDAL's VRT driver[1] supports a look-up-table that works with linear interpolation. In it, you specify pairs of corresponding values in source and destination rasters. The intermediate source values are interpolated linearly. [1]: http://www.gdal.org/gdal_vrttut.html On Fri, Feb 10, 2012 at 6:31 AM, Nikolaos Hatzopoulos nhat...@gmail.comwrote: so I have created a config file for gdalenhance color.config: 1:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 2:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 3:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 is it valid..? is it going to make a linear interpolation of the colors??? --Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalenhance -config file how you do linear interpolation of the colors?
so I have created a config file for gdalenhance color.config: 1:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 2:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 3:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120 120:0.429:190 190:0.231:255 is it valid..? is it going to make a linear interpolation of the colors??? --Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Web site downtime
Now you start realizing why enterprise linux exists :) --Nikos On Wed, Feb 1, 2012 at 5:22 PM, Frank Warmerdam warmer...@pobox.com wrote: Folks, The OSGeo ProjectsVM is down while we upgrade the OS (an upgrade that has encountered some issues). While this is being resolved the hosted sites including gdal.org, mapserver.org, grass.org will be down. http://wiki.osgeo.org/wiki/ProjectsVM Downtime could potentially be in the hours or even a day or two. I won't announce when things are back but you can always try. Note that Trac for bug reporting, and subversion are not down. Sorry for the inconvenience. And damn Debian major OS version in-place upgrades. :-) Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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] GDAL 1.7.3 java bindings on Centos 5 (64 bit)
http://elgis.argeo.org/ this repo has java bindings if that helps --Nikos Hatzopoulos On Mon, Jan 23, 2012 at 9:12 AM, Daniele Romagnoli daniele.romagn...@geo-solutions.it wrote: Hi list, Does anyone have any experience about the reported topic? I have downloaded GDAL 1.7.3 on my Centos 5.7 (64) machine and built it (with only base drivers and with threads support). Utilities are working fine (gdalinfo, gdal_translate, ...) Then, I have installed SWIG 1.3.36 (I know, it's quite old but testing 1.3.4X or 2.x in the past, I got several JVM crashes or other types of issues) and I have created java bindings for it. Once I have configured LD_LIBRARY_PATH to use all SOs it needs, I have started running some ImageIO-Ext tests with maven and JVM is crashing. In case someone don't know it, ImageIO-Ext mainly allows to bridge Java's ImageIO (ImageReaders/writers/SPI) to GDAL format drivers. On several Ubuntu (8, 9, 10, 11) I never had similar problems. We regularly use ImageIO-Ext 1.1.2 built on top of GDAL 1.7.3 on projects like GeoTools, GeoServer, Udig, ... Therefore I guess it's not a problem on the ImageIO-Ext caller side. I think it could be related to the SWIG-JNI counterpart which isn't working properly or something odd with the memory usage. Does anyone have any feedback on this? (supported/never tested/won't work/need some CXX flags/... anything) I'm pasting the hs_err_pid Log in case you find anything interesting. [1]: http://pastebin.com/WQkfnutJ Thanks in advance and best regards, Daniele ERROR: native gdal on centos 64 bit --- T E S T S --- Running it.geosolutions.imageio.plugins.arcgrid.ArcGridReadTest Jan 23, 2012 11:42:45 AM it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL INFO: GDAL Native Library loaded (version: 1.7.3) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b15a3ba7037, pid=9169, tid=1106860352 # # JRE version: 6.0_29-b11 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x4e1037] java_lang_String::utf8_length(oopDesc*)+0x67 # # An error report file with more information is saved as: # /root/tests/imageio1.1.2/plugin/gdal/gdalarcgrid/hs_err_pid9169.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # /bin/sh: line 1: 9169 Aborted /usr/lib/jvm/jdk1.6.0_29/jre/bin/java -Xmx512M -enableassertions -Dtest.extensive=false -Dtest.interactive=false -jar /tmp/ surefirebooter8850919397384240961.jar /tmp/surefire7943635768826345743tmp /tmp/surefire4074398420042204599tmp -- --- Ing. Daniele Romagnoli GeoSolutions S.A.S. Software Engineer Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://it.linkedin.com/in/danieleromagnoli --- ___ 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] PCT Pallete
How you can create your own pallet for the tool rgb2pct from existing rgb image. What kind of technics are existing in order to define such a pallete? --Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libjpeg-turbo for gdal?
I am curios to see the supercharged version :) --Nikos On Wed, Sep 21, 2011 at 3:08 PM, Mateusz Loskot mate...@loskot.net wrote: On 21/09/11 21:46, doug_newc...@fws.gov wrote: I had seen libjpeg-turbo , Has anyone tried using it in GDAL? http://www.gdal.org/frmt_jpeg.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ 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] SWIG JNI binding question with GetMetadataItem function
yes watch that because they also added test so you can do: make test and see if the swing is working --Nikos Hatzopoulos On Tue, Aug 23, 2011 at 8:53 AM, Jim Pendleton j...@ittvis.com wrote: Just to finalize this thread, the underlying problem was that the version of SWIG I was using was outdated. Installing version 2.0.5 corrected the issue. Jim P. ___ 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] SWIG JNI binding question with GetMetadataItem function
Did you follow these instructions? http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix this command must work: java -classpath `pwd`/gdal.jar:`pwd`:`pwd`/build/apps gdalinfo as the instruction are saying: *With luck you will see the gdalinfo usage message. * and try to see a gdalinfo of a file --Nikos Hatzopoulos On Thu, Aug 11, 2011 at 3:21 PM, Jim Pendleton j...@ittvis.com wrote: Even, Thanks for the suggestion, but if I've implemented your suggestion properly, it has not solved the underlying problem. I'm not sure how you've compiled the gdal_warp.cpp, but if you didn't use the provided swig/java/GNUmakefile, there's one point you must be very careful that is mentionned at the bottom of that makefile : To create a .so file from source in Android, you generally use the ndk-build utility along with one or more Android.mk and Application.mk files. I execute the standard make/make install from within the swig/java directory, then I compile and link gdal_wrap.cpp within the context of a separate ndk-build process. Android NDK Release 6 uses GNU Make 3.81 as its build utility. The compiler in my case is arm-linux-androideabi-g++ (GCC) 4.4.3. The loader is GNU ld (GNU Binutils) 2.19. # Do not remove -fno-strict-aliasing while SWIG generates weird code in upcast methods # See http://trac.osgeo.org/gdal/changeset/16006 That would be a plausible cause for the crash, since in your particular case the GetMetadataItem() method is in the MajorObject class, so the Dataset object needs to call the SWIGDatasetUpcast() method... Indeed I was lacking the -fno-strict-aliasing switch in the C++ flags in my Android.mk file. However, I've added this switch to both LOCAL_CFLAGS and LOCAL_CPPFLAGS for the libgdaljni.so build and I continue to get the error during execution. To add some more info to my original message, the actual error comes from within Java_org_gdal_gdal_gdalJNI_MajorObject_1GetMetadataItem_1_1SWIG10 in gdal_wrap.cpp on the call to jenv-GetStringUTFChars(jarg2, 0). First a JNI warning is issued, then the access violation appears to occur before that function can return, or at least before a debug statement I've added after the call can send its output to the Android LogCat output. The error that's issued is related to jarg2 which is supposed to be a jstring, versus the jarg1 argument you mentioned which requires the upcast to GDALMajorObjectShadow. I think I'll need to further debug the pointers that are being passed down to the *GetMetadataItem*1SWIG10* function. None of them look outrageous at first glance. Again, there's every reason to believe I'm missing something that's otherwise obvious to the experts so please feel free to continue sending ideas my way! Jim P. ___ 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] SWIG JNI binding question with GetMetadataItem function
how you can build a vm in android platform? Because I know android is running on linux but again it depends on the device. If they start building cellphone based on atom processor you must follow the same instruction as a 386 processor. --Nikos Hatzopoulos On Thu, Aug 11, 2011 at 5:08 PM, Jim Pendleton j...@ittvis.com wrote: Nikos, ** ** Building for Java in a standard Linux environment is a little different from building in the Android environment. We’ve used as a starting point these instructions:** ** ** ** http://trac.osgeo.org/gdal/wiki/BuildingForAndroid ** ** Though in theory they could be buillt, the individual stand-alone apps such as gdalinfo must be run from a command line (I believe) which is lacking in the Android environment, without rooting. Rooting is not presently an option for me for various administrative reasons. ** ** I’m actually commenting out the builds for the stand-alone applications.** ** ** ** What I’m really building in this case is the libgdaljni.so file (along with libjdalconst.so) that can be loaded and executed from an Android activity. Our libgdaljni.so contains the link results of from libgdal.a, gdal_wrap.o and some kakadu library routines. ** ** If there’s an entry point within the libgdaljni.so that will perform the equivalent functionality as the stand-alone gdalinfo executable, I could try that. ** ** Jim P. ** ** -- *From:* Nikolaos Hatzopoulos [mailto:nhat...@gmail.com] *Sent:* Thursday, August 11, 2011 5:56 PM *To:* Jim Pendleton *Cc:* Even Rouault; gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] SWIG JNI binding question with GetMetadataItem function ** ** Did you follow these instructions? http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix this command must work: java -classpath `pwd`/gdal.jar:`pwd`:`pwd`/build/apps gdalinfo as the instruction are saying: *With luck you will see the gdalinfo usage message. * and try to see a gdalinfo of a file --Nikos Hatzopoulos On Thu, Aug 11, 2011 at 3:21 PM, Jim Pendleton j...@ittvis.com wrote:*** * Even, Thanks for the suggestion, but if I've implemented your suggestion properly, it has not solved the underlying problem. I'm not sure how you've compiled the gdal_warp.cpp, but if you didn't use the provided swig/java/GNUmakefile, there's one point you must be very careful that is mentionned at the bottom of that makefile : To create a .so file from source in Android, you generally use the ndk-build utility along with one or more Android.mk and Application.mk files. I execute the standard make/make install from within the swig/java directory, then I compile and link gdal_wrap.cpp within the context of a separate ndk-build process. Android NDK Release 6 uses GNU Make 3.81 as its build utility. The compiler in my case is arm-linux-androideabi-g++ (GCC) 4.4.3. The loader is GNU ld (GNU Binutils) 2.19. # Do not remove -fno-strict-aliasing while SWIG generates weird code in upcast methods # See http://trac.osgeo.org/gdal/changeset/16006 That would be a plausible cause for the crash, since in your particular case the GetMetadataItem() method is in the MajorObject class, so the Dataset object needs to call the SWIGDatasetUpcast() method... Indeed I was lacking the -fno-strict-aliasing switch in the C++ flags in my Android.mk file. However, I've added this switch to both LOCAL_CFLAGS and LOCAL_CPPFLAGS for the libgdaljni.so build and I continue to get the error during execution. To add some more info to my original message, the actual error comes from within Java_org_gdal_gdal_gdalJNI_MajorObject_1GetMetadataItem_1_1SWIG10 in gdal_wrap.cpp on the call to jenv-GetStringUTFChars(jarg2, 0). First a JNI warning is issued, then the access violation appears to occur before that function can return, or at least before a debug statement I've added after the call can send its output to the Android LogCat output. The error that's issued is related to jarg2 which is supposed to be a jstring, versus the jarg1 argument you mentioned which requires the upcast to GDALMajorObjectShadow. I think I'll need to further debug the pointers that are being passed down to the *GetMetadataItem*1SWIG10* function. None of them look outrageous at first glance. Again, there's every reason to believe I'm missing something that's otherwise obvious to the experts so please feel free to continue sending ideas my way! Jim P. ___ 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] GDAL_DATA
Hi, Is there any way you can define GDAL_DATA using code and not environmental variable? --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL_DATA
Because I was looking for java is this: gdal.SetConfigOption(GDAL_DATA, /home/nikos/mygdal/data); and it is working :) thanks, --Nikos On Tue, Aug 9, 2011 at 2:13 PM, Kyle Shannon ksshan...@gmail.com wrote: I believe you can use CPLSetConfigOptions() docs are here: http://trac.osgeo.org/gdal/wiki/ConfigOptions /** * * Kyle Shannon * ksshan...@gmail.com * */ On Tue, Aug 9, 2011 at 15:11, Nikolaos Hatzopoulos nhat...@gmail.comwrote: Hi, Is there any way you can define GDAL_DATA using code and not environmental variable? --Nikos Hatzopoulos ___ 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] GML elevation
Hi Community, we have this gml data: http://nvclwebservices.vm.csiro.au/geoserverBH/wfs?SERVICE=WFSREQUEST=GetFeatureVERSION=1.1.0maxFeatures=1typeName=gsml:Borehole System.out.println(Layer Count: +poDS.GetLayerCount()); System.out.println(Layer Name: +poDS.GetLayerByIndex(0).GetName()); System.out.println(Feature Count: +poDS.GetLayerByIndex(0).GetFeatureCount()); System.out.println(1st Feature X: +Double.toString(poDS.GetLayerByIndex(0).GetFeature(0).GetGeometryRef().GetX())); System.out.println(1st Feature Y: +Double.toString(poDS.GetLayerByIndex(0).GetFeature(0).GetGeometryRef().GetY())); Output: Layer Count: 1 Layer Name: Borehole Feature Count: 1 1st Feature X: -28.4139 1st Feature Y: 121.142 who I can read the gsml:elevation field? the gdal version I am using is 1.7.2 --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GML elevation
System.out.println(Elevation+poDS.GetLayerByIndex(0).GetFeature(0).GetFieldAsString(elevation)); ERROR 1: No such a field 'elevation' I am refetching to find where in the tree is the elevation :) yes I know is expensive does it has to do with the version I am using? I am using 1.7.2 --Nikos On Mon, Aug 8, 2011 at 6:18 PM, Frank Warmerdam warmer...@pobox.com wrote: On Mon, Aug 8, 2011 at 5:09 PM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: Hi Community, we have this gml data: http://nvclwebservices.vm.csiro.au/geoserverBH/wfs?SERVICE=WFSREQUEST=GetFeatureVERSION=1.1.0maxFeatures=1typeName=gsml:Borehole System.out.println(Layer Count: +poDS.GetLayerCount()); System.out.println(Layer Name: +poDS.GetLayerByIndex(0).GetName()); System.out.println(Feature Count: +poDS.GetLayerByIndex(0).GetFeatureCount()); System.out.println(1st Feature X: +Double.toString(poDS.GetLayerByIndex(0).GetFeature(0).GetGeometryRef().GetX())); System.out.println(1st Feature Y: +Double.toString(poDS.GetLayerByIndex(0).GetFeature(0).GetGeometryRef().GetY())); I imagine something like: System.out.println(poDS.GetLayerByIndex(0).GetFeature(0).GetFieldAsString(elevation)); BTW, refetching the feature each time may be quite expensive! Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GML elevation
GDAL 1.7.2 ogrinfo my.gml Borehole Had to open data source read-only. INFO: Open of `my.gml' using driver `GML' successful. Layer name: Borehole Geometry: Unknown (any) Feature Count: 1 Extent: (-28.413900, 121.142000) - (-28.413900, 121.142000) Layer SRS WKT: (unknown) name: String (71.0) sampledFeature: String (0.0) OGRFeature(Borehole):0 name (String) = WTB5 sampledFeature (String) = POINT (-28.4139002 121.1419996) GDAL 1.8.1 java -Djava.library.path=. -cp gdal.jar:build/apps ogrinfo /home/nickhatz/my.gml Borehole INFO: Open of `/home/nickhatz/my.gml' using driver `GML' successful. Layer name: Borehole Geometry: Point Feature Count: 1 Extent: (121.142, -28.4139) - (121.142, -28.4139) Layer SRS WKT: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9122]], AUTHORITY[EPSG,4326], AXIS[Latitude,NORTH], AXIS[Longitude,EAST]] gml_id: String (0.0) name: StringList (0.0) sampledFeature: String (0.0) elevation: Real (0.0) driller: String (0.0) dateOfDrilling: String (10.0) drillingMethod: String (12.0) startPoint: String (22.0) inclinationType: String (8.0) lowerCorner: Real (0.0) upperCorner: Real (0.0) coreCustodian: String (0.0) OGRFeature(Borehole):5 gml_id (String) = gsml.borehole.WTB5 name (StringList) = (2:,...) sampledFeature (String) = elevation (Real) = 45 driller (String) = dateOfDrilling (String) = 2004-09-17 drillingMethod (String) = diamond core startPoint (String) = natural ground surface inclinationType (String) = vertical lowerCorner (Real) = 106 upperCorner (Real) = 249 coreCustodian (String) = POINT (121.142 -28.4139) What version are you running? --Nikos On Mon, Aug 8, 2011 at 6:45 PM, Frank Warmerdam warmer...@pobox.com wrote: On Mon, Aug 8, 2011 at 6:39 PM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: System.out.println(Elevation+poDS.GetLayerByIndex(0).GetFeature(0).GetFieldAsString(elevation)); ERROR 1: No such a field 'elevation' Niko, Odd, for me ogrinfo reports: ... gml_id: String (0.0) name: StringList (0.0) sampledFeature: String (0.0) elevation: Real (0.0) driller: String (0.0) dateOfDrilling: String (10.0) drillingMethod: String (12.0) startPoint: String (22.0) inclinationType: String (8.0) lowerCorner: Real (0.0) upperCorner: Real (0.0) coreCustodian: String (0.0) OGRFeature(Borehole):5 gml_id (String) = gsml.borehole.WTB5 name (StringList) = (2:,...) sampledFeature (String) = elevation (Real) = 45 driller (String) = ... Fetching with a field name of elevation should have worked. Check your ogrinfo report on the file and see if you see something different. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Including curl in the context of an Android build?
try istead of: LIBS=”-lcurl $LIBS” LIBS=/absolute/path/libcurl.a $LIBS be aware that even the order on how you define static libraries may confused the compile process. --Nikos Hatzopoulos On Wed, Aug 3, 2011 at 12:45 PM, Jim Pendleton j...@ittvis.com wrote: In order to support the GDAL (1.8.1) jpipkak driver on Android, I also need to include libcurl (7.21.7) support. ** ** The inclusion of the curl library into the GDAL build is my current stumbling block. ** ** That is, I’m able to build and execute an Android app that can load my driver and will run to the point of calling gdal.Open() which fails with a 0 status return because of a lack of curl. ** ** I don’t fully understand the checking that’s being performed in the configure utility of GDAL for the –with-curl switch. This apperas to be responsible for overriding the curl_global_init function in a header file and including libcurl.so in the LIBS list. I’m afraid I’m not a makefile guru so I’m probably missing something obvious. ** ** Regardless of how I set this, the build process for GDAL wants to parse files **installed** on the build platform, in this case /usr/bin/curl-config under RedHat 5. The result is that “checking for curl_global_init in –lcurl” always returns “no”. It also appears to want to reference a dynamic libcurl.so (LIBS=”-lcurl $LIBS”), rather than allowing a static library as a part of the build. ** ** Separate from GDAL, I’m able to build a static libcurl.a for Android. ** ** I would really like to link this static library into my final Android .so file, along with the rest of GDAL, the required kakadu modules, and the JNI layer and avoid the need for a separate libcurl.so file. ** ** Does GDAL’s architecture require a separate libcurl.so to be loaded at runtime? And if so, has anyone had any experience with this in the Android environment? ** ** If anyone could help me out with this, I would very much appreciate it.*** * ** ** Thanks, Jim P. ** ** ** ** ___ 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] Modis L1B SWATH: georef problem hdf to geotiff
cool! does it works with 150 files? --Nikos On Tue, Jul 26, 2011 at 9:17 AM, Brian Case r...@winkey.org wrote: Nikolaos I have warped modis with swath2grid and mosaicked it with mapserver, I have not seen that issue. also you don't need to use a vrt to mosaic, this can be done with one gdalwarp call. gdalwarp file1 file2 file3 outfile Brian On Mon, 2011-07-25 at 17:20 -0700, Nikolaos Hatzopoulos wrote: It seems interesting I'll keep a note on this :) The question is how you can build a VRT mosaic directly from MODIS hdf files, because the problem is that you have to mosaic first and after that to transform them to the EPSG:4326 projection. If you transform them first and mosaic them after you might have white lines. --Nikos 2011/7/25 Brian Case r...@winkey.org anna, Nikolaos, after much experimentation I found something that seems to work. gdalwarp --config GEOL_AS_GCPS FULL \ -tps -geoloc -t_srs EPSG:4326 \ -te -119.88004906118 13.5092548294379 \ -92.6036641645677 34.7070050511582 \ HDF4_EOS:EOS_SWATH:MOD02HKM.A2011169.1750.005.NRT.hdf:MODIS_SWATH_Type_L1B:EV_500_RefSB \ MOD02HKM.A2011169.1750.005.NRT.tif note i tried to escape the newlines to make it easy to read but the email may mess that up. there is about 2.7 million gcp's in a normal 5min modis swath file, by default gdal only reads every 10th row and column of gcp's this is not enough to handle the bowtie effect. Brian On Tue, 2011-01-18 at 16:33 -0800, Nikolaos Hatzopoulos wrote: You are right, I notice that there isn't any difference from the band_1.tiff and band_1_warp.tiff --Nikos Hatzopoulos On Mon, Jan 17, 2011 at 8:15 AM, anna auge annaa...@web.de wrote: Hi all, I am trying to convert modis level 1B data (type SWATH) to geotiff following these steps. 1) Examining the HDF gdalinfo d:\modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf gdalinfo HDF4_EOS:EOS_SWATH:d:\modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB 2) Extracting the 1. band of the subdataset MODIS_SWATH_Type_L1B:EV_1KM_RefSB gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:d: \modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB d:\modis\1b\band_1.tiff 4) Warping the image to WGS84 gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d: \modis\1b \band_1_warp.tiff The example dataset, which i am using, can be downloaded here ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf And now to my problem: I get always an certain shift ( http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which is avoided if i am using the Georeference MODIS option in ENVI ( http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/). I also tried a few workarounds, f.g. http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but nothing worked properly. As far as I understand gdal supports Modis L1B SWATH, so what I am doing wrong? Any help is appreciated. Regards Anna P.S. I am using FWTools 2.4.7 on Windows WEB.DE DSL Doppel-Flat ab 19,99 ¤/mtl.! Jetzt mit gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 ___ 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] Modis L1B SWATH: georef problem hdf to geotiff
It seems interesting I'll keep a note on this :) The question is how you can build a VRT mosaic directly from MODIS hdf files, because the problem is that you have to mosaic first and after that to transform them to the EPSG:4326 projection. If you transform them first and mosaic them after you might have white lines. --Nikos 2011/7/25 Brian Case r...@winkey.org anna, Nikolaos, after much experimentation I found something that seems to work. gdalwarp --config GEOL_AS_GCPS FULL \ -tps -geoloc -t_srs EPSG:4326 \ -te -119.88004906118 13.5092548294379 \ -92.6036641645677 34.7070050511582 \ HDF4_EOS:EOS_SWATH:MOD02HKM.A2011169.1750.005.NRT.hdf:MODIS_SWATH_Type_L1B:EV_500_RefSB \ MOD02HKM.A2011169.1750.005.NRT.tif note i tried to escape the newlines to make it easy to read but the email may mess that up. there is about 2.7 million gcp's in a normal 5min modis swath file, by default gdal only reads every 10th row and column of gcp's this is not enough to handle the bowtie effect. Brian On Tue, 2011-01-18 at 16:33 -0800, Nikolaos Hatzopoulos wrote: You are right, I notice that there isn't any difference from the band_1.tiff and band_1_warp.tiff --Nikos Hatzopoulos On Mon, Jan 17, 2011 at 8:15 AM, anna auge annaa...@web.de wrote: Hi all, I am trying to convert modis level 1B data (type SWATH) to geotiff following these steps. 1) Examining the HDF gdalinfo d:\modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf gdalinfo HDF4_EOS:EOS_SWATH:d:\modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB 2) Extracting the 1. band of the subdataset MODIS_SWATH_Type_L1B:EV_1KM_RefSB gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:d:\modis\1b \MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB d:\modis\1b\band_1.tiff 4) Warping the image to WGS84 gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:\modis\1b \band_1_warp.tiff The example dataset, which i am using, can be downloaded here ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf And now to my problem: I get always an certain shift ( http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which is avoided if i am using the Georeference MODIS option in ENVI ( http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/). I also tried a few workarounds, f.g. http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but nothing worked properly. As far as I understand gdal supports Modis L1B SWATH, so what I am doing wrong? Any help is appreciated. Regards Anna P.S. I am using FWTools 2.4.7 on Windows WEB.DE DSL Doppel-Flat ab 19,99 ¤/mtl.! Jetzt mit gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 ___ 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] gdalwarp over tiles in Plate carée
I haven't worked with MERIS on NDVI data but I know about MODIS: so let's say we have four MODIS files lvl3 data: MOD13Q1.A2010113.h08v04.005.2010133194933.hdf MOD13Q1.A2010113.h08v05.005.2010134041223.hdf MOD13Q1.A2010113.h09v04.005.2010135200404.hdf MOD13Q1.A2010113.h09v05.005.2010133080730.hdf if you go to the map: https://lpdaac.usgs.gov/lpdaac/products/modis_overview you are going to see that these tiles represent the west coast what I do is extract the data from hdf to geotiff if you do gdalinfo MOD13Q1.A2010113.h08v04.005.2010133194933.hdf you are going to have: ... SUBDATASET_2_NAME=HDF4_EOS:EOS_GRID:MOD13Q1.A2010113.h08v04.005.2010133194933.hdf:MODIS_Grid_16DAY_250m_500m_VI:250m 16 days EVI SUBDATASET_2_DESC=[4800x4800] 250m 16 days EVI MODIS_Grid_16DAY_250m_500m_VI (16-bit integer) SUBDATASET_3_NAME=HDF4_EOS:EOS_GRID:MOD13Q1.A2010113.h08v04.005.2010133194933.hdf:MODIS_Grid_16DAY_250m_500m_VI:250m 16 days VI Quality SUBDATASET_3_DESC=[4800x4800] 250m 16 days VI Quality MODIS_Grid_16DAY_250m_500m_VI (16-bit unsigned integer) SUBDATASET_4_NAME=HDF4_EOS:EOS_GRID:MOD13Q1.A2010113.h08v04.005.2010133194933.hdf:MODIS_Grid_16DAY_250m_500m_VI:250m 16 days red reflectance SUBDATASET_4_DESC=[4800x4800] 250m 16 days red reflectance MODIS_Grid_16DAY_250m_500m_VI (16-bit integer) ... you do: gdal_translate 'HDF4_EOS:EOS_GRID:MOD13Q1.A2010113.h08v04.005.2010133194933.hdf:MODIS_Grid_16DAY_250m_500m_VI:250m 16 days NDVI' image1.tif 0...10...20...30...40...50...60...70...80...90...100 - done. so you will have your first tif you do the same for the others files and you will have: image1.tif image2.tif image3.tif image4.tif we are going to make a virtual mosaic using the vrt format: gdalbuildvrt mosaic.vrt *.tif if you open in a text editor the mosaic .vrt you are going to see the details now we are going to convert the mosaic to WGS84 projection gdalwarp -t_srs WGS84 mosaic.vrt final.tif my final.tif does not have any lines On Thu, Jul 7, 2011 at 5:02 PM, katrin eggert katrineggert1...@gmail.comwrote: Greetings I'm using gdalwarp to reproject a few tiles from platecarré to UTM WGS84 (for a specific zone). Originally they are tiles so they don't have any blank space between them but when I reproject to UTM I get a few areas in the borders of the image. What can I do to still have a perfect match between tiles? Thanks Kat ___ 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] zmap format
Hi, There is a format called zmap format and it has Zmap Plus grid does anybody know more info about this format? mostly it is used for DEM and petroleum and according to my opinion it is descried by a rectangular kind of cells but it might not, that's why I am asking for some reference for zmap format and of course if it is possible to be adopted by gdal :) --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem Compiling with Oracle (--with-oci)
vi configure :) --Nikos On Tue, Jun 21, 2011 at 12:02 PM, Chris Hodgson chodg...@refractions.netwrote: Ivan I appreciate your help here, but I think I've already tried everything you are suggesting. I dont' have an ORACLE_HOME set on the user doing this compiling, so if I don't specify --with-oci=... I don't get oracle support. I do have expat 1.95 installed (with -devel package as well) and it is automatically picked up by configure. I can build gdal successfully with no configure options, it builds with expat support among other defaults. If I specify --with-oci, I get the error about the funny libexpat path, if I add --with-expat=no, I get past that error, but get an error later when it can't find the XML_* symbols that the oracle library needs to be linked to. In neither of these cases to i get a working version of gdalinfo built. It seems to me that I need to link in expat for the oracle library, but I'm not sure if it is compatible with the 1.95 version the my system has installed and that GDAL requires if I specify --with-expat ... because there is an libexpat.so.0.5 in the oracle lib directory. Since I don't actually need GDAL's expat support, I'm fine with --with-expat=no ... but then I need to somehow tell libtool to ignore the funny expat path it is finding and use the expat in the oracle directory... perhaps the best way to do this is just to copy the libtool command that is failing in the build and tweak it manually to have the right path to the oracle expat instead of the funny path... however I won't be able to get to the next step of the build to see what other commands I need to run... is there a way to modify the makefile or tell configure about this? Thanks, Chris Ivan Lucena wrote: Hi Chris, I would not advise changing the configuration file. If you have a full installation of Oracle in your system you probably have a ORACLE_HOME environment variable, so if you run: $ ./configure ... checking for Oracle OCI headers in /oracle/path/... yes checking for Oracle OCI libraries in /oracle/path/lib... yes checking if Oracle OCI version is = 8.1.7 ... yes checking for Oracle version = 10.x to use -lnnz10 flag... yes checking if Oracle support is enabled... yes ... OCI support: yes GEORASTER support: yes ... If you don't have ORACLE_HOME you can pass the path using $ ./configure --with-oci=/oracle/path/... Now, you system is CentOS and I have never build GDAL on it but I would guess that it doesn't have Expat installed yet. My Linux does, so configure finds it: checking for XML_ParserCreate in -lexpat... yes checking for Expat XML Parser headers in /usr/include... found checking for Expat XML Parser... yes My suggestion is to isolate the problem by running ./configure, make and gdalinfo without Expat once and then make clean, ./configure, make and gdalinfo without OCI, ex: % ./configure --with-expat=NO % ./configure --with-OCI=NO Configure will setup your makefiles, then you run make based on those new settings. Good luck. Ivan ---Original Message--- From: Chris Hodgson chodg...@refractions.net To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem Compiling with Oracle (--with-oci) Sent: Jun 21 '11 12:38 What would need changed in the configure file? There is no reference there to the non-existent libexpat. I'm not familiar with spec files... but if I wanted to learn - what could I do there that I couldn't do in the configure/make process? The spec file still uses the package's build system right? It's not until the final linking with libtool that the problem happens, I just don't know what I need to tell libtool to get it to smarten up... Surely other people have compiled with support for oracle 11g? CentOS is just repackaged RHEL I don't know what I'm doing that is out of the ordinary here. Chris Nikolaos Hatzopoulos wrote: check the configure file it might need changes (vi configure) you can add the elgis repo add the devel package and start getting involved with the compile. this is a src rpm: http://elgis.argeo.org/repos/**testing/5/elgis/SRPMS/gdal-1.** 8.0-2.el5.elgis.src.rpmhttp://elgis.argeo.org/repos/testing/5/elgis/SRPMS/gdal-1.8.0-2.el5.elgis.src.rpm if you are familiar with spec files I strongly suggest you to do it that way :) --Nikos Hatzopoulos On Mon, Jun 20, 2011 at 4:49 PM, Chris Hodgson chodg...@refractions.net mailto:chodgson@refractions.**netchodg...@refractions.net wrote: grep tells me that the /ade/smayer.../ path is not in any text file in my gdal distribution (even after configuring) - which I grabbed the latest 1.8.0 from osgeo.org http://osgeo.org. Chris Ivan Lucena wrote: Chris, I am not on my Linux machine now to confirm but I would never needed to use --with-expat
Re: [gdal-dev] Problem Compiling with Oracle (--with-oci)
check the configure file it might need changes (vi configure) you can add the elgis repo add the devel package and start getting involved with the compile. this is a src rpm: http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/gdal-1.8.0-2.el5.elgis.src.rpm if you are familiar with spec files I strongly suggest you to do it that way :) --Nikos Hatzopoulos On Mon, Jun 20, 2011 at 4:49 PM, Chris Hodgson chodg...@refractions.netwrote: grep tells me that the /ade/smayer.../ path is not in any text file in my gdal distribution (even after configuring) - which I grabbed the latest 1.8.0 from osgeo.org. Chris Ivan Lucena wrote: Chris, I am not on my Linux machine now to confirm but I would never needed to use --with-expat pointing to Oracle's path. It is fanny that you found that smaver path. Sounds like you got a tar.gz package from someone, not from a GDAL distribution. The OCI driver should not depend in nothing but OCI apart from GDAL/OGR stuff. Regards, Ivan ---Original Message--- From: Chris Hodgson chodg...@refractions.net To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Problem Compiling with Oracle (--with-oci) Sent: Jun 20 '11 17:43 I'm trying to compile GDAL/OGR with support for Oracle/OCI. I have the full oracle 11g server installed on CentOS 5.3. # configure --with-oci=/opt/oracle/**product/11.2.0/dbhome_1/ # make ... libtool:. g++: /ade/smayer_perl_510/perl_**source/expat_home/lib/**libexpat.so: No such file or directory I think this path might be from the person who compiled the OCI libraries for oracle 11? I have nothing remotely like it on my system. If I add --with-expat=no to my configure line I get errors during linking about undefined references to XML_... so I'm guessing the linked OCI drivers need the expat lib linked in. I added /opt/oracle/product/11.2.0/**dbhome_1/lib to my LD_LIBRARY_PATH, and there is a libexpat.so.1.5.2 there, as well as my /lib/libexpat.so.0.5.0 which is from my CentOS standarad RPMS: # rpm -qa | grep expat expat-1.95.8-8.2.1 expat-devel-1.95.8-8.2.1 I also tried --with-expat=/opt/oracle/**product/11.2.0/dbhome_1/ but there are no headers there, among other problems. How can I get this to work? Thanks, Chris __**_ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/gdal-devhttp://lists.osgeo.org/mailman/listinfo/gdal-dev __**_ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/gdal-devhttp://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] Converting from 16 bit to 8 bit images (best practices?)
Rapid response for true color has this: ;- Rapid Response default enhancement: 0,0, 30,110, 60,160, 120,210, 190,240, 255,255 x = byte([0, 30, 60, 120, 190, 255]) y = byte([0, 110, 160, 210, 240, 255]) ;- Rapid Response cloud enhancement: 0,0, 25,90, 55,140, 100,175, 255,255 if keyword_set(cloud) then begin x = byte([0, 25, 55, 100, 255]) y = byte([0, 90, 140, 175, 255]) endif how it can be programmed in gdal language? --Nikos On Thu, Jun 9, 2011 at 8:42 PM, Brian Case r...@winkey.org wrote: Nikos 143, and 721 Brian On Thu, 2011-06-09 at 16:49 -0700, Nikolaos Hatzopoulos wrote: for modis truecolor images? --Nikos On Thu, Jun 9, 2011 at 4:44 PM, Brian Case r...@winkey.org wrote: Jonathan I don't know about worldview, but with modis I wound up using multiple ranges 0:0,750:110,1500:160,3000:210,4750:240,6375:255 see lut in the vrt tutorial Brian On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote: Brian: Thanks! Great solution, definitely saved me some time. The main issue (in terms of doing this entirely within GDAL) is getting the right scaling to make the image look good. I was able to figure out the correct scale range within ENVI, and then apply the scales as you suggested below. Nikos' suggestion to use rgb2pct makes me wonder if there is some way to figure out the optimal scale (which, AFAIK, is part of how rgb2pct is functioning) to apply to this image. Incidentally, what I'm trying to do is load Worldview-2 data onto an iPad 2 for use with the GISRoam mobile mapping app. Worldview-2 is 16-bit per band, 8 band data, with a very high dynamic range (we have snow in our image, so we have lots of VERY bright pixels which throw off the adjustment if using -scale without any parameters). 99% (100%?) of mobile mapping applications need 3-band data, usually with only 8 bits per band. Pushing forward, but if someone knows how to figure out an optimal set of scale values to use within GDAL, please post the solution. --j On Wed, Jun 8, 2011 at 9:45 PM, Brian Case r...@winkey.org wrote: Jonathan you can do scaling on individual bands. gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile outfile1.vrt gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile outfile2.vrt gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile outfile3.vrt gdalbuildvrt -separate output.vrt outfile1.vrt outfile2.vrt outfile3.vrt gdal_translate -of gtiff output.vrt output.tif for more complicated scaling you may need to hand write a vrt http://www.gdal.org/gdal_vrttut.html Brian On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote: Nikos and GDALers: This is CLOSE to what I'm looking to do, but I'm having a hard time getting it working properly. Here's my input dataset gdalinfo dump: *** Driver: ENVI/ENVI .hdr Labelled Files: 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr Size is 42255, 51712 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4326]] Origin
Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)
for modis truecolor images? --Nikos On Thu, Jun 9, 2011 at 4:44 PM, Brian Case r...@winkey.org wrote: Jonathan I don't know about worldview, but with modis I wound up using multiple ranges 0:0,750:110,1500:160,3000:210,4750:240,6375:255 see lut in the vrt tutorial Brian On Thu, 2011-06-09 at 12:39 -0700, Jonathan Greenberg wrote: Brian: Thanks! Great solution, definitely saved me some time. The main issue (in terms of doing this entirely within GDAL) is getting the right scaling to make the image look good. I was able to figure out the correct scale range within ENVI, and then apply the scales as you suggested below. Nikos' suggestion to use rgb2pct makes me wonder if there is some way to figure out the optimal scale (which, AFAIK, is part of how rgb2pct is functioning) to apply to this image. Incidentally, what I'm trying to do is load Worldview-2 data onto an iPad 2 for use with the GISRoam mobile mapping app. Worldview-2 is 16-bit per band, 8 band data, with a very high dynamic range (we have snow in our image, so we have lots of VERY bright pixels which throw off the adjustment if using -scale without any parameters). 99% (100%?) of mobile mapping applications need 3-band data, usually with only 8 bits per band. Pushing forward, but if someone knows how to figure out an optimal set of scale values to use within GDAL, please post the solution. --j On Wed, Jun 8, 2011 at 9:45 PM, Brian Case r...@winkey.org wrote: Jonathan you can do scaling on individual bands. gdal_translate -b 1 -scale 0 5000 -ot Byte -of VRT infile outfile1.vrt gdal_translate -b 2 -scale 0 4000 -ot Byte -of VRT infile outfile2.vrt gdal_translate -b 3 -scale 0 3000 -ot Byte -of VRT infile outfile3.vrt gdalbuildvrt -separate output.vrt outfile1.vrt outfile2.vrt outfile3.vrt gdal_translate -of gtiff output.vrt output.tif for more complicated scaling you may need to hand write a vrt http://www.gdal.org/gdal_vrttut.html Brian On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote: Nikos and GDALers: This is CLOSE to what I'm looking to do, but I'm having a hard time getting it working properly. Here's my input dataset gdalinfo dump: *** Driver: ENVI/ENVI .hdr Labelled Files: 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.envi 10SEP10191223-M2AS-052377832030_01_P003_ps_gs_bl_tc.hdr Size is 42255, 51712 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4326]] Origin = (-120.0664799,39.2715542) Pixel Size = (0.0450005,-0.0450005) Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-120.0664800, 39.2715540) (120d 3'59.33W, 39d16'17.59N) Lower Left (-120.0664800, 39.0388500) (120d 3'59.33W, 39d 2'19.86N) Upper Right (-119.8763325, 39.2715540) (119d52'34.80W, 39d16'17.59N) Lower Right (-119.8763325, 39.0388500) (119d52'34.80W, 39d 2'19.86N) Center (-119.9714062, 39.1552020) (119d58'17.06W, 39d 9'18.73N) Band 1 Block=42255x1 Type=UInt16, ColorInterp=Undefined Band 2 Block=42255x1 Type=UInt16, ColorInterp=Undefined Band 3 Block=42255x1 Type=UInt16, ColorInterp=Undefined *** I need to end up with a Byte TIF image with good color balance from this input. Running rgb2pct.py on this dataset just outputted a blank (grey) image. Running gdal_translate -of GTiff -ot Byte -scale [min] [max] worked somewhat, but its near impossible to get this looking right, since the scaling I want to do differs from band to band (e.g. if there any way to use -scale to adjust each band separately)? Alternatively, how would I get rgb2pct.py working on the above image correctly? Thanks! --j On Wed, Jun 8, 2011 at 4:10 PM, Nikolaos Hatzopoulos
Re: [gdal-dev] Converting from 16 bit to 8 bit images (best practices?)
why you don't try rgb2pct http://www.gdal.org/rgb2pct.html? --Nikos Hatzopoulos On Wed, Jun 8, 2011 at 2:20 PM, Jonathan Greenberg greenb...@ucdavis.eduwrote: Folks: I am using a piece of software which is relying on an older version of GDAL that doesn't have the fix to deal with 8 bit geotiffs (it is trying to make a jpeg overlay but can't from a 16 bit image. I think this is the issue: http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG), but when I do a straight convert (-ot Byte) the output image looks really washed out. Any hints for getting the best quality output from a 16 bit to to an 8 bit conversion of a Geotiff? --j -- Jonathan A. Greenberg, PhD Assistant Project Scientist Center for Spatial Technologies and Remote Sensing (CSTARS) Department of Land, Air and Water Resources University of California, Davis One Shields Avenue Davis, CA 95616 Phone: 415-763-5476 AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307 ___ 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] Segmentation fault with debian install of gdal on MODIS hdf4 files
I am using centos and elgis repo and for me it is working.. so there must be a problem with the hdf linking or compile of the library. Note hdf4 is responsible to do the job not hdf5 for the particular case. gdal_translate 'HDF4_EOS:EOS_GRID:MCD15A2. A2002185.h12v05.005.2007172035551.hdf:MOD_Grid_MOD15A2:LaiStdDev_1km' test2.tif Input file size is 1200, 1200 0...10...20...30...40...50...60...70...80...90...100 - done. --Nikos Hatzopoulos On Mon, May 9, 2011 at 5:56 PM, Jonathan Greenberg greenb...@ucdavis.eduwrote: Folks: I did a Debian install of both the unstable and the experimental versions of GDAL, and when running gdal_translate on a MODIS HDF4 file I'm getting a segmentation fault. gdalinfo works fine tho. Thoughts? $ gdal_translate -ot Float32 -of ENVI HDF4_EOS:EOS_GRID:MCD15A2.A2002185.h35v10.005.2007177210333.hdf:MOD_Grid_MOD15A2:Lai_1km test_hdf.envi Input file size is 1200, 1200 0Segmentation fault $ gdalinfo HDF4_EOS:EOS_GRID:MCD15A2.A2002185.h35v10.005.2007177210333.hdf:MOD_Grid_MOD15A2:Lai_1km Driver: HDF4Image/HDF4 Dataset Files: MCD15A2.A2002185.h35v10.005.2007177210333.hdf Size is 1200, 1200 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the custom spheroid, DATUM[Not specified (based on custom spheroid), SPHEROID[Custom spheroid,6371007.181,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Sinusoidal], PARAMETER[longitude_of_center,0], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[Meter,1]] Origin = (18903158.834332998842001,-950.51966744137) Pixel Size = (926.625433055833014,-926.625433054999803) Metadata: HDFEOSVersion=HDFEOS_V2.9 LOCALGRANULEID=MCD15A2.A2002185.h35v10.005.2007177210333.hdf PRODUCTIONDATETIME=2007-06-26T21:03:33.000Z DAYNIGHTFLAG=Day REPROCESSINGACTUAL=reprocessed LOCALVERSIONID=5.0.4 REPROCESSINGPLANNED=further update is anticipated SCIENCEQUALITYFLAG=Not Investigated AUTOMATICQUALITYFLAGEXPLANATION=No automatic quality assessment is performed in the PGE AUTOMATICQUALITYFLAG=Passed SCIENCEQUALITYFLAGEXPLANATION=See http://landweb.nascom/nasa.gov/cgi-bin/QA_WWW/qaFlagPage.cgi?sat=aqua the product Science Quality status. QAPERCENTMISSINGDATA=99 QAPERCENTOUTOFBOUNDSDATA=99 QAPERCENTCLOUDCOVER=0 QAPERCENTINTERPOLATEDDATA=0 PARAMETERNAME=MCD15A2 VERSIONID=5 SHORTNAME=MCD15A2 INPUTPOINTER=MYD15A1.A2002192.h35v10.005.2007162232536.hdf, MYD15A1.A2002191.h35v10.005.2007162024118.hdf, MYD15A1.A2002190.h35v10.005.2007162092900.hdf, MYD15A1.A2002189.h35v10.005.2007161211830.hdf, MYD15A1.A2002188.h35v10.005.2007161122622.hdf, MYD15A1.A2002187.h35v10.005.2007161050931.hdf, MYD15A1.A2002186.h35v10.005.2007161012141.hdf, MYD15A1.A2002185.h35v10.005.2007161153557.hdf, MOD15A1.A2002192.h35v10.005.2007163022444.hdf, MOD15A1.A2002191.h35v10.005.2007162214105.hdf, MOD15A1.A2002190.h35v10.005.2007162180320.hdf, MOD15A1.A2002189.h35v10.005.2007161200152.hdf, MOD15A1.A2002188.h35v10.005.2007161164154.hdf, MOD15A1.A2002187.h35v10.005.2007160174423.hdf, MOD15A1.A2002186.h35v10.005.2007152183046.hdf, MOD15A1.A2002185.h35v10.005.2007152031253.hdf, MCD15A2_ANC_RI4.hdf GRINGPOINTLONGITUDE=172.479315908761, 172.622770159185, 179.999502554976, -179.856407114504 GRINGPOINTLATITUDE=-19.1662177463598, -9.98364248250805, -9.97534112170732, -19.180676222654 GRINGPOINTSEQUENCENO=1, 2, 3, 4 EXCLUSIONGRINGFLAG=N RANGEENDINGDATE=2002-07-11 RANGEENDINGTIME=23:59:59 RANGEBEGINNINGDATE=2002-07-04 RANGEBEGINNINGTIME=00:00:00 PGEVERSION=5.0.6 ASSOCIATEDSENSORSHORTNAME=MODIS ASSOCIATEDPLATFORMSHORTNAME=Terra ASSOCIATEDINSTRUMENTSHORTNAME=MODIS ASSOCIATEDSENSORSHORTNAME=MODIS ASSOCIATEDPLATFORMSHORTNAME=Aqua ASSOCIATEDINSTRUMENTSHORTNAME=MODIS QAPERCENTGOODQUALITY=89 QAPERCENTOTHERQUALITY=100 HORIZONTALTILENUMBER=35 VERTICALTILENUMBER=10 TileID=51035010 NDAYS_COMPOSITED=16 QAPERCENTGOODFPAR=89 QAPERCENTGOODLAI=89 QAPERCENTMAINMETHOD=89 QAPERCENTEMPIRICALMODEL=11 NORTHBOUNDINGCOORDINATE=-9.910197 SOUTHBOUNDINGCOORDINATE=-19.183316106 EASTBOUNDINGCOORDINATE=179.99983337 WESTBOUNDINGCOORDINATE=172.622524004598 ALGORITHMPACKAGEACCEPTANCEDATE=10-01-2004 ALGORITHMPACKAGEMATURITYCODE=Normal ALGORITHMPACKAGENAME=MCDPR_15A2 ALGORITHMPACKAGEVERSION=5 GEOANYABNORMAL=False GEOESTMAXRMSERROR=50.0 LONGNAME=MODIS/Terra+Aqua Leaf Area Index/FPAR 8-Day L4 Global 1km SIN Grid PROCESSINGCENTER=MODAPS SYSTEMFILENAME=MYD15A1.A2002192.h35v10.005.2007162232536.hdf, MYD15A1.A2002191.h35v10.005.2007162024118.hdf, MYD15A1.A2002190.h35v10.005.2007162092900.hdf, MYD15A1.A2002189.h35v10.005.2007161211830.hdf, MYD15A1.A2002188.h35v10.005.2007161122622.hdf, MYD15A1.A2002187.h35v10.005.2007161050931.hdf, MYD15A1.A2002186.h35v10.005.2007161012141.hdf, MYD15A1.A2002185.h35v10.005.2007161153557.hdf,
Re: [gdal-dev] Getting GDAL to work with proj.4 on windows
I think you need to setup the environmental variable: PROJ_LIB=$FWTOOLS_HOME/share/proj --Nikos Hatzopoulos On Thu, Apr 21, 2011 at 12:25 PM, viswaug visw...@yahoo.com wrote: Hi all, I am trying to setup a windows for development with GDAL and PROJ.4 with python bindings. I am running Python2.5 on the machine. I got the GDAL binaries from here http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip and the GDAL python bindings from here http://pypi.python.org/packages/2.5/G/GDAL/GDAL-1.6.0.win32-py2.5.exe#md5=1e0ff5c2da337a6ac9af3e5320aa3366 I also installed PROJ.4 binaries from here http://download.osgeo.org/proj/proj446_win32_bin.zip I also installed the pyproj bindings from here http://code.google.com/p/pyproj/downloads/detail?name=pyproj-1.8.8-1.win32-py2.5.execan=2q= I am trying not to mess with the environment variables and system variables on the machine. So, I copied the GDAL binaries into the 'osgeo' folder of the python site-pacakge. This seemed to do the trick and I was able to fire up my python interpreter and work with GDAL. I also copied the proj.dll from the PROJ.4 binaries and copied it to the osgeo folder. But I am not able to transform coordinates in GDAL. When I try to transform coordinates, I end up with the error unable to load proj.4 library (proj.dll), creation of OGRCoordinateTransformation failed Any thoughts/ideas on what I am doing wrong here? Any help with this issue would be greatly appreciated. Thank You, Vish -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Getting-GDAL-to-work-with-proj-4-on-windows-tp6295300p6295300.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ 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] Modis data level1b
yes I was looking to do the processing though gdal which has better development environment for image processing :) 2011/4/21 Hernán De Angelis dhdeangelis.lis...@gmail.com You need mrtswath, the MODIS reprojection tool: https://lpdaac.usgs.gov/lpdaac/tools/modis_reprojection_tool_swath good luck, H. 2011/4/19 Nikolaos Hatzopoulos nhat...@gmail.com: Hi, I have modis level1b data and I have two hdf files a mod03 with the georeference and a mod02 with the bands how I can combine these files to make a nice geotif in gdal? note: hdfeos files are files with the georeference and the bands but for disk space reasons I have two files --Nikos Hatzopoulos ___ 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] Re: dev-version of HDF4
when does the gcc you must have: -L/Users/knutfd/Software/hdf-4.2.5/lib in order to find the lib so you need to do before the compile: export LDFLAGS=$LDFLAGS -L/Users/knutfd/Software/hdf-4.2.5/lib and obviously you are going to need the include files also: export CPPFLAGS=$CPPFLAGS -I/Users/knutfd/Software/hdf-4.2.5/include I am not quite sure if export is going to work or setenv in setenv you don't need the equal I am not an expert in c shell this kind of problem is because the tools are not install in a standard path library like /usr/lib and /usr/include so you have to define compilation flags On Wed, Apr 20, 2011 at 6:11 AM, Knut-Frode Dagestad knutfrodesop...@hotmail.com wrote: I forgot to say, but I have also tried by specifying the location of HDF4, with similar error: ... checking for SDreaddata in -lmfhdfalt... no checking for SDreaddata in -lmfhdf... no checking for SDreaddata in -lhdf4... no checking for SDreaddata in -lmfhdf... no checking for SDreaddata in -lmfhdf... no configure: error: HDF4 support requested with arg /Users/knutfd/Software/hdf-4.2.5/, but neither hdf4 nor mfhdf lib found ... HDF4 library is there, but somehow configure is not able to detect it. HDF4 is compiled without SLIB, so that should not be the problem. I have also tried with older version of HDF4 (4.2r1), other installation points, and prebuilt binaries. And I compiled with options --disable-fortran --disable-netcdf --with-pic, as suggested on http://osgeo-org.1803224.n2.nabble.com/Error-in-GDAL-compiling-with-HDF4-td3351437.html It has been suggested to use a dev version of HDF4, but I don't know if that would solve this problem? Best regards from Knut-Frode On 19/04/2011 21:51, Nikolaos Hatzopoulos wrote: hdf4 libraries not found that's what the log says :) do a locate libhdf4 to see where the library is On Tue, Apr 19, 2011 at 10:24 AM, Knut-Frode Dagestad knutfrodesop...@hotmail.com mailto:knutfrodesop...@hotmail.com wrote: I am trying to compile GDAL from source with support for HDF4 with: ./configure --with-hdf4 but get complaints about missing libraries, see extract from config.log: ld: library not found for -lmfhdfalt ... ld: library not found for -lmfhdf ... ld: library not found for -lhdf4 ... ld: library not found for -lmfhdf configure:19940: checking for SDreaddata in -lmfhdf configure:19965: gcc -o conftest -g -O2 conftest.c -lmfhdf -ldf -lsz -ljpeg -lz -lz -lpthread -ldl 5 ld: library not found for -lmfhdf configure:20009: error: HDF4 support requested with arg yes, but neither hdf4 nor mfhdf lib found Similar errors are also reported by others, e.g. this one using mapserver: http://osgeo-org.1803224.n2.nabble.com/cannot-find-lmfhdf-td5286909.html I have tried with various versions of HDF4, both binaries and compiled from source. The link above (and also http://trac.osgeo.org/gdal/wiki/BuildingOnUnix) suggests to try a hdf-dev version. But where can I find such dev-versions, in my case for Mac OS X 10.6.7? Would it be possible to update GDAL to work with standard HDF4 libraries? Best regards from Knut-Frode ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: dev-version of HDF4
this might help to fix you configure: sed -i 's|-lmfhdf -ldf|-L$libdir/hdf -lmfhdf -ldf|g' configure On Wed, Apr 20, 2011 at 8:27 AM, Knut-Frode knutfrodesop...@hotmail.comwrote: The paths are taken care of by configure, and they are checked to be ok. I also tried with standard installation folders (/usr/lib/ /usr/include/ etc) but no difference. I did not compile, since configure fails. So I believe it must be some incompatibility with the GDAL configure script and the standard HDF4-libraries I have used. The lib not found message from GDAL configure seems to be misleading. Best regards from Knut-Frode Den 20.04.2011 17:03, skrev Nikolaos Hatzopoulos: when does the gcc you must have: -L/Users/knutfd/Software/hdf-4.2.5/lib in order to find the lib so you need to do before the compile: export LDFLAGS=$LDFLAGS -L/Users/knutfd/Software/hdf-4.2.5/lib and obviously you are going to need the include files also: export CPPFLAGS=$CPPFLAGS -I/Users/knutfd/Software/hdf-4.2.5/include I am not quite sure if export is going to work or setenv in setenv you don't need the equal I am not an expert in c shell this kind of problem is because the tools are not install in a standard path library like /usr/lib and /usr/include so you have to define compilation flags On Wed, Apr 20, 2011 at 6:11 AM, Knut-Frode Dagestad knutfrodesop...@hotmail.com mailto:knutfrodesop...@hotmail.com wrote: I forgot to say, but I have also tried by specifying the location of HDF4, with similar error: ... checking for SDreaddata in -lmfhdfalt... no checking for SDreaddata in -lmfhdf... no checking for SDreaddata in -lhdf4... no checking for SDreaddata in -lmfhdf... no checking for SDreaddata in -lmfhdf... no configure: error: HDF4 support requested with arg /Users/knutfd/Software/hdf-4.2.5/, but neither hdf4 nor mfhdf lib found ... HDF4 library is there, but somehow configure is not able to detect it. HDF4 is compiled without SLIB, so that should not be the problem. I have also tried with older version of HDF4 (4.2r1), other installation points, and prebuilt binaries. And I compiled with options --disable-fortran --disable-netcdf --with-pic, as suggested on http://osgeo-org.1803224.n2.nabble.com/Error-in-GDAL-compiling-with-HDF4-td3351437.html It has been suggested to use a dev version of HDF4, but I don't know if that would solve this problem? Best regards from Knut-Frode On 19/04/2011 21:51, Nikolaos Hatzopoulos wrote: hdf4 libraries not found that's what the log says :) do a locate libhdf4 to see where the library is On Tue, Apr 19, 2011 at 10:24 AM, Knut-Frode Dagestad knutfrodesop...@hotmail.com mailto:knutfrodesop...@hotmail.com mailto:knutfrodesop...@hotmail.com mailto:knutfrodesop...@hotmail.com wrote: I am trying to compile GDAL from source with support for HDF4 with: ./configure --with-hdf4 but get complaints about missing libraries, see extract from config.log: ld: library not found for -lmfhdfalt ... ld: library not found for -lmfhdf ... ld: library not found for -lhdf4 ... ld: library not found for -lmfhdf configure:19940: checking for SDreaddata in -lmfhdf configure:19965: gcc -o conftest -g -O2 conftest.c -lmfhdf -ldf -lsz -ljpeg -lz -lz -lpthread -ldl 5 ld: library not found for -lmfhdf configure:20009: error: HDF4 support requested with arg yes, but neither hdf4 nor mfhdf lib found Similar errors are also reported by others, e.g. this one using mapserver: http://osgeo-org.1803224.n2.nabble.com/cannot-find-lmfhdf-td5286909.html I have tried with various versions of HDF4, both binaries and compiled from source. The link above (and also http://trac.osgeo.org/gdal/wiki/BuildingOnUnix) suggests to try a hdf-dev version. But where can I find such dev-versions, in my case for Mac OS X 10.6.7? Would it be possible to update GDAL to work with standard HDF4 libraries? Best regards from Knut-Frode ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev
[gdal-dev] Modis data level1b
Hi, I have modis level1b data and I have two hdf files a mod03 with the georeference and a mod02 with the bands how I can combine these files to make a nice geotif in gdal? note: hdfeos files are files with the georeference and the bands but for disk space reasons I have two files --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] dev-version of HDF4
hdf4 libraries not found that's what the log says :) do a locate libhdf4 to see where the library is On Tue, Apr 19, 2011 at 10:24 AM, Knut-Frode Dagestad knutfrodesop...@hotmail.com wrote: I am trying to compile GDAL from source with support for HDF4 with: ./configure --with-hdf4 but get complaints about missing libraries, see extract from config.log: ld: library not found for -lmfhdfalt ... ld: library not found for -lmfhdf ... ld: library not found for -lhdf4 ... ld: library not found for -lmfhdf configure:19940: checking for SDreaddata in -lmfhdf configure:19965: gcc -o conftest -g -O2 conftest.c -lmfhdf -ldf -lsz -ljpeg -lz -lz -lpthread -ldl 5 ld: library not found for -lmfhdf configure:20009: error: HDF4 support requested with arg yes, but neither hdf4 nor mfhdf lib found Similar errors are also reported by others, e.g. this one using mapserver: http://osgeo-org.1803224.n2.nabble.com/cannot-find-lmfhdf-td5286909.html I have tried with various versions of HDF4, both binaries and compiled from source. The link above (and also http://trac.osgeo.org/gdal/wiki/BuildingOnUnix) suggests to try a hdf-dev version. But where can I find such dev-versions, in my case for Mac OS X 10.6.7? Would it be possible to update GDAL to work with standard HDF4 libraries? Best regards from Knut-Frode ___ 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] gdal_translate segfault with large netCDF
What kind of netcdf file is causing the problem? is a netcdf4 or netcdf3 file? there is a compiling option in netcdf4 --enable-netcdf-4 On Tue, Apr 19, 2011 at 11:35 AM, Kyle Shannon ksshan...@gmail.com wrote: Josh, As frank said, file a ticket and provide the output of ncdump -h yourfile.nc with the ticket. I will take a look at it as soon as I can, although I am pretty busy. Thanks. kss /** * * Kyle Shannon * ksshan...@gmail.com * */ On Tue, Apr 19, 2011 at 09:57, Frank Warmerdam warmer...@pobox.comwrote: On 11-04-19 05:01 AM, josh.v...@csiro.au wrote: Hi, I’m new to GDAL so please forgive any glaring ignorance J Currently I have an 8GB ER Mapper (ERS) dataset that I want to convert to a NetCDF file with gdal_translate which always results in a segfault when using the following command. gdal_translate -of netCDF input.ers output.nc Whereas translating only a small 4B subset of the dataset works fine. Now I’ve been doing a bit of reading and I know that netcdf 3.6.2 and below doesn’t support variables greater than 4GB however I’ve been doing the translations with the Debian libnetcdf6 package (which I believe includes netCDF 4.1.1 and running ‘ncgen –version’ confirms this). I am operating under the impression that netCDF 4.1.1 should be able to handle netCDF files of this size without trouble. Now I’ve tested gdal_translate from a variety of builds and they all produce the same problem Josh, I don't see any immediately obvious problems in the way we call the netcdf API in netcdfdataset.cpp's CreateCopy method. I would suggest you file a ticket on the issue, and a developer can try to reproduce the problem. I would like to suggest that you do a gdal_translate from a subset of the ERS file at the bottom right corner of the source just to ensure that it isn't a problem with reading past the 4GB mark in the ERS file. I seem to have 3.6.3 of the netcdf library so I can't trivially check this on my system. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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] modis level1b files
Hi, I have a mod03 hdf file which has the geolocation of level1b modis file and I have a mod02 hdf file which has the bands how it's possible to combine this two files in order to have a nice geotif? an hdfeos file has the bands and the geolocation, in my case the data are separate. --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal and hdf-eos
what extra libraries requires hdf4? i think only requires szip zlib and jpeg On Fri, Mar 4, 2011 at 10:03 AM, Chaitanya kumar CH chaitanya...@gmail.comwrote: Matt, If there is a work around it's better to avoid building. HDF4 requires some extra libraries. They are probably missing. On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk maf...@nmsu.edu wrote: Hi Chaitanya, no, i didn't build it myself. I simply downloaded the self-installing package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ I am a little unfamiliar still with building stuff on windows, so i am not sure whether it's worth trying to build gdal and the python bindings from scratch or simply use h4toh5 called from the script. thanks matt On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: Matt, Did you build GDAL yourself? HDF4 format is not compiled by default. You can check if this by running the command gdalinfo --formats. See if HDF4 is in the output. http://www.gdal.org/frmt_hdf4.html On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk maf...@nmsu.edu wrote: Hi, i am using python/gdal. I am trying to open a MODIS satellite file from the Terra satellite (which is hdf4-eos format). Doing: ds = gdal.Open(file) drivertype=ds.GetDriver().LongName returns ERROR 4: `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' not recognised as a supported file format. Is this file format not supported? thanks matt ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ 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] gdal and hdf-eos
you are not compiling things from source? On Fri, Mar 4, 2011 at 10:57 AM, Chaitanya kumar CH chaitanya...@gmail.comwrote: GDAL's HDF4 driver is built on top of NCSA HDF library. On Sat, Mar 5, 2011 at 12:20 AM, Nikolaos Hatzopoulos nhat...@gmail.comwrote: what extra libraries requires hdf4? i think only requires szip zlib and jpeg On Fri, Mar 4, 2011 at 10:03 AM, Chaitanya kumar CH chaitanya.ch@ gmail.com wrote: Matt, If there is a work around it's better to avoid building. HDF4 requires some extra libraries. They are probably missing. On Fri, Mar 4, 2011 at 11:01 PM, Matt Funk maf...@nmsu.edu wrote: Hi Chaitanya, no, i didn't build it myself. I simply downloaded the self-installing package for gdal found at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ I am a little unfamiliar still with building stuff on windows, so i am not sure whether it's worth trying to build gdal and the python bindings from scratch or simply use h4toh5 called from the script. thanks matt On 3/3/2011 9:30 PM, Chaitanya kumar CH wrote: Matt, Did you build GDAL yourself? HDF4 format is not compiled by default. You can check if this by running the command gdalinfo --formats. See if HDF4 is in the output. http://www.gdal.org/frmt_hdf4.html On Fri, Mar 4, 2011 at 6:03 AM, Matt Funk maf...@nmsu.edu wrote: Hi, i am using python/gdal. I am trying to open a MODIS satellite file from the Terra satellite (which is hdf4-eos format). Doing: ds = gdal.Open(file) drivertype=ds.GetDriver().LongName returns ERROR 4: `C:/tmp/SrcData/2010Data/MODISData/MOD03/MOD03.A2010002.1810.005.2010258062733.hdf' not recognised as a supported file format. Is this file format not supported? thanks matt ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] lat lon matrix tables to geotif
So we have three tables: one matrix for latitude values one matrix for longitude values one matrix for our data values all the matrix have the same dimensions how we can convert these three tables to geotif using gdal?? --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] lat lon matrix tables to geotif
So you are talking for something like this: Example VRT file for data (just to show the geolocation metadata reference): VRTDataset rasterXSize=2048 rasterYSize=964 Metadata domain=GEOLOCATION MDI key=X_DATASETdata.lon.vrt/MDI MDI key=X_BAND1/MDI MDI key=Y_DATASETdata.lat.vrt/MDI MDI key=Y_BAND1/MDI MDI key=PIXEL_OFFSET0/MDI MDI key=LINE_OFFSET0/MDI MDI key=PIXEL_STEP1/MDI MDI key=LINE_STEP1/MDI /Metadata SRS stuff goes here/SRS VRTRasterBand dataType=UInt16 band=1 subClass=VRTRawRasterBand ImageOffset1500/ImageOffset PixelOffset10/PixelOffset LineOffset22180/LineOffset ByteOrderLSB/ByteOrder /VRTRasterBand /VRTDataset On Tue, Feb 15, 2011 at 10:34 AM, Frank Warmerdam warmer...@pobox.comwrote: On 11-02-15 01:20 PM, Nikolaos Hatzopoulos wrote: So we have three tables: one matrix for latitude values one matrix for longitude values one matrix for our data values all the matrix have the same dimensions how we can convert these three tables to geotif using gdal?? Mikos, This is a georeferencing method I refer to as geolocation grids. It is not a supported organization in GeoTIFF so there is no way to produce a GeoTIFF with the above data where the meaning of the latitude and longitude values will be well understood. If you want to use the resulting geotiffs in non-GDAL applications I think you are best just turning each matrix into a separate TIFF file with appropriate file names to suggest the meaning to and end user. Another option is to just rectify the image data into a normal north up rectified grid and write that to GeoTIFF. Such an output would be easily exploited in any GeoTIFF reading application. It also is possible to use metadata to associate the latitude and longitude as geolocation grids within a GeoTIFF file in a way that some GDAL applications (like gdalwarp) could take advtange of. This requires setting up very specific metadata items to relate the data. The metadata required (for geotiff or other formats) is listed in RFC 4: http://trac.osgeo.org/gdal/wiki/rfc4_geolocate Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ 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] Modis L1B SWATH: georef problem hdf to geotiff
You are right, I notice that there isn't any difference from the band_1.tiff and band_1_warp.tiff --Nikos Hatzopoulos On Mon, Jan 17, 2011 at 8:15 AM, anna auge annaa...@web.de wrote: Hi all, I am trying to convert modis level 1B data (type SWATH) to geotiff following these steps. 1) Examining the HDF gdalinfo d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf gdalinfo HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB 2) Extracting the 1. band of the subdataset MODIS_SWATH_Type_L1B:EV_1KM_RefSB gdal_translate -of GTiff -b 1 HDF4_EOS:EOS_SWATH:d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf:MODIS_SWATH_Type_L1B:EV_1KM_RefSB d:\modis\1b\band_1.tiff 4) Warping the image to WGS84 gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff d:\modis\1b\band_1_warp.tiff The example dataset, which i am using, can be downloaded here ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf And now to my problem: I get always an certain shift ( http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/), which is avoided if i am using the Georeference MODIS option in ENVI ( http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/). I also tried a few workarounds, f.g. http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482, but nothing worked properly. As far as I understand gdal supports Modis L1B SWATH, so what I am doing wrong? Any help is appreciated. Regards Anna P.S. I am using FWTools 2.4.7 on Windows WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! *http://produkte.web.de/go/DSL_Doppel_Flatrate/2*http://produkte.web.de/go/DSL_Doppel_Flatrate/2 ___ 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] Hierarchical Data Format-EOS 2 conversion in Gdal
is there any sample of these data online? On Tue, Jan 11, 2011 at 6:00 AM, abausch adam.bau...@gmail.com wrote: Hi Nikolaos, I wish I were using the level 2 product in .N1 format but the level 3 MERIS mosaics are processed to .hdf - EOS2. I can work with N1 data just fine if that were the case, but batch processing with BEAM doesn't support what I am trying to do with HDF's (unless I could program in Java..yikes) Best, Adam On 1/10/11 10:54 PM, Nikolaos Hatzopoulos wrote: from here: http://www.brockmann-consult.de/cms/web/beam/meris-products I download this file which is level2 data: http://www.brockmann-consult.de/beam/data/products/MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.zip gdalinfo gives me: Driver: ESAT/Envisat Image Format Files: MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.N1 Size is 2241, 2241 Coordinate System is `' GCP Projection = GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4326]] GCP[ 0]: Id=1, Info= (0.5,0.5) - (10.599538,56.49672,0) Metadata: MPH_PRODUCT=MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.N1 MPH_PROC_STAGE=N MPH_REF_DOC=PO-RS-MDA-GS2009_11_3J MPH_ACQUISITION_STATION=PDHS-K MPH_PROC_CENTER=E-PAC MPH_PROC_TIME=04-AUG-2003 15:12:31.508420 MPH_SOFTWARE_VER=MERIS/4.06 MPH_SENSING_START=14-JUL-2003 10:26:32.276537 MPH_SENSING_STOP=14-JUL-2003 10:32:37.452300 MPH_PHASE=2 MPH_CYCLE=+018 MPH_REL_ORBIT=+00094 MPH_ABS_ORBIT=+07162 MPH_STATE_VECTOR_TIME=14-JUL-2003 10:27:00.00 MPH_DELTA_UT1=-.359896 MPH_X_POSITION=+2948879.180 MPH_Y_POSITION=+0636697.527 MPH_Z_POSITION=+6488093.331 MPH_X_VELOCITY=+6793.676563 MPH_Y_VELOCITY=-1452.749368 MPH_Z_VELOCITY=-2938.824735 MPH_VECTOR_SOURCE=FR MPH_UTC_SBT_TIME=14-JUL-2003 10:18:36.710154 MPH_SAT_BINARY_TIME=+2483253760 MPH_CLOCK_STEP=+3906249805 MPH_LEAP_UTC=17-OCT-2001 00:00:00.00 MPH_LEAP_SIGN=+001 MPH_LEAP_ERR=0 MPH_PRODUCT_ERR=1 SPH_SPH_DESCRIPTOR=MER_FR__2P SPECIFIC HEADER SPH_STRIPLINE_CONTINUITY_INDICATOR=+000 SPH_SLICE_POSITION=+001 SPH_NUM_SLICES=+001 SPH_FIRST_LINE_TIME=14-JUL-2003 10:29:18.385327 SPH_LAST_LINE_TIME=14-JUL-2003 10:30:56.938607 SPH_FIRST_FIRST_LAT=+0056496720 SPH_FIRST_FIRST_LONG=+0010599537 SPH_FIRST_MID_LAT=+0057382170 SPH_FIRST_MID_LONG=+0006097018 SPH_FIRST_LAST_LAT=+0058099238 SPH_FIRST_LAST_LONG=+0001394104 SPH_LAST_FIRST_LAT=+0050903410 SPH_LAST_FIRST_LONG=+0007084803 SPH_LAST_MID_LAT=+0051698757 SPH_LAST_MID_LONG=+0003106173 SPH_LAST_LAST_LAT=+0052354870 SPH_LAST_LAST_LONG=-0001001598 SPH_TRANS_ERR_FLAG=0 SPH_FORMAT_ERR_FLAG=0 SPH_DATABASE_FLAG=0 SPH_COARSE_ERR_FLAG=1 SPH_ECMWF_TYPE=1 SPH_NUM_TRANS_ERR=+00 SPH_NUM_FORMAT_ERR=+00 SPH_TRANS_ERR_THRESH=+0.E+00 SPH_FORMAT_ERR_THRESH=+0.E+00 SPH_NUM_BANDS=+015 SPH_BAND_WAVELEN=+412545+442401+489744+509700+559634+6 19620+664640+680902+708426+753472+761606+778498+8648 33+884849+899860 SPH_BANDWIDTH=+09930+09946+09965+09971+09983+09991+09994+07493+09996+07493+037 42+15000+1+09990+09989 SPH_INST_FOV=+019159 SPH_PROC_MODE=1 SPH_OFFSET_COMP=1 SPH_LINE_TIME_INTERVAL=+043997 SPH_LINE_LENGTH=+02241 SPH_LINES_PER_TIE_PT=+064 SPH_SAMPLES_PER_TIE_PT=+064 SPH_COLUMN_SPACING=+2.6000E+02 DS_LEVEL_1B_PRODUCT_NAME=MER_FR__1PNEPA20030714_102918_00982018_00094_0716 2_0120.N1 DS_AEROSOL_CLIMATOLOGY_FILE_NAME=MER_AER_AXVIEC20030620_12_20020321_193100 _20200101_00 DS_PROCESSING_PARAMS_L2_FILE_NAME=MER_CP2_AXVIEC20030620_12_20021224_12144 5_20121224_121445 DS_ATMOSPHERIC_PARAMETERS_FILE_NAME=MER_ATP_AXVIEC20030620_12_20021224_121 445_20121224_121445 DS_WATER_VAPOUR_PARAMETERS_FILE_NAME=MER_WVP_AXVIEC20030620_12_20020321_19 3100_20120321_193100 DS_OCEAN_AEROSOLS_PARAMS_FILE_NAME=MER_OAP_AXVIEC20030620_120001_20020321_1931 00_20120321_193100 DS_LAND_AEROSOLS_PARAMS_FILE_NAME=MER_LAP_AXVIEC20030715_151450_20020321_19310 0_20120321_193100 DS_OCEAN_I_PARAMETERS_FILE_NAME=MER_OC1_AXVIEC20030620_12_20020321_193100_ 20120321_193100 DS_OCEAN_II_PARAMETERS_FILE_NAME=MER_OC2_AXVIEC20030620_12_20020321_193100 _20120624_174339 DS_CLOUD_MEASUREMENT_FILE_NAME=MER_CMP_AXVIEC20030620_12_20021224_121445_2 0120321_193100 DS_LAND_VEGETATION_INDEX_FILE_NAME=MER_LVI_AXVIEC20030620_12_20020321_1931 00_20130224_164916 Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 2241.0) Upper Right ( 2241.0,0.0) Lower Right ( 2241.0
Re: [gdal-dev] Hierarchical Data Format-EOS 2 conversion in Gdal
-L3_MOSAIC_2005_V2.0_ANNUAL_H35V15.hdf:POSTEL:NDVI SUBDATASET_29_DESC=[1800x1800] NDVI POSTEL (8-bit unsigned integer) Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 512.0) Upper Right ( 512.0,0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) something is going wrong with your hdf library or it's not linked well or the compilation is not correct of gdal I will repeat again I am using elgis for centos linux I don't know what's going on on Ubuntu On Tue, Jan 11, 2011 at 8:04 AM, Nikolaos Hatzopoulos nhat...@gmail.comwrote: is there any sample of these data online? On Tue, Jan 11, 2011 at 6:00 AM, abausch adam.bau...@gmail.com wrote: Hi Nikolaos, I wish I were using the level 2 product in .N1 format but the level 3 MERIS mosaics are processed to .hdf - EOS2. I can work with N1 data just fine if that were the case, but batch processing with BEAM doesn't support what I am trying to do with HDF's (unless I could program in Java..yikes) Best, Adam On 1/10/11 10:54 PM, Nikolaos Hatzopoulos wrote: from here: http://www.brockmann-consult.de/cms/web/beam/meris-products I download this file which is level2 data: http://www.brockmann-consult.de/beam/data/products/MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.zip gdalinfo gives me: Driver: ESAT/Envisat Image Format Files: MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.N1 Size is 2241, 2241 Coordinate System is `' GCP Projection = GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AUTHORITY[EPSG,4326]] GCP[ 0]: Id=1, Info= (0.5,0.5) - (10.599538,56.49672,0) Metadata: MPH_PRODUCT=MER_FR__2PNEPA20030714_102918_00982018_00094_07162_0053.N1 MPH_PROC_STAGE=N MPH_REF_DOC=PO-RS-MDA-GS2009_11_3J MPH_ACQUISITION_STATION=PDHS-K MPH_PROC_CENTER=E-PAC MPH_PROC_TIME=04-AUG-2003 15:12:31.508420 MPH_SOFTWARE_VER=MERIS/4.06 MPH_SENSING_START=14-JUL-2003 10:26:32.276537 MPH_SENSING_STOP=14-JUL-2003 10:32:37.452300 MPH_PHASE=2 MPH_CYCLE=+018 MPH_REL_ORBIT=+00094 MPH_ABS_ORBIT=+07162 MPH_STATE_VECTOR_TIME=14-JUL-2003 10:27:00.00 MPH_DELTA_UT1=-.359896 MPH_X_POSITION=+2948879.180 MPH_Y_POSITION=+0636697.527 MPH_Z_POSITION=+6488093.331 MPH_X_VELOCITY=+6793.676563 MPH_Y_VELOCITY=-1452.749368 MPH_Z_VELOCITY=-2938.824735 MPH_VECTOR_SOURCE=FR MPH_UTC_SBT_TIME=14-JUL-2003 10:18:36.710154 MPH_SAT_BINARY_TIME=+2483253760 MPH_CLOCK_STEP=+3906249805 MPH_LEAP_UTC=17-OCT-2001 00:00:00.00 MPH_LEAP_SIGN=+001 MPH_LEAP_ERR=0 MPH_PRODUCT_ERR=1 SPH_SPH_DESCRIPTOR=MER_FR__2P SPECIFIC HEADER SPH_STRIPLINE_CONTINUITY_INDICATOR=+000 SPH_SLICE_POSITION=+001 SPH_NUM_SLICES=+001 SPH_FIRST_LINE_TIME=14-JUL-2003 10:29:18.385327 SPH_LAST_LINE_TIME=14-JUL-2003 10:30:56.938607 SPH_FIRST_FIRST_LAT=+0056496720 SPH_FIRST_FIRST_LONG=+0010599537 SPH_FIRST_MID_LAT=+0057382170 SPH_FIRST_MID_LONG=+0006097018 SPH_FIRST_LAST_LAT=+0058099238 SPH_FIRST_LAST_LONG=+0001394104 SPH_LAST_FIRST_LAT=+0050903410 SPH_LAST_FIRST_LONG=+0007084803 SPH_LAST_MID_LAT=+0051698757 SPH_LAST_MID_LONG=+0003106173 SPH_LAST_LAST_LAT=+0052354870 SPH_LAST_LAST_LONG=-0001001598 SPH_TRANS_ERR_FLAG=0 SPH_FORMAT_ERR_FLAG=0 SPH_DATABASE_FLAG=0 SPH_COARSE_ERR_FLAG=1 SPH_ECMWF_TYPE=1 SPH_NUM_TRANS_ERR=+00 SPH_NUM_FORMAT_ERR=+00 SPH_TRANS_ERR_THRESH=+0.E+00 SPH_FORMAT_ERR_THRESH=+0.E+00 SPH_NUM_BANDS=+015 SPH_BAND_WAVELEN=+412545+442401+489744+509700+559634+6 19620+664640+680902+708426+753472+761606+778498+8648 33+884849+899860 SPH_BANDWIDTH=+09930+09946+09965+09971+09983+09991+09994+07493+09996+07493+037 42+15000+1+09990+09989 SPH_INST_FOV=+019159 SPH_PROC_MODE=1 SPH_OFFSET_COMP=1 SPH_LINE_TIME_INTERVAL=+043997 SPH_LINE_LENGTH=+02241 SPH_LINES_PER_TIE_PT=+064 SPH_SAMPLES_PER_TIE_PT=+064 SPH_COLUMN_SPACING=+2.6000E+02 DS_LEVEL_1B_PRODUCT_NAME=MER_FR__1PNEPA20030714_102918_00982018_00094_0716 2_0120.N1 DS_AEROSOL_CLIMATOLOGY_FILE_NAME=MER_AER_AXVIEC20030620_12_20020321_193100 _20200101_00 DS_PROCESSING_PARAMS_L2_FILE_NAME=MER_CP2_AXVIEC20030620_12_20021224_12144 5_20121224_121445 DS_ATMOSPHERIC_PARAMETERS_FILE_NAME=MER_ATP_AXVIEC20030620_12_20021224_121 445_20121224_121445 DS_WATER_VAPOUR_PARAMETERS_FILE_NAME=MER_WVP_AXVIEC20030620_12_20020321_19 3100_20120321_193100 DS_OCEAN_AEROSOLS_PARAMS_FILE_NAME=MER_OAP_AXVIEC20030620_120001_20020321_1931 00_20120321_193100 DS_LAND_AEROSOLS_PARAMS_FILE_NAME
Re: [gdal-dev] Hierarchical Data Format-EOS 2 conversion in Gdal
what gdalinfo gives you? this is a very helpful link http://www.gdal.org/frmt_hdf4.html On Mon, Jan 10, 2011 at 10:19 AM, Adam Bausch abau...@nova.whrc.org wrote: Hi All, I am attempting to process a large volume of MERIS mosaic data obtained from ENVISAT in HDF-EOS2 format, however, I continue to get a not a supported format error when I try to run it. I have installed the HDF-4 (libdf), HDF-5 (libhdf5) and NetCDF libraries and checked with our Linux/Unix administrator to try and identify the problem with no resolution. I was wondering if anyone else has had this problem or if there is a fix. Best, Adam ___ 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] Hierarchical Data Format-EOS 2 conversion in Gdal
Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(7) Band 8 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(8) Band 9 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(9) Band 10 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(10) Band 11 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(11) Band 12 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(12) Band 13 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Norm. rho_surf - MDS(13) Band 14 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = YS, SPM, Rect. Rho- MDS(16) Band 15 Block=2241x1 Type=UInt16, ColorInterp=Undefined Description = Epsilon, OPT - MDS(19) I am using centos linux On Mon, Jan 10, 2011 at 12:54 PM, Adam Bausch abau...@nova.whrc.org wrote: Hi, I get the following error. GDALOpen failed - 4 `H29V13.hdf' not recognised as a supported file format. Thanks for the link. Adam On 1/10/11 3:31 PM, Nikolaos Hatzopoulos wrote: what gdalinfo gives you? this is a very helpful link http://www.gdal.org/frmt_hdf4.html On Mon, Jan 10, 2011 at 10:19 AM, Adam Bausch abau...@nova.whrc.orgwrote: Hi All, I am attempting to process a large volume of MERIS mosaic data obtained from ENVISAT in HDF-EOS2 format, however, I continue to get a not a supported format error when I try to run it. I have installed the HDF-4 (libdf), HDF-5 (libhdf5) and NetCDF libraries and checked with our Linux/Unix administrator to try and identify the problem with no resolution. I was wondering if anyone else has had this problem or if there is a fix. Best, Adam ___ 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] gdal_translate and modis ocean HDFs
Could you please send me what you have when you do gdalinfo yourfiles.hdf On Mon, Dec 20, 2010 at 9:55 AM, Gustavo gmpul...@yahoo.com.ar wrote: Hi Nikolaos, sorry for the delay in answering. I've tried your suggestion but the error is the same. Gustavo On Vie 03 Dic 2010 15:03:04 usted escribió: gdal_translate -of GTiff 'HDF4_SDS:UNKNOWN:A20100252010032.L3m_8D_CHL_chlor_a_9km:0' test.tif see if that works you need this : ' On Fri, Dec 3, 2010 at 6:56 AM, Gustavo gmpul...@yahoo.com.ar wrote: Hi everyone, I am trying to import some L3 MODIS satellite images into GRASS 6.4 by following the instructions from: http://grass.osgeo.org/wiki/MODIS#Import I've tried method 1 but I got some error messages. gdal_translate -a_srs +init=epsg:4326 -a_nodata 65535 -a_ullr -180 90 180 -90 -co COMPRESS=PACKBITS HDF4_SDS:UNKNOWN:A20100252010032.L3m_8D_CHL_chlor_a_9km:0 prueba.tif Input file size is 4320, 2160 0ERROR 1: SDreaddata() failed for block. ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0 The error is the same with different files. My system is Ubuntu 9.10 64bits. gdal_translate --version GDAL 1.7.2, released 2010/04/23 What can I do? Thanks, Gustavo Martínez ___ 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] raster lat lon value
Hi, We have a raster one band let's say a geotiff in an x type of geo reference, how we can find what's the raster's value for a specific lat lon (wgs84) --Nikos Hatzopoulos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdawrap nodata value
we have an image named evi.tif: Driver: GTiff/GeoTIFF Files: evi.tif evi.tif.aux.xml Size is 4800, 4800 Coordinate System is: PROJCS[unnamed, GEOGCS[Unknown datum based upon the custom spheroid, DATUM[Not_specified_based_on_custom_spheroid, SPHEROID[Custom spheroid,6371007.181,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Sinusoidal], PARAMETER[longitude_of_center,0], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (950.51966744137,5559752.598333000205457) Pixel Size = (231.656358263749951,-231.656358263750064) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 950.520, 5559752.598) ( 15d33'26.06E, 50d 0'0.00N) Lower Left ( 950.520, 4447802.079) ( 13d 3'14.66E, 40d 0'0.00N) Upper Right ( 2223901.039, 5559752.598) ( 31d 6'52.12E, 50d 0'0.00N) Lower Right ( 2223901.039, 4447802.079) ( 26d 6'29.32E, 40d 0'0.00N) Center ( 1667925.779, 5003777.339) ( 21d12'47.53E, 45d 0'0.00N) Band 1 Block=4800x1 Type=Int16, ColorInterp=Gray Min=-1958.000 Max=9866.000 Minimum=-1958.000, Maximum=9866.000, Mean=2649.127, StdDev=985.073 NoData Value=-3000 Metadata: STATISTICS_MINIMUM=-1958 STATISTICS_MAXIMUM=9866 STATISTICS_MEAN=2649.1270908869 STATISTICS_STDDEV=985.07287762024 we will try to convert the projection: gdalwarp -srcnodata -3000 -dstnodata -3000 -t_srs EPSG:4326 -r near evi.tif test.tif gdalinfo test.tif Driver: GTiff/GeoTIFF Files: test.tif test.tif.aux.xml Size is 8434, 4670 Coordinate System is: 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]] Origin = (13.054072891468254,49.5506890) Pixel Size = (0.002141488569817,-0.002141488569817) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 13.0540729, 50.000) ( 13d 3'14.66E, 50d 0'0.00N) Lower Left ( 13.0540729, 39.9992484) ( 13d 3'14.66E, 39d59'57.29N) Upper Right ( 31.1153875, 50.000) ( 31d 6'55.39E, 50d 0'0.00N) Lower Right ( 31.1153875, 39.9992484) ( 31d 6'55.39E, 39d59'57.29N) Center ( 22.0847302, 44.9996242) ( 22d 5'5.03E, 44d59'58.65N) Band 1 Block=8434x1 Type=Int16, ColorInterp=Gray Min=-1958.000 Max=9866.000 Minimum=-1958.000, Maximum=9866.000, Mean=1838.460, StdDev=1460.598 Metadata: STATISTICS_MINIMUM=-1958 STATISTICS_MAXIMUM=9866 STATISTICS_MEAN=1838.4595819714 STATISTICS_STDDEV=1460.5982146014 NoData value is not defined ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
