Re: [gdal-dev] Extracting data from a parquet file

[Joaquim Manuel Freire Luís via gdal-dev]

Ah, easy 

From: Even Rouault 
Sent: Monday, July 22, 2024 8:30 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Extracting data from a parquet file



Le 22/07/2024 à 21:10, Joaquim Manuel Freire Luís a écrit :
Even,

Thanks for the explanation. But how did you find the name of the geometries 
(geo_point_2D and geo_shape)? Loading the 
“world-administrative-boundaries.parquet” in a binary editor I can see them 
there, but that’s certainly not the way to find these things.
$ ogrinfo world-administrative-boundaries.parquet -al -so | grep "Geometry 
Column"
Geometry Column 1 = geo_point_2d
Geometry Column 2 = geo_shape



Joaquim

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Monday, July 22, 2024 2:29 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Extracting data from a parquet file


Joaquim,

The GeoPackage format only supports one geometry field per layer. and the QGIS 
OGR provider doesn't know currently how to handle several geometry fields per 
layer too

To do what you want, you need to explictly select the desired geometry field 
name with:

ogr2ogr out.gpkg world-administrative-boundaries.parquet -sql "select 
geo_shape, * from \"world-administrative-boundaries\""

Actually if you outputted to a format that supports several geometry fields per 
layer (let's say PostGIS), the above wouldn't work. You would need to exclude 
the geometry fields from the wildcard * selection with:

ogr2ogr out.gpkg  world-administrative-boundaries.parquet -sql "select 
geo_shape, * exclude (geo_point_2D, geo_shape) from 
\"world-administrative-boundaries\""

Even
Le 19/07/2024 à 16:58, Joaquim Manuel Freire Luís via gdal-dev a écrit :
Hi,

I finally managed to build a working GDAL with the arrow/parquet driver and I’m 
now trying to convert this file
(https://public.opendatasoft.com/api/explore/v2.1/catalog/datasets/world-administrative-boundaries/exports/parquet?lang=en=Europe%2FLondon)
but can only extract the “Point”, not the “Multi polygon”

ogrinfo world-administrative-boundaries.parquet
INFO: Open of `world-administrative-boundaries.parquet'
  using driver `Parquet' successful.
1: world-administrative-boundaries (Point, Multi Polygon)

This gets only the points

ogr2ogr lixo.gpkg world-administrative-boundaries.parquet

The same happens if I open the file in QGis. Points only, no polygons.

But if I do an ogrinfo -al, it prints all data in file.

ogrinfo -al world-administrative-boundaries.parquet

….

OGRFeature(world-administrative-boundaries):255
  iso3 (String) = GIB
  status (String) = UK Non-Self-Governing Territory
  color_code (String) = GBR
  name (String) = Gibraltar
…

So, how can we select in ogr2ogr to extract the polygons?




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Extracting data from a parquet file

[Joaquim Manuel Freire Luís via gdal-dev]

Even,

Thanks for the explanation. But how did you find the name of the geometries 
(geo_point_2D and geo_shape)? Loading the 
“world-administrative-boundaries.parquet” in a binary editor I can see them 
there, but that’s certainly not the way to find these things.

Joaquim

From: Even Rouault 
Sent: Monday, July 22, 2024 2:29 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Extracting data from a parquet file


Joaquim,

The GeoPackage format only supports one geometry field per layer. and the QGIS 
OGR provider doesn't know currently how to handle several geometry fields per 
layer too

To do what you want, you need to explictly select the desired geometry field 
name with:

ogr2ogr out.gpkg world-administrative-boundaries.parquet -sql "select 
geo_shape, * from \"world-administrative-boundaries\""

Actually if you outputted to a format that supports several geometry fields per 
layer (let's say PostGIS), the above wouldn't work. You would need to exclude 
the geometry fields from the wildcard * selection with:

ogr2ogr out.gpkg  world-administrative-boundaries.parquet -sql "select 
geo_shape, * exclude (geo_point_2D, geo_shape) from 
\"world-administrative-boundaries\""

Even
Le 19/07/2024 à 16:58, Joaquim Manuel Freire Luís via gdal-dev a écrit :
Hi,

I finally managed to build a working GDAL with the arrow/parquet driver and I’m 
now trying to convert this file
(https://public.opendatasoft.com/api/explore/v2.1/catalog/datasets/world-administrative-boundaries/exports/parquet?lang=en=Europe%2FLondon)
but can only extract the “Point”, not the “Multi polygon”

ogrinfo world-administrative-boundaries.parquet
INFO: Open of `world-administrative-boundaries.parquet'
  using driver `Parquet' successful.
1: world-administrative-boundaries (Point, Multi Polygon)

This gets only the points

ogr2ogr lixo.gpkg world-administrative-boundaries.parquet

The same happens if I open the file in QGis. Points only, no polygons.

But if I do an ogrinfo -al, it prints all data in file.

ogrinfo -al world-administrative-boundaries.parquet

….

OGRFeature(world-administrative-boundaries):255
  iso3 (String) = GIB
  status (String) = UK Non-Self-Governing Territory
  color_code (String) = GBR
  name (String) = Gibraltar
…

So, how can we select in ogr2ogr to extract the polygons?



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Extracting data from a parquet file

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

I finally managed to build a working GDAL with the arrow/parquet driver and I'm 
now trying to convert this file
(https://public.opendatasoft.com/api/explore/v2.1/catalog/datasets/world-administrative-boundaries/exports/parquet?lang=en=Europe%2FLondon)
but can only extract the "Point", not the "Multi polygon"

ogrinfo world-administrative-boundaries.parquet
INFO: Open of `world-administrative-boundaries.parquet'
  using driver `Parquet' successful.
1: world-administrative-boundaries (Point, Multi Polygon)

This gets only the points

ogr2ogr lixo.gpkg world-administrative-boundaries.parquet

The same happens if I open the file in QGis. Points only, no polygons.

But if I do an ogrinfo -al, it prints all data in file.

ogrinfo -al world-administrative-boundaries.parquet



OGRFeature(world-administrative-boundaries):255
  iso3 (String) = GIB
  status (String) = UK Non-Self-Governing Territory
  color_code (String) = GBR
  name (String) = Gibraltar
...

So, how can we select in ogr2ogr to extract the polygons?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HDF5 and geolocation arrays

[Joaquim Manuel Freire Luís via gdal-dev]

> This HDF5 (requires earthdata credentials your "Authorization: Bearer 
> " in GDAL_HTTP_HEADERS, or equiv) presents without geolocation arrays.

gdalinfo 
"/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5;
 -sd 26


Excuse for this little derail, but how do we do that? I mean, the credentials. 
I tried with both:

gdalinfo --config GDAL_HTTP_HEADERS=login:passw 
"/vsicurl/https://n5eil01u.ecs.nsidc.org/…

and

gdalinfo  "/vsicurl/https://login:pas...@n5eil01u.ecs.nsidc.org…

but both errored with

ERROR 3: Cannot read 4029 bytes
gdalinfo failed - unable to open 
'/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5'.

and

ERROR 3: Cannot read 4029 bytes
gdalinfo failed - unable to open 
'/vsicurl/https://login:pas...@n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5'.


Thanks

Joaquim

From: gdal-dev  On Behalf Of Michael Sumner 
via gdal-dev
Sent: Monday, April 29, 2024 8:11 PM
To: gdal-dev 
Subject: [gdal-dev] HDF5 and geolocation arrays

This HDF5 (requires earthdata credentials your "Authorization: Bearer " 
in GDAL_HTTP_HEADERS, or equiv) presents without geolocation arrays.

gdalinfo 
"/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5;
 -sd 26
Driver: HDF5Image/HDF5 Dataset
Files: 
/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5
Size is 608, 896
Metadata:
  Conventions=CF-1.6
  HDFEOS_INFORMATION_HDFEOSVersion=HDFEOS_5.1.15
  history=This version of the Sea Ice processing code contains updates provided 
by the science team on September 16, 2019. For details on these updates, see 
the release notes provided in the DAP.
  institution=NASA's AMSR Science Investigator-led Processing System (SIPS)
  references=Please cite these data as: Markus, T., J. C. Comiso, and W. N. 
Meier. 2018. AMSR-E/AMSR2 Unified L3 Daily 12.5 km Brightness Temperatures, Sea 
Ice Concentration, Motion & Snow Depth Polar Grids, Version 1. [Indicate subset 
used]. Boulder, Colorado USA. NASA National Snow and Ice Data Center 
Distributed Active Archive Center. doi: https://doi.org/10.5067/RA1MIJOYPK3P.
  source=satellite observation
  title=AMSR-E/AMSR2 Unified L3 Daily 12.5 km Brightness Temperatures, Sea Ice 
Concentration, Motion & Snow Depth Polar Grids
Corner Coordinates:
Upper Left  (0.0,0.0)
Lower Left  (0.0,  896.0)
Upper Right (  608.0,0.0)
Lower Right (  608.0,  896.0)
Center  (  304.0,  448.0)
Band 1 Block=608x1 Type=Int32, ColorInterp=Undefined
  Metadata:
comment=data value meaning: 0 -- Open Water, 110 -- missing/not calculated, 
120 -- Land
coordinates=lon lat
long_name=Sea ice concentration daily average
units=percent



gdalinfo --version
GDAL 3.9.0dev-cb4d30f56d, released 2024/04/15

The geolocation arrays are sds 33 and 32 respectively:

HDF5:"/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5"://HDFEOS/GRIDS/NpPolarGrid12km/lon

HDF5:"/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5"://HDFEOS/GRIDS/NpPolarGrid12km/lat

And things work when lining those up in VRT with warp. Can the HDF5 driver be 
made to auto-detect these geolocation arrays?

I see that the NETCDF driver actually does:

gdalinfo 
"NetCDF:/vsicurl/https://n5eil01u.ecs.nsidc.org/AMSA/AU_SI12.001/2012.07.02/AMSR_U2_L3_SeaIce12km_B04_20120702.he5;
 -sd 26

I'm asking as an email rather than pursuing the fix because, these data are 
actually a regular grid on the north and south poles, and so geolocation by 
arrays is sub-optimal  the specification is listed in

https://nsidc.org/sites/default/files/au_si12-v001-userguide_1.pdf

and the two parameter sets are

Np-north: -te -385,  -535, 375, 585 -t_srs EPSG:3411
Sp-south: -te -395,  -395, 395, 435 -t_srs EPSG:3412

Is this generally something we should pursue within GDAL? It seems like an 
endless task to detect-on-open exactly this situation and assign the easy fix, 
but this is a pretty fundamental data stream and it's very common so the 
longlat/arrays might be numerically detectable with other heuristics hinting 
that it's polar (??) and there are plenty of other sources that present 
equivalents in the right way e.g. this one:

"/vsicurl/https://noaadata.apps.nsidc.org/NOAA/G02135/north/daily/geotiff/2012/07_Jul/N_20120702_concentration_v3.0.tif;

The right approach is probably to inform the providers and get the right 
metadata baked in ... but there's pros and cons to either. I'm not sure there's 
even enough information in these files to clearly detect the situation, it 
would be a bit like the NSIDCbin driver with its very strict requirements.

Cheers, Mike


--

Michael Sumner
Software and Database Engineer
Australian Antarctic Division

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

This is not a direct answer but maybe you’d be interested in this Julia package 
that addresses for example the automatic histogram stretching needed to produce 
nice true color images. Its target is Landsat and Sentinel data but there is 
nothing(?) that prevents it to work with data from other proveniences. Lots of 
GDAL work under the hood.

https://www.generic-mapping-tools.org/RemoteS.jl/dev/gallery/L8cube_img/remotes_L8_cube_img/

From: gdal-dev  On Behalf Of Daniel Evans via 
gdal-dev
Sent: Monday, April 22, 2024 3:29 PM
To: Raley, Nathan 
Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Subject: Re: [gdal-dev] Question on building multi band composite and going 
back to RGB GeoTiff

Hi Nathan,

My initial suspicion might just be that the scaling the data provider did to go 
from the raw data to a human-eye-friendly RGB composite isn't the conversion 
you're assuming.

I know that with the data I regularly work with, it may be provided as Uint16, 
but the data range doesn't extend all the way to 65535.

If you compare the values in the separate R and G images to the RGB composite, 
do they appear to match the conversion you're assuming, or is there a different 
scaling (and possibly offset)?

Cheers,
Daniel

On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, 
mailto:gdal-dev@lists.osgeo.org>> wrote:
I currently have a RGB geotiff composite image that has a Byte datatype.  I 
also have individual band images for R, G, Redge, and NIR that are UInt16 
datatypes.  Since I’m missing the Blue band from the individual bands, I was 
attempting to extract the blue band from the RGB composite image, scale it up 
to the UInt16 datatype, and build a composite VRT with R, G, B, NIR, RE bands 
included in it.  I was then attempting to extract the RGB bands from the 
multispec VRT in order to see if the process was working as intended, but I’m 
getting an extremely blue image.

Can anyone shed some light as to what I may be doing wrong here?

I started by building a VRT for each band:
gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255 0 65535
gdalbuildvrt -b 1 r.vrt source_R.tif
gdalbuildvrt -b 1 g.vrt source_G.tif
gdalbuildvrt -b 1 nir.vrt source_NIR.tif
gdalbuildvrt -b 1 re.vrt source_RE.tif

I then merged the VRTs:
gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt

I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with a 
UInt16 datatype.

Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with something 
like:
gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255 -co 
PHOTOMETRIC=RGB multispec.vrt multispec.tif

Viewing the result in QGIS appears overly blue.  What am I doing wrong here?

Thanks,
Nathan


This email transmission, including any attachments, is intended solely for the 
addressee named above, and may contain confidential or privileged information. 
If you are not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this e-mail is prohibited. If you have 
received this e-mail in error, please notify the sender immediately by reply 
email and destroy the message and its attachments.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Failing to build gdal with arrow 15 on Win

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

I can build GDAL with an arrow dev version up until before version 15. Then 
building GDAL dev started to fail after the commit

SHA-1: 16439ecbb66ee6848a463037d355f42b5268b07a

* Arrow/Parquet: add (minimum) support for libarrow 15.0

Complaining that STRING_VIEW and other were not found. I than rebuilt arrow 
version 15 and all build went fine, but it now error as run time with.


[cid:image001.jpg@01DA601A.2B6AD9D0]



Thanks

Joaquim

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for 4.0 ideas

[Joaquim Manuel Freire Luís via gdal-dev]

Even, I understand that. Specially because not all nc files are created with 
GDAL 
But I have more troubles to understand why breaking code that use spatial_ref  
for decades without any real need. Sorry, and I know it's not decided yet, but 
it looks so much the Linux culture of *easy breaking*.

Joaquim

-Original Message-
From: Even Rouault  
Sent: Thursday, September 21, 2023 12:33 AM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Call for 4.0 ideas


Le 21/09/2023 à 01:12, Joaquim Manuel Freire Luís a écrit :
> Remove spatial_ref WKT export in netCDF driver (GDAL 4) #4712
>
> Would this mean all codes that use spatial_ref would be broken

yes, spatial_ref is AFAIK a GDAL specific thing that predates the introduction 
of crs_wkt in the CF conventions (cf 
https://github.com/cf-convention/cf-conventions/issues/222,
https://github.com/opendatacube/datacube-core/issues/837 where this is also 
discussed). Recent GDAL versions write both crs_wkt and spatial_ref as a 
transition step. This would complete the transition by removing writing 
spatial_ref (presumably we'd still accept it on the reading side for older 
datasets). Code that only checks for spatial_ref should be adapted to deal with 
crs_wkt, since it is the standardized attribute, independently on whether GDAL 
discontinues writing spatial_ref or not.

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for 4.0 ideas

[Joaquim Manuel Freire Luís via gdal-dev]

Remove spatial_ref WKT export in netCDF driver (GDAL 4) #4712

Would this mean all codes that use spatial_ref would be broken
Just hope that I'm misunderstanding it.

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Even Rouault
Sent: Wednesday, September 20, 2023 9:32 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Call for 4.0 ideas

Hi,

following latest discussions on RFC 95, I've drafted
https://github.com/OSGeo/gdal/issues/8440 with a few ideas. Please add yours 
into it. We should focus on listing breaking changes, rather than new features 
that can be developed without involving breakage.

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Failing to access a 8-bit SUBDATASET from GMT.

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

I am getting an error in GMT when trying to read the "qual_sst" subdataset of 
this nc file
https://fct-gmt.ualg.pt/gmt/data/cache/A2016152023000.L2_LAC_SST.nc

But it's only that subdataset that errors.

gdalinfo A2016152023000.L2_LAC_SST.nc
...
  SUBDATASET_1_NAME=NETCDF:"A2016152023000.L2_LAC_SST.nc":/geophysical_data/sst
  SUBDATASET_1_DESC=[2030x1354] sea_surface_temperature (16-bit integer)
  
SUBDATASET_2_NAME=NETCDF:"A2016152023000.L2_LAC_SST.nc":/geophysical_data/qual_sst
  SUBDATASET_2_DESC=[2030x1354] /geophysical_data/qual_sst (8-bit integer)
...

For example, this works (and works for all other subdasets except "qual_sst"):

gmt grd2xyz 
A2016152023000.L2_LAC_SST.nc=gd?NETCDF:"A2016152023000.L2_LAC_SST.nc":/geophysical_data/sst
 -ZTLf > lixo.b

but this fails with

ERROR 7: Assertion `false' failed in file 
`C:\progs_cygw\GMTdev\gmt5\master\src\gmt_gdalread.c', line 1402

The code in question starts in

https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalread.c#L1246

and debugging shows that GDALGetRasterDataType(hBand) is returning 14, which 
according to this page
https://gdal.org/api/raster_c_api.html#_CPPv412GDALDataType

indicates that the layer is interpreted to be GDT_CFloat64

I get the exact same error when loading that subdataset from my Julia wrapper, 
that inquires the gdal shared lib directly and does not use the code wrapped in 
GMT.

But GDAL itself does not have problems extracting the data. This works fine

gdal_translate NETCDF:"A2016152023000.L2_LAC_SST.nc":/geophysical_data/qual_sst 
qual_lixo.nc


Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Change name of compiled DLL

[Joaquim Manuel Freire Luís via gdal-dev]

Yes, there is. The docs explain that somewhere. Set the variable 
GDAL_LIB_OUTPUT_NAME

I have this in my ConfigUser.cmake file

set (GDAL_LIB_OUTPUT_NAME gdal_w${BITAGE} CACHE STRING "" FORCE)

From: gdal-dev  On Behalf Of Derek Newhall
Sent: Thursday, June 29, 2023 3:35 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Change name of compiled DLL

Não costuma receber e-mails de 
dnewh...@carlsonsw.com. Saiba por que motivo 
isto é importante
Hi,

When building GDAL 3.5.1 and earlier with Nmake, the created DLL was named 
gdal305.dll (or similar). Now with Cmake and 3.7.0 it's just gdal.dll. Is there 
a way to configure the DLL name?  We're concerned about version clashes with 
just using the name gdal.dll. I checked the build documentation, but couldn't 
find a setting for this. I also tried -DOUTPUT_NAME and -DLIBRARY_OUTPUT_NAME 
(per the CMake documentation) with no success.

Thanks,

Derek Newhall


Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Debugging in Visual Studio 2019?

[Joaquim Manuel Freire Luís via gdal-dev]

Second SS

From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís via gdal-dev
Sent: Thursday, June 29, 2023 3:15 PM
To: Abel Pau ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Debugging in Visual Studio 2019?


Debugging with VS is actually simple. You need:


  *   To build GDAL and your driver in debug mode
  *   Step 1, see Screenshot_1. Load one executable that has a code path into 
that of your driver (gdalinfo?)
  *   Step 2, see Screenshot_2. Right-click on Properties and give the full set 
of options to run the executable select in 2)
  *   Load the c/c++ codes and set breakpoints.
  *   Hit F5, etc... (here I'm assuming you know how to use the debugger)

NOTE. Screenshot_2 will be sent in a second message as the limit for the attach 
is so low that makes is very difficult to attach images-

Good luck

Joaquim


From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Abel Pau
Sent: Thursday, June 29, 2023 2:15 PM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: [gdal-dev] Debugging in Visual Studio 2019?

Não costuma receber e-mails de a@creaf.uab.cat<mailto:a@creaf.uab.cat>. 
Saiba por que motivo isto é 
importante<https://aka.ms/LearnAboutSenderIdentification>
Hi everyone,
I am a little stuck in something. Let's see if someone can help me.

I'm immersed in the creation of a new driver.
First step OK: download GDAL from GitHub, install some dependences, and use 
Cmake to create GDAL for Visual Studio. Big one project.
Second step OK: Add a new driver in ogr (using another project as inspiration) 
in this big project (adding some lines in CmakeLists etc..)
Third step: fill all functions to really make this driver work.
I'm stuck here. I want to debug in Visual Studio to complete the Third step but 
I don't know how. There is any way to debug something (in Visual Studio project 
I created using CMake) like a simple transformation "ogr2ogr layer.shp 
MiraMon_layer.pol ". I'm interested in debug inside the code to see if all is 
as I expect and this kind of things developers do... If not, then I supose I 
have to use testing
After having the project created I don't know how to debug it.
[cid:image001.png@01D9AA9D.397E82C0]

Can anyone give me some clue? Thanks in advance!!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Debugging in Visual Studio 2019?

[Joaquim Manuel Freire Luís via gdal-dev]

Debugging with VS is actually simple. You need:


  *   To build GDAL and your driver in debug mode
  *   Step 1, see Screenshot_1. Load one executable that has a code path into 
that of your driver (gdalinfo?)
  *   Step 2, see Screenshot_2. Right-click on Properties and give the full set 
of options to run the executable select in 2)
  *   Load the c/c++ codes and set breakpoints.
  *   Hit F5, etc... (here I'm assuming you know how to use the debugger)

NOTE. Screenshot_2 will be sent in a second message as the limit for the attach 
is so low that makes is very difficult to attach images-

Good luck

Joaquim


From: gdal-dev  On Behalf Of Abel Pau
Sent: Thursday, June 29, 2023 2:15 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Debugging in Visual Studio 2019?

Não costuma receber e-mails de a@creaf.uab.cat. 
Saiba por que motivo isto é 
importante
Hi everyone,
I am a little stuck in something. Let's see if someone can help me.

I'm immersed in the creation of a new driver.
First step OK: download GDAL from GitHub, install some dependences, and use 
Cmake to create GDAL for Visual Studio. Big one project.
Second step OK: Add a new driver in ogr (using another project as inspiration) 
in this big project (adding some lines in CmakeLists etc..)
Third step: fill all functions to really make this driver work.
I'm stuck here. I want to debug in Visual Studio to complete the Third step but 
I don't know how. There is any way to debug something (in Visual Studio project 
I created using CMake) like a simple transformation "ogr2ogr layer.shp 
MiraMon_layer.pol ". I'm interested in debug inside the code to see if all is 
as I expect and this kind of things developers do... If not, then I supose I 
have to use testing
After having the project created I don't know how to debug it.
[cid:image001.png@01D9AA9C.7D0EC3C0]

Can anyone give me some clue? Thanks in advance!!
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can we do Delaunay with 3D points?

[Joaquim Manuel Freire Luís via gdal-dev]

Thanks Even

Your example actually also works for me too.

julia> g1 = fromWKT("MULTIPOINT Z(0 0 10,0 1 10,1 1 12,1 0 10)");

julia> d = delaunay(g1,0.0,false)
Geometry: GEOMETRYCOLLECTION (POLYGON ((0 1 10,0 0 10,1 0 10 ... 10)))

julia> toWKT(d)
"GEOMETRYCOLLECTION (POLYGON ((0 1 10,0 0 10,1 0 10,0 1 10)),POLYGON ((0 1 10,1 
0 10,1 1 12,0 1 10)))"

It’s when I try to extract the data into a table (a GMT type) that the problem 
arises.
My code, so up to me to fix it.

julia> gd2gmt(d)
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
BoundingBox: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2×3 GMTdataset{Float64, 2}
Row │   col.1col.2col.3
 │ Float64  Float64  Float64
─┼───
   1 │ 0.0  0.0  0.0

From: gdal-dev  On Behalf Of Even Rouault
Sent: Sunday, June 25, 2023 7:05 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Can we do Delaunay with 3D points?

Joaquim,

Looked at the GDAL tests and there it also uses only 2D (a 3D test is 
commented).
I assume you're speaking about the PolyhedralSurface / TIN tests in 
ogr_geom.py.  The reason is that the code (and in particularly GEOS) is not 
ready for those geometry types.

I am doing something wrong or delaunay in GDAL is only possible with with 2D 
points?

Quick testing shows that it works with a multipoint z with a recent GEOS master 
version  (but might work with older ones perhaps)

>>> g = ogr.CreateGeometryFromWkt("MULTIPOINT Z (0 0 10,0 1 10,1 1 12,1 0 10)")

>>> triangulation = g.DelaunayTriangulation()

>>> triangulation.ExportToWkt()

'GEOMETRYCOLLECTION (POLYGON ((0 1 10,0 0 10,1 0 10,0 1 10)),POLYGON ((0 1 10,1 
0 10,1 1 12,0 1 10)))'

Even



--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Can we do Delaunay with 3D points?

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

This (GMT Julia wrapper) works fine:

julia> D1 = mat2ds([0 0;10 0;10 10;11 10], geom=wkbMultiPoint);

julia> delaunay(D1,0.0,false)
Vector{GMTdataset} with 2 segments
Show first segment. To see other segments just type its element number. E.g. 
D[7]

BoundingBox: [0.0, 10.0, 0.0, 10.0]
4×2 GMTdataset{Float64, 2}
Row │   col.1col.2
 │ Float64  Float64
─┼──
   1 │ 0.0  0.0
   2 │10.0  0.0
   3 │10.0 10.0
   4 │ 0.0  0.0

But when I try with 3D points

julia> D1 = mat2ds([0 0 0;10 0 1;10 10 2;11 10 3], geom=wkbMultiPoint);

julia> delaunay(D1,0.0,false)
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
ERROR 6: Incompatible geometry for operation
BoundingBox: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2×3 GMTdataset{Float64, 2}
Row │   col.1col.2col.3
 │ Float64  Float64  Float64
─┼───
   1 │ 0.0  0.0  0.0
   2 │ 0.0  0.0  0.0


I’ve tried with wkbMultiPointZ, wkbMultiPoint25D and same thing.
Looked at the GDAL tests and there it also uses only 2D (a 3D test is 
commented).
I am doing something wrong or delaunay in GDAL is only possible with with 2D 
points?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] +proj=wintri +over option works weel in gdalwarp but not in ogr2ogr

[Joaquim Manuel Freire Luís via gdal-dev]

Eve, thanks for looking to this but I think I’ve not been clear enough in my 
goals.
I don’t want to clip into the [0 360] interval. Quite on the contrary, I want 
to make maps that extend that limit but keep ofc the earth periodicity. My 
initial attempts worked quite well with the Van Der Grinten projection 
(https://forum.generic-mapping-tools.org/t/best-projection-for-rectangular-world-map/3715/82?u=joaquim).

For the Winkel Triple gdalwarp actually works quite well too

try this with the grid in the issue https://github.com/OSGeo/gdal/issues/7644

gdalwarp -t_srs "+proj=wintri +over" earth15.grd lixo.tiff

It’s the vector step that fails (but the cl540 has 384 segments, not just one).

Anyway, this is not an important matter. It would just be nice if I could to 
with “+proj=wintry +over” what I can with “+proj=vandg +over”

Note, I saw the warning at 
https://proj.org/usage/projections.html#longitude-wrapping

“Note however that for most projections where the 180 meridian does not project 
to a straight line, +over will have no effect or will not lead to expected 
results.”

The Van Der Grinten doesn’t fulfill that condition but things still work for 
it, so I don’t really know how to interpret that warning.

Joaquim

From: Even Rouault 
Sent: Sunday, April 30, 2023 2:43 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] +proj=wintri +over option works weel in gdalwarp but 
not in ogr2ogr


Joaquim,

I've looked at that. Experimentally, it doesn't seem that the current maths for 
wintri in +over mode give reasonable results for longitudes > 360deg in 
absolute value (and I'm not sure if there would be a natural extension 
possible. Far beyond my knowledge of the underlying maths).

gdalwarp does a little better by default because it couples the forward and 
inverse transformer to check the domain of validity and experimentally must 
find this limitation and will thus give up for source pixels whose longitude > 
360 deg. For ogr2ogr / vector this is more complicated as reprojection of a 
single geometry  (here cl540.gpkg is a single polygon with longitudes in 
[-540,540] range). is a "all points succeed to reproject => OK" / "one single 
point fails to reproject => KO" type of situation, at least in the logic 
followed by OGRGeometry::transform() logic.

So while the following patch to PROJ is probably technically correct, it 
wouldn't help in practice

diff --git a/src/projections/aitoff.cpp b/src/projections/aitoff.cpp
index 9d060999f..cce319157 100644
--- a/src/projections/aitoff.cpp
+++ b/src/projections/aitoff.cpp
@@ -59,6 +59,11 @@ static PJ_XY aitoff_s_forward(PJ_LP lp, PJ *P) { /* 
Spheroidal, forward */
 struct pj_opaque *Q = static_cast(P->opaque);
 double c, d;

+if( fabs(lp.lam) > 2 * M_PI ) {
+proj_errno_set(
+P, PROJ_ERR_COORD_TRANSFM_OUTSIDE_PROJECTION_DOMAIN);
+return xy;
+}
 c = 0.5 * lp.lam;
 d = acos(cos(lp.phi) * cos(c));
 if (d != 0.0) { /* basic Aitoff */

The only solution I can offer is that you must explictly clip your source 
geometry to the validity range of wintri with -clipsrc -360 -90 360 90.

Even


Le 30/04/2023 à 03:11, Joaquim Manuel Freire Luís via gdal-dev a écrit :
Even, this is a kind of continuation of the subject that I brought up in 
https://github.com/OSGeo/gdal/issues/7644

The file size limitation of attachments doesn’t help to make this case easily 
reproducible, but the story is, I can make that rectangular map using gdalwarp 
and ogr2ogr that use the +over option and +proj=vandg
(see 
https://forum.generic-mapping-tools.org/t/best-projection-for-rectangular-world-map/3715/82?u=joaquim)

But when I try the same with +proj=wintry the gdalwarp op works well but the 
ogr2ogr doesn’t.
(see 
https://forum.generic-mapping-tools.org/t/best-projection-for-rectangular-world-map/3715/85?u=joaquim)

You can more less reproduce this case using this file
http://fct-gmt.ualg.pt/tmp/cl540.gpkg

ogr2ogr  -t_srs "+proj=wintri +over" cl540_wintri.gpkg cl540.gpkg

Why would that be in this case?

Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] +proj=wintri +over option works weel in gdalwarp but not in ogr2ogr

[Joaquim Manuel Freire Luís via gdal-dev]

Even, this is a kind of continuation of the subject that I brought up in 
https://github.com/OSGeo/gdal/issues/7644

The file size limitation of attachments doesn't help to make this case easily 
reproducible, but the story is, I can make that rectangular map using gdalwarp 
and ogr2ogr that use the +over option and +proj=vandg
(see 
https://forum.generic-mapping-tools.org/t/best-projection-for-rectangular-world-map/3715/82?u=joaquim)

But when I try the same with +proj=wintry the gdalwarp op works well but the 
ogr2ogr doesn't.
(see 
https://forum.generic-mapping-tools.org/t/best-projection-for-rectangular-world-map/3715/85?u=joaquim)

You can more less reproduce this case using this file
http://fct-gmt.ualg.pt/tmp/cl540.gpkg

ogr2ogr  -t_srs "+proj=wintri +over" cl540_wintri.gpkg cl540.gpkg

Why would that be in this case?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Failure to read some geojson files

[Joaquim Manuel Freire Luís via gdal-dev]

Thanks Andrea,

I thought that could be the case and downloaded the file with a 
right-click-save-as and what I got seemed to be a valid json file and clearly 
not an html file. And that one doesn't work either. It does when I select to 
download as "raw".

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Andrea 
Giudiceandrea via gdal-dev
Sent: Friday, April 28, 2023 8:23 PM
To: gdal-dev@lists.osgeo.org
Cc: Andrea Giudiceandrea 
Subject: Re: [gdal-dev] Failure to read some geojson files

Il 28/04/2023 19:08, Joaquim Manuel Freire Luís via gdal-dev ha scritto:
> This is with OSGeo4W GDAL but I get the same with my own build. But I 
> can read some other geojson files. Why?
> 
> ogrinfo
> https://github.com/OSGeo/PROJ/blob/9.1/docs/plot/data/coastline.geojso
> n 
> <https://github.com/OSGeo/PROJ/blob/9.1/docs/plot/data/coastline.geojs
> on>
> 
> ERROR 4: Failed to read TopoJSON data

Hi Joaquim,
the URL
https://github.com/OSGeo/PROJ/blob/9.1/docs/plot/data/coastline.geojson
does not point to the actual coastline.geojson file. It points to a GitHub HTML 
page.

You need to use the URL
https://github.com/OSGeo/PROJ/raw/9.1/docs/plot/data/coastline.geojson
instead.

Best regards.

Andrea Giudiceandrea
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Failure to read some geojson files

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

In my quest to find a small coastlines file made of closed polygons (well, they 
all should be closed by definition but ...) I thought in using the file used to 
create the PROJ examples, but to my surprise GDAL can't read those geojson 
files.

This is with OSGeo4W GDAL but I get the same with my own build. But I can read 
some other geojson files. Why?


ogrinfo https://github.com/OSGeo/PROJ/blob/9.1/docs/plot/data/coastline.geojson
ERROR 4: Failed to read TopoJSON data
ERROR 4: Failed to read TopoJSON data
FAILURE:
Unable to open datasource 
`https://github.com/OSGeo/PROJ/blob/9.1/docs/plot/data/coastline.geojson' with 
the following drivers.
...

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Mysterious master build break on Win11

[Joaquim Manuel Freire Luís via gdal-dev]

Hi,

I'm hitting a weird building error on Win11.

The error is

[1322/1350] Linking CXX shared library gdal_w64.dll
FAILED: gdal_w64.dll gdal_w64.lib
cmd.exe /C "cd . && C:\programs\CMake\bin\cmake.exe -E vs_link_dll 
--intdir=CMakeFiles\GDAL.dir 
--rc=C:\PROGRA~2\WI3CF2~1\10\bin\100220~1.0\x64\rc.exe 
--mt=C:\PROGRA~2\WI3CF2~1\10\bin\100220~1.0\x64\mt.exe --manifests  -- 
C:\PROGRA~1\MICROS~4\2022\COMMUN~1\VC\Tools\MSVC\1435~1.322\bin\Hostx64\x64\link.exe
 /nologo @CMakeFiles\GDAL.rsp  /out:gdal_w64.dll /implib:gdal_w64.lib 
/pdb:gdal_w64.pdb /dll /version:37.0 /machine:x64 /INCREMENTAL:NO  && cd ."
LINK: command 
"C:\PROGRA~1\MICROS~4\2022\COMMUN~1\VC\Tools\MSVC\1435~1.322\bin\Hostx64\x64\link.exe
 /nologo @CMakeFiles\GDAL.rsp /out:gdal_w64.dll /implib:gdal_w64.lib 
/pdb:gdal_w64.pdb /dll /version:37.0 /machine:x64 /INCREMENTAL:NO /MANIFEST 
/MANIFESTFILE:gdal_w64.dll.manifest" failed (exit code 1181) with the following 
output:
LINK : fatal error LNK1181: cannot open input file 'm.lib'
ninja: build stopped: subcommand failed.

And indeed, there is one file 
"C:\programs\compa_libs\gdal_GIT\build\CMakeFiles\GDAL.rsp" that has this line

   C:\programs\PostgreSQL\15\lib\libpq.lib  
C:\programs\compa_libs\hdf5-1.12.2\compileds\VC14_64\lib\hdf5_cpp.lib  
psapi.lib  m.lib


Now, the weirdest part is that this happens in a new computer with Win11 but 
the GDAL repo dir was copied from another computer (that has Win10) and there 
this error does not show up. Both are built with same version of VS.

If I cheat it and add a valid lib called as m.lib then all runs apparently fine.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Generated CMake build files missing external references

[Joaquim Manuel Freire Luís via gdal-dev]

Hi, I also build GDAL like that and noticed that you have an error in 
XercesC_INCLUDE_DIR. This is what I have. Notice that it ends with “/include”

When you solve them please report if you were able to build with PDFIUM. I 
wasn’t, lots of C++ incomprehensible errors.

Joaquim


   set(XercesC_INCLUDE_DIR 
"C:/programs/compa_libs/xerces-c-3.1.1/compileds/VC14_64/include" CACHE STRING 
"" FORCE)
   set(XercesC_LIBRARY 
"C:/programs/compa_libs/xerces-c-3.1.1/compileds/VC14_64/lib/xerces-c_3.lib" 
CACHE STRING "" FORCE)

From: gdal-dev  On Behalf Of Derek Newhall
Sent: Thursday, March 16, 2023 7:51 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Generated CMake build files missing external references

Não costuma receber e-mails de 
dnewh...@carlsonsw.com. Saiba por que motivo 
isto é importante
Hello,

We are trying to migrate from GDAL 3.5.1 to 3.6.3. We currently build a custom 
gdal*.dll file using a modified nmake.opt file and are trying to duplicate it 
as a ConfigUser.cmake file. We are building GDAL with ECW 5.5, curl, sqlite3, 
pdfium, OpenSSL, and Expat.

With 3.6.3 I can get the build files to generate seemingly correctly with our 
ConfigUser.cmake file and 'cmake -G "Visual Studio 16 2019" .. -C 
..\ConfigUser.cmake' but the build fails once 'cmake --build .' is run.

The output of the configure step confirms everything's found, listing the 
following at the end:

"-- The following OPTIONAL package have been found:" ODBC, XercesC, OpenSSL, 
ECW, PDFIUM
"-- The following RECOMMENDED packages have been found:" CURL, EXPAT, SQLite3
"-- The following REQUIRED packages have been found:" PROJ

However, once the build happens, a few projects have compilation errors 
relating to external header files (specifically Xerces):

D:\gdal-3.6.3\ogr\ogr_xerces_headers.h(37,10): fatal error C1083: Cannot open 
include file: 'xercesc/framework/MemoryManager.hpp': No such file or directory 
[D:\gdal-3.6.3\build\gcore\gcore.vcxproj]

We are able to fix these references manually in Visual Studio by adding the 
external include directories to Xerces for the following projects: gcore, ogr, 
ogr_GMLAS, ogr_GML, ogr_NAS, ogr_ILI

That gets it to compile at least, but then we run into some similar linking 
issues.

We're new to building the 3.6.x branch, so I'm presuming we've misconfigured 
something somewhere, but I am not sure what it is in this case.

Thank you,

Derek Newhall


The following is the contents of our ConfigUser.cmake file:

set(GDAL_BUILD_ABS_PATH "D:/gdal-3.6.3")
set(GLOBAL_LIBRARIES_ABS_PATH "D:/global_libraries")
set (CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "" FORCE)
set(PROJ_INCLUDE_DIR "${GDAL_BUILD_ABS_PATH}/proj-6.3.1/src" CACHE STRING "" 
FORCE)
set(PROJ_LIBRARY_RELEASE 
"${GDAL_BUILD_ABS_PATH}/proj-6.3.1/build_VS2017_x64/lib/RelWithDebInfo/proj.lib"
 CACHE STRING "" FORCE)
set(ECW_ROOT "${GDAL_BUILD_ABS_PATH}/ERDAS ECW JPEG 2000 SDK 5.5.0/Desktop 
Read-Only")
set(ECW_INCLUDE_DIR "${ECW_ROOT}/include" CACHE STRING "" FORCE)
set(ECW_LIBRARY "${ECW_ROOT}/lib/vc141/x64/NCSEcwS.lib" CACHE STRING "" FORCE)
set(XERCES_DIR "${GLOBAL_LIBRARIES_ABS_PATH}/xerces-c-3.2.1/build/2017/" CACHE 
STRING "" FORCE)
set(XercesC_INCLUDE_DIR "${XERCES_DIR}/src/" CACHE STRING "" FORCE)
set(XercesC_LIBRARY "${XERCES_DIR}/src/Release/xerces-c_3.lib" CACHE STRING "" 
FORCE)
set(SQLite3_INCLUDE_DIR "${GDAL_BUILD_ABS_PATH}/sqlite-amalgamation-3370200" 
CACHE STRING "" FORCE)
set(SQLite3_LIBRARY 
"${GDAL_BUILD_ABS_PATH}/sqlite-amalgamation-3370200/sqlite3.lib" CACHE STRING 
"" FORCE)
set(CURL_DIR "${GDAL_BUILD_ABS_PATH}/libcurl" CACHE STRING "" FORCE)
set(CURL_INCLUDE_DIR "${CURL_DIR}/include" CACHE STRING "" FORCE)
set(CURL_LIBRARY_RELEASE "${CURL_DIR}/lib/libcurl.lib" CACHE STRING "" FORCE)
set(PDFIUM_INCLUDE_DIR 
"${GDAL_BUILD_ABS_PATH}/ExtractPDFium/install/include/pdfium" CACHE STRING "" 
FORCE)
set(PDFIUM_LIBRARY 
"${GDAL_BUILD_ABS_PATH}/ExtractPDFium/install/lib/pdfium.lib" CACHE STRING "" 
FORCE)
set(GDAL_ENABLE_DRIVER_PDF_PLUGIN ON)
set(OPENSSL_ROOT_DIR "${GLOBAL_LIBRARIES_ABS_PATH}/openssl-1.1.0f-vs2017" CACHE 
STRING "" FORCE)
set(OPENSSL_INCLUDE_DIR "${OPENSSL_ROOT_DIR}/include64" CACHE STRING "" FORCE)
set(OPENSSL_USE_STATIC_LIBS TRUE CACHE STRING "" FORCE)
set(OPENSSL_MSVC_STATIC_RT TRUE CACHE STRING "" FORCE)
set(EXPAT_DIR "${GDAL_BUILD_ABS_PATH}/Expat/" CACHE STRING "" FORCE)
set(EXPAT_INCLUDE_DIR "${GDAL_BUILD_ABS_PATH}/Expat/Source/lib" CACHE STRING "" 
FORCE)
set(EXPAT_LIBRARY "${GDAL_BUILD_ABS_PATH}/Expat/Bin/libexpatwMT.lib" CACHE 
STRING "" FORCE)


Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is 

Re: [gdal-dev] Convex hull with holes

[Joaquim Manuel Freire Luís via gdal-dev]

I do that type of things with GMT’s mask module (-D option)
https://docs.generic-mapping-tools.org/latest/mask.html

From: gdal-dev  On Behalf Of Paul Meems
Sent: Friday, March 3, 2023 2:47 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Convex hull with holes

Thanks Jukka for your reply.

I understand it is hard.
In my case, I have a lot of data points making your edge case not a problem for 
me.
The data points are collected driving over a field with 1 or more sensors.
The result can be something like this:
[cid:image001.png@01D94DE5.376CB160]
The red dots are the data points and I manually created the black border and 
added a small buffer.
The red dots are transformed into polygons using inverse distance and 
afterward, I need to 'blank' the data using the black border.
I can automate all steps except for creating this field border.

I'm also struggling to get a proper name for my needs, making it harder to 
Google for a solution.
'Convex hull' is not correct. What would be a more appropriate name?

Regards,

Paul

Op vr 3 mrt. 2023 om 14:13 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

So you have an uncategorized bunch of points and you wish to have an algorithm 
that recognizes outer and inner rings automatically? I fear that is not as easy 
as it may appear. Have a look at the annexed image with two polygons having the 
same vertices. How could an algorithm know which interpretation is correct? In 
this simple case you could make a convex hull, delete the vertices which were 
consumed for the outer ring, and create a new ring from the remaining points, 
but generally it will not work if there are two holes, for example.

If the points come from a GPX device, make the application to record indexes 
for both the points and the rings “ring1-point1, 
ring1-point2---ring2-point1,ring2-point2” and construct the polygon ring by 
ring.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Paul Meems
Lähetetty: perjantai 3. maaliskuuta 2023 14.52
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Convex hull with holes

How can I algorithmically create a parcel border that accounts for islands or 
holes within the parcel based on a list of coordinates?

While GDAL+GEOS has a Convex hull method, it only identifies the outer border.

Has GDAL+GEOS a method that I can use to detect inner holes as well, such as in 
a donut-shaped field?

The output can be json or shapefile, that doesn't matter.

Thanks,

Paul Meems
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Segmentation fault while compiling

[Joaquim Manuel Freire Luís]

Funny, I just got that same error (Windows). Apparently not fatal as I could do
ninja install
and all apparently went well

From: gdal-dev  On Behalf Of Even Rouault
Sent: Wednesday, February 15, 2023 11:44 PM
To: afernandez ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Segmentation fault while compiling


This is a new Python script that runs the Python bindings and use PROJ 
functionality. Aren't you running into the issue of having 2 PROJ versions 
described in https://github.com/OSGeo/gdal/pull/7250?

If you don't need to run GDAL tests, you can add -DBUILD_TESTING=OFF to your 
CMake invokation and that will avoid running this script. But the crash 
indicates something fishy that might hit you at execution of your GDAL build
Le 16/02/2023 à 00:20, afernandez a écrit :
Hello,
I'm trying to compile GDAL from source in order to include the KEA components. 
My attempt at compiling (configured simply with cmake .. 
-DCMAKE_INSTALL_PREFIX=/usr) failed towards the end with a segmentation fault 
error, which I cannot figure out
...
[ 98%] Built target testlog
[ 98%] Building CXX object 
autotest/cpp/CMakeFiles/test_osr_set_proj_search_paths.dir/test_osr_set_proj_search_paths.cpp.o
[ 98%] Building CXX object 
autotest/cpp/CMakeFiles/test_osr_set_proj_search_paths.dir/main_gtest.cpp.o
[ 98%] Linking CXX executable test_osr_set_proj_search_paths
[ 98%] Built target test_osr_set_proj_search_paths
[ 98%] Building CXX object 
autotest/cpp/CMakeFiles/proj_with_fork.dir/proj_with_fork.cpp.o
[ 98%] Building CXX object 
autotest/cpp/CMakeFiles/proj_with_fork.dir/main_gtest.cpp.o
[ 98%] Linking CXX executable proj_with_fork
[ 98%] Built target proj_with_fork
[ 98%] Building CXX object 
autotest/CMakeFiles/pytest_runner.dir/pytest_runner.cpp.o
[ 98%] Linking CXX executable pytest_runner
[ 98%] Built target pytest_runner
Segmentation fault
make[2]: *** [autotest/CMakeFiles/run_setup_proj_db_tmpdir.dir/build.make:70: 
autotest/CMakeFiles/run_setup_proj_db_tmpdir] Error 1
make[1]: *** [CMakeFiles/Makefile2:12792: 
autotest/CMakeFiles/run_setup_proj_db_tmpdir.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
Thanks.
P.S. OS is Ubuntu22.04 and architecture is aarch64; GDAL is cloned from Github




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] building gdal problems

[Joaquim Manuel Freire Luís]

> Could NOT find PROJ (missing: PROJ_INCLUDE_DIR) (Required is at least
   version "6.0")


Linking to PROJ lib is mandatory.

All other dependencies are optional (though many are strongly recommended).

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Bjørn Ruff
Sent: Friday, February 10, 2023 12:29 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] building gdal problems

[Não costuma receber e-mails de b...@forstware.de. Saiba por que motivo isto é 
importante em https://aka.ms/LearnAboutSenderIdentification. ]

Hello,

I have following problem building gdal with cmake under Windows (having newest 
version of all)

Can someone tell me what i am doing wrong?

C:\externLibs\gdal\build>cmake -G "Visual Studio 17 2022" ..
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19044.
-- GDAL_VERSION  = 3.7.0dev
-- GDAL_ABI_FULL_VERSION = 37
-- GDAL_SOVERSION=
-- Could NOT find ODBCCPP (missing: ODBCCPP_LIBRARY ODBCCPP_INCLUDE_DIR)
-- Could NOT find MSSQL_NCLI (missing: MSSQL_NCLI_LIBRARY
MSSQL_NCLI_INCLUDE_DIR) (found version "11")
-- Could NOT find MySQL (missing: MYSQL_LIBRARY MYSQL_INCLUDE_DIR)
-- Could NOT find Iconv (missing: Iconv_LIBRARY Iconv_CHARSET_LIBRARY)
-- Could NOT find LibXml2 (missing: LIBXML2_INCLUDE_DIR)
-- Could NOT find EXPAT (missing: EXPAT_DIR)
-- Could NOT find EXPAT (missing: EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
-- Failed to find XercesC (missing: XercesC_LIBRARY XercesC_INCLUDE_DIR
XercesC_VERSION)
-- Could NOT find Deflate (missing: Deflate_LIBRARY Deflate_INCLUDE_DIR)
-- Could NOT find CryptoPP (missing: CRYPTOPP_LIBRARY CRYPTOPP_TEST_KNOWNBUG 
CRYPTOPP_INCLUDE_DIR) CMake Error at C:/Program
Files/CMake/share/cmake-3.26/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
   Could NOT find PROJ (missing: PROJ_INCLUDE_DIR) (Required is at least
   version "6.0")
Call Stack (most recent call first):
   C:/Program
Files/CMake/share/cmake-3.26/Modules/FindPackageHandleStandardArgs.cmake:600
(_FPHSA_FAILURE_MESSAGE)
   cmake/modules/packages/FindPROJ.cmake:57
(find_package_handle_standard_args)
   cmake/helpers/CheckDependentLibraries.cmake:356 (find_package)
   gdal.cmake:265 (include)
   CMakeLists.txt:224 (include)

Thanks,
Björn Ruff
Forstware Informationssysteme
Von Lassbergstr. 35
D 88709 Meersburg
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] dfMaxAngleStepSizeDegrees in ApproximateArcAngles

[Joaquim Manuel Freire Luís]

Ah ghrr, I missed one argin in my wrapping (the dfRotation) and probably 
because the dfMaxAngleStepSizeDegrees  has a default value, an error was not 
triggered.
Now it works. Sorry for the noise.

From: Even Rouault 
Sent: Thursday, June 16, 2022 5:49 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] dfMaxAngleStepSizeDegrees in ApproximateArcAngles


I can't replicate that. Below the output with the Python bindings that directly 
map OGR_G_ApproximateArcAngles():

>>> from osgeo import ogr
>>> g = ogr.ApproximateArcAngles(0, 0, 0, 1, 1, 0, 0, -90, 0)
>>> g.FlattenTo2D()
>>> g.ExportToWkt()
'LINESTRING (1 0,0.997668769190539 0.068242413364671,0.990685946036331 
0.136166649096247,0.979084087682323 0.203456013052634,0.962917287347799 
0.269796771157024,0.942260922118821 0.334879612170986,0.917211301505453 
0.398401089846241,0.887885218402375 0.460065037731152,0.854419404546489 
0.519583950035434,0.816969893010442 0.576680322114867,0.77571129070442 
0.631087944326053,0.730835964278124 0.682553143218654,0.682553143218654 
0.730835964278124,0.631087944326053 0.77571129070442,0.576680322114867 
0.816969893010442,0.519583950035434 0.854419404546489,0.460065037731152 
0.887885218402375,0.398401089846242 0.917211301505453,0.334879612170986 
0.942260922118821,0.269796771157024 0.962917287347799,0.203456013052634 
0.979084087682323,0.136166649096247 0.990685946036331,0.068242413364671 
0.997668769190539,0.0 1.0)'

>>> g = ogr.ApproximateArcAngles(0, 0, 0, 1, 1, 0, 0, -90, 10)
>>> g.FlattenTo2D()
>>> g.ExportToWkt()
'LINESTRING (1 0,0.984807753012208 0.17364817766693,0.939692620785908 
0.342020143325669,0.866025403784439 0.5,0.76603118978 
0.642787609686539,0.642787609686539 0.76603118978,0.5 
0.866025403784439,0.342020143325669 0.939692620785908,0.17364817766693 
0.984807753012208,0.0 1.0)'
>>>

For the inc=0 case, note that there's a x/y inversion compared to your output.

The inc=10 case has 10 points in its output as expected

Even
Le 16/06/2022 à 18:27, Joaquim Manuel Freire Luís a écrit :
Even, I wrapped OGR_G_ApproximateArcAngles() in Julia and I think there is 
something wrong with the  dfMaxAngleStepSizeDegrees argument
(here shortcut to ‘inc’)

This is fine (just repeating the default 0.0 value). Note, I’m dropping the z 
(=0) argin but that’s only the julia wrapper interface.

D = GMT.Gdal.arcellipse(0, 0, 1., 1., 0., -90., inc=0.)
BoundingBox: [6.123233995736766e-17, 1.0, 0.0, 1.0]
24×2 GMTdataset{Float64, 2}
Row │ xy
 │ Float64  Float64
─┼
   1 │ 6.12323e-17  1.0
   2 │ 0.06824240.997669
   3 │ 0.136167 0.990686
   4 │ 0.203456 0.979084
   5 │ 0.269797 0.962917
  ⋮  │  ⋮   ⋮
  20 │ 0.962917 0.269797
  21 │ 0.979084 0.203456
  22 │ 0.990686 0.136167
  23 │ 0.997669 0.0682424
  24 │ 1.0  0.0

But if I use for example 10 (or any other number) the dfEndAngle is no longer 
respected

D = GMT.Gdal.arcellipse(0, 0., 1., 1., 0., -90., inc=10.)
BoundingBox: [6.123233995736766e-17, 0.9993908270190958, -0.17364817766693033, 
1.0]
26×2 GMTdataset{Float64, 2}
Row │ xy
 │ Float64  Float64
─┼─
   1 │ 6.12323e-17   1.0
   2 │ 0.0697565 0.997564
   3 │ 0.139173  0.990268
   4 │ 0.207912  0.978148
   5 │ 0.275637  0.961262
   6 │ 0.34202   0.939693
   7 │ 0.406737  0.913545
   8 │ 0.469472  0.882948
  ⋮  │  ⋮   ⋮
  19 │ 0.951057  0.309017
  20 │ 0.970296  0.241922
  21 │ 0.984808  0.173648
  22 │ 0.994522  0.104528
  23 │ 0.999391  0.0348995
  24 │ 0.999391 -0.0348995
  25 │ 0.994522 -0.104528
  26 │ 0.984808 -0.173648


Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] dfMaxAngleStepSizeDegrees in ApproximateArcAngles

[Joaquim Manuel Freire Luís]

Even, I wrapped OGR_G_ApproximateArcAngles() in Julia and I think there is 
something wrong with the  dfMaxAngleStepSizeDegrees argument
(here shortcut to ‘inc’)

This is fine (just repeating the default 0.0 value). Note, I’m dropping the z 
(=0) argin but that’s only the julia wrapper interface.

D = GMT.Gdal.arcellipse(0, 0, 1., 1., 0., -90., inc=0.)
BoundingBox: [6.123233995736766e-17, 1.0, 0.0, 1.0]
24×2 GMTdataset{Float64, 2}
Row │ xy
 │ Float64  Float64
─┼
   1 │ 6.12323e-17  1.0
   2 │ 0.06824240.997669
   3 │ 0.136167 0.990686
   4 │ 0.203456 0.979084
   5 │ 0.269797 0.962917
  ⋮  │  ⋮   ⋮
  20 │ 0.962917 0.269797
  21 │ 0.979084 0.203456
  22 │ 0.990686 0.136167
  23 │ 0.997669 0.0682424
  24 │ 1.0  0.0

But if I use for example 10 (or any other number) the dfEndAngle is no longer 
respected

D = GMT.Gdal.arcellipse(0, 0., 1., 1., 0., -90., inc=10.)
BoundingBox: [6.123233995736766e-17, 0.9993908270190958, -0.17364817766693033, 
1.0]
26×2 GMTdataset{Float64, 2}
Row │ xy
 │ Float64  Float64
─┼─
   1 │ 6.12323e-17   1.0
   2 │ 0.0697565 0.997564
   3 │ 0.139173  0.990268
   4 │ 0.207912  0.978148
   5 │ 0.275637  0.961262
   6 │ 0.34202   0.939693
   7 │ 0.406737  0.913545
   8 │ 0.469472  0.882948
  ⋮  │  ⋮   ⋮
  19 │ 0.951057  0.309017
  20 │ 0.970296  0.241922
  21 │ 0.984808  0.173648
  22 │ 0.994522  0.104528
  23 │ 0.999391  0.0348995
  24 │ 0.999391 -0.0348995
  25 │ 0.994522 -0.104528
  26 │ 0.984808 -0.173648


Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogrinfo , ogr2ogr file size limits

[Joaquim Manuel Freire Luís]

xtf is the extension by a format of sidescan sonar data.

This one was picked randomly from a google search
https://www.usna.edu/Users/oceano/pguth/md_help/html/sidescan.htm

From: gdal-dev  On Behalf Of Even Rouault
Sent: Tuesday, May 17, 2022 10:43 AM
To: Gonzalez Velasquez, Frando Alexis ; 
gdal-dev@lists.osgeo.org
Cc: Serrano Granados, Yency 
Subject: Re: [gdal-dev] Ogrinfo , ogr2ogr file size limits


Frando,

The .xtf extension doens't ring a bell to me. Which OGR driver recognizes such 
file ? (remove the -q option and look at the beginning of the report of 
ogrinfo), and what is your GDAL version ?

Most OGR drivers work in streaming mode and can handle arbitrary big files, but 
a few ones have no other choice than ingesting the whole file, in which case 
there's no workaround apart splitting the file with other tools or buy more RAM

Even
Le 17/05/2022 à 04:21, Gonzalez Velasquez, Frando Alexis a écrit :
Hi dev team!

I am writing to inquire about big files problem,

We are using the ogrinfo and ogr2ogr executables over small files with success 
(1 gb max)  but with 10 gb files we are experiencing memory problems and and it 
does not work, is there a file size limit? And if there is a size limit, is 
there any strategy to handle this problema and process big files with success ?

For example:

ogrinfo -q -so C:\\tmp\\file.xtf

When file is 1Gb success ; but when  the file is 10gb size the process fails.


Any advice would be appreciated, thanks.



[minsait-indra]

FRANDO GONZÁLEZ
Senior Systems Engineer
fagonzal...@indracompany.com

Calle 93 16 25
Bogotá, Colombia
T +57 1 646 36 00
M +57 3006604908

minsait.com
indracompany.com





Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda 
notificado que la lectura, utilización, divulgación y/o copia sin autorización 
está prohibida en virtud de la legislación vigente. En el caso de haber 
recibido este correo electrónico por error, se ruega notificar inmediatamente 
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its recipient(s). If 
you are not the indicated recipient, you are informed that reading, using, 
disseminating and/or copying it without authorisation is forbidden in 
accordance with the legislation in effect. If you have received this email by 
mistake, please immediately notify the sender of the situation by resending it 
to their email address.
Avoid printing this message if it is not absolutely necessary.



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] -if netCDF fails to read Matlab .mat files

[Joaquim Manuel Freire Luís]

I think the mail system refused the mat file in my previous mail. Let’s try 
with it zipped.


From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Monday, April 18, 2022 7:50 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] -if netCDF fails to read Matlab .mat files

Strange, I don’t see an HDF5 driver in my list of drivers but I do include it 
in the GDAL build.

$ gdalinfo --formats | grep HDF
  HDF4 -raster,multidimensional raster- (ros): Hierarchical Data Format Release 
4
  HDF4Image -raster- (rw+): HDF4 Dataset

Also

$ gdalinfo "NETCDF:"U.mat
ERROR 4: NETCDF:U.mat: No such file or directory
gdalinfo failed - unable to open 'NETCDF:U.mat'.

I’m sending attached the U.mat file

From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Monday, April 18, 2022 7:07 PM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] -if netCDF fails to read Matlab .mat files


Joaquim,

https://www.loc.gov/preservation/digital/formats/fdd/fdd000440.shtml mentions 
HDF5, but I don't know if it is HDF5-only or the HDF5 profile of netCDF 4.

From my tests trying to simulate the situation (I don't have a .mat file handy),

- if it is netCDF 3 file (non-HDF5), the netCDF driver should be able to open 
even with the .mat extension

- if it is netCDF 4 file,

- and the netCDF and HDF5 drivers are present, the HDF5 driver will kick 
in. The reason is that there's no easy way to recognize a HDF5 file from a 
netCDF 4 from their header, so the netCDF driver has a white list of extensions 
(which doesn't include .mat) when it sees the HDF5 driver is there, since it 
knows it is a potential fallback

- and only the netCDF driver is present, it will kick in

- and only the HDF5 driver is present, it will kick in

So basically I don't reproduce your issue.

You should be able to force the NetCDF driver by prefixing "NETCDF:" to the 
filename (the -if flag only restricts drivers which are probed. it doesn't 
force a driver to accept a file)

Even


Le 18/04/2022 à 18:31, Joaquim Manuel Freire Luís a écrit :
Hi,

Matlab creates files in what they call the “mat” format (with a .mat extension) 
but which in fact are files in netCDF/HDF

And indeed we can read them … but only if renamed to .nc

Why is this failing?

$ gdalinfo -if netCDF windaa.mat
ERROR 4: `windaa.mat' not recognized as a supported file format.
gdalinfo failed - unable to open 'windaa.mat'.

But this works

$ gdalinfo windaa.nc
Driver: netCDF/Network Common Data Format
Files: windaa.nc
Size is 512, 512
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"windaa.nc":u
  SUBDATASET_1_DESC=[15x41x35] u (64-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"windaa.nc":v
  SUBDATASET_2_DESC=[15x41x35] v (64-bit floating-point)
…



Joaquim


___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
<>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] -if netCDF fails to read Matlab .mat files

[Joaquim Manuel Freire Luís]

Strange, I don’t see an HDF5 driver in my list of drivers but I do include it 
in the GDAL build.

$ gdalinfo --formats | grep HDF
  HDF4 -raster,multidimensional raster- (ros): Hierarchical Data Format Release 
4
  HDF4Image -raster- (rw+): HDF4 Dataset

Also

$ gdalinfo "NETCDF:"U.mat
ERROR 4: NETCDF:U.mat: No such file or directory
gdalinfo failed - unable to open 'NETCDF:U.mat'.

I’m sending attached the U.mat file

From: Even Rouault 
Sent: Monday, April 18, 2022 7:07 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] -if netCDF fails to read Matlab .mat files


Joaquim,

https://www.loc.gov/preservation/digital/formats/fdd/fdd000440.shtml mentions 
HDF5, but I don't know if it is HDF5-only or the HDF5 profile of netCDF 4.

From my tests trying to simulate the situation (I don't have a .mat file handy),

- if it is netCDF 3 file (non-HDF5), the netCDF driver should be able to open 
even with the .mat extension

- if it is netCDF 4 file,

- and the netCDF and HDF5 drivers are present, the HDF5 driver will kick 
in. The reason is that there's no easy way to recognize a HDF5 file from a 
netCDF 4 from their header, so the netCDF driver has a white list of extensions 
(which doesn't include .mat) when it sees the HDF5 driver is there, since it 
knows it is a potential fallback

- and only the netCDF driver is present, it will kick in

- and only the HDF5 driver is present, it will kick in

So basically I don't reproduce your issue.

You should be able to force the NetCDF driver by prefixing "NETCDF:" to the 
filename (the -if flag only restricts drivers which are probed. it doesn't 
force a driver to accept a file)

Even


Le 18/04/2022 à 18:31, Joaquim Manuel Freire Luís a écrit :
Hi,

Matlab creates files in what they call the “mat” format (with a .mat extension) 
but which in fact are files in netCDF/HDF

And indeed we can read them … but only if renamed to .nc

Why is this failing?

$ gdalinfo -if netCDF windaa.mat
ERROR 4: `windaa.mat' not recognized as a supported file format.
gdalinfo failed - unable to open 'windaa.mat'.

But this works

$ gdalinfo windaa.nc
Driver: netCDF/Network Common Data Format
Files: windaa.nc
Size is 512, 512
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"windaa.nc":u
  SUBDATASET_1_DESC=[15x41x35] u (64-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"windaa.nc":v
  SUBDATASET_2_DESC=[15x41x35] v (64-bit floating-point)
…



Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.


U.mat
Description: U.mat
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] -if netCDF fails to read Matlab .mat files

[Joaquim Manuel Freire Luís]

Hi,

Matlab creates files in what they call the "mat" format (with a .mat extension) 
but which in fact are files in netCDF/HDF

And indeed we can read them ... but only if renamed to .nc

Why is this failing?

$ gdalinfo -if netCDF windaa.mat
ERROR 4: `windaa.mat' not recognized as a supported file format.
gdalinfo failed - unable to open 'windaa.mat'.

But this works

$ gdalinfo windaa.nc
Driver: netCDF/Network Common Data Format
Files: windaa.nc
Size is 512, 512
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"windaa.nc":u
  SUBDATASET_1_DESC=[15x41x35] u (64-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"windaa.nc":v
  SUBDATASET_2_DESC=[15x41x35] v (64-bit floating-point)
...



Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

[Joaquim Manuel Freire Luís]

Damn it. Can't tell a GTM from a GMT. Sorry. 

-Original Message-
From: Even Rouault  
Sent: Tuesday, March 22, 2022 8:08 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers


Le 22/03/2022 à 20:23, Joaquim Manuel Freire Luís a écrit :
> Even,
>
> Please the vector GMT driver is not to be removed
It is not. The commit you refer to removes the GTM (GPS Track Maker) driver.
>
> https://github.com/OSGeo/gdal/pull/5269/commits/f89bccc10e00ef57312165
> f5ee11f5ee1f1dddc3
>
> it's very much used in GMT. We talked about this before (sorry didn't keep 
> references of it).
> What is to be deprecated is the old netCDF GMT grid format, but not 
> the vector one
I'm in line with that.
> (whose implementation was paid for).
I assume most GDAL drivers, including those in that batch of removal, have been 
paid for at some point. That's not a criterion by itself to keep them 15 years 
after if no one is willing to keep up with their overhead and can justify they 
are still relevant.
>
> Cheers
>
> Joaquim
>
> -Original Message-
> From: gdal-dev  On Behalf Of Even 
> Rouault
> Sent: Tuesday, March 22, 2022 6:58 PM
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Motion (V2): remove and deprecate a few 
> drivers
>
> Hi,
>
> I'd appreciate if I could get some approval of
> https://github.com/OSGeo/gdal/pull/5269 (it'll need some trivial adjustment 
> to be applied due to conflicts) that implements the below decision (for some 
> reason people tend to be more generous in adding emojis to pull requests that 
> add new features than ones that remove code).
>
> The removal of the OpenDAP/DODS drivers is not included in that PR since 
> there was apparently some interest in it 
> https://github.com/OSGeo/gdal/issues/5173, but that failed to materialize 
> with concrete elements to be able to support them, so I believe they will 
> ultimately go to the rm -rf road too.
>
> Even
>
> Le 04/03/2021 à 17:32, Even Rouault a écrit :
>> Hi,
>>
>> Updating my yesterday motion with the feedback received (only second 
>> bullet updated with a more restricted set of drivers)
>>
>> Motion:
>>
>> - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, 
>> SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, 
>> IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and 
>> I'm not aware of them having been much used or being still in use.
>> Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver 
>> code, doc and tests) have been moved to the 
>> https://github.com/OSGeo/gdal-extra-drivers
>>
>> - deprecate the raster drivers DODS, JPEG2000 (superseded per 
>> JP2OpenJPEG), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector 
>> driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
>> GEOMEDIA, GTM, INGRES, MONGODB (superserded per MongoDBV3), REC, WALK 
>> . They will now be disabled at runtime by default, with an explicit 
>> error message when they are triggered, unless the 
>> GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
>> configuration option is set to YES, and will be removed in GDAL 3.5.
>> Implemented in https://github.com/OSGeo/gdal/pull/3505
>>
>> Starting with my +1
>>
>> Even
>>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

[Joaquim Manuel Freire Luís]

Even,

Please the vector GMT driver is not to be removed

https://github.com/OSGeo/gdal/pull/5269/commits/f89bccc10e00ef57312165f5ee11f5ee1f1dddc3

it's very much used in GMT. We talked about this before (sorry didn't keep 
references of it).
What is to be deprecated is the old netCDF GMT grid format, but not the vector 
one (whose implementation was paid for).

Cheers

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Even Rouault
Sent: Tuesday, March 22, 2022 6:58 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

Hi,

I'd appreciate if I could get some approval of
https://github.com/OSGeo/gdal/pull/5269 (it'll need some trivial adjustment to 
be applied due to conflicts) that implements the below decision (for some 
reason people tend to be more generous in adding emojis to pull requests that 
add new features than ones that remove code).

The removal of the OpenDAP/DODS drivers is not included in that PR since there 
was apparently some interest in it https://github.com/OSGeo/gdal/issues/5173, 
but that failed to materialize with concrete elements to be able to support 
them, so I believe they will ultimately go to the rm -rf road too.

Even

Le 04/03/2021 à 17:32, Even Rouault a écrit :
> Hi,
>
> Updating my yesterday motion with the feedback received (only second 
> bullet updated with a more restricted set of drivers)
>
> Motion:
>
> - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, 
> SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, 
> IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and 
> I'm not aware of them having been much used or being still in use.
> Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver 
> code, doc and tests) have been moved to the 
> https://github.com/OSGeo/gdal-extra-drivers
>
> - deprecate the raster drivers DODS, JPEG2000 (superseded per 
> JP2OpenJPEG), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector 
> driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
> GEOMEDIA, GTM, INGRES, MONGODB (superserded per MongoDBV3), REC, WALK 
> . They will now be disabled at runtime by default, with an explicit 
> error message when they are triggered, unless the 
> GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
> configuration option is set to YES, and will be removed in GDAL 3.5. 
> Implemented in https://github.com/OSGeo/gdal/pull/3505
>
> Starting with my +1
>
> Even
>
--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Good morning all and question: Good Python GDAL beginner tutorial?

[Joaquim Manuel Freire Luís]

And if you are open to non-Python alternatives and more upper level, I have 
this small Julia package tailored for satellite data.

https://github.com/GenericMappingTools/RemoteS.jl

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Stefan Gofferje
Sent: Monday, February 21, 2022 12:15 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Good morning all and question: Good Python GDAL 
beginner tutorial?

Hi,

On 2/21/22 12:51, Miguel A. Manso wrote:
> The cookbook v1 (https://pcjericks.github.io/py-gdalogr-cookbook/) may 
> be a good starting point.

THAT is very cool and almost exactly what I was looking for! Thanks a bunch!

> But previos to it you need to install a python developong enviroment. 
> You can trial with miniconda3 software and then creating a new 
> environment and installing GDAL libraries.

I'm on Linux since 1996, but thanks anyways :).

-S

-- 
  (o_   Stefan Gofferje| SCLT, MCP, CCSA
  //\   Reg'd Linux User #247167   | VCP #2263
  V_/_  https://www.gofferje.net   | https://www.saakeskus.fi

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

>Ah my if(MSVC) suggestion was because I wrongly assumed you used mingw (the 
>_w64.dll >suffix made me thing of mingw64), but I see the VC14 so you use MSVC.

The “_w64.dll” (and _w32.dll) suffixes are the reason why I rebuild everything. 
Is there any way to set them in current cmake solution? It was possible with 
nmake but for cmake I’m using this patch to the root CMakeList.txt, which at a 
later stage, if there is no existing alternative, I would like to propose it’s 
official inclusion.



# If a renaming of the dll has been set in ConfigUser.cmake

if (WIN32 AND GDAL_DLL_RENAME)

set_target_properties(GDAL PROPERTIES RUNTIME_OUTPUT_NAME ${GDAL_DLL_RENAME})

endif (WIN32 AND GDAL_DLL_RENAME)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Yes, I’m using MSVC (2022) and yeap, with that change it works fine.

From: Even Rouault 
Sent: Wednesday, January 26, 2022 7:34 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] cmake status update - 99% good news!



Le 26/01/2022 à 20:26, Joaquim Manuel Freire Luís a écrit :


Ok, sorry you meant the FindHDF4.cmake that comes with GDAL. Doing what you 
suggested (tried both) makes no difference but commenting

if(WIN32)
#list(APPEND HDF4_LIBRARIES ws2_32.lib)
endif()

makes the ws2_32 trouble go.

Ah my if(MSVC) suggestion was because I wrongly assumed you used mingw (the 
_w64.dll suffix made me thing of mingw64), but I see the VC14 so you use MSVC.

Can you try this then ?

if (WIN32)

   find_library(WS2_32_LIBRARY ws2_32)

   if( WS2_32_LIBRARY )

  list(APPEND HDF4_LIBRARIES ${WS2_32_LIBRARY})

   endif()

endif()






Le 26/01/2022 à 20:08, Joaquim Manuel Freire Luís a écrit :
Updated master (sorry, didn’t stop to think if the commit had been merged)

However, I have cmake 3.22.1 but it doesn’t have a FindHDF4.cmake, only a 
FinfHDF5
FindHDF4.cmake is in the GDAL repository, in 
cmake/modules/packages/FindHDF4.cmake, so you can try editing it locally with 
my below suggestions



I was building with

   set(HDF4_INCLUDE_DIR 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_34/include)
   set(HDF4_df_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/hdfdll.lib)
   set(HDF4_mfhdf_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/mfhdfdll.lib)

and when I commented those lines the build advance … till it stop at the 
“Cannot open include file: 'zlib.h'” but that is normal since I’m not using the 
commit who fixed it.

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, January 26, 2022 6:50 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] cmake status update - 99% good news!


did you update to master or did you try my pull request (not merged yet) ?

If only master, can you try to change the reference to "ws2_32.lib" to "ws2_32" 
in cmake/modules/packages/FindHDF4.cmake as I suggested ?

Or perhaps change the if (WIN32) at line 91 to if (MSVC)
Le 26/01/2022 à 19:43, Joaquim Manuel Freire Luís a écrit :
Don’t know which commit did it. Updated this afternoon and started to erroring 
right away with missing 'ws2_32.lib`

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, January 26, 2022 6:36 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] cmake status update - 99% good news!



Le 26/01/2022 à 19:31, Joaquim Manuel Freire Luís a écrit :

I do have HDF4 but before I was able to build till the end. I've here a 
gdal_w64.dll smiling to me. That's why I said it got worst.
Sorry you lost me. Is https://github.com/OSGeo/gdal/pull/5179 helping or not ?  
If not helping, which commit in it is causing an issue ?











Le 26/01/2022 à 17:26, Joaquim Manuel Freire Luís a écrit :

>

> Joaquim,

>> But I found two other new issues when adding more dependencies

>>

>> 1.

>> C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45):

>> fatal error C1083: Cannot open include file: 'zlib.h': No such file

>> or directory

>>

>> To work around this, I temporarily added zlib.h and zconf.h to

>> frmts\mbtiles

> Should be fixed by the first commit of

> https://github.com/OSGeo/gdal/pull/5179

>

> I'm afraid it got worst



-- Configuring done

-- Generating done

-- Build files have been written to: C:/programs/compa_libs/gdal_GIT/build

ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll', missing and no known rule 
to make it



I'd say on the contrary that it helped the build to go further, didn't it ? My 
fixes are totally unrelated to a ws2_32.lib missing



I see in configure.ac that we had the following logic



dnl

---

dnl Check if we need -lws2_32 (mingw)

dnl

---



echo "#include " > test_ws2_32.c echo "#include " >> 
test_ws2_32.c echo "void foo() {}" >> test_ws2_32.c



if test -z "`${CC} -c test_ws2_32.c 2>&1`" ; then

  LIBS="$LIBS -lws2_32"

fi

rm -f test_ws2_32*



dnl

---

dnl Check if we need -lpsapi (mingw)

dnl

---



echo "#include " > test_psapi.c echo "#include " >> 
test_psapi.c echo "void foo()

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Ok, sorry you meant the FindHDF4.cmake that comes with GDAL. Doing what you 
suggested (tried both) makes no difference but commenting

if(WIN32)
#list(APPEND HDF4_LIBRARIES ws2_32.lib)
endif()

makes the ws2_32 trouble go.


Le 26/01/2022 à 20:08, Joaquim Manuel Freire Luís a écrit :
Updated master (sorry, didn’t stop to think if the commit had been merged)

However, I have cmake 3.22.1 but it doesn’t have a FindHDF4.cmake, only a 
FinfHDF5
FindHDF4.cmake is in the GDAL repository, in 
cmake/modules/packages/FindHDF4.cmake, so you can try editing it locally with 
my below suggestions


I was building with

   set(HDF4_INCLUDE_DIR 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_34/include)
   set(HDF4_df_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/hdfdll.lib)
   set(HDF4_mfhdf_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/mfhdfdll.lib)

and when I commented those lines the build advance … till it stop at the 
“Cannot open include file: 'zlib.h'” but that is normal since I’m not using the 
commit who fixed it.

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, January 26, 2022 6:50 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] cmake status update - 99% good news!


did you update to master or did you try my pull request (not merged yet) ?

If only master, can you try to change the reference to "ws2_32.lib" to "ws2_32" 
in cmake/modules/packages/FindHDF4.cmake as I suggested ?

Or perhaps change the if (WIN32) at line 91 to if (MSVC)
Le 26/01/2022 à 19:43, Joaquim Manuel Freire Luís a écrit :
Don’t know which commit did it. Updated this afternoon and started to erroring 
right away with missing 'ws2_32.lib`

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, January 26, 2022 6:36 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] cmake status update - 99% good news!



Le 26/01/2022 à 19:31, Joaquim Manuel Freire Luís a écrit :

I do have HDF4 but before I was able to build till the end. I've here a 
gdal_w64.dll smiling to me. That's why I said it got worst.
Sorry you lost me. Is https://github.com/OSGeo/gdal/pull/5179 helping or not ?  
If not helping, which commit in it is causing an issue ?










Le 26/01/2022 à 17:26, Joaquim Manuel Freire Luís a écrit :

>

> Joaquim,

>> But I found two other new issues when adding more dependencies

>>

>> 1.

>> C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45):

>> fatal error C1083: Cannot open include file: 'zlib.h': No such file

>> or directory

>>

>> To work around this, I temporarily added zlib.h and zconf.h to

>> frmts\mbtiles

> Should be fixed by the first commit of

> https://github.com/OSGeo/gdal/pull/5179

>

> I'm afraid it got worst



-- Configuring done

-- Generating done

-- Build files have been written to: C:/programs/compa_libs/gdal_GIT/build

ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll', missing and no known rule 
to make it



I'd say on the contrary that it helped the build to go further, didn't it ? My 
fixes are totally unrelated to a ws2_32.lib missing



I see in configure.ac that we had the following logic



dnl

---

dnl Check if we need -lws2_32 (mingw)

dnl

---



echo "#include " > test_ws2_32.c echo "#include " >> 
test_ws2_32.c echo "void foo() {}" >> test_ws2_32.c



if test -z "`${CC} -c test_ws2_32.c 2>&1`" ; then

  LIBS="$LIBS -lws2_32"

fi

rm -f test_ws2_32*



dnl

---

dnl Check if we need -lpsapi (mingw)

dnl

---



echo "#include " > test_psapi.c echo "#include " >> 
test_psapi.c echo "void foo() {}" >> test_psapi.c



if test -z "`${CC} -c test_psapi.c 2>&1`" ; then

  LIBS="$LIBS -lpsapi"

fi

rm -f test_psapi*



This hasn't been ported yet to cmake builds.



I've ticketed that in https://github.com/OSGeo/gdal/issues/5180.



Hum, upon reflection, the error message would seem to indicate that we try to 
link to ws2_32.lib but it is not found in your environemnt



Looking for ws2_32 in cmake build scripts, I see it is referenced in



cmake/modules/packages/FindODBC.cmake: set(_odbc_required_libs_names

odbccp32;ws2_32)

cmake/modules/packages/FindHDF4.cmake:list(APPEND HDF4_LIBRARIES

ws2_32

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Updated master (sorry, didn’t stop to think if the commit had been merged)

However, I have cmake 3.22.1 but it doesn’t have a FindHDF4.cmake, only a 
FinfHDF5

I was building with

   set(HDF4_INCLUDE_DIR 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_34/include)
   set(HDF4_df_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/hdfdll.lib)
   set(HDF4_mfhdf_LIBRARY_RELEASE 
C:/programs/compa_libs/hdf-4.2.9/compileds/VC14_64/lib/mfhdfdll.lib)

and when I commented those lines the build advance … till it stop at the 
“Cannot open include file: 'zlib.h'” but that is normal since I’m not using the 
commit who fixed it.


From: Even Rouault 
Sent: Wednesday, January 26, 2022 6:50 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] cmake status update - 99% good news!


did you update to master or did you try my pull request (not merged yet) ?

If only master, can you try to change the reference to "ws2_32.lib" to "ws2_32" 
in cmake/modules/packages/FindHDF4.cmake as I suggested ?

Or perhaps change the if (WIN32) at line 91 to if (MSVC)
Le 26/01/2022 à 19:43, Joaquim Manuel Freire Luís a écrit :
Don’t know which commit did it. Updated this afternoon and started to erroring 
right away with missing 'ws2_32.lib`

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, January 26, 2022 6:36 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] cmake status update - 99% good news!



Le 26/01/2022 à 19:31, Joaquim Manuel Freire Luís a écrit :

I do have HDF4 but before I was able to build till the end. I've here a 
gdal_w64.dll smiling to me. That's why I said it got worst.
Sorry you lost me. Is https://github.com/OSGeo/gdal/pull/5179 helping or not ?  
If not helping, which commit in it is causing an issue ?









Le 26/01/2022 à 17:26, Joaquim Manuel Freire Luís a écrit :

>

> Joaquim,

>> But I found two other new issues when adding more dependencies

>>

>> 1.

>> C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45):

>> fatal error C1083: Cannot open include file: 'zlib.h': No such file

>> or directory

>>

>> To work around this, I temporarily added zlib.h and zconf.h to

>> frmts\mbtiles

> Should be fixed by the first commit of

> https://github.com/OSGeo/gdal/pull/5179

>

> I'm afraid it got worst



-- Configuring done

-- Generating done

-- Build files have been written to: C:/programs/compa_libs/gdal_GIT/build

ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll', missing and no known rule 
to make it



I'd say on the contrary that it helped the build to go further, didn't it ? My 
fixes are totally unrelated to a ws2_32.lib missing



I see in configure.ac that we had the following logic



dnl

---

dnl Check if we need -lws2_32 (mingw)

dnl

---



echo "#include " > test_ws2_32.c echo "#include " >> 
test_ws2_32.c echo "void foo() {}" >> test_ws2_32.c



if test -z "`${CC} -c test_ws2_32.c 2>&1`" ; then

  LIBS="$LIBS -lws2_32"

fi

rm -f test_ws2_32*



dnl

---

dnl Check if we need -lpsapi (mingw)

dnl

---



echo "#include " > test_psapi.c echo "#include " >> 
test_psapi.c echo "void foo() {}" >> test_psapi.c



if test -z "`${CC} -c test_psapi.c 2>&1`" ; then

  LIBS="$LIBS -lpsapi"

fi

rm -f test_psapi*



This hasn't been ported yet to cmake builds.



I've ticketed that in https://github.com/OSGeo/gdal/issues/5180.



Hum, upon reflection, the error message would seem to indicate that we try to 
link to ws2_32.lib but it is not found in your environemnt



Looking for ws2_32 in cmake build scripts, I see it is referenced in



cmake/modules/packages/FindODBC.cmake: set(_odbc_required_libs_names

odbccp32;ws2_32)

cmake/modules/packages/FindHDF4.cmake:list(APPEND HDF4_LIBRARIES

ws2_32.lib)



Do you use any of ODBC or HDF4 in your build ? Could you try to disable them 
and see if it makes a difference ?



Or maybe if you've HDF4, try to change the ws2_32.lib to ws2_32 in 
cmake/modules/packages/FindHDF4.cmake ?



Even



--

http://www.spatialys.com

My software is free, but my time generally not.



--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Don’t know which commit did it. Updated this afternoon and started to erroring 
right away with missing 'ws2_32.lib`

From: Even Rouault 
Sent: Wednesday, January 26, 2022 6:36 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] cmake status update - 99% good news!



Le 26/01/2022 à 19:31, Joaquim Manuel Freire Luís a écrit :

I do have HDF4 but before I was able to build till the end. I've here a 
gdal_w64.dll smiling to me. That's why I said it got worst.
Sorry you lost me. Is https://github.com/OSGeo/gdal/pull/5179 helping or not ?  
If not helping, which commit in it is causing an issue ?




[cid:image001.png@01D812E4.9E542DF0]



Le 26/01/2022 à 17:26, Joaquim Manuel Freire Luís a écrit :

>

> Joaquim,

>> But I found two other new issues when adding more dependencies

>>

>> 1.

>> C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45):

>> fatal error C1083: Cannot open include file: 'zlib.h': No such file

>> or directory

>>

>> To work around this, I temporarily added zlib.h and zconf.h to

>> frmts\mbtiles

> Should be fixed by the first commit of

> https://github.com/OSGeo/gdal/pull/5179

>

> I'm afraid it got worst



-- Configuring done

-- Generating done

-- Build files have been written to: C:/programs/compa_libs/gdal_GIT/build

ninja: error: 'ws2_32.lib', needed by 'gdal_w64.dll', missing and no known rule 
to make it



I'd say on the contrary that it helped the build to go further, didn't it ? My 
fixes are totally unrelated to a ws2_32.lib missing



I see in configure.ac that we had the following logic



dnl

---

dnl Check if we need -lws2_32 (mingw)

dnl

---



echo "#include " > test_ws2_32.c echo "#include " >> 
test_ws2_32.c echo "void foo() {}" >> test_ws2_32.c



if test -z "`${CC} -c test_ws2_32.c 2>&1`" ; then

  LIBS="$LIBS -lws2_32"

fi

rm -f test_ws2_32*



dnl

---

dnl Check if we need -lpsapi (mingw)

dnl

---



echo "#include " > test_psapi.c echo "#include " >> 
test_psapi.c echo "void foo() {}" >> test_psapi.c



if test -z "`${CC} -c test_psapi.c 2>&1`" ; then

  LIBS="$LIBS -lpsapi"

fi

rm -f test_psapi*



This hasn't been ported yet to cmake builds.



I've ticketed that in https://github.com/OSGeo/gdal/issues/5180.



Hum, upon reflection, the error message would seem to indicate that we try to 
link to ws2_32.lib but it is not found in your environemnt



Looking for ws2_32 in cmake build scripts, I see it is referenced in



cmake/modules/packages/FindODBC.cmake: set(_odbc_required_libs_names

odbccp32;ws2_32)

cmake/modules/packages/FindHDF4.cmake:list(APPEND HDF4_LIBRARIES

ws2_32.lib)



Do you use any of ODBC or HDF4 in your build ? Could you try to disable them 
and see if it makes a difference ?



Or maybe if you've HDF4, try to change the ws2_32.lib to ws2_32 in 
cmake/modules/packages/FindHDF4.cmake ?



Even



--

http://www.spatialys.com

My software is free, but my time generally not.



--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Some more news on this before I lose track of it.

Couldn't find a way to build against my HDF5 1.10.5 (everything I tried failed) 
so built HDF51.12.1 and now simple setting

set(HDF5_ROOT "C:/programs/compa_libs/hdf5-1.12.1/compileds/VC14_64")

finds it and no more troubles (yet found)

But I found two other new issues when adding more dependencies

1.
C:\programs\compa_libs\gdal_GIT\frmts\mbtiles\mbtilesdataset.cpp(45): fatal 
error C1083: Cannot open include file: 'zlib.h': No such file or directory

To work around this, I temporarily added zlib.h and zconf.h to frmts\mbtiles  

2.
C:\programs\compa_libs\libxml2-2.9.1\compileds\VC14_64\include\libxml/encoding.h(28):
 fatal error C1083: Cannot open include file: 'iconv.h': No such file or 
directory

Didn't try to find a fix to this one.

