Thanks a lot to both of you! The GDAL_NETCDF_IGNORE_XY_AXIS_NAME_CHECKS
option did the trick!
Didn't know about the --debug on flag, it will come in handy in the future
Regarding the last part:
What is at least missing in that particular file is the
> Easting:standard_name =
Hi,
There are implicit rules when you read the OGR/GDAL docs in fact, in
particular when you use `ogr2ogr` or `ogrinfo`
`-oo =` like "Open Options"
`-lco =` for "Layer Creation Option"
`-dsco =` for "DataSet Creation Option"
So, when you read for instance
Yes, some versions ago the netCDF driver became much more stricter,
expecting a strict respect of the netCDF CF conventions for axis names &
attributes, to avoid false identification of non-georeferenced axis,
which could cause issues.
The below debug message gives a hint to use the
On Tue, 26 Mar 2024, Cristhian Rivera via gdal-dev wrote:
Hi all,
I'm trying to debug an issue with a NetCDF file where in previous gdal
versions (up until 3.3.0) the geolocation was correctly identified by
gdalinfo, but in newer versions (>= 3.3.1) it is not.
I note that both versions
Hi all,
I'm trying to debug an issue with a NetCDF file where in previous gdal
versions (up until 3.3.0) the geolocation was correctly identified by
gdalinfo, but in newer versions (>= 3.3.1) it is not.
In the attachments are the outputs of gdalinfo from the versions mentioned,
but the
Hi,
It is very difficult to create manually the table & field structure that
will be generated by the GMLAS driver. It is likely that the attribute
name generated by the GMLAs driver is not the one you expect. First try
ogr2ogr to a not-yet-existing PotsgreSQL table to see if data is
Hello,
i am importing an xml with ogr2ogr using GMLAS driver to a PostgreSQL server. I
am also using an .xsd file to correctly import and manage the imported xml in
the server. This way i was able to import every element into the correct column
based on the xsd, except one, a type="xsd:time"
