[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Even Rouault]

Selon Dmitriy Baryshnikov <bishop.dev at gmail.com>:

> Hi Even,
>
> On code sprint I can work on:
> - unification of OGR driver model with GDAL driver
> - XYZM
> - cmake for GDAL
>
> That about thoughts - e.g. now I work on linear referencing using OGR
> datasources. As the absence of M value I use other algorithms. So I have
> ogrlineref application which can create needed data for linear
> referencing and using it for get:
> 1) point on path from linear position
> 2) linear position from point
> 3) sublinestring from two linear positions
>
> Also, I added few new methods to OGRLineString:
> virtual double Project(const OGRPoint *) const;
> virtual OGRLineString* getSubLine(double, double, int) const;

I just have had a look at those 2 in
https://github.com/nextgis/gdal-svn/compare/cmake4gdal. That looks fine
generally. I have just seen that GEOSProject_r isn't available in GEOS 3.1.0
which is our new minimal required GEOS version, but it has been added in 3.2.0.
You should just conditionalize the implementation of Project method with the
GEOS version.
And perhaps also add Doxygen comments of the functions.

>
> I can commit all this, but I don't sure - is this a GDAL scope?

Apart from the above remarks, I'd say: go ahead and commit it.

>  And
> there is a border for functionality which is not applicable to GDAL.
> Also I have some doubts about breaking ABI as a result of adding new
> methods to the OGRLineString.

Such breakage of the C++ ABI is within our usual rules.

Even