Hi, Thanks! But it is workig only for some while for some hdf's, error still appears. I assigned one uniform target extent for all the files since this was what I specified before I downloaded the files from the oceancolor nasa.
ERROR: D:\hdf\file\input> gdalwarp -geoloc -te 109.975 3.475 135.025 25.025 HDF4_SDS:UNKNOWN:"A2014045050000.L2_LA C.SeAHABS.hdf":37 sample.tif Creating output file that is 927P x 798L. Processing input file HDF4_SDS:UNKNOWN:A2014045050000.L2_LAC.SeAHABS.hdf:37. ERROR 1: Too many points (438 out of 441) failed to transform, unable to compute output bounds. Warning 1: Unable to compute source region for output window 0,0,927,798, skipping. 0...10...20...30...40...50...60...70...80...90...100 - done. On Mon, Sep 15, 2014 at 11:02 PM, <gdal-dev-requ...@lists.osgeo.org> wrote: > Send gdal-dev mailing list submissions to > gdal-dev@lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > gdal-dev-requ...@lists.osgeo.org > > You can reach the person managing the list at > gdal-dev-ow...@lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. Problem with HDF5 CSK files and .hdr files generated by ENVI (vf) > 2. Working with Kakadu (kursatk) > 3. GDAL sqlite /spatialite support with trignometric functions > (yhema.2705) > 4. Re: Problem with HDF5 CSK files and .hdr files generated by > ENVI (Even Rouault) > 5. Re: Working with Kakadu (Even Rouault) > 6. Re: Problem with HDF5 CSK files and .hdr files generated by > ENVI (victor fomin) > 7. Re: GDAL sqlite /spatialite support with trignometric > functions (Jukka Rahkonen) > 8. Re: ERROR 1: Too many points (440 out of 441) failed to > transform, unable to compute output bounds. (Andre Joost) > 9. Re: ERROR 1: Too many points (440 out of 441) failed to > transform, unable to compute output bounds. (Simon Shak) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Sep 2014 01:44:54 -0700 (PDT) > From: vf <victor.fomi...@gmail.com> > To: gdal-dev@lists.osgeo.org > Subject: [gdal-dev] Problem with HDF5 CSK files and .hdr files > generated by ENVI > Message-ID: <1410770694879-5161812.p...@n6.nabble.com> > Content-Type: text/plain; charset=us-ascii > > > Dear GDAL developers, > > I constate that GDAL (e.g. gdalinfo) fails to open correctly CSK hdf5 files > which have been read before by ENVI software (and .hdr file is generated > near .h5 source file). In this case GDAL uses driver "ENVI/ENVI .hdr > Labelled" instead of HDF5 if the file is not present. Suppression of the > generated .hdr file can fix the problem. Do you think that it is the only > solution ? > > Cheers, > Victor > > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Problem-with-HDF5-CSK-files-and-hdr-files-generated-by-ENVI-tp5161812.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 2 > Date: Mon, 15 Sep 2014 01:57:27 -0700 (PDT) > From: kursatk <kurs...@gmail.com> > To: gdal-dev@lists.osgeo.org > Subject: [gdal-dev] Working with Kakadu > Message-ID: <1410771447865-5161815.p...@n6.nabble.com> > Content-Type: text/plain; charset=us-ascii > > Hi; > > I read lots of texts about gdal and kakadu, and i am a bit confused. I'm > trying to read a jp2 image with kakadu driver by using gdal java bindings > api. Hence, i should register JP2KAK driver. Most of my researchs say that, > i can do that by building gdal with kakadu library. But, i wonder, isn't > there a way to do that as using plugin architecture? I mean, i am looking > for some easy ways. > > Thanks for your advance. > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Working-with-Kakadu-tp5161815.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 3 > Date: Mon, 15 Sep 2014 04:23:33 -0700 (PDT) > From: "yhema.2705" <yhema.2...@gmail.com> > To: gdal-dev@lists.osgeo.org > Subject: [gdal-dev] GDAL sqlite /spatialite support with trignometric > functions > Message-ID: <1410780213752-5161833.p...@n6.nabble.com> > Content-Type: text/plain; charset=us-ascii > > hi , > > I have build gdal 1.11 with spatialite and sqlite support. I want the layer > attributes of the shape file be updated with trignometric values .Update is > functioning well for arithemetic functions for trignometric functions it is > giving error : ERROR 1: In ExecuteSQL(): sqlite3_prepare(UPDATE > gemetry_test > SET ID = tan(45) ): > no such function: tan. > thanks all > > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/GDAL-sqlite-spatialite-support-with-trignometric-functions-tp5161833.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > > > ------------------------------ > > Message: 4 > Date: Mon, 15 Sep 2014 14:48:26 +0200 > From: Even Rouault <even.roua...@spatialys.com> > To: vf <victor.fomi...@gmail.com> > Cc: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] Problem with HDF5 CSK files and .hdr files > generated by ENVI > Message-ID: <1410785306.5416e01af3...@imp.free.fr> > Content-Type: text/plain; charset=ISO-8859-15 > > Selon vf <victor.fomi...@gmail.com>: > > > > > Dear GDAL developers, > > > > I constate that GDAL (e.g. gdalinfo) fails to open correctly CSK hdf5 > files > > which have been read before by ENVI software (and .hdr file is generated > > near .h5 source file). In this case GDAL uses driver "ENVI/ENVI .hdr > > Labelled" instead of HDF5 if the file is not present. Suppression of the > > generated .hdr file can fix the problem. Do you think that it is the only > > solution ? > > Victor, > > You can define GDAL_SKIP=ENVI as environment variable as well to avoid the > ENVI > driver to be used at all. > We could/should probably register the ENVI driver in last, so to be sure > it is > used only after all other drivers have been tried. > Could you paste the content of the .hdr file ? It is a bit strange that > such a > file is generated without a BIL/BIP/BIQ image file that matches it (isn't > there > any other file next to the .hdr and .h5 file that would have been > generated by > ENVI?). There are perhaps some keywords in that .hdr file that would show > it > should be ignored. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > > > ------------------------------ > > Message: 5 > Date: Mon, 15 Sep 2014 14:54:27 +0200 > From: Even Rouault <even.roua...@spatialys.com> > To: kursatk <kurs...@gmail.com> > Cc: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] Working with Kakadu > Message-ID: <1410785667.5416e18321...@imp.free.fr> > Content-Type: text/plain; charset=ISO-8859-15 > > Selon kursatk <kurs...@gmail.com>: > > > Hi; > > > > I read lots of texts about gdal and kakadu, and i am a bit confused. I'm > > trying to read a jp2 image with kakadu driver by using gdal java bindings > > api. Hence, i should register JP2KAK driver. Most of my researchs say > that, > > i can do that by building gdal with kakadu library. But, i wonder, isn't > > there a way to do that as using plugin architecture? I mean, i am looking > > for some easy ways. > > In theory almost all GDAL drivers could be compiled as plugins, but not > all of > them have the makefile support to do so. I've looked at the JP2KAK driver > and > currently there are no makefile rules for Linux or Windows to make it > build as a > plugin. I don't think there ara fundamental reasons for not having plugin > support for this driver (although JP2KAK could be a pain since the way the > Kakadu library makes it available to other programs/libraries is non > standard). > Just someone has to do it. > > > > > Thanks for your advance. > > > > > > > > -- > > View this message in context: > > http://osgeo-org.1560.x6.nabble.com/Working-with-Kakadu-tp5161815.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 > > > > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > > > ------------------------------ > > Message: 6 > Date: Mon, 15 Sep 2014 14:57:11 +0200 > From: victor fomin <victor.fomi...@gmail.com> > To: Even Rouault <even.roua...@spatialys.com>, > gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] Problem with HDF5 CSK files and .hdr files > generated by ENVI > Message-ID: > < > ca+ynr02ptayt5k8a+5xgt8zjrpbg8qgb+h532af52daw0tx...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Even, > > > Thank you for the suggestion to skip the driver, it is ok for me. > Concerning other files generated by ENVI, I am not sure how it is working, > but I have the only .hdr file after simple opening the CSK imagery. > > Here is the content of the .hdr file : > -------- > ENVI > description = { > COSMO SkyMed # 3 Prod Type: Level 1A Single-look Complex Sland > Acquisition > Mode:ENHANCED SPOTLIGHT Pol: Vertical Tx/Vertical Rx} > samples = 19124 > lines = 14378 > bands = 2 > header offset = 0 > file type = ENVI Standard > data type = 2 > interleave = bsq > sensor type = COSMO-SkyMed > byte order = 0 > read procedures = {envi_cosmo_read_spatial, envi_cosmo_read_spectral} > subset procedure = envi_cosmo_read_scroll > wavelength units = Unknown > band names = { > Real-SCS_U-ENHANCED SPOTLIGHT-VV, Imaginary-SCS_U-ENHANCED SPOTLIGHT-VV} > cosmo info = { > /S01/SBI, > CSKS3_SCS_U_S2_19_VV_RD_SF_20140905173604_20140905173612_qlk_S01_00, none, > none, /S01/SBI, > CSKS3_SCS_U_S2_19_VV_RD_SF_20140905173604_20140905173612_qlk_S01_01, none, > none} > ------- > > > Victor > > > > > On Mon, Sep 15, 2014 at 2:48 PM, Even Rouault <even.roua...@spatialys.com> > wrote: > > > Selon vf <victor.fomi...@gmail.com>: > > > > > > > > Dear GDAL developers, > > > > > > I constate that GDAL (e.g. gdalinfo) fails to open correctly CSK hdf5 > > files > > > which have been read before by ENVI software (and .hdr file is > generated > > > near .h5 source file). In this case GDAL uses driver "ENVI/ENVI .hdr > > > Labelled" instead of HDF5 if the file is not present. Suppression of > the > > > generated .hdr file can fix the problem. Do you think that it is the > only > > > solution ? > > > > Victor, > > > > You can define GDAL_SKIP=ENVI as environment variable as well to avoid > the > > ENVI > > driver to be used at all. > > We could/should probably register the ENVI driver in last, so to be sure > > it is > > used only after all other drivers have been tried. > > Could you paste the content of the .hdr file ? It is a bit strange that > > such a > > file is generated without a BIL/BIP/BIQ image file that matches it (isn't > > there > > any other file next to the .hdr and .h5 file that would have been > > generated by > > ENVI?). There are perhaps some keywords in that .hdr file that would show > > it > > should be ignored. > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140915/73a1aabb/attachment-0001.html > > > > ------------------------------ > > Message: 7 > Date: Mon, 15 Sep 2014 14:20:01 +0000 (UTC) > From: Jukka Rahkonen <jukka.rahko...@mmmtike.fi> > To: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] GDAL sqlite /spatialite support with > trignometric functions > Message-ID: <loom.20140915t161807-...@post.gmane.org> > Content-Type: text/plain; charset=us-ascii > > yhema.2705 <yhema.2705 <at> gmail.com> writes: > > > > > hi , > > > > I have build gdal 1.11 with spatialite and sqlite support. I want the > layer > > attributes of the shape file be updated with trignometric values .Update > is > > functioning well for arithemetic functions for trignometric functions it > is > > giving error : ERROR 1: In ExecuteSQL(): sqlite3_prepare(UPDATE > gemetry_test > > SET ID = tan(45) ): > > no such function: tan. > > thanks all > > Works for me with the Windows binaries (v.2.0-dev) from gisinternalt.com. > > C:\temp\>ogrinfo -dialect sqlite tantest.shp -sql "update tantest set > num=tan(45)" > > C:\temp\>ogrinfo tantest.shp -al > INFO: Open of `tantest.shp' > using driver `ESRI Shapefile' successful. > > Layer name: tantest > Geometry: Polygon > Feature Count: 1 > Extent: (3213863.000000, 6802915.000000) - (3215302.000000, 6804011.000000) > Layer SRS WKT: > (unknown) > num: Real (33.16) > OGRFeature(tantest):0 > num (Real) = 1.6197751905438615 > POLYGON ((3213863 6803646,3215055 6804011,3215302 6803152,3214776 > 6802915,3213863 6803646)) > > > -Jukka Rahkonen- > > > > ------------------------------ > > Message: 8 > Date: Mon, 15 Sep 2014 16:39:06 +0200 > From: Andre Joost <andre+jo...@nurfuerspam.de> > To: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) > failed to transform, unable to compute output bounds. > Message-ID: <lv6u0h$kfa$1...@ger.gmane.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 15.09.2014 04:22, schrieb Love: > > Thanks andre, will try this as soon as I can and will give you a update. > > > > I just want to ask if will it be possible to batch process my hdf files > and > > gdalwarp everything if I'm going to specify the -te of each files? > > > > I am not sure if the -te coordinates follow a certain pattern. It should > be possible to read the metadata information with gdalinfo, and extract > the coordinate information with a python script that can build the > gdalwarp command from it. But I am not a python expert. > > HTH, > Andr? Joost > > > > > ------------------------------ > > Message: 9 > Date: Mon, 15 Sep 2014 10:02:05 -0500 > From: Simon Shak <skunkmyrd...@gmail.com> > To: Andre Joost <andre+jo...@nurfuerspam.de> > Cc: gdal-dev@lists.osgeo.org > Subject: Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) > failed to transform, unable to compute output bounds. > Message-ID: > <CAJuTQSGAJ_sy2AM0ZXH+13GfR= > w5ur-rawjq3lfmvafuky2...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I have had this error message show up if the s_srs is not correctly auto > detected or not present in the input file. I have used a combination of > looking through other nonstandard meta data files present with the image > sets or using a program like global mapper which has a good chance at > guessing the correct s_srs and then specifying it with the -s_srs option. > On Sep 12, 2014 11:19 AM, "Andre Joost" <andre+jo...@nurfuerspam.de> > wrote: > > > Am 12.09.2014 04:54, schrieb Love: > > > >> Hi, > >> > >> The gdalinfo in my post is the gdalinfo of the subdataset 37. I have > also > >> tried gdal_translate but when I tried to use gdalwarp using the > >> gdal_translate output, it has error. I really need to use gdalwarp so > that > >> I could project the image into epsg:4326(+prj=longlat). If I'm going to > >> use > >> the gdal_translate I am ask to indicate the gcp which is not good in my > >> case because I have many hdf files in my local directory and maybe they > >> have different gcp and I need to batch process them later using the > >> gdalwarp with the +proj=longlat command. What could be the solution? > >> > > > > gdalwarp needs the -geoloc switch, and the target extent with -te. See > > also <http://osgeo-org.1560.x6.nabble.com/gdal-dev- > > Geolocation-Arrays-td4372909.html> > > > > There does not seen to be any progress on this issue. > > > > The values for -te can be found with gdalinfo on the subdataset. > > > > HTH, > > Andr? Joost > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140915/5ab581c6/attachment.html > > > > ------------------------------ > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > End of gdal-dev Digest, Vol 124, Issue 22 > ***************************************** >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev