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 can commit all this, but I don't sure - is this a GDAL scope? 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.
Best regards,
Dmitry
21.02.2014 14:07, Even Rouault пишет:
Selon Dmitriy Baryshnikov <bishop....@gmail.com>:
Hi Even,
I plan to participate in code sprint too and work on GDAL.
In addition to the mentioned tasks I would like to discuss some politics
and direction to add new functionality to GDAL.
Great, perhaps you can share some of your thoughts ahead of time ?
Best regards,
Dmitry
14.02.2014 1:14, Even Rouault пОÑеÑ:
Hi,
I've confirmed my presence to the OSGeo Vienna code sprint (
http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 ). Are there folks that
will be there and indent doing some work on GDAL ? Any particular topics of
interest ?
It could be the opportunity to take a crack at some changes that have been
mentionned for some time and are listed at
http://trac.osgeo.org/gdal/wiki/GDAL20Changes
We should decide how to manage the 2.0 transition. I think that the 2.0
number
should be reserved as the opportunity of introducing breaking changes in
the
API / ABI. But this might take a long time to implement all that is listed
above, so there's a risk we end up with a trunk that is never ready for
release for years. Not a good thing.
On the other hand, we could just be more modest and take breaking changes
as
they are introduced and raise the major version number (so the yearly
version
after 2.0 could be 3.0). This will require projects using GDAL to adapt
multiple times.
An alternative would be to prepare the API for new features even if they
are
not implemented, but that's a difficult exercise and there's a risk that at
implementation time, the API doesn't fit.
Any thoughts ?
Currently we have no such breakage in trunk so it could qualify as GDAL
1.11.
Perhaps we should just release it as such for now before the bigger changes
?
Somes topics I can see for GDAL 2.0 that impact API/ABI :
- well, the mythological unification of OGR driver model with GDAL driver
model.
- XYZM support
- Curve geometries
- 64 bit integer support
Other possible structural changes :
- Change of master version control system: switch to git / GitHub ?
- New build system : cmake ?
Of course all of this will more likely happen if contributors or funders
show
up !
Even
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
