[Proj] Coming releases of PROJ.4

[Even Rouault]

On jeudi 22 juin 2017 21:15:27 CEST Sebastiaan Couwenberg wrote:
> On 06/22/2017 08:49 PM, Kristian Evers wrote:
> >> I'm also thinking to Linux distributions that will be able to ship only a
> >> single proj version and will perhaps have packages that still use the
> >> old API while others have already migrated.> 
> > Good point.
> 
> To be more specific, there will be projects that will never move to the
> new API due to lack of development manpower, etc.
> 
> Ideally the old API remains available, and gets put into an indefinite
> maintenance mode.

On my ubuntu 16.04, I see

$ apt-cache rdepends libproj9
libproj9
Reverse Depends:
  libproj-dev
  libmapserver2
  zygrib
  xastir
  thuban
  therion
  survex-aven
  survex
  sumo
  spatialite-gui
  sosi2osm
  shapelib
  saga
  qmapshack
  qlandkartegt
  qgis
  python3-pyproj
  python-pyproj
  proj-bin
  postgresql-9.5-postgis-2.2
  pdl
  osm2pgsql
  ogdi-bin
  ncl-ncarg
  merkaartor
  libvtk6.2
  libsqlite3-mod-spatialite
  libspatialite7
  libqgis-core2.8.6
  libproj-java
  liblwgeom-2.2-5
  libogdi3.2
  libmapserver2
  libmapnik3.0
  libmagplus3v5
  cdo
  libgeotiff2
  libgeo-proj4-perl
  libgdal1i
  grass-core
  gpx2shp

I didn't think the list was so long. Indeed the cumulative amount of effort for migrating all 
those projects is very likely much higher than supporting the old API.

As far as I'm concerned, I'm afraid I'm somehow the fallback maintainer of libgeotiff and 
shapelib, but I've never touched at their proj.4 dependant part (I'm in fact almost discovering 
that they depend on proj.4 !) I wouldn't be so enthousiastic in spending time touching that 
part.

Kristian, do you think that would be feasible to keep the proj_api API, while possibly making 
it internally use the new API if that simplifies design / maintainance ? A kind of compatibility 
layer.

I could potentially collect the API calls of projects I'm familiar with (GDAL, shapelib, libgeotiff, 
mapserver and QGIS), so we have a better picture of what is actually used in the wild. At the 
very least, it will give us an idea of what the capabilities the new API should cover...

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170622/3175e61e/attachment.html>