Re: [gdal-dev] grib driver

On jeudi 28 février 2019 10:55:00 CET Zhan Zhang - NOAA Affiliate wrote: > May I ask whether gdal grib driver support changing grid in a GRIB2 > message? For instance, given a GRIB2 message, I want to change from polar > stereographic grid projection to lambert conformal grid projection, and the >

Re: [gdal-dev] grib driver

May I ask whether gdal grib driver support changing grid in a GRIB2 message? For instance, given a GRIB2 message, I want to change from polar stereographic grid projection to lambert conformal grid projection, and the data section need also be changed accordingly, and then output this to a new

Re: [gdal-dev] grib driver

On jeudi 28 février 2019 09:29:41 CET Zhan Zhang - NOAA Affiliate wrote: > I am new to the gdal apis and is interested in getting some knowledge of > the grib driver. May I ask whether it basically provides the same > functionality as degrib from MDL/NWS/NOAA? Thanks! --Zhan The GDAL GRIB driver

[gdal-dev] grib driver

I am new to the gdal apis and is interested in getting some knowledge of the grib driver. May I ask whether it basically provides the same functionality as degrib from MDL/NWS/NOAA? Thanks! --Zhan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

Ah, then just the #include "tdlpack.h" in metaprint needs to get commentout, wrapped, or removed On Fri, Dec 8, 2017 at 1:39 PM, Even Rouault wrote: > On vendredi 8 décembre 2017 13:33:11 CET Kurt Schwehr wrote: > > > What about metaprint? Can the TDLP_MERCATOR,

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

On vendredi 8 décembre 2017 13:33:11 CET Kurt Schwehr wrote: > What about metaprint? Can the TDLP_MERCATOR, TDLP_POLAR, and TDLP_LAMBERT > go away? And then I think that is the last use of tdlpack.h The code in metaprint.cpp that uses TDLP_ was already commented out -- Spatialys -

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

What about metaprint? Can the TDLP_MERCATOR, TDLP_POLAR, and TDLP_LAMBERT go away? And then I think that is the last use of tdlpack.h On Fri, Dec 8, 2017 at 9:34 AM, Even Rouault wrote: > On mardi 5 décembre 2017 07:15:39 CET Kurt Schwehr wrote: > > > I've found

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

On mardi 5 décembre 2017 07:15:39 CET Kurt Schwehr wrote: > I've found nothing that depends on TDLPACK I've just committed the change to remove TDLPACK support from compilation -- Spatialys - Geospatial professional services http://www.spatialys.com

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

I've found nothing that depends on TDLPACK On Mon, Dec 4, 2017 at 12:32 PM, Kurt Schwehr wrote: > I'm pretty much up to head in production and testing is doing fine. > But... It's only been a couple hours. If there is nothing from me in the > next day or two, I give it a +1.

Re: [gdal-dev] GRIB driver updates / call for testing / TDLPACK

I'm pretty much up to head in production and testing is doing fine. But... It's only been a couple hours. If there is nothing from me in the next day or two, I give it a +1. Thanks for the hard work! My first pass check with TDLPACK is that I know of nobody who uses it. On Mon, Dec 4, 2017 at

[gdal-dev] GRIB driver updates / call for testing / TDLPACK

Hi, I wanted to inform you that the GRIB driver has received significant updates lately in trunk : * the underlying degrib and g2clib libraries used to do the GRIB1 & GRIB2 parsing have been updated to their latest upstream versions (*). Given that they are patched in GDAL for various

[gdal-dev] GRIB driver crashes with large numbers of bands

Hi, I have some GRIB datasets downloaded from ECMWF http://data-portal.ecmwf.int/data/d/interim_daily/. The files contain many bands (19728). When I try gdalinfo on these datasets, it waits for a long time. The python bindings segfault. The driver does fine with a smaller dataset (around a

Re: [gdal-dev] GRIB driver crashes with large numbers of bands

Jose Gómez-Dans wrote: Hi, I have some GRIB datasets downloaded from ECMWF http://data-portal.ecmwf.int/data/d/interim_daily/. The files contain many bands (19728). When I try gdalinfo on these datasets, it waits for a long time. The python bindings segfault. The driver does fine with a