Hi!
I have a GeoPDF with lots of layers where the layer names needs to be changed.
Is it possible to do a simple rename of the individual layers in a GeoPDF using
OGR without messing with the rest of the GeoPDF?
Regards, Casper
___
gdal-dev mailing li
Thanks! Adding -DNETCDF_HAS_NC4 makes the warning go away.
Now I wonder what that means to users of this code that have been living
without that for forever.
I will try gdal_translate with and without that flag and see what happens.
It looks like I should see differences with unsigned types.
On
On mercredi 7 août 2019 14:24:32 CEST Kurt Schwehr wrote:
> Hmm... these are netcdf 5 according to file.
HDF5, not netCDF 5. netCDF v4 file format is a profile on top of HDF5.
> I have the extra fun that my build is bazel based.
Ah that likely explains it... You need to add -DNETCDF_HAS_NC4 to
Hmm... these are netcdf 5 according to file. Does that not imply that that
I don't need to worry about NC4?
file *.nc
OR_ABI-L2-FDCF-M6_G17_s20192011300341_e20192011309408_c20192011309501.nc:
Hierarchical Data Format (version 5) data
OR_ABI-L2-FDCF-M6_G17_s20192011310341_e20192011319407_c20192011
On mercredi 7 août 2019 20:58:54 CEST Joe Lee wrote:
> Hi, Even!
>
> Is there a configure flag for enabling it by default without relying on
> LD_PRELOAD=...? (e.g., --with-vsipreload)
No,
- this needs to be loaded with LD_PRELOAD because it overrides very common
symbols of the libc (fopen, et
On mercredi 7 août 2019 20:36:48 CEST Joe Lee wrote:
> Hi, Even!
>
> I tested it and your new code works very well.
> Thank you for adding this new feature so quickly!
>
> Now I wish /vsis3 work on HDF4 like HDF5.
> That would be perfect because I tried /vsicurl as you suggested in [1] bu
Even, Kurt,
I've been thru the same issue last week. I might be wrong but the only way that
I found to add support for NC4 into the netcdf-c-4.6.3 build was by enabling
HDF4 .
You might try run "./configure --help | grep 4" on the netCDF SDK to see if
there is another way.
I rebuild everythin
Kurt,
I would say that your netCDF build lacks libhdf5 support needed to open netCDF
4 files, and/or that your GDAL build has been done against a netCDF version
that lacked it (if you added support of HDF5 in the netCDF build, after doing
an initial build of GDAL, you also need to rebuild GDAL)
Hi, Even!
I tested it and your new code works very well.
Thank you for adding this new feature so quickly!
Now I wish /vsis3 work on HDF4 like HDF5.
That would be perfect because I tried /vsicurl as you suggested in [1] but it
did not work.
[1]
http://osgeo-org.1560.x6.nabble.com/gdal
For a custom build of gdal, I'm seeing:
Warning 1: NetCDF driver detected file type=5, but libnetcdf detected
type=3
Any idea what is causing this? With gdal 2.3.2, from debian testing, I
don't see the message.
This warning message was added here:
https://github.com/OSGeo/gdal/commit/813aa22
Oh I see, thanks for explaining!
Cheers, Mike
On Wed., 7 Aug. 2019, 18:19 Even Rouault,
wrote:
>
> Michael,
>
> >
> > In this MVT source poLayer->GetFeatureCount() reports that there are 85
> > features, as does ogrinfo summary:
> >
> > But, iterating features finds 81 valid features, as report
Michael,
>
> In this MVT source poLayer->GetFeatureCount() reports that there are 85
> features, as does ogrinfo summary:
>
> But, iterating features finds 81 valid features, as reported by
The difference is due to clipping geometries to the tile extent.
GetFeatureCount() do a super fast scan,
12 matches
Mail list logo
