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

[Dmitriy Baryshnikov]

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.dev at 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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
>