[gdal-dev] gdal-dev Digest, Vol 124, Issue 22
Love
ljvillarin30 at gmail.com
Tue Sep 16 19:59:03 PDT 2014
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-request at lists.osgeo.org> wrote:
> Send gdal-dev mailing list submissions to
> gdal-dev at 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-request at lists.osgeo.org
>
> You can reach the person managing the list at
> gdal-dev-owner at 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.fomin.1 at gmail.com>
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] Problem with HDF5 CSK files and .hdr files
> generated by ENVI
> Message-ID: <1410770694879-5161812.post at 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 <kursatk at gmail.com>
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] Working with Kakadu
> Message-ID: <1410771447865-5161815.post at 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.2705 at gmail.com>
> To: gdal-dev at lists.osgeo.org
> Subject: [gdal-dev] GDAL sqlite /spatialite support with trignometric
> functions
> Message-ID: <1410780213752-5161833.post at 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.rouault at spatialys.com>
> To: vf <victor.fomin.1 at gmail.com>
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Problem with HDF5 CSK files and .hdr files
> generated by ENVI
> Message-ID: <1410785306.5416e01af385f at imp.free.fr>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Selon vf <victor.fomin.1 at 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.rouault at spatialys.com>
> To: kursatk <kursatk at gmail.com>
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Working with Kakadu
> Message-ID: <1410785667.5416e18321d43 at imp.free.fr>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Selon kursatk <kursatk at 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 at 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.fomin.1 at gmail.com>
> To: Even Rouault <even.rouault at spatialys.com>,
> gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Problem with HDF5 CSK files and .hdr files
> generated by ENVI
> Message-ID:
> <
> CA+ynR02PTAYT5k8A+5xGt8ZJrpBG8qgB+H532aF52dAw0tx4cg at 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.rouault at spatialys.com>
> wrote:
>
> > Selon vf <victor.fomin.1 at 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.rahkonen at mmmtike.fi>
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] GDAL sqlite /spatialite support with
> trignometric functions
> Message-ID: <loom.20140915T161807-624 at 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+joost at nurfuerspam.de>
> To: gdal-dev at 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 at 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 <skunkmyrddyn at gmail.com>
> To: Andre Joost <andre+joost at nurfuerspam.de>
> Cc: gdal-dev at 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-RAwJQ3LFmvafUKy2L1w at 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+joost at 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 at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> End of gdal-dev Digest, Vol 124, Issue 22
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140917/5c6f9890/attachment-0001.html>
More information about the gdal-dev
mailing list