[Proj] Coming releases of PROJ.4

[Kristian Evers]

Even,



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

On top of my head, yes. It might be a challenge to sort out contexts and the ProjFileAPI, but I think it is doable. I'll have to have a closer look though.

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

That would be very helpful. I am especially interested to see if anyone has ever used the ProjFileAPI functions...



Howard,

> Ditching manually-constructed and out-of-date nmake for cmake seems fine to me (ooh, CMake gives me project files now!), but ditching autotools that has worked for people for decades does not. That change would ripple into packagers and the distros for little or no appreciable benefit.

I won't claim to be an expert  in CMake, quite the opposite really, but I was under the impression that it  would be possible to set up CMake in a way so that it mimics the autotools behavior exactly when UNIX makefiles are generated. I am completely wrong here?
The benefit would be to limit the amount of code we have to maintain. It would only benefit us, true, but it would also free time that can be spend improving the overall project instead of maintaining status quo. I don't feel too strongly about this, I just wanted to throw it out there while I was at it.

> but I must say I'm very skeptical that we can actually *remove* anything -- especially headers with ambiguous public vs. private behavior that people now depend upon


I get that. On the other hand I fear that we will be locked in place forever if we don't allow breaking stuff once in a while. If at least we can get away with not exposing projects.h I think there will be much more room to play in the future. I hope that Even's assessment about it not being used much is true.

> We need to be delicate about changing things for a library such as Proj.4 only for the sake of being "better". This is an unfortunate consequence of maintaining a library that everything ultimately uses (and started using 20+ years ago).

Perhaps the ambition should be to BE MUCH BETTER than previous versions on PROJ.4. So much better that other projects will benefit hugely from using the new API and update their codebase voluntarily. Eventually the problem will solve itself. I already think we are on the right track.

/Kristian

Fra: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] På vegne af Even Rouault
Sendt: 22. juni 2017 21:49
Til: proj at lists.maptools.org
Cc: Sebastiaan Couwenberg
Emne: Re: [Proj] Coming releases of PROJ.4


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/cb501cf9/attachment.html>