Selon Dmitriy Baryshnikov <bishop....@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
