Re: [gdal-dev] Prevent GDAL reads for .aux or any other s3 objects that do not exist

[Vincent Sarago]

Hi Darren

You can do this by setting `GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR` or by 
narrowing the allowed extension with "CPL_VSIL_CURL_ALLOWED_EXTENSIONS=.tif"

Kyle is working on some docs that explains those env in TiTiler:
- 
https://github.com/developmentseed/titiler/blob/0a5288de30845865256a0124ed233f918812aa78/docs/concepts/performance_tuning.md#gdal_disable_readdir_on_open
 

- 
https://github.com/developmentseed/titiler/blob/0a5288de30845865256a0124ed233f918812aa78/docs/concepts/performance_tuning.md#cpl_vsil_curl_allowed_extensions
 


Vincent

> On Mar 3, 2021, at 6:56 PM, Darren Weber  
> wrote:
> 
> In https://github.com/mapbox/rasterio/issues/2119#issuecomment-790024225 
>  I've 
> noted how s3-COG reads can use retries to handle s3 rate throttling (503) by 
> enabling the `GDAL_HTTP_MAX_RETRY`.  Our dataset on s3 only contains *.tif 
> files and we need to prevent GDAL from issuing any GET/HEAD requests to try 
> to read any other files.  Is there an env-var for this?
> 
> The `GDAL_DISABLE_READDIR_ON_OPEN` is `False` so that GDAL can read the s3 
> prefix to list objects in one GET request.  From that read, it should have 
> already determined that there are only *.tif files and no *.aux* files 
> available.  When it gets a 503 rate throttle response, however, it seems to 
> auto-try to read some supplementary files, e.g. one log contains messages 
> that indicate GDAL is trying to read an .aux file that does not exist and we 
> want to prevent GDAL from issuing any GET or HEAD requests for anything other 
> than *.tif files (objects).
> 
> [WARNING] 2021-03-03T19:37:40.312Z CPLE_AppDefined in HTTP error code: 503 - 
> https://a-bucket.s3.amazonaws.com/geotiff.aux 
> . Retrying again in 0.5 secs
> [WARNING] 2021-03-03T19:37:40.795Z CPLE_AppDefined in HTTP error code: 503 - 
> https://a-bucket.s3.amazonaws.com/geotiff.aux 
> . Retrying again in 1.0 secs
> [WARNING] 2021-03-03T19:37:41.796Z CPLE_AppDefined in HTTP error code: 503 - 
> https://a-bucket.s3.amazonaws.com/geotiff.aux 
> . Retrying again in 2.2 secs
> [WARNING] 2021-03-03T19:37:44.290Z CPLE_AppDefined in HTTP response code on 
> https://a-bucket.s3.amazonaws.com/geotiff.aux 
> : 503
> 2021-03-03 19:37:44,155 | INFO | extract_raster_points:1036 | 
> s3://a-bucket/geotiff.tif extract cells (1)...
> 2021-03-03 19:37:44,347 | INFO | extract_raster_points:1050 | 
> s3://a-bucket/geotiff.tif extract cells (1) done
> That log suggests that there is a huge performance hit to retry reading an 
> .aux file that does not exist and GDAL should not even try to issue any kind 
> of request for it (i.e. we want to prevent it).
> 
> When running some unit tests with debug curl details available (but no 
> ability to create 503 responses), it appears that GDAL finds just the file 
> required and reads only partial reads from that file, e.g. this is a sample 
> of GET requests to read from one .tif s3-COG:
> 
> $ grep 'GET' tmp.log
> > GET /?delimiter=%2F=unit_tests%2Fgis%2F HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> > GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> 
> TIA, Darren
> 
> 
> -- 
> Darren Weber, PhD
> Senior Software Engineer
> Jupiter Intelligence
> 
> 
> "Predicting risk in a changing climate"
> ___
> 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] Motion: remove and deprecate a few drivers

[Frank Warmerdam]

On Wed, Mar 3, 2021 at 6:55 PM Even Rouault 
wrote:

> Frank,
>
> Even,
>
> I'm -1 on this motion as it stands.  There are a quite a few formats that
> I think we ought to continue to support for archival purposes
> indefinitely including FIT, JDEM, GMT, DOQ1/2, LAN, MFF, NDF, SDTS, SGI,
> XPM, and TIGER.  I am prepared to be listed as supporting maintainer for
> these drivers.
>
> Those formats were aimed for the runtime deprecation mechanism. The idea
> was to get ~ 1 year feedback period to see if people really need that
> nowadays, which I strongly doubt about. There are Docker images of older
> GDAL versions available for people that would still need to access such
> archives. I believe I tried to make previously the point that the issue
> wasn't the individual maintenance of those formats, but the weight they had
> to the whole for little benefit to the majority of users & developers.
>
> Are you OK at least with the removal of the drivers I mentioned in the
> first bullet of the motion ? (the ones of
> https://github.com/OSGeo/gdal/pull/3373). I'm not willing to support them
> any longer (and I'm not asking anyone to step up for that!)
> Even
>
> -- http://www.spatialys.com
>
> Even,

I'm ok with the removal list.  I do not really agree with the deprecating
the formats I listed.  I feel like the deprecate and wait for useful
feedback is more appropriate to formats that are hard to support now (like
those depending on external libraries) and that the main kind of feedback
to be sought would be someone willing to be responsible for them.

Best regards,
Frank




-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Prevent GDAL reads for .aux or any other s3 objects that do not exist

[Darren Weber]

In https://github.com/mapbox/rasterio/issues/2119#issuecomment-790024225
I've noted how s3-COG reads can use retries to handle s3 rate throttling
(503) by enabling the `GDAL_HTTP_MAX_RETRY`.  Our dataset on s3 only
contains *.tif files and we need to prevent GDAL from issuing any GET/HEAD
requests to try to read any other files.  Is there an env-var for this?

The `GDAL_DISABLE_READDIR_ON_OPEN` is `False` so that GDAL can read the s3
prefix to list objects in one GET request.  From that read, it should have
already determined that there are only *.tif files and no *.aux* files
available.  When it gets a 503 rate throttle response, however, it seems to
auto-try to read some supplementary files, e.g. one log contains messages
that indicate GDAL is trying to read an .aux file that does not exist and
we want to prevent GDAL from issuing any GET or HEAD requests for anything
other than *.tif files (objects).

[WARNING] 2021-03-03T19:37:40.312Z CPLE_AppDefined in HTTP error code:
503 - https://a-bucket.s3.amazonaws.com/geotiff.aux. Retrying again in
0.5 secs
[WARNING] 2021-03-03T19:37:40.795Z CPLE_AppDefined in HTTP error code:
503 - https://a-bucket.s3.amazonaws.com/geotiff.aux. Retrying again in
1.0 secs
[WARNING] 2021-03-03T19:37:41.796Z CPLE_AppDefined in HTTP error code:
503 - https://a-bucket.s3.amazonaws.com/geotiff.aux. Retrying again in
2.2 secs
[WARNING] 2021-03-03T19:37:44.290Z CPLE_AppDefined in HTTP response
code on https://a-bucket.s3.amazonaws.com/geotiff.aux: 503
2021-03-03 19:37:44,155 | INFO | extract_raster_points:1036 |
s3://a-bucket/geotiff.tif extract cells (1)...
2021-03-03 19:37:44,347 | INFO | extract_raster_points:1050 |
s3://a-bucket/geotiff.tif extract cells (1) done

That log suggests that there is a huge performance hit to retry reading an
.aux file that does not exist and GDAL should not even try to issue any
kind of request for it (i.e. we want to prevent it).

When running some unit tests with debug curl details available (but no
ability to create 503 responses), it appears that GDAL finds just the file
required and reads only partial reads from that file, e.g. this is a sample
of GET requests to read from one .tif s3-COG:

$ grep 'GET' tmp.log
> GET /?delimiter=%2F=unit_tests%2Fgis%2F HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1
> GET /unit_tests/gis/cea_blocks.tif HTTP/1.1

TIA, Darren


-- 
Darren Weber, PhD
Senior Software Engineer
Jupiter Intelligence


*"Predicting risk in a changing climate"*
___
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

[Even Rouault]

Frank,

Even,

I'm -1 on this motion as it stands.  There are a quite a few formats 
that I think we ought to continue to support for archival purposes 
indefinitely including FIT, JDEM, GMT, DOQ1/2, LAN, MFF, NDF, SDTS, 
SGI, XPM, and TIGER.  I am prepared to be listed as supporting 
maintainer for these drivers.


Those formats were aimed for the runtime deprecation mechanism. The idea 
was to get ~ 1 year feedback period to see if people really need that 
nowadays, which I strongly doubt about. There are Docker images of older 
GDAL versions available for people that would still need to access such 
archives. I believe I tried to make previously the point that the issue 
wasn't the individual maintenance of those formats, but the weight they 
had to the whole for little benefit to the majority of users & developers.


Are you OK at least with the removal of the drivers I mentioned in the 
first bullet of the motion ? (the ones of 
https://github.com/OSGeo/gdal/pull/3373). I'm not willing to support 
them any longer (and I'm not asking anyone to step up for that!)


Even

--
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

[Frank Warmerdam]

Even,

I'm -1 on this motion as it stands.  There are a quite a few formats that I
think we ought to continue to support for archival purposes
indefinitely including FIT, JDEM, GMT, DOQ1/2, LAN, MFF, NDF, SDTS, SGI,
XPM, and TIGER.  I am prepared to be listed as supporting maintainer for
these drivers.

Best regards,
Frank


On Wed, Mar 3, 2021 at 1:49 PM Even Rouault 
wrote:

> 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
>


-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JPEG 2000 Driver

[Greg Troxel]

Even Rouault  writes:

>> But, I'm worried about something different.  As a packager, I'd like to
>> know that unless I take the affirmative step of passing --enable-foo,
>> for any GPLish or proprietary foo, I won't end up with a gdal build
>> linked with foo just because it happened to be present in my build
>> environment.
>
> This should normally be the case. One of the few GPL dependencies is
> Poppler and must be explicitly enabled with --with-poppler . Similarly
> with MySQL. All proprietary dependencies need also to be explicitly
> enabled AFAIK (you actually need to point to their SDK).

Thanks.   I'll report if I find any otherwise.

> GEOS (LGPL) is enabled by default is found.

That seems entirely reasonable to me.


signature.asc
Description: PGP signature
___
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

[Paul Harwood]

I have to agree with the comments about Surfer and GS7. I was given a file
in that format only last week.

On Wed, 3 Mar 2021 at 20:40, Even Rouault 
wrote:

>  > Deprecate JPEG2000
> >
> > Is there something the openjpeg2 driver can't do that Jasper can?  Can
> > it be removed?
>
> I'm not aware of things that Jasper/JPEG2000 can do that JP2OpenJPEG
> can't. But there are definitely binary distributions still using it, and
> not yet JP2OpenJPEG. The deprecation hint for that driver is to use
> JP2OpenJPEG, so yes ultimately we'll remove it.
>
> 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] problem: gdal_grid, output ers raster file

[Ron Palmer]

Thanks Even for the follow up and description of the work-around, will 
try it right now.


Ron

On 4/03/2021 8:11 am, Even Rouault wrote:


Hi,

This is a "well known" behaviour of gdal_grid in which it writes 
raster with a bottom-left corner origin, whereas most other GDAL 
utilities use a top-left corner origin. The ERS driver doesn't support 
such convention. The workaround you can use is to output gdal_grid as 
a TIFF (tmp.tif), then use "gdalwarp tmp.tif out.ers" to flip the 
origin to a top-left one.


Even

Le 03/03/2021 à 22:55, Ron Palmer a écrit :


Looks to me like the ERMapper ERS driver has a bug, using the bottom 
left corner to georef the raster, instead of top left. I can only use 
it if I use local coordinates, any negative northings are plotted 
towards the north. ERS is the main raster format I use.


I am happy to assist in sorting out the ERS format if the person 
behind it is willing to have a look at it.


Thanks,

Ron

On 17/02/2021 4:55 pm, Ron Palmer wrote:


I am having issues with outputting ers raster file from gdal_grid. I 
import a csv as shape, then grid it and output as ers. The Y coords 
are all negative as it is in fact a section I simply grid as a 2D 
raster. Although the shape file plots as I expect it, the ers is 
flipped upside-down, and hung at the lowest Y value. Please note, if 
I use GS7BG it works fine.


How do I get an ERS output that matches the shape file/data points?

I have created a simple example... however, I am new to GDAL, and 
this is my first post, so please let me know if there is anything 
else I should provide.


Thanks

Ron


These are the commands:

  711  ogr2ogr -f "ESRI Shapefile" xc_zc.shp new.csv -oo 
X_POSSIBLE_NAMES=xc -oo Y_POSSIBLE_NAMES=zc
  712  gdal_grid -zfield Value -a linear:radius=5 xc_zc.shp -of ERS 
xc_zc.ers


here is the content of the data

xc,zc,Value
1.25,-0.625,5
3.75,-0.625,5
6.25,-0.625,5
8.75,-0.625,5
11.25,-0.625,5
1.25,-1.938,4
3.75,-1.938,4
6.25,-1.938,4
8.75,-1.938,4
11.25,-1.938,4
1.25,-3.381,3
3.75,-3.381,3
6.25,-3.381,3
8.75,-3.381,3
11.25,-3.381,3
1.25,-4.969,2
3.75,-4.969,2
6.25,-4.969,2
8.75,-4.969,2
11.25,-4.969,2
1.25,-6.716,1
3.75,-6.716,1
6.25,-6.716,1
8.75,-6.716,1
11.25,-6.716,1

I have attached a jpg of my output (not sure whether the mailing 
list allows attachments...)




 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

*Ron Palmer*MSc MBA

Principal Geophysicist

0413 579 099 ron.pal...@pgcgroup.com.au

www.pgcgroup.com.au 

*/PGC Geophysics - We specialise in Electrical Surveys!/*


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

--
http://www.spatialys.com

--

*Ron Palmer*MSc MBA

Principal Geophysicist

0413 579 099  ron.pal...@pgcgroup.com.au

www.pgcgroup.com.au 

*/PGC Geophysics - We specialise in Electrical Surveys!/*



--
This email has been checked for viruses by AVG.
https://www.avg.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] problem: gdal_grid, output ers raster file

[Even Rouault]

Hi,

This is a "well known" behaviour of gdal_grid in which it writes raster 
with a bottom-left corner origin, whereas most other GDAL utilities use 
a top-left corner origin. The ERS driver doesn't support such 
convention. The workaround you can use is to output gdal_grid as a TIFF 
(tmp.tif), then use "gdalwarp tmp.tif out.ers" to flip the origin to a 
top-left one.


Even

Le 03/03/2021 à 22:55, Ron Palmer a écrit :


Looks to me like the ERMapper ERS driver has a bug, using the bottom 
left corner to georef the raster, instead of top left. I can only use 
it if I use local coordinates, any negative northings are plotted 
towards the north. ERS is the main raster format I use.


I am happy to assist in sorting out the ERS format if the person 
behind it is willing to have a look at it.


Thanks,

Ron

On 17/02/2021 4:55 pm, Ron Palmer wrote:


I am having issues with outputting ers raster file from gdal_grid. I 
import a csv as shape, then grid it and output as ers. The Y coords 
are all negative as it is in fact a section I simply grid as a 2D 
raster. Although the shape file plots as I expect it, the ers is 
flipped upside-down, and hung at the lowest Y value. Please note, if 
I use GS7BG it works fine.


How do I get an ERS output that matches the shape file/data points?

I have created a simple example... however, I am new to GDAL, and 
this is my first post, so please let me know if there is anything 
else I should provide.


Thanks

Ron


These are the commands:

  711  ogr2ogr -f "ESRI Shapefile" xc_zc.shp new.csv -oo 
X_POSSIBLE_NAMES=xc -oo Y_POSSIBLE_NAMES=zc
  712  gdal_grid -zfield Value -a linear:radius=5 xc_zc.shp -of ERS 
xc_zc.ers


here is the content of the data

xc,zc,Value
1.25,-0.625,5
3.75,-0.625,5
6.25,-0.625,5
8.75,-0.625,5
11.25,-0.625,5
1.25,-1.938,4
3.75,-1.938,4
6.25,-1.938,4
8.75,-1.938,4
11.25,-1.938,4
1.25,-3.381,3
3.75,-3.381,3
6.25,-3.381,3
8.75,-3.381,3
11.25,-3.381,3
1.25,-4.969,2
3.75,-4.969,2
6.25,-4.969,2
8.75,-4.969,2
11.25,-4.969,2
1.25,-6.716,1
3.75,-6.716,1
6.25,-6.716,1
8.75,-6.716,1
11.25,-6.716,1

I have attached a jpg of my output (not sure whether the mailing list 
allows attachments...)




 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

*Ron Palmer*MSc MBA

Principal Geophysicist

0413 579 099 ron.pal...@pgcgroup.com.au

www.pgcgroup.com.au 

*/PGC Geophysics - We specialise in Electrical Surveys!/*


___
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] problem: gdal_grid, output ers raster file

[Ron Palmer]

Looks to me like the ERMapper ERS driver has a bug, using the bottom 
left corner to georef the raster, instead of top left. I can only use it 
if I use local coordinates, any negative northings are plotted towards 
the north. ERS is the main raster format I use.


I am happy to assist in sorting out the ERS format if the person behind 
it is willing to have a look at it.


Thanks,

Ron

On 17/02/2021 4:55 pm, Ron Palmer wrote:


I am having issues with outputting ers raster file from gdal_grid. I 
import a csv as shape, then grid it and output as ers. The Y coords 
are all negative as it is in fact a section I simply grid as a 2D 
raster. Although the shape file plots as I expect it, the ers is 
flipped upside-down, and hung at the lowest Y value. Please note, if I 
use GS7BG it works fine.


How do I get an ERS output that matches the shape file/data points?

I have created a simple example... however, I am new to GDAL, and this 
is my first post, so please let me know if there is anything else I 
should provide.


Thanks

Ron


These are the commands:

  711  ogr2ogr -f "ESRI Shapefile" xc_zc.shp new.csv -oo 
X_POSSIBLE_NAMES=xc -oo Y_POSSIBLE_NAMES=zc
  712  gdal_grid -zfield Value -a linear:radius=5 xc_zc.shp -of ERS 
xc_zc.ers


here is the content of the data

xc,zc,Value
1.25,-0.625,5
3.75,-0.625,5
6.25,-0.625,5
8.75,-0.625,5
11.25,-0.625,5
1.25,-1.938,4
3.75,-1.938,4
6.25,-1.938,4
8.75,-1.938,4
11.25,-1.938,4
1.25,-3.381,3
3.75,-3.381,3
6.25,-3.381,3
8.75,-3.381,3
11.25,-3.381,3
1.25,-4.969,2
3.75,-4.969,2
6.25,-4.969,2
8.75,-4.969,2
11.25,-4.969,2
1.25,-6.716,1
3.75,-6.716,1
6.25,-6.716,1
8.75,-6.716,1
11.25,-6.716,1

I have attached a jpg of my output (not sure whether the mailing list 
allows attachments...)




 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

*Ron Palmer*MSc MBA

Principal Geophysicist

0413 579 099  ron.pal...@pgcgroup.com.au

www.pgcgroup.com.au 

*/PGC Geophysics - We specialise in Electrical Surveys!/*



--
This email has been checked for viruses by AVG.
https://www.avg.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JPEG 2000 Driver

[Frank Warmerdam]

Folks,

When Andrew first mentioned RFC 34 I skimmed it and was a bit surprised it
existed though perhaps it seemed a wee bit familiar.  Now that Even
mentions it was not ever implemented I see that *I* proposed it and
presumably did not actually follow up on implementing it or getting it
adopted.   It still seems like a vaguely good idea, but also apparently one
without a compelling need since it has not been followed up on.

However, it does not solve the build-time problem posed by Greg.  I think
the approach that inclusion of reciprocally licensed or proprietary drivers
requiring explicit inclusion at configure time is a reasonable approach to
avoid accidental license violations by packagers.

Best regards,
Frank



On Wed, Mar 3, 2021 at 3:31 PM Even Rouault 
wrote:

> Hi,
> > https://gdal.org/development/rfc/rfc34_license_policy.html
>
> As indicated in the top of the RFC, its status is "development" (draft),
> which here means stalled/non-adopted given that it was proposed long
> time ago. So there's no runtime mechanism to control license compatibility.
>
>
> > But, I'm worried about something different.  As a packager, I'd like to
> > know that unless I take the affirmative step of passing --enable-foo,
> > for any GPLish or proprietary foo, I won't end up with a gdal build
> > linked with foo just because it happened to be present in my build
> > environment.
>
> This should normally be the case. One of the few GPL dependencies is
> Poppler and must be explicitly enabled with --with-poppler . Similarly
> with MySQL. All proprietary dependencies need also to be explicitly
> enabled AFAIK (you actually need to point to their SDK).
>
> GEOS (LGPL) is enabled by default is found.
>
> Even
>
> --
>
> http://www.spatialys.com
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
---+--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
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

[Even Rouault]

> Deprecate JPEG2000


Is there something the openjpeg2 driver can't do that Jasper can?  Can 
it be removed?


I'm not aware of things that Jasper/JPEG2000 can do that JP2OpenJPEG 
can't. But there are definitely binary distributions still using it, and 
not yet JP2OpenJPEG. The deprecation hint for that driver is to use 
JP2OpenJPEG, so yes ultimately we'll remove it.


Even

--
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

[Kurt Schwehr]

Thanks Even! Hurray for cleanup!  Some thoughts looking at the list:

> SEGY

Makes me sad, but I've never seen anyone use it.  I've done seismic work
but never needed it.  +1 to nuke it.

> E00GRID

I keep running into E00 data from the USGS, but it's mostly been vector
data.  I'm +0 on removing this.  I ended up using GDAL on an e00 grid a
year or two ago, but that isn't much of an argument for keeping it.

> Deprecate JPEG2000

Is there something the openjpeg2 driver can't do that Jasper can?  Can it
be removed?

> TIGER

It looks like they don't use that format any more, so +1

https://www.census.gov/programs-surveys/geography/guidance/tiger-data-products-guide.html


On Wed, Mar 3, 2021 at 12:07 PM Even Rouault 
wrote:

> OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's
> mark GSAG and GSBG as deprecated and see if that triggers reactions once
> this is in the wild.
>
> Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :
> >> 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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JPEG 2000 Driver

[Even Rouault]

Hi,

https://gdal.org/development/rfc/rfc34_license_policy.html


As indicated in the top of the RFC, its status is "development" (draft), 
which here means stalled/non-adopted given that it was proposed long 
time ago. So there's no runtime mechanism to control license compatibility.




But, I'm worried about something different.  As a packager, I'd like to
know that unless I take the affirmative step of passing --enable-foo,
for any GPLish or proprietary foo, I won't end up with a gdal build
linked with foo just because it happened to be present in my build
environment.


This should normally be the case. One of the few GPL dependencies is 
Poppler and must be explicitly enabled with --with-poppler . Similarly 
with MySQL. All proprietary dependencies need also to be explicitly 
enabled AFAIK (you actually need to point to their SDK).


GEOS (LGPL) is enabled by default is found.

Even

--

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

[Norman Barker]

I wrote the Cloudant driver (though it extends the CouchDB driver), it was
very useful! However afaik it is no longer being used. Though I no longer
work with CouchDB I see very little mention of geospatial and CouchDB
nowadays on their mailing lists.

I agree with the list of drivers proposed for deprecation.

+1

Norman

On Wed, Mar 3, 2021 at 2:07 PM Even Rouault 
wrote:

> OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's
> mark GSAG and GSBG as deprecated and see if that triggers reactions once
> this is in the wild.
>
> Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :
> >> 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
>
___
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

[Even Rouault]

Le 03/03/2021 à 21:20, Ivan Lucena a écrit :

Even,

Is the INGR driver for Integraph raster install needed?

It was developed when the format was already deprecated.

It was supposed to read old files and there was some old hardware, 
scanner, spitting out in that file format.



I'll add it to the list of deprecated drivers then.


Even




Regards,

Ivan

*From:* gdal-dev  on behalf of Even 
Rouault 

*Sent:* Wednesday, March 3, 2021 3:07 PM
*To:* Joaquim Manuel Freire Luís ; 
gdal-dev@lists.osgeo.org 

*Subject:* Re: [gdal-dev] Motion: remove and deprecate a few drivers
OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's
mark GSAG and GSBG as deprecated and see if that triggers reactions once
this is in the wild.

Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :
>> 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 



--
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

[Ivan Lucena]

still (not install)


From: gdal-dev  on behalf of Ivan Lucena 

Sent: Wednesday, March 3, 2021 3:20 PM
To: Even Rouault ; Joaquim Manuel Freire Luís 
; gdal-dev@lists.osgeo.org 
Subject: Re: [gdal-dev] Motion: remove and deprecate a few drivers

Even,

Is the INGR driver for Integraph raster install needed?

It was developed when the format was already deprecated.

It was supposed to read old files and there was some old hardware, scanner, 
spitting out in that file format.

Regards,

Ivan

From: gdal-dev  on behalf of Even Rouault 

Sent: Wednesday, March 3, 2021 3:07 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org 

Subject: Re: [gdal-dev] Motion: remove and deprecate a few drivers

OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's
mark GSAG and GSBG as deprecated and see if that triggers reactions once
this is in the wild.

Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :
>> 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
___
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

[Ivan Lucena]

Even,

Is the INGR driver for Integraph raster install needed?

It was developed when the format was already deprecated.

It was supposed to read old files and there was some old hardware, scanner, 
spitting out in that file format.

Regards,

Ivan

From: gdal-dev  on behalf of Even Rouault 

Sent: Wednesday, March 3, 2021 3:07 PM
To: Joaquim Manuel Freire Luís ; gdal-dev@lists.osgeo.org 

Subject: Re: [gdal-dev] Motion: remove and deprecate a few drivers

OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's
mark GSAG and GSBG as deprecated and see if that triggers reactions once
this is in the wild.

Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :
>> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JPEG 2000 Driver

[Greg Troxel]

Andrew C Aitchison  writes:

> On Mon, 1 Mar 2021, Greg Troxel wrote:
>
>> I also was unclear on the optional driver situation.  Certainly if
>> drivers can link with proprietary libraries, there is absolutely no
>> reason to object to a driver because it links so an AGPL3 library.
>>
>> I believe that drivers with non-MIT licenses shouldn't be built by
>> default even if the prerequisite libraries are available in the build
>> environment.  Partly this bias is from pkgsrc, as packaging systems
>> typically try to control the build to get a repeatable outcome, and
>> partly because having a proprietary library installed is different from
>> a decision to make gdal use it and thus end up with possible
>> distribrution problems.
>>
>> I found
>>  https://gdal.org/download.html#development-source
>>  https://gdal.org/drivers/vector/index.html#vector-drivers
>>  https://gdal.org/drivers/raster/index.html#raster-drivers
>>
>> but didn't from that understand if one needs to pass --enable, or if the
>> library being found is enough.
>>
>> Consulting configure.ac, it seems some drivers are built if the library
>> is found, and others are only built if the driver is requested and also
>> the library is found.
>
> I take it you are aware of
> doc/source/development/rfc/rfc34_license_policy.rst
> https://gdal.org/development/rfc/rfc34_license_policy.html

No, I was not aware of that; thanks for pointing it out.

What I did was look at the top-level docs and for the INSTALL file that
is typically present, to try to understand the prereqs and rules.  Even
looking at that page there is a bunch of text that doesn't read like
it's a done deal.

But, I'm worried about something different.  As a packager, I'd like to
know that unless I take the affirmative step of passing --enable-foo,
for any GPLish or proprietary foo, I won't end up with a gdal build
linked with foo just because it happened to be present in my build
environment.

I don't think this set of build defaults is controlled by RFC34.



signature.asc
Description: PGP signature
___
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

[Even Rouault]

OK, I amend my motion to keep GS7BG as non-deprecated for now. Let's 
mark GSAG and GSBG as deprecated and see if that triggers reactions once 
this is in the wild.


Le 03/03/2021 à 20:55, Joaquim Manuel Freire Luís a écrit :

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]

> 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

[Even Rouault]

Is the GSAG format really used ?

Which one(s) are proposed by default as output of current Surfer versions ?

Can't Surfer export to other formats already handled by GDAL ?

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

[gdal-dev] Motion: remove and deprecate a few drivers

[Even Rouault]

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