Re: GDAL 3.13.0 release candidate available

Hi,

When it comes to reducing whitespace in GeoJSON and geojsonseq, I believe (and also tested with GDAL 3.13.0beta2 "Iowa City", released 2026/04/29) that the newlines between features remain. The corresponding PR is https://github.com/OSGeo/gdal/pull/13485.

-Jukka Rahkonen-


________________________________________
Lähettäjä: gdal-dev <[email protected]> käyttäjän Greg Troxel via gdal-dev <[email protected]> puolesta
Lähetetty: Maanantai 4. toukokuuta 2026 18.15
Vastaanottaja: Even Rouault via gdal-dev <[email protected]>
Aihe: Re: [gdal-dev] GDAL 3.13.0 release candidate available


HUOM! Ulkoinen lähettäjä. Älä avaa linkkejä tai liitteitä, ellet tunnista lähettäjää.
OBS! Extern avsändare. Öppna inte länkar eller bilagor om du inte känner igen avsändaren.
NOTE! External sender. Do not open links or attachments unless you recognize the sender.




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.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev