Re: GDAL 3.13.0 release candidate available

Even Rouault via gdal-dev <[email protected]> writes:

> I have prepared a GDAL/OGR 3.13.0 "Iowa City" release candidate.

Built fine on NetBSD 10 amd64.

NEWS has a pointer to MIGRATION_GUIDE.TXT, and that file contains a link
to online docs (which feels like a minor bug; the migration guide should
be IMHO be in the sources).   But, on following the link, there is no
3.12 to 3.13 content.

In NEWS,

  a missed newly-installed file: include/gdal_mem.h

  there are a lot of new gdal subcommand man pages, not mentioned in
  NEWS.   It's not clear to me how users would find these.

  there are a lot of new bash completion functions, not mentoined in
  NEWS

Not a big deal for users, but I try to line up changes in the set of
installed files with NEWS to make sure I'm not making a packaging error.

Removing the shlib change, the packing list changes by adding the
following:

  +include/gdal_mem.h
  +include/gdal_thread_pool.h
  +include/ogr_refcountedptr.h
  +man/man1/gdal-dataset-check.1
  +man/man1/gdal-raster-read.1
  +man/man1/gdal-raster-write.1
  +man/man1/gdal-vector-combine.1
  +man/man1/gdal-vector-create.1
  +man/man1/gdal-vector-dissolve.1
  +man/man1/gdal-vector-export-schema.1
  +man/man1/gdal-vector-read.1
  +man/man1/gdal-vector-rename-layer.1
  +man/man1/gdal-vector-sort.1
  +man/man1/gdal-vector-update.1
  +man/man1/gdal-vector-write.1
  +share/bash-completion/completions/gdal2tiles
  +share/bash-completion/completions/gdal2xyz
  +share/bash-completion/completions/gdal_calc
  +share/bash-completion/completions/gdal_edit
  +share/bash-completion/completions/gdal_fillnodata
  +share/bash-completion/completions/gdal_merge
  +share/bash-completion/completions/gdal_polygonize
  +share/bash-completion/completions/gdal_proximity
  +share/bash-completion/completions/gdal_retile
  +share/bash-completion/completions/gdal_sieve
  +share/bash-completion/completions/gdalcompare
  +share/bash-completion/completions/gdalmove
  +share/bash-completion/completions/ogr_layer_algebra
  +share/bash-completion/completions/ogrmerge


----------------------------------------

And, with packager hat off and user hat on:

  GeoJSON driver:
   * minify output (no whitespace) for Feature objects

To me, this is a regression rather than a feature.  A key point for
geojson to me is that it's nerd readable, and it makes it harder for
what I see as a minor change in file size.  I can see a switch to ask
for minified output, but I really wonder who sues geojson and what they
on balance care about.  I can't really say that I read these files a
lot, so the byte savings might well be on better across all users.

On a real dataset I happen to be working on, with 234 point features:
  41231 bytes 3.12.2
  36338 bytes 3.13.0
  126976 bytes in the geopackage storing the features


I do very much appreciate that geojson as written has one feature per
line.  That is perhaps a compromise between full-on remove all whitspace
and nerd-reading comfort.