>
> HDF5 is a bit confusing. Here I use the same settings that I use to 
> build NetCDF, some settings are likely repeated but it works to build 
> netCDF
>
> set(HDF5_path C:/programs/compa_libs/hdf5-1.10.5)
> set(HDF5_ROOT_DIR ${HDF5_path}/compileds/VC14_64) 
> set(HDF5_INCLUDE_DIRS ${HDF5_path}/compileds/VC14_32/include)
> set(HDF5_LIBRARIES ${HDF5_path}/compileds/VC14_64/lib/hdf5.lib
> ${HDF5_path}/compileds/VC14_64/lib/hdf5_hl.lib  
> ${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl_cpp.lib   
> ${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_cpp.lib)
> set(HDF5_HL_LIBRARIES ${HDF5_path}/compileds/VC14_64/lib/hdf5.lib 
> ${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl.lib   
> ${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl_cpp.lib   
> ${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_cpp.lib)
>
> but the build complains with
>
> -- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) 
> (found version "1.10.5")

GDAL use the FindHDF5.cmake module provided by CMake itself : 
https://cmake.org/cmake/help/latest/module/FindHDF5.html / 
https://github.com/Kitware/CMake/blob/master/Modules/FindHDF5.cmake

I doubt you can directly specify HDF5_INCLUDE_DIRS, HDF5_LIBRARIES and 
HDF5_HL_LIBRARIES as they are output variables of the FindHDF5 module, not 
input variables

I'd say you should rather set HDF5_ROOT=${HDF5_path}/compileds/VC14_64

You may instrument the FindHDF5.cmake file to have more details

>
>>> For ECW, it looks like I tested on Windows with ECW 5.5
> I use SDK 3.3 and
>
> -- Could NOT find ECW (missing: ECWnet_LIBRARY ECWC_LIBRARY 
> NCSUtil_LIBRARY) (found version "NCS_VERSION_NUMBER 3.3.0.161")

If you have a standard layout ( ${prefix}/include and ${prefix}/lib ) then 
specifying ECW_ROOT=${prefix} should normally work out of the box.

Logic is at
https://github.com/OSGeo/gdal/blob/master/cmake/modules/packages/FindECW.cmake

>
>> For MrSID, not sure I tested on Windows. Works on Linux with
> DSDK-9.5.4.4709-rhel6
>
> I don't really know what to set in this one. I have 
> MrSID_DSDK-8.5.0.3422, that works in the nmake build
>
>   set(MRSID_INCLUDE_DIR 
> "C:/programs/compa_libs/MrSID_DSDK-8.5.0.3422/compileds/VC14_64/include")
>   set(MRSID_LIBRARY 
> "C:/programs/compa_libs/MrSID_DSDK-8.5.0.3422/compileds/VC14_64/lib/lt
> i_dsdk.lib")
Looks good. If you want to debug the logic, it is at 
https://github.com/OSGeo/gdal/blob/master/cmake/modules/packages/FindMRSID.cmake
> and get
>
> -- Could NOT find ECW (missing: ECWnet_LIBRARY ECWC_LIBRARY 
> NCSUtil_LIBRARY) (found version "NCS_VERSION_NUMBER 3.3.0.161")
That's not the right message

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

>> I made also an attempt on Windows and so far my findings are:

>> The docs say that the PROJ variables should be

>> PROJ_INCLUDE_DIR
>> PROJ_LIBRARY_RELEASE

>> But the lib var must in fact be

>> PROJ_LIBRARY

> How do you build exactly ?

> If you build with "cmake --build . --config Release" then I believe 
> PROJ_LIBRARY_RELEASE should be honored. Perhaps if you don't specify a 
> configuration (is it possible with MSVC CMake builds ? I don't have a VM 
> started right now), then PROJ_LIBRARY will be used.

I build with Ninja and by including a ConfigUser.make file (like GMT and NetCDF 
do) that is made of lines like

set(PROJ_INCLUDE_DIR 
"C:/programs/compa_libs/proj5_GIT/compileds/VC14_64/include")
set(PROJ_LIBRARY 
"C:/programs/compa_libs/proj5_GIT/compileds/VC14_64/lib/proj.lib")

I also built all the dependencies myself. I do this because I want to be able 
to control the dll file name (I'll get back to this in a future thread).

>> Couldn't yet find a way to build with HDF5, ECW and MRSID, which I can do 
>> with no problems with the current nmake solution.

> HDF5 1.12.1 is tested with Windows Conda builds


HDF5 is a bit confusing. Here I use the same settings that I use to build 
NetCDF, some settings are likely repeated but it works to build netCDF

set(HDF5_path C:/programs/compa_libs/hdf5-1.10.5)
set(HDF5_ROOT_DIR ${HDF5_path}/compileds/VC14_64)
set(HDF5_INCLUDE_DIRS ${HDF5_path}/compileds/VC14_32/include)
set(HDF5_LIBRARIES ${HDF5_path}/compileds/VC14_64/lib/hdf5.lib  
${HDF5_path}/compileds/VC14_64/lib/hdf5_hl.lib  
${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl_cpp.lib   
${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_cpp.lib)
set(HDF5_HL_LIBRARIES ${HDF5_path}/compileds/VC14_64/lib/hdf5.lib   
${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl.lib   
${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_hl_cpp.lib   
${HDF5_path}/compileds/VC14_${BITAGE}/lib/hdf5_cpp.lib)

but the build complains with

-- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) (found 
version "1.10.5")

>> For ECW, it looks like I tested on Windows with ECW 5.5

I use SDK 3.3 and

-- Could NOT find ECW (missing: ECWnet_LIBRARY ECWC_LIBRARY NCSUtil_LIBRARY) 
(found version "NCS_VERSION_NUMBER 3.3.0.161")

> For MrSID, not sure I tested on Windows. Works on Linux with
DSDK-9.5.4.4709-rhel6

I don't really know what to set in this one. I have MrSID_DSDK-8.5.0.3422, that 
works in the nmake build

set(MRSID_INCLUDE_DIR 
"C:/programs/compa_libs/MrSID_DSDK-8.5.0.3422/compileds/VC14_64/include")
set(MRSID_LIBRARY 
"C:/programs/compa_libs/MrSID_DSDK-8.5.0.3422/compileds/VC14_64/lib/lti_dsdk.lib")

and get

-- Could NOT find ECW (missing: ECWnet_LIBRARY ECWC_LIBRARY NCSUtil_LIBRARY) 
(found version "NCS_VERSION_NUMBER 3.3.0.161")
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] cmake status update - 99% good news!

[Joaquim Manuel Freire Luís]

Hi,

I made also an attempt on Windows and so far my findings are:

The docs say that the PROJ variables should be 

PROJ_INCLUDE_DIR
PROJ_LIBRARY_RELEASE

But the lib var must in fact be

PROJ_LIBRARY

Couldn't yet find a way to build with HDF5, ECW and MRSID, which I can do with 
no problems with the current nmake solution.
For the rest, I haven't test anything but it builds fine and a quick 
`Dependency` analysis shows no issues.

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Greg Troxel
Sent: Tuesday, January 25, 2022 12:05 AM
To: Even Rouault 
Cc: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] cmake status update - 99% good news!


I have started testing cmake support on gdal master.
My approach is

  1) Build gdal from git using cmake.

  2) Be able to create a release tarball (not actually a release of
  course) from master in order to use for building with pkgsrc.

  3) Build the release using autoconf, basically unchanged pkgsrc
  control files execpt for version, and run tests and check qgis
  functionality.

  4) Convert the package control files to use cmake instead of autoconf
  and test again.  This involves our "gdal-lib" and "py-gdal" packages.

In step 1, I have so far found one problem, an incorrect INCLUDE variable for 
poppler.  I have created a pull request with a simple fix:
  https://github.com/OSGeo/gdal/pull/5161

For step 2, as Even suggested would be the case, I ran into a number of small 
portability issues (some makefiles need GNU make, even though the cmake 
makefiles don't) and missing documentation (breathe and swig (4?) are required 
to run mkgdaldist.sh).  None of these are a big deal and the list is pretty 
small for what I think might be the first time the script has been used on a 
different operating system.  I have a branch in progress and will submit a PR 
when it settles down.  The changes are minor.

For step 3, I've been able to build the release, but haven't tested yet.

Greg
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Experiences with the WMS driver

[Joaquim Manuel Freire Luís]

Tanks again Momtchil. Your example works indeed ... but not with my layer

curl 
http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=3140_21200=CRS:84=image/png=FALSE=512==GetMap=2048=-50.2,69.11,-49.6,69.26==1.3.0
 --output raw.png

the output is an html file saying

The document has moved https://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMSLAYERS=3140_21200CRS=CRS:84FORMAT=image/pngTRANSPARENT=FALSEHEIGHT=512BGCOLOR=REQUEST=GetMapWIDTH=2048BBOX=-50.2,69.11,-49.6,69.26STYLES=VERSION=1.3.0>here.


Anyway, the curl solution is of little interest for me because I don't know how 
to programmatically select it instead of using gdal_translate.

From: Momtchil Momtchev 
Sent: Wednesday, January 5, 2022 12:18 AM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Experiences with the WMS driver




You can get the raw image with curl (it is just a static image):

$ curl 
"https://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=GetMap=1.3.0=3170_21483_bg==image/png=-180,-90,180,90=CRS:84=FALSE=922=461;<https://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=GetMap=1.3.0=3170_21483_bg==image/png=-180,-90,180,90=CRS:84=FALSE=922=461>
  --output raw.png

Then use gdal_translate to georeference it:

$ gdal_translate -a_srs CRS:84  -a_ullr -180 90 180 -90 raw.png out.png


On 03/01/2022 21:15, Joaquim Manuel Freire Luís wrote:
Thanks. That's right that modifying the host name prints the same size info but 
there is nothing in the url that permits to estimate the "Pixel Size".

Also, this not the main issue. The main one is when passing a valid "GetMap" 
string that works in a browser but errors in gdal_translate.


From: Momtchil Momtchev <mailto:momtc...@momtchev.com>
Sent: Monday, January 3, 2022 3:08 PM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>; Joaquim Manuel 
Freire Luís <mailto:jl...@ualg.pt>
Subject: Re: [gdal-dev] Experiences with the WMS driver




gdalinfo does not contact the remote server at all, it extracts all the 
information it displays from the URL.

Try replacing the hostname with something invalid, keeping all the 
parameters and you will still get the same output.




On 01/01/2022 19:47, Joaquim Manuel Freire Luís wrote:


But if I do

gdalinfo 
"WMS:http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=1.3.0=GetMap=3170_21483_bg=CRS:84=-180.0,-90.0,180.0,90.0=FALSE;

it seems to work but note the reported sizes and unreasonable resolution.

Data axis to CRS axis mapping: 1,2
Origin = (-180.000,90.000)
Pixel Size = (0.00335276127,-0.00335276127)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left  (-180.000, -90.000) (180d 0' 0.00"W, 90d 0' 0.00"S)
Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right ( 180.000, -90.000) (180d 0' 0.00"E, 90d 0' 0.00"S)
Center  (   0.000,   0.000) (  0d 0' 0.01"E,  0d 0' 0.01"N)
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
  Overviews: 536870912x268435456, 268435456x134217728, 134217728x67108864, 
67108864x33554432, 33554432x16777216, 16777216x8388608, 8388608x4194304, 
4194304x2097152, 2097152x1048576, 1048576x524288, 524288x262144, 262144x131072, 
131072x65536, 65536x32768, 32768x16384, 16384x8192, 8192x4096, 4096x2048, 
2048x1024, 1024x512



--

Momtchil Momtchev <mailto:momtc...@momtchev.com>

--

Momtchil Momtchev <mailto:momtc...@momtchev.com>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Experiences with the WMS driver

[Joaquim Manuel Freire Luís]

Thanks. That's right that modifying the host name prints the same size info but 
there is nothing in the url that permits to estimate the "Pixel Size".

Also, this not the main issue. The main one is when passing a valid "GetMap" 
string that works in a browser but errors in gdal_translate.


From: Momtchil Momtchev 
Sent: Monday, January 3, 2022 3:08 PM
To: gdal-dev@lists.osgeo.org; Joaquim Manuel Freire Luís 
Subject: Re: [gdal-dev] Experiences with the WMS driver




gdalinfo does not contact the remote server at all, it extracts all the 
information it displays from the URL.

Try replacing the hostname with something invalid, keeping all the 
parameters and you will still get the same output.




On 01/01/2022 19:47, Joaquim Manuel Freire Luís wrote:


But if I do

gdalinfo 
"WMS:http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=1.3.0=GetMap=3170_21483_bg=CRS:84=-180.0,-90.0,180.0,90.0=FALSE;

it seems to work but note the reported sizes and unreasonable resolution.

Data axis to CRS axis mapping: 1,2
Origin = (-180.000,90.000)
Pixel Size = (0.00335276127,-0.00335276127)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left  (-180.000, -90.000) (180d 0' 0.00"W, 90d 0' 0.00"S)
Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right ( 180.000, -90.000) (180d 0' 0.00"E, 90d 0' 0.00"S)
Center  (   0.000,   0.000) (  0d 0' 0.01"E,  0d 0' 0.01"N)
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
  Overviews: 536870912x268435456, 268435456x134217728, 134217728x67108864, 
67108864x33554432, 33554432x16777216, 16777216x8388608, 8388608x4194304, 
4194304x2097152, 2097152x1048576, 1048576x524288, 524288x262144, 262144x131072, 
131072x65536, 65536x32768, 32768x16384, 16384x8192, 8192x4096, 4096x2048, 
2048x1024, 1024x512



--

Momtchil Momtchev <mailto:momtc...@momtchev.com>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Experiences with the WMS driver

[Joaquim Manuel Freire Luís]

Hello and Happy New Year

I started playing (learning) with the WMS driver and wrote a couple of Julia 
functions to use it that work well ... some times.
If I use the "http://tiles.maps.eox.at/wms?; service I can get images from 
there but it already starts to feel strange the image resolution reported

But when I try one example used by the Matlab docs, 
http://svs.gsfc.nasa.gov/cgi-bin/wms? Then nothing works

First list the layers
gdalinfo http://svs.gsfc.nasa.gov/cgi-bin/wms?

Then try to download one

gdal_translate -of PNG 
"WMS:http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=1.3.0=GetMap=3170_21483_bg=CRS:84=-180.0,-90.0,180.0,90.0=FALSE;
 -outsize 2048 512 out.png
Input file size is 1073741824, 536870912
ERROR 1: GDALWMS: The server returned exception code 'InvalidSize': WIDTH is 
invalid for layer. Should be 922.

ERROR 1: GDALWMS: The server returned exception code 'InvalidSize': HEIGHT is 
invalid for layer.  Should be 461.

ERROR 1: GDALWMS: The server returned exception code 'InvalidFormat': FORMAT is 
invalid for layer.  Should be image/png.

ERROR 1: GDALWMS: The server returned exception code 'InvalidBBOX': BBOX is 
invalid for layer.  Should be [-180,-90,180,90]

ERROR 1: GDALWMS: The server returned exception code 'LayerNotDefined': Unable 
to find layer.

ERROR 1: IReadBlock failed at X offset 0, Y offset 0: GDALWMS: The server 
returned exception code 'LayerNotDefined': Unable to find layer.


But if I do

gdalinfo 
"WMS:http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=1.3.0=GetMap=3170_21483_bg=CRS:84=-180.0,-90.0,180.0,90.0=FALSE;

it seems to work but note the reported sizes and unreasonable resolution.

Data axis to CRS axis mapping: 1,2
Origin = (-180.000,90.000)
Pixel Size = (0.00335276127,-0.00335276127)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
Lower Left  (-180.000, -90.000) (180d 0' 0.00"W, 90d 0' 0.00"S)
Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
Lower Right ( 180.000, -90.000) (180d 0' 0.00"E, 90d 0' 0.00"S)
Center  (   0.000,   0.000) (  0d 0' 0.01"E,  0d 0' 0.01"N)
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
  Overviews: 536870912x268435456, 268435456x134217728, 134217728x67108864, 
67108864x33554432, 33554432x16777216, 16777216x8388608, 8388608x4194304, 
4194304x2097152, 2097152x1048576, 1048576x524288, 524288x262144, 262144x131072, 
131072x65536, 65536x32768, 32768x16384, 16384x8192, 8192x4096, 4096x2048, 
2048x1024, 1024x512


Debuggin in Matlab I could recover this request URL

http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=3140_21200=CRS:84=image/png=FALSE=512==GetMap=2048=-50.2,69.11,-49.6,69.26==1.3.0

that works if we past it into a browser, but

trying it with gdal_translate errors again,  and again those huge image sizes

gdal_translate -of PNG 
"WMS:http://svs.gsfc.nasa.gov/cgi-bin/wms?SERVICE=WMS=3140_21200=CRS:84=image/png=FALSE=512==GetMap=2048=-50.2,69.11,-49.6,69.26==1.3.0;
 out.png
Input file size is 1073741824, 268435456
ERROR 1: libpng: Read Error
ERROR 1: libpng: Read Error
Warning 1: libpng: Image width exceeds user limit in IHDR
Warning 1: libpng: Image height exceeds user limit in IHDR
ERROR 1: libpng: Invalid IHDR data


Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Get max elevation on "squares"

[Joaquim Manuel Freire Luís]

This is for the Lisbon Airport.
The first time it downloads the grid(s). Here something is probably failing 
because it shouldn't need to download all tiles that make up the global grid (8 
tiles and 30 Mb for this resolution)

echo -9.1409 38.7718 | grdtrack -G@earth_relief_03m
grdblend [NOTICE]: Remote data courtesy of GMT data server oceania 
[http://oceania.generic-mapping-tools.org]

grdblend [NOTICE]: Earth Relief at 3x3 arc minutes from Gaussian Cartesian 
filtering (5.6 km fullwidth) of SRTM15+V2.1 [Tozer et al., 2019].
grdblend [NOTICE]:   -> Download 90x90 degree grid tile (earth_relief_03m_p): 
S90W180

-9.1409 38.7718 87.2690486581

-Original Message-
From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Tuesday, December 28, 2021 6:00 PM
To: Luca Bertoncello ; gdal dev 
Subject: Re: [gdal-dev] Get max elevation on "squares"

With GMT that is a single command using the grdtrack module

https://docs.generic-mapping-tools.org/dev/grdtrack.html

-Original Message-
From: gdal-dev  On Behalf Of Luca Bertoncello
Sent: Tuesday, December 28, 2021 5:48 PM
To: gdal dev 
Subject: Re: [gdal-dev] Get max elevation on "squares"

Am 28.12.2021 um 16:45 schrieb Alan Snow:
> This resource is useful to help you get started exploring raster data 
> with Python:

Maybe there is other possibility than write a Python code? I really don't know 
Python and if I first need to learn it to extract the information I need, it 
will take a while...

I discovered this:

https://www.eea.europa.eu/data-and-maps/data/digital-elevation-model-of-europe/

The resolution is enough for my purpose and the file size is OK.
So as I understand in this file every pixel has a size of 3x3 km, is it correct?

So my problem is now to get the "pixel coordinate" from latitude and longitude 
and extract the elevation from the TIF.

Am I right, until here?

If yes: can someone suggest me a way to extract the data from this file?
Best solution is a PERL or BASH script, no matter if it runs for hours or days, 
since I do the export just once.

Thanks
Luca Bertoncello
(lucab...@lucabert.de)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Get max elevation on "squares"

[Joaquim Manuel Freire Luís]

With GMT that is a single command using the grdtrack module

https://docs.generic-mapping-tools.org/dev/grdtrack.html

-Original Message-
From: gdal-dev  On Behalf Of Luca Bertoncello
Sent: Tuesday, December 28, 2021 5:48 PM
To: gdal dev 
Subject: Re: [gdal-dev] Get max elevation on "squares"

Am 28.12.2021 um 16:45 schrieb Alan Snow:
> This resource is useful to help you get started exploring raster data 
> with Python:

Maybe there is other possibility than write a Python code? I really don't know 
Python and if I first need to learn it to extract the information I need, it 
will take a while...

I discovered this:

https://www.eea.europa.eu/data-and-maps/data/digital-elevation-model-of-europe/

The resolution is enough for my purpose and the file size is OK.
So as I understand in this file every pixel has a size of 3x3 km, is it correct?

So my problem is now to get the "pixel coordinate" from latitude and longitude 
and extract the elevation from the TIF.

Am I right, until here?

If yes: can someone suggest me a way to extract the data from this file?
Best solution is a PERL or BASH script, no matter if it runs for hours or days, 
since I do the export just once.

Thanks
Luca Bertoncello
(lucab...@lucabert.de)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Building Gdal with C++ Visual Studio 2019 - Error Linking.

[Joaquim Manuel Freire Luís]

My wild guess.

Somewhere you have a spaces-in-name shit and a code named (some variation of 
this) "lib thisprogram.cpp" got truncated and the linker is now searching for 
the lib.obj instead of "lib thisprogram.obj"

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Jeff McKenna
Sent: Friday, November 12, 2021 3:14 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Building Gdal with C++ Visual Studio 2019 - Error 
Linking.

Please also see the BuildHints wiki, as many of us were contributing there 
steps for Windows and other GDAL drivers over the years: 
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows. Today it's still a gold 
mine of tips and configure steps that are key to making it all work together.

-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of 
FOSS4G http://gatewaygeo.com/


On 2021-11-11 6:39 p.m., peter vG via gdal-dev wrote:
> I've been trying to build the binaries for Gdal 3.3.3 (and 3.4.0) using 
> Visual C++ (via Visual Studio 2019), but I am getting a linking error 
> that has me scratching my head: LINK : "fatal error LNK1104: cannot open 
> file 'C:\gdal-3.4.0\lib.obj'". What is lib.obj? I am new to Visual C++, 
> having come from the CPP Builder world, so I'm still getting my head 
> around this product. Any suggestions would be greatly appreciated as I 
> am wasting my life trying to hunt down a solution!
> 
>


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ingesting .gpx files from FFI

[Joaquim Manuel Freire Luís]

Ah, Ghrrr. Not in this simple code sample but I (thought) I did in the real 
implementation

https://github.com/GenericMappingTools/GMT.jl/blob/master/src/gdal_utils.jl#L197

but it only looked at the first layer

making it scan all layers produces the correct plot.

Cheers

Joaquim


From: Even Rouault 
Sent: Friday, October 29, 2021 5:50 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] ingesting .gpx files from FFI


You didn't explore completely the dataset. The waypoints layer has 0 feature, 
but the tracks one has 1 and the track_points one 2469
Le 29/10/2021 à 18:32, Joaquim Manuel Freire Luís a écrit :
Hi,

Trying to read .gpx files from Julia (and I would bet, from python too but 
can’t test it) is showing puzzling results.
For example, with the attached gpx file I get this

julia> ds = gdalread("25708.gpx", gdataset=true);

julia> layer = getlayer(ds, 0)
Layer: waypoints (1)
  Geometry 0 (�∟*��): [1]
 Field 0 (ele): [Real]
 Field 1 (time): []
 Field 2 (magvar): [Real]
 Field 3 (geoidheigh): [Real]
 Field 4 (name): [String]
...
Number of Fields: 23

But there are no Features in the layers, so I can’t get the data from the 
geometries

julia> GMT.Gdal.nfeature(layer)
0

HOWEVER, both the GDAL `ogr2ogr` command line or it’s Julia wrapper works in 
converting, e.g., to geopackage

julia> ogr2ogr("25708.gpx", dest="25708.gpkg")

and I can now plot "25708.gpkg" (not shown here but the plot can be seen in 
https://discourse.julialang.org/t/what-is-your-favorite-mapping-package/70509/22?u=joa-quim)

How is ogr2ogr able to read this file data?

Thanks

Joaquim





___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ingesting .gpx files from FFI

[Joaquim Manuel Freire Luís]

Hi,

Trying to read .gpx files from Julia (and I would bet, from python too but 
can’t test it) is showing puzzling results.
For example, with the attached gpx file I get this

julia> ds = gdalread("25708.gpx", gdataset=true);

julia> layer = getlayer(ds, 0)
Layer: waypoints (1)
  Geometry 0 (�∟*��): [1]
 Field 0 (ele): [Real]
 Field 1 (time): []
 Field 2 (magvar): [Real]
 Field 3 (geoidheigh): [Real]
 Field 4 (name): [String]
...
Number of Fields: 23

But there are no Features in the layers, so I can’t get the data from the 
geometries

julia> GMT.Gdal.nfeature(layer)
0

HOWEVER, both the GDAL `ogr2ogr` command line or it’s Julia wrapper works in 
converting, e.g., to geopackage

julia> ogr2ogr("25708.gpx", dest="25708.gpkg")

and I can now plot "25708.gpkg" (not shown here but the plot can be seen in 
https://discourse.julialang.org/t/what-is-your-favorite-mapping-package/70509/22?u=joa-quim)

How is ogr2ogr able to read this file data?

Thanks

Joaquim


<>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] What's so wrong with this nc file ...

[Joaquim Manuel Freire Luís]

That the geotransform is not detected

gdalinfo xxx.grd
Warning 1: dimension #1 (x) is not a Longitude___/X dimension.
Warning 1: dimension #0 (y) is not a Latitude/Y dimension.
Driver: netCDF/Network Common Data Format
...
Corner Coordinates:
Upper Left  (0.0,0.0)
Lower Left  (0.0,   59.0)
Upper Right (   37.0,0.0)
Lower Right (   37.0,   59.0)
Center  (   18.5,   29.5)

I can't get why it's complaining on "dimension #1 (x) is not a Longitude/X 
dimension."
Tried to check the full docs (netcdfdataset.cpp) but not even with a debugger I 
can understand the why.

Due to it the x,y coordinates are not fished from file, either from Julia or 
from GMT

NOTE: this works but does not use GDAL

grdinfo xxx.grd
xxx.grd: Title: z
xxx.grd: Command:
xxx.grd: Remark:
xxx.grd: Gridline node registration used [Cartesian grid]
xxx.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
xxx.grd: x_min: 580155 x_max: 581235 x_inc: 30 name: x n_columns: 37
xxx.grd: y_min: 4416795 y_max: 4418535 y_inc: 30 name: y n_rows: 59
xxx.grd: v_min: 0.205308780074 v_max: 0.56782335043 name: z
...

This DOES NOT WORK (it uses GDAL)

grdinfo xxx.grd=gd
Warning 1: dimension #1 (x) is not a Longitude___/X dimension.
Warning 1: dimension #0 (y) is not a Latitude/Y dimension.
xxx.grd: Title: Grid imported via GDAL
xxx.grd: Command:
xxx.grd: Remark:
xxx.grd: Gridline node registration used [Cartesian grid]
xxx.grd: Grid file format: gd = Import/export through GDAL
xxx.grd: x_min: 0.5 x_max: 36.5 x_inc: 1 name: x n_columns: 37
xxx.grd: y_min: 0.5 y_max: 58.5 y_inc: 1 name: y n_rows: 59
xxx.grd: v_min: 0.205308780074 v_max: 0.56782335043 name: z
xxx.grd: scale_factor: 1 add_offset: 0
+proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs

What's so wrong with this nc file? I have others that look similar in terms of 
attributes and things work fine, but for some other cases I get the terrible

Warning 1: dimension #1 (x) is not a Longitude/X dimension.
Warning 1: dimension #0 (y) is not a Latitude/Y dimension.

and I'm screwed.




xxx.grd
Description: xxx.grd
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

Even, sorry to keep bothering you with this but found no docs on this.

The CreateCopy() solution created me a file with the coordinates system info 
stored in the "transverse_mercator" attribute (why?)

Metadata:
  Band1#grid_mapping=transverse_mercator
  Band1#long_name=GDAL Band Number 1
  Band1#_FillValue=65535
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 3.4.0dev, released 2021/99/99
  NC_GLOBAL#history=Thu Oct 14 20:59:24 2021: GDAL CreateCopy( gd_cube.nc, ... )
  NETCDF_DIM_EXTRA={time}
  NETCDF_DIM_time_DEF={7,6}
  NETCDF_DIM_time_VALUES={1,2,3,4,5,6,7}
  time#axis=t
  transverse_mercator#false_easting=50
  transverse_mercator#false_northing=0
  transverse_mercator#GeoTransform=481845 30 0 4287765 0 -30
  transverse_mercator#grid_mapping_name=transverse_mercator
  transverse_mercator#inverse_flattening=298.257223563
  transverse_mercator#latitude_of_projection_origin=0
  transverse_mercator#longitude_of_central_meridian=-9
  transverse_mercator#longitude_of_prime_meridian=0
  transverse_mercator#long_name=CRS definition
  transverse_mercator#scale_factor_at_central_meridian=0.9996
  transverse_mercator#semi_major_axis=6378137
  
transverse_mercator#spatial_ref=PROJCS["unknown",GEOGCS["unknown",DATUM["WGS_1984",SPHEROID["WGS
 
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",50],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH]]


The problem is that either GMT and Mirone look for that info in global 
attribute called "grid_mapping" as in

...
Metadata:
  grid_mapping#spatial_ref=PROJCS["unknown",
GEOGCS["unknown",
DATUM["Unknown based on WGS84 ellipsoid",
SPHEROID["WGS 84",6378137,298.257223563,


How can I control the name of the attribute where the CRS is tored so I can 
find it from other programs?

Also, is there a way of setting the "actual_range" and "_Fillvalue" data 
attributes?

Joaquim

From: Joaquim Manuel Freire Luís 
Sent: Thursday, October 14, 2021 9:03 PM
To: Joaquim Manuel Freire Luís ; Even Rouault 
; gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Writing multi-bands vs multi-datasets

On more. The warning about "No 1D variable is indexed by dimension time" turned 
out to be because I was calling

Gdal.setmetadataitem(ds, "NETCDF_DIM_EXTRA", "{time}")

(like you call '{time,Z}' in your Python example). Removing the curly braces 
here made that warning go away.

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Joaquim Manuel Freire Luís
Sent: Thursday, October 14, 2021 8:42 PM
To: Even Rouault 
mailto:even.roua...@spatialys.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets

Much better (I was confused by those curly braces thinking it was part of 
python syntax).
Though still get this warning

Warning 1: No 1D variable is indexed by dimension time

But otherwise gdalinfo does not complain on anything wrong

The "-co" is confusing. I had to add in other situations otherwise some options 
were not set.

Julia does not use bindings, it can access the exported functions in shared 
libraries directly
(if you are curious see 
https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/
and https://docs.julialang.org/en/v1/base/c/#ccall)
so passing that vector of strings should be translated automatically to a "char 
*string[]" and GDAL expects the "-co" (I think)

From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Thursday, October 14, 2021 8:14 PM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets



Le 14/10/2021 à 21:03, Joaquim Manuel Freire Luís a écrit :
Even,

There are some issues with this way.

My draft Julia function looks like bellow  (tested with a MxNx7 array) but get 
this errors

julia> GMT.write_multiband(cube, "gd_cube.nc")
Warning 1: No 1D variable is indexed by dimension time
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
I d

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

[Joaquim Manuel Freire Luís]

Found this

https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg35514.html

So my guess is that is that the shipped OpenJPEG dll is not compatible with the 
gdal.dll, it misses that opj_encoder_set_extra_options() function.


From: gdal-dev  On Behalf Of Even Rouault
Sent: Friday, October 15, 2021 1:38 PM
To: Pedro Venâncio ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed



Le 15/10/2021 à 14:05, Pedro Venâncio a écrit :
Hi Even,

I've been trying to tackle this issue and these are my last findings:

https://github.com/conda-forge/gdal-feedstock/issues/541#issuecomment-944228747

Does this make sense to you? Do you remember any change between gdal 3.2.1 and 
3.2.2 that can explain this behaviour?
No, looking at the git diff, nothing significant in the Python bindings has 
changed between 3.2.1 and 3.2.2


Thank you very much!

Pedro

Alexandre Neto mailto:senhor.n...@gmail.com>> escreveu 
no dia quinta, 14/10/2021 à(s) 01:26:
Hi pedro,

Are you sure you are not mixing conda channels? Normally, in the same 
environment, you should stick to a single channel to avoid dependency problems.

I also noticed that you are using anaconda. I suggest you use miniconda 
instead. It comes with the bare minimal tools to install and manage the 
packages you explicitly want, instead of installating Gb of packages that 
unless you know them, you will never use.

Alexandre Neto

A quarta, 13/10/2021, 17:16, Pedro Venâncio 
mailto:pedrongvenan...@gmail.com>> escreveu:
I will ask on GDAL conda-forge, maybe this can be some packaging problem.

Thanks!


Pedro Venâncio mailto:pedrongvenan...@gmail.com>> 
escreveu no dia quarta, 13/10/2021 à(s) 17:00:
Tried to define several environment variables, but nothing seems to work



Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>> escreveu no 
dia quarta, 13/10/2021 à(s) 16:23:
Não Pedro,

When I look into my own build of the gdall dll I see no dependency on that 
“opj_encoder_set_extra_options” but likely because it’s a different version (I 
build from master).

From my experience on this there is really nothing one can do other than 
rebuild the dll or replace the dependency that is missing the required symbol. 
Nothing we can do from a conda installation.

But ofc my analysis may be all wrong.

Joaquim

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Pedro Venâncio
Sent: Wednesday, October 13, 2021 4:04 PM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed

Hi Joaquim,

Thanks for sharing your case. Did you manage to make it work in some way?

I've already uninstalled a test PostgreSQL/PostGIS that I supposed to be the 
source of the conflict, but I keep having the same error.

I also reinstalled conda, but nothing had changed.



Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>> escreveu no 
dia quarta, 13/10/2021 à(s) 15:24:
Hi,

I have a certain horror to python (that I’m trying to fight) a bit of it is 
because I never manage to really use it.

I had and older Miniconda (Mini => 18 GB ) that was so big that I removed 
and installed a new one in which I tried Pedro’s case and got exactly the same 
errors.

I then run a dependency analysis from within the conda shell and found two 
weird things


  1.  The gdal dll depends on a xerces-c_3_2.dll locate at C:\WINDOWS\system32. 
This seems quite dangerous (for dependency sakes) but seems to not cause any 
problem in this case.
  2.  There is a “red mark” on the opj_encoder_set_extra_options symbol and 
this alone can explain the “ImportError: DLL load failed while importing _gdal: 
The specified procedure could not be found.”

Hopefully the screen capture is small enough to get through.

Joaquim

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Even Rouault
Sent: Wednesday, October 13, 2021 2:39 PM
To: Pedro Venâncio mailto:pedrongvenan...@gmail.com>>
Cc: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed


ok, so now you have to inspect the PATH and fix it so that the gdal DLL and its 
dependencies are in it. But all of this sounds like there's something weird in 
your environment. Perhaps a mix of GDAL versions?
Le 13/10/2021 à 15:36, Pedro Venâncio a écrit :

Can you change in __init__.py

try:
os.add_dll_directory(p)
except FileNotFoundError:
continue



to

try:
os.add_dll_directory(p)
except (FileNotFoundError, OSError):
continue

Yes, here is the output:

Traceback (most recent call last):

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 lin

Re: [gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

On more. The warning about "No 1D variable is indexed by dimension time" turned 
out to be because I was calling

Gdal.setmetadataitem(ds, "NETCDF_DIM_EXTRA", "{time}")

(like you call '{time,Z}' in your Python example). Removing the curly braces 
here made that warning go away.

From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Thursday, October 14, 2021 8:42 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets

Much better (I was confused by those curly braces thinking it was part of 
python syntax).
Though still get this warning

Warning 1: No 1D variable is indexed by dimension time

But otherwise gdalinfo does not complain on anything wrong

The "-co" is confusing. I had to add in other situations otherwise some options 
were not set.

Julia does not use bindings, it can access the exported functions in shared 
libraries directly
(if you are curious see 
https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/
and https://docs.julialang.org/en/v1/base/c/#ccall)
so passing that vector of strings should be translated automatically to a "char 
*string[]" and GDAL expects the "-co" (I think)

From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Thursday, October 14, 2021 8:14 PM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets



Le 14/10/2021 à 21:03, Joaquim Manuel Freire Luís a écrit :
Even,

There are some issues with this way.

My draft Julia function looks like bellow  (tested with a MxNx7 array) but get 
this errors

julia> GMT.write_multiband(cube, "gd_cube.nc")
Warning 1: No 1D variable is indexed by dimension time
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
I don't know the Julia bindings, but the error message seems to suggest you can 
remove the "-co" element in your options[] array since it presumably must only 
contain the "key=value" creation options, like in the Python bindings
ERROR 1: netcdf error #-45 : NetCDF: Not a valid data type or _FillValue type 
mismatch .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,netCDFDataset::CreateCopy,9012)

ERROR 1: netcdf error #-49 : NetCDF: Variable not found .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,NCDFPutAttr,10454)

Warning 1: No 1D variable is indexed by dimension time

And indeed the "time" variable shows up filled with 7 zeros when I open the nc 
file that is nevertheless created.
Also checked with getmetadataitem(ds, "NETCDF_DIM_time_VALUES")  that the 
"1,2,3,4,5,6,7" info was correctly set.
You need to surround the values of the _DEF and _VALUES items with { and } 
braces to indicate this is a list (this is the particular syntax expected by 
the netCDF driver)

I's also strange the warnings about the "-co" options also because they were in 
fact taken into account. Omitting them creates a classic nc file.


function write_multiband(cube, fname::AbstractString, v=nothing; 
dim_name::String="time")
   nbands = size(cube,3)
   ds = gmt2gd(cube)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_EXTRA", dim_name)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_DEF", 
"$(nbands),6")
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_VALUES", 
"1,2,3,4,5,6,7")
   Gdal.setmetadataitem(ds, dim_name * "#axis", string(dim_name[1]))
   crs = Gdal.getproj(cube, wkt=true)
   (crs != "" ) && Gdal.setproj!(ds, crs)
       Gdal.unsafe_copy(ds, filename=fname, driver=getdriver("netCDF"), 
options=["-co", "FORMAT=NC4", "-co", "COMPRESS=DEFLATE", "-co", "ZLEVEL=4"])
end

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Sunday, October 10, 2021 10:48 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets


Joaquim,

https://github.com/OSGeo/gdal/pull/4634 should hopefully help

Even
Le 10/10/2021 à 22:26, Joaquim Manuel Freire Luís a écrit :
Hi,

I have a Julia version of gdal_translate (that ends up calling 
GDALDatasetRasterIOEx) that works in saving a MxNxP array, but not the way I 
wanted.
It creates a multi-subdatasets file, whilst what I wished is to write a 
multi-band file.

For example, the file written with this 

Re: [gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

Much better (I was confused by those curly braces thinking it was part of 
python syntax).
Though still get this warning

Warning 1: No 1D variable is indexed by dimension time

But otherwise gdalinfo does not complain on anything wrong

The "-co" is confusing. I had to add in other situations otherwise some options 
were not set.

Julia does not use bindings, it can access the exported functions in shared 
libraries directly
(if you are curious see 
https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/
and https://docs.julialang.org/en/v1/base/c/#ccall)
so passing that vector of strings should be translated automatically to a "char 
*string[]" and GDAL expects the "-co" (I think)

From: Even Rouault 
Sent: Thursday, October 14, 2021 8:14 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets



Le 14/10/2021 à 21:03, Joaquim Manuel Freire Luís a écrit :
Even,

There are some issues with this way.

My draft Julia function looks like bellow  (tested with a MxNx7 array) but get 
this errors

julia> GMT.write_multiband(cube, "gd_cube.nc")
Warning 1: No 1D variable is indexed by dimension time
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
I don't know the Julia bindings, but the error message seems to suggest you can 
remove the "-co" element in your options[] array since it presumably must only 
contain the "key=value" creation options, like in the Python bindings

ERROR 1: netcdf error #-45 : NetCDF: Not a valid data type or _FillValue type 
mismatch .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,netCDFDataset::CreateCopy,9012)

ERROR 1: netcdf error #-49 : NetCDF: Variable not found .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,NCDFPutAttr,10454)

Warning 1: No 1D variable is indexed by dimension time

And indeed the "time" variable shows up filled with 7 zeros when I open the nc 
file that is nevertheless created.
Also checked with getmetadataitem(ds, "NETCDF_DIM_time_VALUES")  that the 
"1,2,3,4,5,6,7" info was correctly set.
You need to surround the values of the _DEF and _VALUES items with { and } 
braces to indicate this is a list (this is the particular syntax expected by 
the netCDF driver)


I's also strange the warnings about the "-co" options also because they were in 
fact taken into account. Omitting them creates a classic nc file.


function write_multiband(cube, fname::AbstractString, v=nothing; 
dim_name::String="time")
   nbands = size(cube,3)
   ds = gmt2gd(cube)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_EXTRA", dim_name)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_DEF", 
"$(nbands),6")
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_VALUES", 
"1,2,3,4,5,6,7")
   Gdal.setmetadataitem(ds, dim_name * "#axis", string(dim_name[1]))
   crs = Gdal.getproj(cube, wkt=true)
   (crs != "" ) && Gdal.setproj!(ds, crs)
   Gdal.unsafe_copy(ds, filename=fname, driver=getdriver("netCDF"), 
options=["-co", "FORMAT=NC4", "-co", "COMPRESS=DEFLATE", "-co", "ZLEVEL=4"])
end

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Sunday, October 10, 2021 10:48 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets


Joaquim,

https://github.com/OSGeo/gdal/pull/4634 should hopefully help

Even
Le 10/10/2021 à 22:26, Joaquim Manuel Freire Luís a écrit :
Hi,

I have a Julia version of gdal_translate (that ends up calling 
GDALDatasetRasterIOEx) that works in saving a MxNxP array, but not the way I 
wanted.
It creates a multi-subdatasets file, whilst what I wished is to write a 
multi-band file.

For example, the file written with this Julia function looks like below

How can I write a multi-band instead of a multi-datasets?
I've been looking at the docs of GDALDatasetRasterIOEx but can't see any way of 
picking one or the other.

Joaquim

gdalinfo cube_rad.nc
Driver: netCDF/Network Common Data Format
Files: cube_rad.nc
Size is 512, 512
Metadata:
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 3.4.0dev, released 2021/99/99
  NC_GLOBAL#history=Sun Oct 10 13:01:06 2021: GDAL CreateCopy( cube_rad.nc, ... 
)
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"cube_rad.nc":Band1
  SUBDATASET_1_DESC=[1567x1519] Band1 (32-bit floating-point)
  SUBDA

Re: [gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

Even,

There are some issues with this way.

My draft Julia function looks like bellow  (tested with a MxNx7 array) but get 
this errors

julia> GMT.write_multiband(cube, "gd_cube.nc")
Warning 1: No 1D variable is indexed by dimension time
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
Warning 6: creation option '-co' is not formatted with the key=value format
ERROR 1: netcdf error #-45 : NetCDF: Not a valid data type or _FillValue type 
mismatch .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,netCDFDataset::CreateCopy,9012)

ERROR 1: netcdf error #-49 : NetCDF: Variable not found .
at 
(C:\programs\compa_libs\gdal_GIT\gdal\frmts\netcdf\netcdfdataset.cpp,NCDFPutAttr,10454)

Warning 1: No 1D variable is indexed by dimension time

And indeed the "time" variable shows up filled with 7 zeros when I open the nc 
file that is nevertheless created.
Also checked with getmetadataitem(ds, "NETCDF_DIM_time_VALUES")  that the 
"1,2,3,4,5,6,7" info was correctly set.

I's also strange the warnings about the "-co" options also because they were in 
fact taken into account. Omitting them creates a classic nc file.


function write_multiband(cube, fname::AbstractString, v=nothing; 
dim_name::String="time")
   nbands = size(cube,3)
   ds = gmt2gd(cube)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_EXTRA", dim_name)
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_DEF", 
"$(nbands),6")
   Gdal.setmetadataitem(ds, "NETCDF_DIM_" * dim_name * "_VALUES", 
"1,2,3,4,5,6,7")
   Gdal.setmetadataitem(ds, dim_name * "#axis", string(dim_name[1]))
   crs = Gdal.getproj(cube, wkt=true)
   (crs != "" ) && Gdal.setproj!(ds, crs)
   Gdal.unsafe_copy(ds, filename=fname, driver=getdriver("netCDF"), 
options=["-co", "FORMAT=NC4", "-co", "COMPRESS=DEFLATE", "-co", "ZLEVEL=4"])
end

From: Even Rouault 
Sent: Sunday, October 10, 2021 10:48 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets


Joaquim,

https://github.com/OSGeo/gdal/pull/4634 should hopefully help

Even
Le 10/10/2021 à 22:26, Joaquim Manuel Freire Luís a écrit :
Hi,

I have a Julia version of gdal_translate (that ends up calling 
GDALDatasetRasterIOEx) that works in saving a MxNxP array, but not the way I 
wanted.
It creates a multi-subdatasets file, whilst what I wished is to write a 
multi-band file.

For example, the file written with this Julia function looks like below

How can I write a multi-band instead of a multi-datasets?
I've been looking at the docs of GDALDatasetRasterIOEx but can't see any way of 
picking one or the other.

Joaquim

gdalinfo cube_rad.nc
Driver: netCDF/Network Common Data Format
Files: cube_rad.nc
Size is 512, 512
Metadata:
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 3.4.0dev, released 2021/99/99
  NC_GLOBAL#history=Sun Oct 10 13:01:06 2021: GDAL CreateCopy( cube_rad.nc, ... 
)
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"cube_rad.nc":Band1
  SUBDATASET_1_DESC=[1567x1519] Band1 (32-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"cube_rad.nc":Band2
  SUBDATASET_2_DESC=[1567x1519] Band2 (32-bit floating-point)
...

Saving the same data (or similar) from a Matlab code that I wrote long ago to 
stack grids, shows

gdalinfo evi_cube.nc
Driver: netCDF/Network Common Data Format
Files: evi_cube.nc
Size is 37, 59
Origin = (580140.000,4418550.000)
Pixel Size = (30.000,-30.000)
Metadata:
...
  latitude#actual_range={4416795,4418535}
  latitude#long_name=latitude
  latitude#units=degrees_north
  longitude#actual_range={580155,581235}
  longitude#long_name=longitude
  longitude#units=degrees_east
  NC_GLOBAL#Conventions=COARDS
  NC_GLOBAL#description=File written from Matlab
  NC_GLOBAL#node_offset=0
  NC_GLOBAL#Source_Software=Mirone
  NC_GLOBAL#title=Grid created by Mirone
  NETCDF_DIM_EXTRA={time}
  NETCDF_DIM_time_DEF={67,6}
  
NETCDF_DIM_time_VALUES={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67}
  z#actual_range={-856.4703369140625,176.8457641601562}
  z#long_name=z
  z#units=unknown
  z#_FillValue=-nan(ind)
Corner Coordinates:
Upper Left  (  580140.000, 4418550.000)
Lower Left  (  580140.000, 4416780.000)
Upper Right (  581250.000, 4418550.000)
Lower Right (  581250.000, 4416780.000)
Center  (  580695.000, 4417665.000)
Band 1 Block=37x59 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Ty

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

[Joaquim Manuel Freire Luís]

Não Pedro,

When I look into my own build of the gdall dll I see no dependency on that 
“opj_encoder_set_extra_options” but likely because it’s a different version (I 
build from master).

From my experience on this there is really nothing one can do other than 
rebuild the dll or replace the dependency that is missing the required symbol. 
Nothing we can do from a conda installation.

But ofc my analysis may be all wrong.

Joaquim

From: gdal-dev  On Behalf Of Pedro Venâncio
Sent: Wednesday, October 13, 2021 4:04 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed

Hi Joaquim,

Thanks for sharing your case. Did you manage to make it work in some way?

I've already uninstalled a test PostgreSQL/PostGIS that I supposed to be the 
source of the conflict, but I keep having the same error.

I also reinstalled conda, but nothing had changed.



Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>> escreveu no 
dia quarta, 13/10/2021 à(s) 15:24:
Hi,

I have a certain horror to python (that I’m trying to fight) a bit of it is 
because I never manage to really use it.

I had and older Miniconda (Mini => 18 GB ) that was so big that I removed 
and installed a new one in which I tried Pedro’s case and got exactly the same 
errors.

I then run a dependency analysis from within the conda shell and found two 
weird things


  1.  The gdal dll depends on a xerces-c_3_2.dll locate at C:\WINDOWS\system32. 
This seems quite dangerous (for dependency sakes) but seems to not cause any 
problem in this case.
  2.  There is a “red mark” on the opj_encoder_set_extra_options symbol and 
this alone can explain the “ImportError: DLL load failed while importing _gdal: 
The specified procedure could not be found.”

Hopefully the screen capture is small enough to get through.

Joaquim

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Even Rouault
Sent: Wednesday, October 13, 2021 2:39 PM
To: Pedro Venâncio mailto:pedrongvenan...@gmail.com>>
Cc: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed


ok, so now you have to inspect the PATH and fix it so that the gdal DLL and its 
dependencies are in it. But all of this sounds like there's something weird in 
your environment. Perhaps a mix of GDAL versions?
Le 13/10/2021 à 15:36, Pedro Venâncio a écrit :

Can you change in __init__.py

try:
os.add_dll_directory(p)
except FileNotFoundError:
continue



to

try:
os.add_dll_directory(p)
except (FileNotFoundError, OSError):
continue

Yes, here is the output:

Traceback (most recent call last):

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 21, in swig_import_helper

return importlib.import_module(mname)

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\importlib\__init__.py", line 
127, in import_module

return _bootstrap._gcd_import(name[level:], package, level)

  File "", line 1014, in _gcd_import

  File "", line 991, in _find_and_load

  File "", line 975, in _find_and_load_unlocked

  File "", line 657, in _load_unlocked

  File "", line 556, in module_from_spec

  File "", line 1166, in create_module

  File "", line 219, in _call_with_frames_removed

ImportError: DLL load failed while importing _gdal: Impossível localizar o 
procedimento especificado.



During handling of the above exception, another exception occurred:



Traceback (most recent call last):

  File "demo.py", line 1, in 

from osgeo import gdal

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 37, in 

_gdal = swig_import_helper()

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 34, in swig_import_helper

return importlib.import_module('_gdal')

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\importlib\__init__.py", line 
127, in import_module

return _bootstrap._gcd_import(name[level:], package, level)

ModuleNotFoundError: No module named '_gdal'


--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

[Joaquim Manuel Freire Luís]

Hi,

I have a certain horror to python (that I’m trying to fight) a bit of it is 
because I never manage to really use it.

I had and older Miniconda (Mini => 18 GB ) that was so big that I removed 
and installed a new one in which I tried Pedro’s case and got exactly the same 
errors.

I then run a dependency analysis from within the conda shell and found two 
weird things


  1.  The gdal dll depends on a xerces-c_3_2.dll locate at C:\WINDOWS\system32. 
This seems quite dangerous (for dependency sakes) but seems to not cause any 
problem in this case.
  2.  There is a “red mark” on the opj_encoder_set_extra_options symbol and 
this alone can explain the “ImportError: DLL load failed while importing _gdal: 
The specified procedure could not be found.”

Hopefully the screen capture is small enough to get through.

Joaquim

From: gdal-dev  On Behalf Of Even Rouault
Sent: Wednesday, October 13, 2021 2:39 PM
To: Pedro Venâncio 
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL 
load failed


ok, so now you have to inspect the PATH and fix it so that the gdal DLL and its 
dependencies are in it. But all of this sounds like there's something weird in 
your environment. Perhaps a mix of GDAL versions?
Le 13/10/2021 à 15:36, Pedro Venâncio a écrit :

Can you change in __init__.py

try:
os.add_dll_directory(p)
except FileNotFoundError:
continue



to

try:
os.add_dll_directory(p)
except (FileNotFoundError, OSError):
continue

Yes, here is the output:

Traceback (most recent call last):

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 21, in swig_import_helper

return importlib.import_module(mname)

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\importlib\__init__.py", line 
127, in import_module

return _bootstrap._gcd_import(name[level:], package, level)

  File "", line 1014, in _gcd_import

  File "", line 991, in _find_and_load

  File "", line 975, in _find_and_load_unlocked

  File "", line 657, in _load_unlocked

  File "", line 556, in module_from_spec

  File "", line 1166, in create_module

  File "", line 219, in _call_with_frames_removed

ImportError: DLL load failed while importing _gdal: Impossível localizar o 
procedimento especificado.



During handling of the above exception, another exception occurred:



Traceback (most recent call last):

  File "demo.py", line 1, in 

from osgeo import gdal

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 37, in 

_gdal = swig_import_helper()

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\site-packages\osgeo\__init__.py",
 line 34, in swig_import_helper

return importlib.import_module('_gdal')

  File 
"C:\Users\PedroVenancio\anaconda3\envs\arosics\lib\importlib\__init__.py", line 
127, in import_module

return _bootstrap._gcd_import(name[level:], package, level)

ModuleNotFoundError: No module named '_gdal'


--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov

[Joaquim Manuel Freire Luís]

Rebuilt GDAL and now works again (but not the 3.0.4 version in the University 
Campus).

Probably a system reboot would have been much simpler. 

Joaquim

From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Tuesday, October 12, 2021 11:31 AM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov

Hmm, that was in linux with a “GDAL 3.0.4, released 2020/01/28” but I get the 
same error on Windows with my build (< one month) of master.
The strange thing is that I was working in a script that downloads many of 
those files and between two iterations of bug fixes I started receiving that 
error.

From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Tuesday, October 12, 2021 11:05 AM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov


Joaquim,

FWIW, works for me with HEAD of master or 3.3 branch.

Even
Le 12/10/2021 à 12:00, Joaquim Manuel Freire Luís a écrit :
Hi,

This seems to be related to some service change as it was working till 
yesterday and then started giving a 303 error.
Note that downloading the file with a browse, works.

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt
ERROR 11: HTTP response code: 303
gdalinfo failed - unable to open 
'/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.

Joaquim


___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Failure to compile master

[Joaquim Manuel Freire Luís]

Hi,

I'm getting this error while building master (on Windows but shouldn't matter)

C:\programs\compa_libs\gdal_GIT\gdal\ogr\ogrspatialreference.cpp(7835): error 
C3861: 'proj_create_conversion_pole_rotation_netcdf_cf_convention': identifier 
not found

Found also this PROJ PR

https://github.com/OSGeo/PROJ/pull/2835

Does it mean we need to rebuild PROJ lib in order to build GDAL?

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov

[Joaquim Manuel Freire Luís]

Hmm, that was in linux with a "GDAL 3.0.4, released 2020/01/28" but I get the 
same error on Windows with my build (< one month) of master.
The strange thing is that I was working in a script that downloads many of 
those files and between two iterations of bug fixes I started receiving that 
error.

From: Even Rouault 
Sent: Tuesday, October 12, 2021 11:05 AM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov


Joaquim,

FWIW, works for me with HEAD of master or 3.3 branch.

Even
Le 12/10/2021 à 12:00, Joaquim Manuel Freire Luís a écrit :
Hi,

This seems to be related to some service change as it was working till 
yesterday and then started giving a 303 error.
Note that downloading the file with a browse, works.

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt
ERROR 11: HTTP response code: 303
gdalinfo failed - unable to open 
'/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.

Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] HTTP response code: 303 from lpdaac.earthdata.nasa.gov

[Joaquim Manuel Freire Luís]

Hi,

This seems to be related to some service change as it was working till 
yesterday and then started giving a 303 error.
Note that downloading the file with a browse, works.

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt
ERROR 11: HTTP response code: 303
gdalinfo failed - unable to open 
'/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

I see thanks, will study it.
I'll end up learning some python at the force of studying it's examples

Joaquim

From: Even Rouault 
Sent: Sunday, October 10, 2021 10:48 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Writing multi-bands vs multi-datasets


Joaquim,

https://github.com/OSGeo/gdal/pull/4634 should hopefully help

Even
Le 10/10/2021 à 22:26, Joaquim Manuel Freire Luís a écrit :
Hi,

I have a Julia version of gdal_translate (that ends up calling 
GDALDatasetRasterIOEx) that works in saving a MxNxP array, but not the way I 
wanted.
It creates a multi-subdatasets file, whilst what I wished is to write a 
multi-band file.

For example, the file written with this Julia function looks like below

How can I write a multi-band instead of a multi-datasets?
I've been looking at the docs of GDALDatasetRasterIOEx but can't see any way of 
picking one or the other.

Joaquim

gdalinfo cube_rad.nc
Driver: netCDF/Network Common Data Format
Files: cube_rad.nc
Size is 512, 512
Metadata:
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 3.4.0dev, released 2021/99/99
  NC_GLOBAL#history=Sun Oct 10 13:01:06 2021: GDAL CreateCopy( cube_rad.nc, ... 
)
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"cube_rad.nc":Band1
  SUBDATASET_1_DESC=[1567x1519] Band1 (32-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"cube_rad.nc":Band2
  SUBDATASET_2_DESC=[1567x1519] Band2 (32-bit floating-point)
...

Saving the same data (or similar) from a Matlab code that I wrote long ago to 
stack grids, shows

gdalinfo evi_cube.nc
Driver: netCDF/Network Common Data Format
Files: evi_cube.nc
Size is 37, 59
Origin = (580140.000,4418550.000)
Pixel Size = (30.000,-30.000)
Metadata:
...
  latitude#actual_range={4416795,4418535}
  latitude#long_name=latitude
  latitude#units=degrees_north
  longitude#actual_range={580155,581235}
  longitude#long_name=longitude
  longitude#units=degrees_east
  NC_GLOBAL#Conventions=COARDS
  NC_GLOBAL#description=File written from Matlab
  NC_GLOBAL#node_offset=0
  NC_GLOBAL#Source_Software=Mirone
  NC_GLOBAL#title=Grid created by Mirone
  NETCDF_DIM_EXTRA={time}
  NETCDF_DIM_time_DEF={67,6}
  
NETCDF_DIM_time_VALUES={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67}
  z#actual_range={-856.4703369140625,176.8457641601562}
  z#long_name=z
  z#units=unknown
  z#_FillValue=-nan(ind)
Corner Coordinates:
Upper Left  (  580140.000, 4418550.000)
Lower Left  (  580140.000, 4416780.000)
Upper Right (  581250.000, 4418550.000)
Lower Right (  581250.000, 4416780.000)
Center  (  580695.000, 4417665.000)
Band 1 Block=37x59 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Type: unknown
  Metadata:
actual_range={-856.4703369140625,176.8457641601562}
long_name=z
NETCDF_DIM_time=1
NETCDF_VARNAME=z
units=unknown
_FillValue=-nan(ind)
Band 2 Block=37x59 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Type: unknown
  Metadata:
actual_range={-856.4703369140625,176.8457641601562}
long_name=z
NETCDF_DIM_time=2
NETCDF_VARNAME=z
units=unknown
_FillValue=-nan(ind)
...



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Writing multi-bands vs multi-datasets

[Joaquim Manuel Freire Luís]

Hi,

I have a Julia version of gdal_translate (that ends up calling 
GDALDatasetRasterIOEx) that works in saving a MxNxP array, but not the way I 
wanted.
It creates a multi-subdatasets file, whilst what I wished is to write a 
multi-band file.

For example, the file written with this Julia function looks like below

How can I write a multi-band instead of a multi-datasets?
I've been looking at the docs of GDALDatasetRasterIOEx but can't see any way of 
picking one or the other.

Joaquim

gdalinfo cube_rad.nc
Driver: netCDF/Network Common Data Format
Files: cube_rad.nc
Size is 512, 512
Metadata:
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 3.4.0dev, released 2021/99/99
  NC_GLOBAL#history=Sun Oct 10 13:01:06 2021: GDAL CreateCopy( cube_rad.nc, ... 
)
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"cube_rad.nc":Band1
  SUBDATASET_1_DESC=[1567x1519] Band1 (32-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"cube_rad.nc":Band2
  SUBDATASET_2_DESC=[1567x1519] Band2 (32-bit floating-point)
...

Saving the same data (or similar) from a Matlab code that I wrote long ago to 
stack grids, shows

gdalinfo evi_cube.nc
Driver: netCDF/Network Common Data Format
Files: evi_cube.nc
Size is 37, 59
Origin = (580140.000,4418550.000)
Pixel Size = (30.000,-30.000)
Metadata:
...
  latitude#actual_range={4416795,4418535}
  latitude#long_name=latitude
  latitude#units=degrees_north
  longitude#actual_range={580155,581235}
  longitude#long_name=longitude
  longitude#units=degrees_east
  NC_GLOBAL#Conventions=COARDS
  NC_GLOBAL#description=File written from Matlab
  NC_GLOBAL#node_offset=0
  NC_GLOBAL#Source_Software=Mirone
  NC_GLOBAL#title=Grid created by Mirone
  NETCDF_DIM_EXTRA={time}
  NETCDF_DIM_time_DEF={67,6}
  
NETCDF_DIM_time_VALUES={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67}
  z#actual_range={-856.4703369140625,176.8457641601562}
  z#long_name=z
  z#units=unknown
  z#_FillValue=-nan(ind)
Corner Coordinates:
Upper Left  (  580140.000, 4418550.000)
Lower Left  (  580140.000, 4416780.000)
Upper Right (  581250.000, 4418550.000)
Lower Right (  581250.000, 4416780.000)
Center  (  580695.000, 4417665.000)
Band 1 Block=37x59 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Type: unknown
  Metadata:
actual_range={-856.4703369140625,176.8457641601562}
long_name=z
NETCDF_DIM_time=1
NETCDF_VARNAME=z
units=unknown
_FillValue=-nan(ind)
Band 2 Block=37x59 Type=Float32, ColorInterp=Undefined
  NoData Value=nan
  Unit Type: unknown
  Metadata:
actual_range={-856.4703369140625,176.8457641601562}
long_name=z
NETCDF_DIM_time=2
NETCDF_VARNAME=z
units=unknown
_FillValue=-nan(ind)
...
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to access remote data that requires authentication?

[Joaquim Manuel Freire Luís]

Hmm, very tricky situations. Apparently from Julia things remain in memory and 
it remembers previous errors.

From a clean Juia REPL start this works (even with authentication)

julia> set_config_option("GDAL_HTTP_COOKIEFILE", joinpath(tempdir(), 
"cookies.txt"))
julia> set_config_option("GDAL_HTTP_COOKIEJAR", joinpath(tempdir(), 
"cookies.txt"))
julia> set_config_option("GDAL_DISABLE_READDIR_ON_OPEN","YES")
julia> set_config_option("CPL_VSIL_CURL_ALLOWED_EXTENSIONS","TIF")
julia> set_config_option("CPL_VSIL_CURL_USE_HEAD","FALSE")

gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
"Driver: GTiff/GeoTIFF\nFiles: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif\nSize
 is 3660, 3660\nCoordinate System is:\nPROJCRS[\"UTM Zone 10, Northern 
Hemisphere\",\nBASEGEOGCRS[\"Unknown datum based upon the WGS 84 
ellipsoid\",\nDATUM[\"Not_specified_based_on_WGS_84_spheroid\",\n …..

However, if run the gdalinfo(…) first and set the options after, then any 
posterior call to gdalinfo will return that “not supported file format” error.

In fact the errors evolve like this (after another clean start)

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 11: HTTP response code: 206

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 does not exist in the file system, and is not recognized as a supported 
dataset name.

From: Even Rouault 
Sent: Tuesday, October 5, 2021 8:11 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


There are a few historically exported VSIInstaller symbols, but 
VSIInstallCurlFileHandler is never exported. None of those symbols need to be 
explicitly called as GDAL will automatically register the builtin-handlers. 
Perhaps your gdal.dll lacks curl support ? I assumed you pass the needed config 
options / env variables for that service. Perhaps you could try with something 
simpler that doesn't require authentication.
Le 05/10/2021 à 21:05, Joaquim Manuel Freire Luís a écrit :
Even, sorry to continue this.

Now is from Julia

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 not recognized as a supported file format.

I saw a reference to VSIInstallCurlFileHandler() so I thought “right I need 
this guy too” but when I try to install it

julia> GMT.Gdal.VSIInstallCurlFileHandler()
ERROR: could not load symbol "VSIInstallCurlFileHandler":
The specified procedure could not be found.

And indeed my gdal.dll has a couple of VSIInstaller symbols but not this one 
(nor zip, gzip and others).

Is the “not supported file format” related to this? Shouldn’t that symbol be 
exported to the dll?


From: gdal-dev 
<mailto:gdal-dev-boun...@lists.osgeo.org> On 
Behalf Of Joaquim Manuel Freire Luís
Sent: Tuesday, October 5, 2021 5:59 PM
To: Even Rouault 
<mailto:even.roua...@spatialys.com>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See

Re: [gdal-dev] How to access remote data that requires authentication?

[Joaquim Manuel Freire Luís]

Even, sorry to continue this.

Now is from Julia

julia> 
gdalinfo("/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif;)
ERROR 4: 
`/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'
 not recognized as a supported file format.

I saw a reference to VSIInstallCurlFileHandler() so I thought “right I need 
this guy too” but when I try to install it

julia> GMT.Gdal.VSIInstallCurlFileHandler()
ERROR: could not load symbol "VSIInstallCurlFileHandler":
The specified procedure could not be found.

And indeed my gdal.dll has a couple of VSIInstaller symbols but not this one 
(nor zip, gzip and others).

Is the “not supported file format” related to this? Shouldn’t that symbol be 
exported to the dll?


From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Tuesday, October 5, 2021 5:59 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to access remote data that requires authentication?


>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html

You need to add things like --config GDAL_HTTP_COOKIEFILE /tmp/cookies.txt 
--config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt
Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.



gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE



* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...

OK, right it's not there.



But latter down it says



* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults



Now this is not right.



< HTTP/1.1 401 Unauthorized

...

< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new<https://urs.earthdata.nasa.gov/users/new>"

...

ERROR 11: HTTP response code: 401





So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?



-Original Message-

From: thomas bonfort <mailto:thomas.bonf...@gmail.com>

Sent: Tuesday, October 5, 2021 4:31 PM

To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>

Subject: Re: [gdal-dev] How to access remote data that requires authentication?



for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"

in the archives



On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís 
<mailto:jl...@ualg.pt> wrote:





you should also change your password, now you have posted it on a

public mailing list :/



Shit, thanks for spotting it.



But it doesn't work with /vsicur/ neither (had tried it  before). Now

the error is  206



gdalinfo

/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected

/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

ERROR 11: HTTP response code: 206





On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís 
<mailto:jl...@ualg.pt> wrote:



Hi,







I’ve read a lot of the docs, tried many -co options but can’t get through this 
mystery.







I can access the data through GMT, which uses GDAL to do this job,

but can’t do it with GDAL directly







gdalinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.

Re: [gdal-dev] How to access remote data that requires authentication?

[Joaquim Manuel Freire Luís]

>The mention to _netrc is weird...

On Windows is _netrc, not .netrc

And I finally made it (twisted). The problem was that I detest where MS decides 
is my home dir (and all the hidden dirs stuff that it puts there) and always 
have had a home at “HOME=c:\j” and it’s there that libcurl (I presume) seeks 
for the netrc file.

Thanks for all the tips. But I still wonder how GMT manages to read the file 
without anything of this.



For the record if any other Windows user needs it

gdalinfo 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config 
CPL_VSIL_CURL_USE_HEAD FALSE --config GDAL_HTTP_COOKIEFILE c:/TEMP/cookies.txt 
--config GDAL_HTTP_COOKIEJAR c:/TEMP/cookies.txt

Driver: GTiff/GeoTIFF

Files: 
/vsicurl/https://lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

Size is 3660, 3660

Coordinate System is:

PROJCRS["UTM Zone 10, Northern Hemisphere",



Regarding authentication issues, this service is quite annoying and requires 
enabling cookies. See 
https://lists.osgeo.org/pipermail/gdal-dev/2021-October/054728.html

You need to add things like --config GDAL_HTTP_COOKIEFILE /tmp/cookies.txt 
--config GDAL_HTTP_COOKIEJAR /tmp/cookies.txt
Le 05/10/2021 à 18:20, Joaquim Manuel Freire Luís a écrit :

OK, tried more things from that thread.



gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE



* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...

OK, right it's not there.



But latter down it says



* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults



Now this is not right.



< HTTP/1.1 401 Unauthorized

...

< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new<https://urs.earthdata.nasa.gov/users/new>"

...

ERROR 11: HTTP response code: 401





So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?



-Original Message-

From: thomas bonfort <mailto:thomas.bonf...@gmail.com>

Sent: Tuesday, October 5, 2021 4:31 PM

To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>

Subject: Re: [gdal-dev] How to access remote data that requires authentication?



for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"

in the archives



On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís 
<mailto:jl...@ualg.pt> wrote:





you should also change your password, now you have posted it on a

public mailing list :/



Shit, thanks for spotting it.



But it doesn't work with /vsicur/ neither (had tried it  before). Now

the error is  206



gdalinfo

/vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected

/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif

ERROR 11: HTTP response code: 206





On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís 
<mailto:jl...@ualg.pt> wrote:



Hi,







I’ve read a lot of the docs, tried many -co options but can’t get through this 
mystery.







I can access the data through GMT, which uses GDAL to do this job,

but can’t do it with GDAL directly







gdalinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif



ERROR 1: HTTP error code : 401



gdalinfo failed - unable to open 
'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.







So passing longin:password via url does not work either. But it does

if indirectly used







grdinfo

https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30

.0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via

GDAL



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration

used [Cartesian grid]



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd =

Import/export through GDAL



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max:

609780 x_inc: 30 name: x n_columns: 3660



HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max:

450 y_inc: 30 name: y n_rows: 3660



HLS.S30.T10TEK.2020273T

Re: [gdal-dev] How to access remote data that requires authentication?

[Joaquim Manuel Freire Luís]

OK, tried more things from that thread.

gdalinfo 
/vsicurl/https://data.lpdaac.earthdatacloud.nasa.gov/lp-prod-protected/HLSL30.020/HLS.L30.T10TEK.2021192T184511.v2.0/HLS.L30.T10TEK.2021192T184511.v2.0.B04.tif
 --config GDAL_DISABLE_READDIR_ON_OPEN EMPTY_DIR --config CPL_CURL_VERBOSE ON 
--config CPL_VSIL_CURL_USE_HEAD FALSE 

* Couldn't find host data.lpdaac.earthdatacloud.nasa.gov in the _netrc file; 
using defaults ...
OK, right it's not there.

But latter down it says

* Couldn't find host urs.earthdata.nasa.gov in the _netrc file; using defaults

Now this is not right.

< HTTP/1.1 401 Unauthorized
...
< WWW-Authenticate: Basic realm="Please enter your Earthdata Login credentials. 
If you do not have a Earthdata Login, create one at 
https://urs.earthdata.nasa.gov//users/new;
...
ERROR 11: HTTP response code: 401


So I'm back to the Authentication problem. I do have an _netrc file (and .netrc 
btw) in my home dir as well as current dir but it does seem to find it. Is 
there something else that I must to in order to that file be found/used?

-Original Message-
From: thomas bonfort  
Sent: Tuesday, October 5, 2021 4:31 PM
To: Joaquim Manuel Freire Luís 
Subject: Re: [gdal-dev] How to access remote data that requires authentication?

for the 206 there seems to be a similar issue posted here a few days ago, 
search for "Problem accessing NASA Cloud Optimized GeoTIFF data"
in the archives

On Tue, Oct 5, 2021 at 5:26 PM Joaquim Manuel Freire Luís  wrote:
>
>
> you should also change your password, now you have posted it on a 
> public mailing list :/
>
> Shit, thanks for spotting it.
>
> But it doesn't work with /vsicur/ neither (had tried it  before). Now 
> the error is  206
>
> gdalinfo 
> /vsicurl/https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected
> /HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> ERROR 11: HTTP response code: 206
>
>
> On Tue, Oct 5, 2021 at 5:12 PM Joaquim Manuel Freire Luís  
> wrote:
> >
> > Hi,
> >
> >
> >
> > I’ve read a lot of the docs, tried many -co options but can’t get through 
> > this mystery.
> >
> >
> >
> > I can access the data through GMT, which uses GDAL to do this job, 
> > but can’t do it with GDAL directly
> >
> >
> >
> > gdalinfo
> > https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
> > .0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> >
> > ERROR 1: HTTP error code : 401
> >
> > gdalinfo failed - unable to open 
> > 'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.
> >
> >
> >
> > So passing longin:password via url does not work either. But it does 
> > if indirectly used
> >
> >
> >
> > grdinfo
> > https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30
> > .0 15/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via 
> > GDAL
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration 
> > used [Cartesian grid]
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd = 
> > Import/export through GDAL
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max:
> > 609780 x_inc: 30 name: x n_columns: 3660
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max:
> > 450 y_inc: 30 name: y n_rows: 3660
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max:
> > 0.8833 name: z
> >
> > HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001
> > add_offset: 0 packed z-range: [-149,8833]
> >
> > +proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs
> >
> >
> >
> > Joaquim
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] How to access remote data that requires authentication?

[Joaquim Manuel Freire Luís]

Hi,

I've read a lot of the docs, tried many -co options but can't get through this 
mystery.

I can access the data through GMT, which uses GDAL to do this job, but can't do 
it with GDAL directly

gdalinfo 
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
ERROR 1: HTTP error code : 401
gdalinfo failed - unable to open 
'https://jluis:abaixo0earthd...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif'.

So passing longin:password via url does not work either. But it does if 
indirectly used

grdinfo 
https://user:p...@lpdaac.earthdata.nasa.gov/lp-prod-protected/HLSS30.015/HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Title: Grid imported via GDAL
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Command:
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Remark:
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Pixel node registration used 
[Cartesian grid]
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: Grid file format: gd = 
Import/export through GDAL
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: x_min: 499980 x_max: 609780 x_inc: 
30 name: x n_columns: 3660
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: y_min: 4390200 y_max: 450 
y_inc: 30 name: y n_rows: 3660
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: v_min: -0.0149 v_max: 0.8833 name: z
HLS.S30.T10TEK.2020273T190109.v1.5.B8A.tif: scale_factor: 0.0001 add_offset: 0 
packed z-range: [-149,8833]
+proj=utm +zone=10 +ellps=WGS84 +units=m +no_defs

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp

[Joaquim Manuel Freire Luís]

Ok, I tried to use the handle like you said but couldn't find how to. That 
handle is a *void and options to gdalwarp are passed as strings.

Also tried to create a /vismem/filename but the same code that creates the in 
Memory GDAL datasets errored at line  (when line 285 was uncommented)
https://github.com/GenericMappingTools/GMT.jl/blob/master/src/gdal_utils.jl#L333
(setfeature!(layer, feature))

But it was not all failures. Managed to make it work if using ogr2ogr to write 
the /vsimem/file (though I might as well write it on disk)

This succeeded

julia> ogr2ogr(ds, dest="/vsimem/lixo.gmt")
julia> gdalwarp("IMG_9106.jpg", ["-cutline", "/vsimem/lixo.gmt", "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"])

Not the best but also allows me to keep learning this business.


From: Even Rouault 
Sent: Wednesday, March 31, 2021 8:28 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp


Ah, is it using the Memory driver ? As I saw a /vsimem/ filename and mention of 
gmt, I assumed you create a GMT file in /vsimem/, for which my example would 
have worked. But if you use the Memory driver, there's no way you can't use it 
as a cutline, since a dataset of the Memory driver can't be re-opened. You can 
just use the handle returned by the create method.
Le 31/03/2021 à 20:03, Joaquim Manuel Freire Luís a écrit :
This one is resisting. I can't spot any difference from your python example but 
it still fails.

What you mean by "Make sure that the cutline dataset is properly closed".
If I call GDALClose on it, then it disappears.
(note, I also tried by creating a "/vsimem/cut.shp" Memory cutline but the 
result was the same)


GDALGetDescription(ds.ptr)
"/vsimem/##280"

GDALClose(ds.ptr)

GDALGetDescription(ds.ptr)
""

From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Wednesday, March 31, 2021 2:43 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp


Joaquim,

yes, you should be able to use a /vsimem/ file as a cutline dataset. Here's an 
example in Python with a shapefile in /vsimem/:

https://github.com/OSGeo/gdal/blob/fec15b146f8a750c23c5e765cac12ed5fc9c2b85/autotest/utilities/test_gdalwarp_lib.py#L1103

The cutlineDSName= is just python syntaxic sugar to format the arguments. 
There's no reason it shouldn't work in Julia too

Make sure that the cutline dataset is properly closed, before using it with 
gdalwarp

Even
Le 31/03/2021 à 15:34, Joaquim Manuel Freire Luís a écrit :
I have low hopes on this one but have to confirm.

I have this "ds" dataset with one polygon geometry, which is correctly saved on 
disk with

ogr2ogr(ds, save="lixo.gmt")

and later correctly "cutlines" with

gdalwarp("IMG_9106.jpg", ["-cutline", "lixo.gmt", "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"]);

but I wanted to avoid the step of saving to disk and instead using the inMemory 
file. If I ask its name, I see

GDALGetDescription(ds.ptr)
"/vsimem/##258"

But this fails

gdalwarp("IMG_9106.jpg", ["-cutline", GDALGetDescription(ds.ptr), "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"])
NULL Dataset

Can this be made to work (would it work with the python bindings?) and I'm just 
doing it wrong or it just can't?

Thanks

Joaquim




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp

[Joaquim Manuel Freire Luís]

This one is resisting. I can't spot any difference from your python example but 
it still fails.

What you mean by "Make sure that the cutline dataset is properly closed".
If I call GDALClose on it, then it disappears.
(note, I also tried by creating a "/vsimem/cut.shp" Memory cutline but the 
result was the same)


GDALGetDescription(ds.ptr)
"/vsimem/##280"

GDALClose(ds.ptr)

GDALGetDescription(ds.ptr)
""

From: Even Rouault 
Sent: Wednesday, March 31, 2021 2:43 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp


Joaquim,

yes, you should be able to use a /vsimem/ file as a cutline dataset. Here's an 
example in Python with a shapefile in /vsimem/:

https://github.com/OSGeo/gdal/blob/fec15b146f8a750c23c5e765cac12ed5fc9c2b85/autotest/utilities/test_gdalwarp_lib.py#L1103

The cutlineDSName= is just python syntaxic sugar to format the arguments. 
There's no reason it shouldn't work in Julia too

Make sure that the cutline dataset is properly closed, before using it with 
gdalwarp

Even
Le 31/03/2021 à 15:34, Joaquim Manuel Freire Luís a écrit :

I have low hopes on this one but have to confirm.

I have this "ds" dataset with one polygon geometry, which is correctly saved on 
disk with

ogr2ogr(ds, save="lixo.gmt")

and later correctly "cutlines" with

gdalwarp("IMG_9106.jpg", ["-cutline", "lixo.gmt", "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"]);

but I wanted to avoid the step of saving to disk and instead using the inMemory 
file. If I ask its name, I see

GDALGetDescription(ds.ptr)
"/vsimem/##258"

But this fails

gdalwarp("IMG_9106.jpg", ["-cutline", GDALGetDescription(ds.ptr), "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"])
NULL Dataset

Can this be made to work (would it work with the python bindings?) and I'm just 
doing it wrong or it just can't?

Thanks

Joaquim





___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] using an in-memory file as -cutline argument in gdalwarp

[Joaquim Manuel Freire Luís]

I have low hopes on this one but have to confirm.

I have this "ds" dataset with one polygon geometry, which is correctly saved on 
disk with

ogr2ogr(ds, save="lixo.gmt")

and later correctly "cutlines" with

gdalwarp("IMG_9106.jpg", ["-cutline", "lixo.gmt", "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"]);

but I wanted to avoid the step of saving to disk and instead using the inMemory 
file. If I ask its name, I see

GDALGetDescription(ds.ptr)
"/vsimem/##258"

But this fails

gdalwarp("IMG_9106.jpg", ["-cutline", GDALGetDescription(ds.ptr), "-to", 
"SRC_METHOD=NO_GEOTRANSFORM"])
NULL Dataset

Can this be made to work (would it work with the python bindings?) and I'm just 
doing it wrong or it just can't?

Thanks

Joaquim


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't access to points in a buffer returned geometry with OGR_G_GetX

[Joaquim Manuel Freire Luís]

Le 29/03/2021 à 17:46, Joaquim Manuel Freire Luís a écrit :
Thanks,

Maybe add that info to the docs? By now it only says

We would definitely appreciate your contribution !



OK, I owe you at least that. It's just a heavy first step (fork+PR) for this 
small thing but I'll do it.





"OGR_G_GetX() Fetch the x coordinate of a point from a geometry."


From: Even Rouault 
<mailto:even.roua...@spatialys.com>
Sent: Monday, March 29, 2021 4:43 PM
To: Joaquim Manuel Freire Luís <mailto:jl...@ualg.pt>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Can't access to points in a buffer returned geometry 
with OGR_G_GetX


OGR_G_GetX() can only work on a Point or a LineString/LinearRing

for a polygon, you need to extract the ring first with OGR_G_GetGeometryRef() / 
OGR_G_GetGeometryCount()

Even
Le 29/03/2021 à 17:26, Joaquim Manuel Freire Luís a écrit :
OK, one more from the Julia wrappers. Playing with buffers now, and it works 
but I want to get the points and that fails

julia> wkt = "POINT (1198054.34 648493.09)";

julia> dbf = Gdal.buffer(Gdal.fromWKT(wkt), 500)
Geometry: POLYGON ((1198554.34 648493.09,1198553.65476738 64 ... .09))

julia> toWKT(dbf)[1:90]
"POLYGON ((1198554.34 648493.09,1198553.65476738 
648466.922021879,1198551.60094768 648440.8"

The 'toWKT()' function calls OGR_G_ExportToWkt()

But now if I try to extract the points with OGR_G_GetX() it errors

julia> Gdal.OGR_G_GetX(dbf.ptr, 0)
ERROR 6: Incompatible geometry for operation# 
ç= 
0.0

julia> Gdal.OGR_G_GetPointCount(dbf.ptr)   # 
ç= Why so?
0

Although the toWKT() works, tat's an ascii representation but I want I want to 
access them in binary (not in WKB) to send to GMT.


Joaquim




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't access to points in a buffer returned geometry with OGR_G_GetX

[Joaquim Manuel Freire Luís]

Thanks,

Maybe add that info to the docs? By now it only says

"OGR_G_GetX() Fetch the x coordinate of a point from a geometry."


From: Even Rouault 
Sent: Monday, March 29, 2021 4:43 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Can't access to points in a buffer returned geometry 
with OGR_G_GetX


OGR_G_GetX() can only work on a Point or a LineString/LinearRing

for a polygon, you need to extract the ring first with OGR_G_GetGeometryRef() / 
OGR_G_GetGeometryCount()

Even
Le 29/03/2021 à 17:26, Joaquim Manuel Freire Luís a écrit :
OK, one more from the Julia wrappers. Playing with buffers now, and it works 
but I want to get the points and that fails

julia> wkt = "POINT (1198054.34 648493.09)";

julia> dbf = Gdal.buffer(Gdal.fromWKT(wkt), 500)
Geometry: POLYGON ((1198554.34 648493.09,1198553.65476738 64 ... .09))

julia> toWKT(dbf)[1:90]
"POLYGON ((1198554.34 648493.09,1198553.65476738 
648466.922021879,1198551.60094768 648440.8"

The 'toWKT()' function calls OGR_G_ExportToWkt()

But now if I try to extract the points with OGR_G_GetX() it errors

julia> Gdal.OGR_G_GetX(dbf.ptr, 0)
ERROR 6: Incompatible geometry for operation# 
ç= 
0.0

julia> Gdal.OGR_G_GetPointCount(dbf.ptr)   # 
ç= Why so?
0

Although the toWKT() works, tat's an ascii representation but I want I want to 
access them in binary (not in WKB) to send to GMT.


Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Can't access to points in a buffer returned geometry with OGR_G_GetX

[Joaquim Manuel Freire Luís]

OK, one more from the Julia wrappers. Playing with buffers now, and it works 
but I want to get the points and that fails

julia> wkt = "POINT (1198054.34 648493.09)";

julia> dbf = Gdal.buffer(Gdal.fromWKT(wkt), 500)
Geometry: POLYGON ((1198554.34 648493.09,1198553.65476738 64 ... .09))

julia> toWKT(dbf)[1:90]
"POLYGON ((1198554.34 648493.09,1198553.65476738 
648466.922021879,1198551.60094768 648440.8"

The 'toWKT()' function calls OGR_G_ExportToWkt()

But now if I try to extract the points with OGR_G_GetX() it errors

julia> Gdal.OGR_G_GetX(dbf.ptr, 0)
ERROR 6: Incompatible geometry for operation# 
<=== 
0.0

julia> Gdal.OGR_G_GetPointCount(dbf.ptr)   # 
<=== Why so?
0

Although the toWKT() works, tat's an ascii representation but I want I want to 
access them in binary (not in WKB) to send to GMT.


Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Where is the projection info stored in a GDAL dataset?

[Joaquim Manuel Freire Luís]

Thanks Even,

That led me to OGR_L_GetSpatialRef()

julia> Gdal.OGR_L_GetSpatialRef(getlayer(ds2,0).ptr)
Ptr{Nothing} @0x67ce4610

and

julia> toWKT(Gdal.SpatialRef(p))
"GEOGCS[\"unknown\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 
84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Longitude\",EAST],AXIS[\"Latitude\",NORTH]]"

Just have to make this a bit more smooth.


From: Even Rouault 
Sent: Sunday, March 28, 2021 7:14 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Where is the projection info stored in a GDAL dataset?


Joaquim,

ogr2ogr -t_srs passes the CRS object as an argument of the 
GDALDataset::CreateLayer() API

GDALDataset::SetProjection() / GDALSetProjection() is (at least in all 
implementations of in-tree drivers) reserved for the raster API, and raster 
drivers that support the Create() API.

Similarly GDALDataset::GetSpatialRef() / GDALGetSpatialRef() is for the raster 
API

For the vector API, use OGRLayer::GetSpatialRef() (different layers in a same 
dataset could have different CRS)

Best regards,

Even
Le 28/03/2021 à 19:57, Joaquim Manuel Freire Luís a écrit :
Hi,

I am trying to use the GDAL shared lib directly from Julia and there are things 
that keep breaking my head. For example, the lines below use a mix of GMT and 
GDAL wrapper functions calls that WORK. First command creates a GMT dataset 
with two UTM points type with an assigned coordinate system. Next, in 2), I 
create a GDAL dataset of a LineString, convert it to geog in 3) and save it to 
file using the OGR_GMT driver in 4)

1) D2 = mat2ds([588977.324434907 4095339.69117669; 579551.921920776 
4150721.71333039], proj="+proj=utm +zone=29");
2) ds = gmt2gd(D2);
3) ds2=ogr2ogr(ds, ["-t_srs", "+proj=longlat", "-overwrite"])
4) ogr2ogr(ds2, dest="lixo2.gmt")

Now the troubles. When I tried to use GDALSetProjection() I got an error like 
this

ERROR 6: /vsimem/##269: Dataset does not support the SetSpatialRef() method.

So I found that I could set the CRS with GDALDatasetCreateLayer() while 
creating a layer on the dataset (using the Memory driver)
(https://github.com/GenericMappingTools/GMT.jl/blob/master/src/gdal_utils.jl#L254)

But oddly trying to inquiry the *ds* with GDALGetSpatialRef() returns an empty 
pointer. I.e.:

julia> Gdal.GDALGetSpatialRef(ds.ptr)
Ptr{Nothing} @0x

However the CSR was well sored in some place because the ="lixo2.gmt" is 
correct (it has this)

# @VGMT1.0 @GLINESTRING
# @R-8.1/-8/37/37.5
# @Jp"+proj=longlat +datum=WGS84 +no_defs"
# @Jw"GEOGCS[\"unknown\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 
84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Longitude\",EAST],AXIS[\"Latitude\",NORTH]]"
# FEATURE_DATA
>
-8 37.0
-8.1 37.5

But my trouble is that I want to fish the CRS from the ogr2ogr dataset (the ds2 
above) so that I can convert back from GDAL to GMT (which I already can) 
without having to save to a file in disk.

So basically my question is where is that CRS stored and how can I access it?

Thanks

Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Where is the projection info stored in a GDAL dataset?

[Joaquim Manuel Freire Luís]

Hi,

I am trying to use the GDAL shared lib directly from Julia and there are things 
that keep breaking my head. For example, the lines below use a mix of GMT and 
GDAL wrapper functions calls that WORK. First command creates a GMT dataset 
with two UTM points type with an assigned coordinate system. Next, in 2), I 
create a GDAL dataset of a LineString, convert it to geog in 3) and save it to 
file using the OGR_GMT driver in 4)

1) D2 = mat2ds([588977.324434907 4095339.69117669; 579551.921920776 
4150721.71333039], proj="+proj=utm +zone=29");
2) ds = gmt2gd(D2);
3) ds2=ogr2ogr(ds, ["-t_srs", "+proj=longlat", "-overwrite"])
4) ogr2ogr(ds2, dest="lixo2.gmt")

Now the troubles. When I tried to use GDALSetProjection() I got an error like 
this

ERROR 6: /vsimem/##269: Dataset does not support the SetSpatialRef() method.

So I found that I could set the CRS with GDALDatasetCreateLayer() while 
creating a layer on the dataset (using the Memory driver)
(https://github.com/GenericMappingTools/GMT.jl/blob/master/src/gdal_utils.jl#L254)

But oddly trying to inquiry the *ds* with GDALGetSpatialRef() returns an empty 
pointer. I.e.:

julia> Gdal.GDALGetSpatialRef(ds.ptr)
Ptr{Nothing} @0x

However the CSR was well sored in some place because the ="lixo2.gmt" is 
correct (it has this)

# @VGMT1.0 @GLINESTRING
# @R-8.1/-8/37/37.5
# @Jp"+proj=longlat +datum=WGS84 +no_defs"
# @Jw"GEOGCS[\"unknown\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 
84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AXIS[\"Longitude\",EAST],AXIS[\"Latitude\",NORTH]]"
# FEATURE_DATA
>
-8 37.0
-8.1 37.5

But my trouble is that I want to fish the CRS from the ogr2ogr dataset (the ds2 
above) so that I can convert back from GDAL to GMT (which I already can) 
without having to save to a file in disk.

So basically my question is where is that CRS stored and how can I access it?

Thanks

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Computing a geo-transform with gdalwarp from a set of GCPs also rectifies the input images

[Joaquim Manuel Freire Luís]

>Since GDAL's code base is quite large, it is not easy to find the appropriate 
>location.

I have found that using Visual Studio Code is an unvaluable tool to navigate in 
large source codes.
To find a definition of a function one only have to right-click it and ask to 
go to its definition.

From: gdal-dev  On Behalf Of Bullinger, 
Sebastian
Sent: Thursday, March 25, 2021 5:31 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Computing a geo-transform with gdalwarp from a set of 
GCPs also rectifies the input images

Hi,


@Andrew

> Have you noticed whether the output image has no-data pixels at the
> edges, or crops the original ? I would expect it to do a little of each.

The output image has no-data values - it does not crop the image - which is 
inline with the description by Even (see below).


@Even

> When creating an output file from scatch (either it doesn't exist, or 
> -overwrite is used),
> gdalwarp will always produce a "north-up" image in the target CRS.
> ...
> How gdalwarp rectifies depends on content of the source dataset (GCP, 
> geolocation arrays, RPCs),
> user switches and default behaviours. For a source dataset with GCPs, if you 
> have < 6 GCPs,
> a linear fit will be used by default. For >= 6 GCPs, a 2nd order polynomial 
> fit will be used.

Thank you for clarifying this - this explains the results I'm observing.

Is it possible access the transformation used to rectify the images during the 
gdalwarp call?
At the moment, I feel that gdalwarp acts (w.r.t. the rectification) like a 
black box.
Maybe it would be reasonable to (optionally) provide some information about the 
rectification process?

If it is not possible to get this information, could you point out the code 
snippet that performs the rectification step?
Since GDAL's code base is quite large, it is not easy to find the appropriate 
location.

Thank you for your help - and sorry for the noise.


Best regards,
Sebastian



--
Dr. Sebastian Bullinger
Department Object Recognition
Fraunhofer Institute of
Optronics, Sytem Technologies and Image Exploitation IOSB
Gutleuthausstr. 1, 76275 Ettlingen, Germany
Phone +49 7243 992-197
sebastian.bullin...@iosb.fraunhofer.de
www.iosb.fraunhofer.de


From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Thursday, March 25, 2021 5:08 PM
To: Bullinger, Sebastian; 
gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Computing a geo-transform with gdalwarp from a set of 
GCPs also rectifies the input images


Hi,

When creating an output file from scatch (either it doesn't exist, or 
-overwrite is used), gdalwarp will always produce a "north-up" image in the 
target CRS. This is by design of the utility. If you just want to subset, 
preserving the original orientation, use gdal_translate. In update mode of an 
existing target dataset however, gdalwarp will use the georeferencing attached 
to the target (so potentially not north-up).

How gdalwarp rectifies depends on content of the source dataset (GCP, 
geolocation arrays, RPCs), user switches and default behaviours. For a source 
dataset with GCPs, if you have < 6 GCPs, a linear fit will be used by default. 
For >= 6 GCPs, a 2nd order polynomial fit will be used. You may also use the 
-tps switch to ask for thin plate splines. The -to switch can also be used for 
finer control: see link pointed by 
https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-to

Even
Le 23/03/2021 à 18:47, Bullinger, Sebastian a écrit :
Dear gdal community,

I'm currently working with a set of satellite images that are geo-registered 
with a set of GCPs. To compute a geo-transform from the GCPs, I've been using 
gdalwarp with:

gdalwarp -of GTiff path/to/original/file path/to/warped/file

While "gdalwarp" correctly computes a transformation from the GCPs, at the same 
it also performs some kind of rectification / north-up image transformation. 
I'm not sure about the applied operation.

Presumably, the reason for this is that the original GCPs reflect a 
transformation with skew factors.
See the following transformations of the original and the warped image.

>>> import gdal
>>> dataset = gdal.Open("path/to/original/file")
>>> print(gdal.GCPsToGeoTransform(dataset.GetGCPs()))
(-58.57294039342205, -3.991598267026281e-06, 0.0, -34.451175177186684, 
-3.6492767328575985e-07, 3.1987810722132996e-06)

>>> import gdal
>>> dataset = gdal.Open("path/to/warped/file")
>>> print(dataset.GetGeoTransform())
(-58.577917916461026, 3.435846284510554e-06, 0.0, -34.44693359348493, 0.0, 
-3.435846284510554e-06)

The "rectification" result is very convenient, since it allows to use the 
images with an existing satellite image segmentation pipeline (which tiles the 

Re: [gdal-dev] Is it possible to switch warnings off?

[Joaquim Manuel Freire Luís]

Thanks Even e Mateusz

It is the same gdal lib in both cases. The only other one I have is sheltered 
in OSCeo4W.
And I had found where the messages are coming from but it's weird that they are 
printed in one case and not the other. I guess some internal setting that 
doesn't get set when called via Julia.

I'll explore the CPLPushErrorHandler()

Joaquim

From: Even Rouault 
Sent: Sunday, March 7, 2021 10:15 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Is it possible to switch warnings off?


Joaquim,

I suspect you are not testing with the same GDAL version with your gdalinfo 
shell invokation or within julia.

With the C API, you can shut down warnings and errors with

CPLPushErrorHandler(CPLQuietErrorHandler);

...

CPLPopErrorHandler();

You can install a custom error handler that filters only some category of 
events. See

https://gdal.org/api/cpl.html?highlight=cplpusherrorhandler#_CPPv419CPLPushErrorHandler15CPLErrorHandler

Even
Le 07/03/2021 à 21:42, Joaquim Manuel Freire Luís a écrit :
Hi,

I have this strange case where some warnings come from don't know where.

>From a shell command (cmd but it doesn't matter) all fine

gdalinfo AQUA_MODIS.20020717T135006.L2.SST.nc
Driver: netCDF/Network Common Data Format
Files: AQUA_MODIS.20020717T135006.L2.SST.nc
Size is 512, 512
Metadata:
  
/navigation_data/NC_GLOBAL#gringpointlatitude={28.923635,25.633446,42.81229,46.942131}
...


However, the same but this time called from Julia that wraps calls to
  options = GDALInfoOptionsNew(options, C_NULL)
  result = GDALInfo(ds.ptr, options)
  GDALInfoOptionsFree(options)

I get these warnings

julia> println(gdalinfo("AQUA_MODIS.20020717T135006.L2.SST.nc"))
Warning 1: The dataset has several variables that could be identified as vector 
fields, but not all share the same primary dimension. Consequently they will be 
ignored.
Warning 1: The dataset has several variables that could be identified as vector 
fields, but not all share the same primary dimension. Consequently they will be 
ignored.
Driver: netCDF/Network Common Data Format
Files: AQUA_MODIS.20020717T135006.L2.SST.nc
Size is 512, 512
Metadata:
  
/navigation_data/NC_GLOBAL#gringpointlatitude={28.923635,25.633446,42.81229,46.942131}
...

Also get several of these in other commands

Warning 1: dimension #1 (pixels_per_line) is not a Longitude/X dimension.
Warning 1: dimension #0 (number_of_lines) is not a Latitude/Y dimension.


Is there anyway to shut up this warnings, or warnings in general?


Thanks

Joaquim



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Is it possible to switch warnings off?

[Joaquim Manuel Freire Luís]

Hi,

I have this strange case where some warnings come from don't know where.

>From a shell command (cmd but it doesn't matter) all fine

gdalinfo AQUA_MODIS.20020717T135006.L2.SST.nc
Driver: netCDF/Network Common Data Format
Files: AQUA_MODIS.20020717T135006.L2.SST.nc
Size is 512, 512
Metadata:
  
/navigation_data/NC_GLOBAL#gringpointlatitude={28.923635,25.633446,42.81229,46.942131}
...


However, the same but this time called from Julia that wraps calls to
  options = GDALInfoOptionsNew(options, C_NULL)
  result = GDALInfo(ds.ptr, options)
  GDALInfoOptionsFree(options)

I get these warnings

julia> println(gdalinfo("AQUA_MODIS.20020717T135006.L2.SST.nc"))
Warning 1: The dataset has several variables that could be identified as vector 
fields, but not all share the same primary dimension. Consequently they will be 
ignored.
Warning 1: The dataset has several variables that could be identified as vector 
fields, but not all share the same primary dimension. Consequently they will be 
ignored.
Driver: netCDF/Network Common Data Format
Files: AQUA_MODIS.20020717T135006.L2.SST.nc
Size is 512, 512
Metadata:
  
/navigation_data/NC_GLOBAL#gringpointlatitude={28.923635,25.633446,42.81229,46.942131}
...

Also get several of these in other commands

Warning 1: dimension #1 (pixels_per_line) is not a Longitude/X dimension.
Warning 1: dimension #0 (number_of_lines) is not a Latitude/Y dimension.


Is there anyway to shut up this warnings, or warnings in general?


Thanks

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: remove and deprecate a few drivers

[Joaquim Manuel Freire Luís]

> Is the GSAG format really used ?

What can I say. Because it's a simple format I used to have colleagues that 
used it for I/O of their codes and not rarely it ended up in my hands. But 
can't honestly say it's much used. 


> Which one(s) are proposed by default as output of current Surfer versions ?

GS7BG. In fact GMT can read the simple variations (without breaklines) of this 
somewhat complicated format 


> Can't Surfer export to other formats already handled by GDAL ?

Yes, some. Nc and ArcInfo ascii at least



Le 03/03/2021 à 20:02, Joaquim Manuel Freire Luís a écrit :
> Even,
>
> May you reconsider the Golden Software drivers --- GS7BG, GSAG, GSBG --- ?
> GMT can read/write GSBG, but specially GS7BG, besides Surfer, GDAL is the 
> only one that I know that is able to read this format. Maybe not in this list 
> but there are still many people who use Golden software grid formats.
>
> Joaquim
>
> -Original Message-
> From: gdal-dev  On Behalf Of Even Rouault
> Sent: Wednesday, March 3, 2021 6:49 PM
> To: gdal-dev@lists.osgeo.org
> Subject: [gdal-dev] Motion: remove and deprecate a few drivers
>
> Hi,
>
> Following the discussions of past weeks, I motion to:
>
> - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, SEGY, 
> SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, IGNFHeightASCIIGrid, 
> NTv1. They have all been authored by myself and I'm not aware of them having 
> been much used or being still in use.
> Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver code, 
> doc and tests) have been moved to the 
> https://github.com/OSGeo/gdal-extra-drivers
>
> - deprecate the raster drivers DODS, FIT, GS7BG, GSAG, GSBG, JDEM, JPEG2000, 
> JPEGLS, MG4LIDAR, GMT, DOQ1, DOQ2, FUJIBAS, IDA, LAN, MFF, NDF, SDTS, SGI, 
> XPM, ZMAP and vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, 
> FME, GEOMEDIA, GTM, INGRES, MONGODB, REC, SDTDS, TIGER, WALK. They will now 
> be disabled at runtime by default, unless the 
> GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
> configuration option is set to YES, and will be removed in GDAL 3.5.
> Implemented in https://github.com/OSGeo/gdal/pull/3505
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: remove and deprecate a few drivers

[Joaquim Manuel Freire Luís]

Even,

May you reconsider the Golden Software drivers --- GS7BG, GSAG, GSBG --- ?
GMT can read/write GSBG, but specially GS7BG, besides Surfer, GDAL is the only 
one that I know that is able to read this format. Maybe not in this list but 
there are still many people who use Golden software grid formats.

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Even Rouault
Sent: Wednesday, March 3, 2021 6:49 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Motion: remove and deprecate a few drivers

Hi,

Following the discussions of past weeks, I motion to:

- remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, SEGY, SUA, 
XPlane and raster drivers BPG, E00GRID, EPSILON, IGNFHeightASCIIGrid, NTv1. 
They have all been authored by myself and I'm not aware of them having been 
much used or being still in use. 
Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver code, doc 
and tests) have been moved to the https://github.com/OSGeo/gdal-extra-drivers

- deprecate the raster drivers DODS, FIT, GS7BG, GSAG, GSBG, JDEM, JPEG2000, 
JPEGLS, MG4LIDAR, GMT, DOQ1, DOQ2, FUJIBAS, IDA, LAN, MFF, NDF, SDTS, SGI, XPM, 
ZMAP and vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
GEOMEDIA, GTM, INGRES, MONGODB, REC, SDTDS, TIGER, WALK. They will now be 
disabled at runtime by default, unless the 
GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
configuration option is set to YES, and will be removed in GDAL 3.5. 
Implemented in https://github.com/OSGeo/gdal/pull/3505

Starting with my +1

Even

--
http://www.spatialys.com

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Considering drivers removal ?

[Joaquim Manuel Freire Luís]

> - GMT is an active project and some GMT developers appear on this list as 
> well. Maybe some of them happend to read this and say if GMT ASCII vectors 
> are still important for GMT. Or otherwise I can ask from the GMT forum.


Right.

The GMT raster driver is from the times GNT used a 1-d array to represent 2-D 
grids in netCDF. That was abandoned some ~15 years ago for COARS compliant nc 
grids and is a good candidate for deprecation.

The " GMT ASCII vectors" format (written under contract with NIWA) is still 
very much used (under the hood) by the GMT library and should be kept alive 
until we finish the integration with the GDAL vector side.

Joaquim




-Original Message-
From: gdal-dev  On Behalf Of jratike80
Sent: Monday, January 11, 2021 6:56 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Considering drivers removal ?

Hi,

The joy of being a Windows user is that it is so easy to use old GDAL versions 
if the binaries still happen to be on some dusty backup disk. Even the FWTools 
including GDAL 1.7.0 from 2010 seemed to work fine and include quite a many 
later removed drivers.

A few comments about the driver list:

- There are indeed questions about SVG in gis.stackexchange every now and then.
- I used LAN a lot when FWTools was young and ERDAS wrote bad GeoTIFFs.
Things are probably changed since that. 
- GMT is an active project and some GMT developers appear on this list as well. 
Maybe some of them happend to read this and say if GMT ASCII vectors are still 
important for GMT. Or otherwise I can ask from the GMT forum.
- GPS Track Maker, as far as I know, is quite popular in Brazil. However, when 
I used the software I just used GPX format for data transfer. Are there any 
Brazilian GDAL user here to comment?

When it comes to Windows binaries, there is a very valuable archive in 
https://gisinternals.com/archive.php. It would be pity if it would get lost 
some day.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> It's not spring yet, but I'm in a mood lately of axing useless things, 
> and we probably have tons of candidate for that in GDAL, especially in 
> drivers.
> I was going to just axe the DB2 driver
> (https://github.com/OSGeo/gdal/pull/3366) but the issue is more general.
> 
> Any idea how we can know what is used and what isn't ? A "call-home" 
> functionality where we would track driver usage would only be 
> acceptable if people enable it and have network connectivity, so we 
> won't probably get lots of feedback. Having a spreadsheet with the 
> driver list and asking people to fill it would probably also receive 
> little feedback. So the idea I had was to do something like the 
> following in the Open() method of a candidate for
> removal:
> 
> GDALDataset* FooDriver::Open(  )
> {
>if( !Identify(poOpenInfo) )
>   return nullptr;
> 
>if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )
>{
>CPLError(CE_Failure, CPLE_AppDefined,
> "Driver FOO is considered for removal in GDAL 3.5. You are invited "
> "to convert any dataset in that format to another more common one ."
> "If you need this driver in future GDAL versions, create a ticket at "
> "https://github.com/OSGeo/gdal (look first for an existing one 
> first) to "
> "explain how critical it is for you (but the GDAL project may still "
> "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "
> "configuration option / environment variable to YES");
>return nullptr;
> }
> ...
> }
> 
> That is, when we detect a file to be handled by the driver, emit the 
> above error message and do not open the dataset, unless the user 
> defines the environment variable.
> Similarly in the Create()/CreateCopy() methods.
> If we ship this in 3.3, with a 3.5 milestone for removal, this would 
> offer a feedback period of one year / 2 feature versions.
> 
> Here's my own list of candidates for retirement (probably 
> over-conservative).
> Mostly based on gut feeling. None of them are particularly bad 
> citizens, but I have no indication that they are still used, which 
> doesn't mean they aren't.
> 
> * Raster side:
> BPG
> DB2Raster
> DOQ1
> DOQ2
> E00GRID
> Epsilon
> FujiBAS
> GS7BG
> GSAG
> IDA
> JDEM
> JPEG2000 (Jasper): JP2OpenJPEG is a better replacement JPEGLS LAN MFF 
> MG4Lidar ?
> NDF
> NTv1
> SDTS Raster
> SGI
> XPM
> ZMap
> 
> * Vector side:
> AERONAVFAA
> ESRI ArcObjects
> ARCGEN
> BNA
> Cloudant
> CouchDB
> DB2
> DODS
> FMEObjects Gateway
> Geomedia MDB
> GMT ASCII Vectors
> GTM
> HTF
> INGRES
> MongoDB (the old one, superseded by MongoDBv3) OpenAIR REC SDTS SUA 
> SVG TIGER WALK
> 
> 
> Anything you'd add / remove ?
> 
> What is not obvious is what would be the criterion for keeping a driver:
> 1,
> 10, 100 users asking for the driver to be kept ?
> If a GDAL developer contributing to the overall good of the project 
> needs the preservation of a driver to be able to justify its continued 
> involvement, 

Re: [gdal-dev] Sampling raster bands at irregular points

[Joaquim Manuel Freire Luís]

Another option is the GMT program grdtrack 
(https://docs.generic-mapping-tools.org/dev/grdtrack.html). It's pure C and 
extremely fast.

-Original Message-
From: gdal-dev  On Behalf Of Felix
Sent: Thursday, December 3, 2020 1:16 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Sampling raster bands at irregular points

Hello All,

I'm here for some suggestions on how to sample from a raster band at 
_non-regular_ points. Non-regular in this context means that the points have 
arbitrary coordinates and do not lie on a regular lattice/mesh like all pairs 
of integers would do.

In my application, there is an irregular set of points for which we require 
bathymetric data (i.e. topographical data/elevation). I started out by manually 
reading in the ETOPO1 dataset (for now, we might use
Earth2014 later) and then interpolating around each point sequentially. 
As we have up to hundred-tousands of points and doing the computation 
sequentially in Python/numpy, this is currently running for days (well, we 
canceled it at that point).

Ideally, I'd like to use something like the "gdal_grid" tool, where the 
interpolation algorithm can be configured and the heavy-lifting is done in C 
rather than in Python. But it only supports creating a new _regular_ grid. The 
inverse distance interpolation with cutoff radii would be ideal.

Does such a tool/such functionality exist in in GDAL or was my search 
rightfully fruitless? I mainly searched in the raster programs, the
(C++) API of GDALRasterBand and of course generally in the internet. 
Thank you for your suggestions, in advance!

Cheers and Stay Safe
Felix Divo

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

[Joaquim Manuel Freire Luís]

Yes, I know that and I also had crossed with that HDF error (nc and HDF libs 
must be in sync building) but that nc file clearly has its issues. Both Matlab 
and HDF-Explorer confirm that and even GDAL touches it. See

gdalinfo AROME_OPER_001_FC_SP_PT2_025_RH_2-HTGL_2020102000.nc
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute

Which is not true. The “Conventions” attribute it’s there but something is 
wrong with its string value (but not only “Conventions”, at least “long_name” 
suffers from the same).

From: Pedro Venâncio 
Sent: Tuesday, October 20, 2020 4:13 PM
To: Joaquim Manuel Freire Luís 
Cc: qgis-developer ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

Hi Joaquim Luís,

This is an IPMA NetCDF, it was working before the update.

And I think it is in fact a HDF5 library version problem:

> gdalinfo AROME_OPER_001_FC_SP_PT2_025_RH_2-HTGL_2020102000.nc

Warning 1: Recode from UTF-8 to CP_ACP failed with the error: "Invalid 
argument".
Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.10.4, library is 1.10.5
SUMMARY OF THE HDF5 CONFIGURATION
=

General Information:
---
   HDF5 Version: 1.10.5
  Configured on: 2020-10-19
  Configured by: Visual Studio 14 2015 Win64
Host system: Windows-10.0.19041
  Uname information: Windows
   Byte sex: little-endian
 Installation point: 
D:/src/osgeo4w64/src/hdf5/osgeo4w/install-x86_64

Compiling Options:
--
 Build Mode:
  Debugging Symbols:
Asserts:
  Profiling:
 Optimization Level:

Linking Options:

  Libraries:
  Statically Linked Executables: OFF
LDFLAGS: /machine:x64
 H5_LDFLAGS:
 AM_LDFLAGS:
Extra libraries:
   Archiver:
 Ranlib:

Languages:
--
  C: yes
 C Compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/x86_amd64/cl.exe 19.0.24215.1
   CPPFLAGS:
H5_CPPFLAGS:
AM_CPPFLAGS:
 CFLAGS:  /DWIN32 /D_WINDOWS /W3
  H5_CFLAGS:
  AM_CFLAGS:
   Shared C Library: YES
   Static C Library: YES

Fortran: OFF
   Fortran Compiler:
  Fortran Flags:
   H5 Fortran Flags:
   AM Fortran Flags:
 Shared Fortran Library: YES
 Static Fortran Library: YES

C++: ON
   C++ Compiler: C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/bin/x86_amd64/cl.exe 19.0.24215.1
  C++ Flags: /DWIN32 /D_WINDOWS /W3 /GR /EHsc
   H5 C++ Flags:
   AM C++ Flags:
 Shared C++ Library: YES
 Static C++ Library: YES

JAVA: OFF
   JAVA Compiler:

Features:
-
   Parallel HDF5: OFF
Parallel Filtered Dataset Writes:
  Large Parallel I/O:
  High-level library: ON
Threadsafety: ON
 Default API mapping: v110
  With deprecated public symbols: ON
  I/O filters (external):  DEFLATE DECODE
 MPE:
  Direct VFD:
 dmalloc:
  Packages w/ extra debug output:
 API Tracing: OFF
Using memory checker: OFF
 Memory allocation sanity checks: OFF
  Function Stack Tracing: OFF
   Strict File Format Checks: OFF
Optimization Instrumentation:
Bye...

Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>> escreveu no 
dia terça, 20/10/2020 à(s) 15:36:
But I do find something strange in that nc file. Mirone (Matlab independent nc 
loader) errors when trying to load it because of the  “Conventions” attribute 
and HDF-Explorer says it’s a “4-byte null-terminated ASCII s

Re: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

[Joaquim Manuel Freire Luís]

But I do find something strange in that nc file. Mirone (Matlab independent nc 
loader) errors when trying to load it because of the  “Conventions” attribute 
and HDF-Explorer says it’s a “4-byte null-terminated ASCII string” when in fact 
that attribute has 6-bytes
“CF-1.5”

From: Joaquim Manuel Freire Luís
Sent: Tuesday, October 20, 2020 3:00 PM
To: 'Pedro Venâncio' ; qgis-developer 
; gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

Pedro,

Probably a netcdf lib related issue. I have a very fresh GDAL build (from 
yesterday’s master) and can access that file. Either from GDAL or GMT, but my 
nc lib has not been updated for some time (which is not so bad as nc has had a 
couple of issues in recent past).

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Pedro Venâncio
Sent: Tuesday, October 20, 2020 1:58 PM
To: qgis-developer 
mailto:qgis-develo...@lists.osgeo.org>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

Hi all,

Sorry about the cross posting but today, after the update of OSGeo4W to 
qgis-dev 3.15.0-82, I get a QGIS crash both with qgis-dev, qgis-ltr-dev 
3.10.10-3 and qgis-rel-dev 3.14.16-3.

I've only looked at Desktop updates and so I cannot say what libs were updated 
at the same time.

The crash happens when I try to open some NetCDF file (for instance 
http://mf2.ipma.pt/downloads/?latest=arome.2m.relative_humidity=PT2 ) as 
raster file, as mesh layer or simply when I open a folder with a NetCDF file 
inside Browser.

This is something like this one: https://issues.qgis.org/issues/21162

As it only happens with QGIS "-dev" versions, I believe it can be related with 
GDAL 3.2.0dev, but I cannot say what version I had before this update, maybe 
from one week or two ago.

Can someone reproduce?

Another issue with QGIS "-dev" versions is related to GRASS. I get this error 
message on QGIS initialization, and then I cannot, for instance, create a new 
mapset with GRASS Plugin:


GRASS init error: Problem in GRASS initialization, GRASS provider and plugin 
will not work : Module built against version 8bcecc9a6 but trying to use 
version d8fbd49af. You need to rebuild GRASS GIS or untangle multiple 
installations.



I can open two different tickets, but I'm not certain about the right place to 
open them.



Thanks!



Best regards,

Pedro Venâncio
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.4 RC1 available

[Joaquim Manuel Freire Luís]

Well,

Mine also built correctly. It was on usage that the problem surfaced.

-Original Message-
From: Even Rouault  
Sent: Tuesday, October 20, 2020 3:08 PM
To: Joaquim Manuel Freire Luís 
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available

On mardi 20 octobre 2020 11:27:13 CEST Joaquim Manuel Freire Luís wrote:
> Even,
> 
> I don't think that was the case. I use a build system that resemble a 
> bit homebrew. All packages are built in their own directories and SATAY there.
> Then I have a batch that creates symlinks do a directory that is the 
> only in the computer path for my builds. So when I rebuild any package 
> it gets automatically updated in my machine. Yes I did rebuild PROJ 
> and GDAL from master as I always do and the problem arise but when I 
> reverted PROJ to a commit only 9 days older 
> (d1a0d95da549f7d32bcd8be408afe1fca62a6fb2), the problem disappeared.

I have no explanation for your issue but 
https://github.com/rouault/gdal/runs/1280973974?check_suite_focus=true
( https://github.com/rouault/gdal/blob/
424c570530bc9725cf7391d023ffbb72edf85ebb/.github/workflows/windows_build.yml ) 
is an example of a successful Windows build with both PROJ and GDAL masters.

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

[Joaquim Manuel Freire Luís]

Pedro,

Probably a netcdf lib related issue. I have a very fresh GDAL build (from 
yesterday’s master) and can access that file. Either from GDAL or GMT, but my 
nc lib has not been updated for some time (which is not so bad as nc has had a 
couple of issues in recent past).

From: gdal-dev  On Behalf Of Pedro Venâncio
Sent: Tuesday, October 20, 2020 1:58 PM
To: qgis-developer ; gdal-dev@lists.osgeo.org
Subject: [gdal-dev] QGIS from OSGeo4W crashes with latest update on NetCDF

Hi all,

Sorry about the cross posting but today, after the update of OSGeo4W to 
qgis-dev 3.15.0-82, I get a QGIS crash both with qgis-dev, qgis-ltr-dev 
3.10.10-3 and qgis-rel-dev 3.14.16-3.

I've only looked at Desktop updates and so I cannot say what libs were updated 
at the same time.

The crash happens when I try to open some NetCDF file (for instance 
http://mf2.ipma.pt/downloads/?latest=arome.2m.relative_humidity=PT2 ) as 
raster file, as mesh layer or simply when I open a folder with a NetCDF file 
inside Browser.

This is something like this one: https://issues.qgis.org/issues/21162

As it only happens with QGIS "-dev" versions, I believe it can be related with 
GDAL 3.2.0dev, but I cannot say what version I had before this update, maybe 
from one week or two ago.

Can someone reproduce?

Another issue with QGIS "-dev" versions is related to GRASS. I get this error 
message on QGIS initialization, and then I cannot, for instance, create a new 
mapset with GRASS Plugin:


GRASS init error: Problem in GRASS initialization, GRASS provider and plugin 
will not work : Module built against version 8bcecc9a6 but trying to use 
version d8fbd49af. You need to rebuild GRASS GIS or untangle multiple 
installations.



I can open two different tickets, but I'm not certain about the right place to 
open them.



Thanks!



Best regards,

Pedro Venâncio
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.4 RC1 available

[Joaquim Manuel Freire Luís]

Even,

I don't think that was the case. I use a build system that resemble a bit 
homebrew. All packages are built in their own directories and SATAY there. Then 
I have a batch that creates symlinks do a directory that is the only in the 
computer path for my builds. So when I rebuild any package it gets 
automatically updated in my machine. Yes I did rebuild PROJ and GDAL from 
master as I always do and the problem arise but when I reverted PROJ to a 
commit only 9 days older (d1a0d95da549f7d32bcd8be408afe1fca62a6fb2), the 
problem disappeared.

-Original Message-
From: Even Rouault  
Sent: Tuesday, October 20, 2020 10:01 AM
To: Joaquim Manuel Freire Luís 
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available

Joaquim,

Yes GDAL 3.1.4 makes use of the new function proj_crs_get_datum_ensemble() of 
PROJ master (tested by checking PROJ version number to be >= 7.2 since this is 
queued for the PROJ 7.2 release in a few days). So I suspect you might build 
GDAL against the header of a recent PROJ master, but at runtime use an older 
version of the .dll that has not the symbol

Even

> Reverting PROJ to
> 
> d1a0d95da549f7d32bcd8be408afe1fca62a6fb2
> (* Database query: add
> AuthorityFactory::ObjectType::DYNAMIC_GEODETIC_REFERENCE_FRAME and 
> DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work)
 
> Solved the issue.
> 
> -Original Message-
> From: gdal-dev  On Behalf Of Joaquim 
> Manuel Freire Luís
 Sent: Monday, October 19, 2020 11:04 PM
> To: Even Rouault ; 
> gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available
> 
> Even,
> 
> I'm puzzled with this but after updating and building GDAL+PROJ today
> (master) one of my MEX dlls that depend on GDAL and PROJ started to 
> error with
 
> Invalid MEX-file
> 'C:\progs_cygw\GMTdev\gmt5\compileds\gmt6\VC14_64\bin\gmtmex.mexw64': 
> The specified procedure could not be found.
 
> I managed to trace it to this likely source provided by 
> DependencyWalker. I don't get it  because it seems to indicate that 
> "proj_crs_get_datum_ensemble" is not exported but that is not the 
> case. Any new use of that function?
 
> Joaquim
> 
> -Original Message-
> From: gdal-dev  On Behalf Of Even 
> Rouault
> Sent: Monday, October 19, 2020 3:31 PM
> To: gdal-dev@lists.osgeo.org
> Subject: [gdal-dev] GDAL 3.1.4 RC1 available
> 
> Hi,
> 
> So that we can focus on 3.2.0 and onwards, I have prepared a GDAL/OGR 
> 3.1.4 release candidate, which should be the final one in the 3.1 series.
 
> Pick up an archive among the following ones (by ascending size):
> 
>   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
>   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
>   https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip
> 
> A snapshot of the gdalautotest suite is also available :
> 
>   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
>   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip
> 
> GDAL-GRASS plugin:
> 
>   https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz
> 
> The NEWS file is here :
> 
>   https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS
> 
> I'll call for a vote promoting it to final soon if no serious problems 
> are reported before.
 
> Best regards,
> 
> Even
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com 
> ___
 gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Spatialys - Geospatial professional services http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.4 RC1 available

[Joaquim Manuel Freire Luís]

Reverting PROJ to 

d1a0d95da549f7d32bcd8be408afe1fca62a6fb2 
(* Database query: add 
AuthorityFactory::ObjectType::DYNAMIC_GEODETIC_REFERENCE_FRAME and 
DYNAMIC_VERTICAL_REFERENCE_FRAME, and make corresponding C API work)

Solved the issue.

-Original Message-
From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Monday, October 19, 2020 11:04 PM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL 3.1.4 RC1 available

Even,

I'm puzzled with this but after updating and building GDAL+PROJ today (master) 
one of my MEX dlls that depend on GDAL and PROJ started to error with

Invalid MEX-file 
'C:\progs_cygw\GMTdev\gmt5\compileds\gmt6\VC14_64\bin\gmtmex.mexw64': The 
specified procedure could not be found.

I managed to trace it to this likely source provided by DependencyWalker. I 
don't get it  because it seems to indicate that "proj_crs_get_datum_ensemble" 
is not exported but that is not the case. Any new use of that function?

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Even Rouault
Sent: Monday, October 19, 2020 3:31 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] GDAL 3.1.4 RC1 available

Hi,

So that we can focus on 3.2.0 and onwards, I have prepared a GDAL/OGR 3.1.4 
release candidate, which should be the final one in the 3.1 series.

Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
  https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
  https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip

A snapshot of the gdalautotest suite is also available :

  https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
  https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip

GDAL-GRASS plugin:

  https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz

The NEWS file is here :

  https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS

I'll call for a vote promoting it to final soon if no serious problems are 
reported before.

Best regards,

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.4 RC1 available

[Joaquim Manuel Freire Luís]

Even,

I'm puzzled with this but after updating and building GDAL+PROJ today (master) 
one of my MEX dlls that depend on GDAL and PROJ started to error with

Invalid MEX-file 
'C:\progs_cygw\GMTdev\gmt5\compileds\gmt6\VC14_64\bin\gmtmex.mexw64': The 
specified procedure could not be found.

I managed to trace it to this likely source provided by DependencyWalker. I 
don't get it  because it seems to indicate that "proj_crs_get_datum_ensemble" 
is not exported but that is not the case. Any new use of that function?

Joaquim

-Original Message-
From: gdal-dev  On Behalf Of Even Rouault
Sent: Monday, October 19, 2020 3:31 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] GDAL 3.1.4 RC1 available

Hi,

So that we can focus on 3.2.0 and onwards, I have prepared a GDAL/OGR 3.1.4 
release candidate, which should be the final one in the 3.1 series.

Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
  https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
  https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip

A snapshot of the gdalautotest suite is also available :

  https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
  https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip

GDAL-GRASS plugin:

  https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz

The NEWS file is here :

  https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS

I'll call for a vote promoting it to final soon if no serious problems are 
reported before.

Best regards,

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com 
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.2 soon to fix issue with GeoTIFF driver / PROJ [was Re: A crash with 3..1.1]

[Joaquim Manuel Freire Luís]

Thanks Even,

It took quite a bit of work to trick MacOS and Cmake to use a custom GDAL build 
in the GMT build but now things seem to run smooth again.

Joaquim

From: Even Rouault 
Sent: Saturday, July 4, 2020 5:30 PM
To: gdal-dev@lists.osgeo.org
Cc: Joaquim Manuel Freire Luís ; Paul Wessel 
Subject: GDAL 3.1.2 soon to fix issue with GeoTIFF driver / PROJ [was Re: 
[gdal-dev] A crash with 3..1.1]


Hi,



I strongly believe that this issue was also reproduced with PostgisRaster in

https://github.com/OSGeo/gdal/issues/2744. The key to reproduce it is a call to 
OSRCleanup() before using the GeoTIFF driver.



I've now a fix for #2744 queued in https://github.com/OSGeo/gdal/pull/2746, and 
I believe it should fix the GMT issue (I would appreciate confirmation of that)



Due to the issue affecting several downstream programs, I intend to release a 
3.1.2 release next tuesday, unless there are other critical issues found in 
between that need to be adressed



Even





On mercredi 1 juillet 2020 08:25:21 CEST Joaquim Manuel Freire Luís wrote:

> Hi Even,

>

> My colleagues from Mac are getting crashes when using latest 3.1.1 GDAL from

> GMT.

>

>

> the crash occurs for example when running a command such as (the @ is a

> recognized flag to GMT that downloads that particular file)

>

> gmt grdimage -JM6.5i -R0/360/-45/45 -Bag @earth_day_01d > t.ps

>

> You can see the stack trace at

>

> https://github.com/GenericMappingTools/gmt/issues/3568

>

> The crash occurs at line

>

> https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalread.c#L3

> 39

>

> which is accessed right after reading the file

>

> https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalread.c#L3

> 4

>

>

> A strange thing though is that it works fine for me on Windows with a GDAL

> build from master (2 days old).

>

> Any idea on what might be causing this?

>

> Thanks

>

> Joaquim



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] A crash with 3..1.1

[Joaquim Manuel Freire Luís]

And sorry again for not reporting everything in same post. It happens also in 
the CI tests

https://github.com/GenericMappingTools/gmt/issues/3566


and just got one more info

GDAL 3.1.0 fine, 3.1.1 crash
Either macports or homebrew
Seems to involve Geotiff.


From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Wednesday, July 1, 2020 10:28 AM
To: Even Rouault ; gdal-dev@lists.osgeo.org
Cc: Paul Wessel 
Subject: Re: [gdal-dev] A crash with 3..1.1

No, not build directly from source. I believe it's a GDAL supplied by Macports 
but Paul is at Hawaii and sleeping now, so can't confirm. And I forgot to 
mention in previous post. No problem when using GDAL 3.1.0 (same origin)

From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Wednesday, July 1, 2020 10:22 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Cc: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>; Paul 
Wessel mailto:pwes...@hawaii.edu>>
Subject: Re: [gdal-dev] A crash with 3..1.1


Hi,



> Any idea on what might be causing this?



As it seems this involves building GDAL from source, and possibly from the same 
tree, perhaps a missing "make clean" before different build attempts



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] A crash with 3..1.1

[Joaquim Manuel Freire Luís]

No, not build directly from source. I believe it's a GDAL supplied by Macports 
but Paul is at Hawaii and sleeping now, so can't confirm. And I forgot to 
mention in previous post. No problem when using GDAL 3.1.0 (same origin)

From: Even Rouault 
Sent: Wednesday, July 1, 2020 10:22 AM
To: gdal-dev@lists.osgeo.org
Cc: Joaquim Manuel Freire Luís ; Paul Wessel 
Subject: Re: [gdal-dev] A crash with 3..1.1


Hi,



> Any idea on what might be causing this?



As it seems this involves building GDAL from source, and possibly from the same 
tree, perhaps a missing "make clean" before different build attempts



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] A crash with 3..1.1

[Joaquim Manuel Freire Luís]

Hi Even,

My colleagues from Mac are getting crashes when using latest 3.1.1 GDAL from 
GMT.


the crash occurs for example when running a command such as (the @ is a 
recognized flag to GMT that downloads that particular file)

gmt grdimage -JM6.5i -R0/360/-45/45 -Bag @earth_day_01d > t.ps

You can see the stack trace at

https://github.com/GenericMappingTools/gmt/issues/3568

The crash occurs at line

https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalread.c#L339

which is accessed right after reading the file

https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalread.c#L34


A strange thing though is that it works fine for me on Windows with a GDAL 
build from master (2 days old).

Any idea on what might be causing this?

Thanks

Joaquim

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with latest pdfium

[Joaquim Manuel Freire Luís]

Tried with another python (miniconda this time) and ... some other error
(very picky these pythons)


A subdirectory or file out already exists.
A subdirectory or file Release already exists.
1 file(s) copied.
Done. Made 139 targets from 82 files in 4709ms
ninja: Entering directory `out\Release'
[5/1097] COPY ../../third_party/icu/common/icudtl.dat icudtl.dat
FAILED: icudtl.dat
C:/programs/compa_libs/PDFium/depot_tools/bootstrap-3_8_0_chromium_8_bin/python/bin/python.exe
 ../../build/toolchain/win/tool_wrapper.py recursive-mirror 
../../third_party/icu/common/icudtl.dat icudtl.dat
Traceback (most recent call last):
  File "../../build/toolchain/win/tool_wrapper.py", line 51, in 
import win32file# pylint: disable=import-error
ImportError: No module named win32file
[18/1097] CXX obj/third_party/googletest/gmock/gmock-spec-builders.obj
ninja: build stopped: subcommand failed.

From: Joaquim Manuel Freire Luís 
Sent: Monday, June 29, 2020 3:43 PM
To: Joaquim Manuel Freire Luís ; Even Rouault 

Cc: gdal-dev@lists.osgeo.org; William Kyngesburye 
Subject: RE: [gdal-dev] Problems with latest pdfium

The python error coes from running this command

call gn.bat gen out\Release

apparently it doesn't find something and gives that incomprehensible error 
message.


From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Joaquim Manuel Freire Luís
Sent: Monday, June 29, 2020 1:50 PM
To: Even Rouault mailto:even.roua...@spatialys.com>>
Cc: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>; William 
Kyngesburye mailto:kyngch...@kyngchaos.com>>
Subject: Re: [gdal-dev] Problems with latest pdfium

Even, I would try it but I'm not being able to build pdfium. I get python 
errors such

 running 'vpython.bat pdfium/tools/clang/scripts/update.py' in 
'C:\programs\compa_libs\PDFium'
Downloading 
https://commondatastorage.googleapis.com/chromium-browser-clang/Win/clang-371202-8455294f-1.tgz
 .. Done.
Copying C:\Program Files (x86)/Microsoft Visual Studio/2017/Community\DIA 
SDK\bin\amd64\msdia140.dll to 
C:\programs\compa_libs\PDFium\pdfium\third_party\llvm-build\Release+Asserts\bin
Running hooks: 100% (16/16), done.
1 file(s) copied.
  File "C:\programs\WPy64-3.7.2\python-3.7.2.amd64\lib\site.py", line 177
file=sys.stderr)
^
SyntaxError: invalid syntax
ninja: error: loading 'build.ninja': The system cannot find the file specified.

ninja: Entering directory `out\Release'
A subdirectory or file C:\programs\compa_libs\PDFium\install already exists.
A subdirectory or file C:\programs\compa_libs\PDFium\install\include\pdfium 
already exists.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\public already exists.
...

The build continues but ends with (before It had several "already exists")

   18 file(s) copied.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\third_party\base\numerics 
already exists.
third_party\base\numerics\safe_conversions.h
third_party\base\numerics\safe_conversions_arm_impl.h
third_party\base\numerics\safe_conversions_impl.h
third_party\base\numerics\safe_math.h
third_party\base\numerics\safe_math_impl.h
5 file(s) copied.
A subdirectory or file C:\programs\compa_libs\PDFium\install\lib already exists.
The system cannot find the path specified.




From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Monday, June 29, 2020 1:18 PM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>
Cc: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>; William 
Kyngesburye mailto:kyngch...@kyngchaos.com>>
Subject: Re: [gdal-dev] Problems with latest pdfium


Joaquim,



> I tried to build with your pdfium.lib but got these linking errors.



It seems they are due to your GDAL build also linking against openjp2.lib, and 
pdfium.lib being linked against its internal copy of openjp2. I don't remember 
how I tested this. Perhaps this was with a GDAL build without openjp2. Or maybe 
when building the PDF driver as a plugin the error doesn't show up. I guess you 
could modify the pdfium build scripts to build against an external openjp2 lib.



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with latest pdfium

[Joaquim Manuel Freire Luís]

The python error coes from running this command

call gn.bat gen out\Release

apparently it doesn't find something and gives that incomprehensible error 
message.


From: gdal-dev  On Behalf Of Joaquim Manuel 
Freire Luís
Sent: Monday, June 29, 2020 1:50 PM
To: Even Rouault 
Cc: gdal-dev@lists.osgeo.org; William Kyngesburye 
Subject: Re: [gdal-dev] Problems with latest pdfium

Even, I would try it but I'm not being able to build pdfium. I get python 
errors such

 running 'vpython.bat pdfium/tools/clang/scripts/update.py' in 
'C:\programs\compa_libs\PDFium'
Downloading 
https://commondatastorage.googleapis.com/chromium-browser-clang/Win/clang-371202-8455294f-1.tgz
 .. Done.
Copying C:\Program Files (x86)/Microsoft Visual Studio/2017/Community\DIA 
SDK\bin\amd64\msdia140.dll to 
C:\programs\compa_libs\PDFium\pdfium\third_party\llvm-build\Release+Asserts\bin
Running hooks: 100% (16/16), done.
1 file(s) copied.
  File "C:\programs\WPy64-3.7.2\python-3.7.2.amd64\lib\site.py", line 177
file=sys.stderr)
^
SyntaxError: invalid syntax
ninja: error: loading 'build.ninja': The system cannot find the file specified.

ninja: Entering directory `out\Release'
A subdirectory or file C:\programs\compa_libs\PDFium\install already exists.
A subdirectory or file C:\programs\compa_libs\PDFium\install\include\pdfium 
already exists.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\public already exists.
...

The build continues but ends with (before It had several "already exists")

   18 file(s) copied.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\third_party\base\numerics 
already exists.
third_party\base\numerics\safe_conversions.h
third_party\base\numerics\safe_conversions_arm_impl.h
third_party\base\numerics\safe_conversions_impl.h
third_party\base\numerics\safe_math.h
third_party\base\numerics\safe_math_impl.h
5 file(s) copied.
A subdirectory or file C:\programs\compa_libs\PDFium\install\lib already exists.
The system cannot find the path specified.




From: Even Rouault 
mailto:even.roua...@spatialys.com>>
Sent: Monday, June 29, 2020 1:18 PM
To: Joaquim Manuel Freire Luís mailto:jl...@ualg.pt>>
Cc: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>; William 
Kyngesburye mailto:kyngch...@kyngchaos.com>>
Subject: Re: [gdal-dev] Problems with latest pdfium


Joaquim,



> I tried to build with your pdfium.lib but got these linking errors.



It seems they are due to your GDAL build also linking against openjp2.lib, and 
pdfium.lib being linked against its internal copy of openjp2. I don't remember 
how I tested this. Perhaps this was with a GDAL build without openjp2. Or maybe 
when building the PDF driver as a plugin the error doesn't show up. I guess you 
could modify the pdfium build scripts to build against an external openjp2 lib.



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with latest pdfium

[Joaquim Manuel Freire Luís]

Even, I would try it but I'm not being able to build pdfium. I get python 
errors such

 running 'vpython.bat pdfium/tools/clang/scripts/update.py' in 
'C:\programs\compa_libs\PDFium'
Downloading 
https://commondatastorage.googleapis.com/chromium-browser-clang/Win/clang-371202-8455294f-1.tgz
 .. Done.
Copying C:\Program Files (x86)/Microsoft Visual Studio/2017/Community\DIA 
SDK\bin\amd64\msdia140.dll to 
C:\programs\compa_libs\PDFium\pdfium\third_party\llvm-build\Release+Asserts\bin
Running hooks: 100% (16/16), done.
1 file(s) copied.
  File "C:\programs\WPy64-3.7.2\python-3.7.2.amd64\lib\site.py", line 177
file=sys.stderr)
^
SyntaxError: invalid syntax
ninja: error: loading 'build.ninja': The system cannot find the file specified.

ninja: Entering directory `out\Release'
A subdirectory or file C:\programs\compa_libs\PDFium\install already exists.
A subdirectory or file C:\programs\compa_libs\PDFium\install\include\pdfium 
already exists.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\public already exists.
...

The build continues but ends with (before It had several "already exists")

   18 file(s) copied.
A subdirectory or file 
C:\programs\compa_libs\PDFium\install\include\pdfium\third_party\base\numerics 
already exists.
third_party\base\numerics\safe_conversions.h
third_party\base\numerics\safe_conversions_arm_impl.h
third_party\base\numerics\safe_conversions_impl.h
third_party\base\numerics\safe_math.h
third_party\base\numerics\safe_math_impl.h
5 file(s) copied.
A subdirectory or file C:\programs\compa_libs\PDFium\install\lib already exists.
The system cannot find the path specified.




From: Even Rouault 
Sent: Monday, June 29, 2020 1:18 PM
To: Joaquim Manuel Freire Luís 
Cc: gdal-dev@lists.osgeo.org; William Kyngesburye 
Subject: Re: [gdal-dev] Problems with latest pdfium


Joaquim,



> I tried to build with your pdfium.lib but got these linking errors.



It seems they are due to your GDAL build also linking against openjp2.lib, and 
pdfium.lib being linked against its internal copy of openjp2. I don't remember 
how I tested this. Perhaps this was with a GDAL build without openjp2. Or maybe 
when building the PDF driver as a plugin the error doesn't show up. I guess you 
could modify the pdfium build scripts to build against an external openjp2 lib.



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with latest pdfium

[Joaquim Manuel Freire Luís]

Hi Even,

I tried to build with your pdfium.lib but got these linking errors.

Joaquim


pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_info_handler already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_warning_handler already 
defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_error_handler already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_create_decompress already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_default_decoder_parameters 
already defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_codec_set_threads already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_setup_decoder already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_read_header already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_decode already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_decode_area already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_get_decoded_tile already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_decoded_resolution_factor 
already defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_create_compress already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_set_default_encoder_parameters 
already defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_setup_encoder already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_start_compress already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_end_compress already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_end_decompress already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_write_tile already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_destroy_codec already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_get_cstr_info already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(openjpeg.obj) : error LNK2005: opj_destroy_cstr_info already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(image.obj) : error LNK2005: opj_image_destroy already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(image.obj) : error LNK2005: opj_image_tile_create already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_create already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_destroy already defined in 
openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_read_function already 
defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_seek_function already 
defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_write_function already 
defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_skip_function already 
defined in openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_user_data already defined 
in openjp2.lib(openjp2_w64.dll)
pdfium.lib(cio.obj) : error LNK2005: opj_stream_set_user_data_length already 
defined in openjp2.lib(openjp2_w64.dll)
   Creating library gdal_i.lib and object gdal_i.exp
gdal_w64.dll : fatal error LNK1169: one or more multiply defined symbols found


From: gdal-dev  On Behalf Of Even Rouault
Sent: Monday, June 29, 2020 10:34 AM
To: gdal-dev@lists.osgeo.org; William Kyngesburye 
Subject: Re: [gdal-dev] Problems with latest pdfium


William,



> I'm getting multiple errors trying to compile PDF support with pdfium.



See https://gdal.org/drivers/raster/pdf.html#pdfium



You need to build pdfium from the indicated forks.



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Issue with writen colortables

[Joaquim Manuel Freire Luís]

Ah, thanks. So the solution is to not call GDALSetRasterNoDataValue() unless we 
really want to set one color as transparent.

From: Even Rouault 
Sent: Thursday, March 26, 2020 11:24 PM
To: Joaquim Manuel Freire Luís 
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Issue with writen colortables


On jeudi 26 mars 2020 23:19:47 CET Joaquim Manuel Freire Luís wrote:

> Funny, I made it nodata = 1 and the zero moved to second place.



Fully determinstic behaviour: GDAL sets the alpha component of the entry in

the color table whose value is nodata to 0:



https://github.com/OSGeo/gdal/blob/master/gdal/frmts/png/pngdataset.cpp#L1820



--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Issue with writen colortables

[Joaquim Manuel Freire Luís]

Funny, I made it nodata = 1 and the zero moved to second place.

[cid:image002.jpg@01D603C5.0A070080]

From: Even Rouault 
Sent: Thursday, March 26, 2020 8:47 PM
To: gdal-dev@lists.osgeo.org
Cc: Joaquim Manuel Freire Luís 
Subject: Re: [gdal-dev] Issue with writen colortables


On jeudi 26 mars 2020 19:58:52 CET Joaquim Manuel Freire Luís wrote:

> images created with GMT but via GDAL.

> The .tif file looks right but if look at the .png (it needs lots of zoom) we

> can see that the top left pixel is missing. That happens, I think, because

> the transparency column has a first value of 0 whilst all the others are

> 1's. I checked this both with



You should probably not set the nodata value to 0. This will cause the alpha 
component for entry 0 of the color table to be set to 0 when writing PNG



Even





--

Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Issue with writen colortables

[Joaquim Manuel Freire Luís]

Attached are two tinny indexed images created with GMT but via GDAL.
The .tif file looks right but if look at the .png (it needs lots of zoom) we 
can see that the top left pixel is missing. That happens, I think, because the 
transparency column has a first value of 0 whilst all the others are 1's. I 
checked this both with GDAL and Matlab.

The code that writes it is
https://github.com/GenericMappingTools/gmt/blob/master/src/gmt_gdalwrite.c#L343
where .c4 is well set to 255. However when it lands on the file, the first was 
converted to 0.

Again, I'm doing this the Julia bindings so have no C code to provide a MWE.


[cid:image003.jpg@01D603A8.F88800A0]

Thanks

Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev