On Fri, Mar 28, 2014 at 3:24 PM, Mateusz Łoskot wrote:
> On 28 March 2014 21:04, Tim Keitt wrote:
> > Something to consider is writing an interface that wraps the old code.
> > Modern generic approaches make this easy.
> >
> > Perhaps evaluate the Generic Image Library and Boost Geometry as
> ca
On 28 March 2014 21:04, Tim Keitt wrote:
> Something to consider is writing an interface that wraps the old code.
> Modern generic approaches make this easy.
>
> Perhaps evaluate the Generic Image Library and Boost Geometry as candidates?
GDAL is I/O oriented, whereas in GIL and BG, I/O layer is
Something to consider is writing an interface that wraps the old code.
Modern generic approaches make this easy.
Perhaps evaluate the Generic Image Library and Boost Geometry as candidates?
THK
On Fri, Mar 28, 2014 at 3:24 AM, Even Rouault
wrote:
> Dmitriy,
>
> It is not at all my intention to
Dmitriy,
It is not at all my intention to have a big-bang for GDAL 2.0. According to the
ohloh estimation ( http://www.ohloh.net/p/gdal/estimated_cost ), the cumulated
development to make GDAL as it is currently would represent a 265 person-years
effort. I do think it is overestimated (they also i
Hi Etienne,
Yes, on first stage some format will be dropped. But exist GDAL 1.x will
help where.
It seems to me that rewriting of formats will not so hard as develop new
one.
NetCDF is popular form and should be rewrite in first stage. We can
create a wiki page with table of format and stages
Dmitry - I am not sure that a wholescale refactor is the way to go - many
formats will be dropped because quite a few do not have active maintainers,
and development is mostly on a volunteer basis (correct me if I am wrong,
Even).
As an example, the netcdf driver has been mostly maintained by myse
Hi Even,
I think that we can discuss the starting point for 2.0.
You start with idea "...to "refactor" a code base of 1.2 million lines.."
Maybe we have to start from white list - create ideal (brilliant) set of
classes and create a well-designed foundation for GDAL. Also rewrite
several wide u
14:05:29 +0100
> > To: etourigny@gmail.com
> > CC: gdal-dev@lists.osgeo.org
> > Subject: Re: [gdal-dev] Draft GDAL/OGR class hierarchy for GDAL 2.0
> >
> > On 27 March 2014 13:40, Etienne Tourigny wrote:
> > > How about multiple inheritance for mixed clas
On 27 March 2014 16:08, Even Rouault wrote:
> Selon Ivan Lucena :
>
>> Hi there,
>>
>> That is a great discussion and I applause Evens efforts and all the
>> contributions, so but don't get me wrong by asking that:
>>
>> What do we want to accomplish with that class hierarchy?
>>
>> Will GDAL 2.0
Open mechanism probe for all those possibilities?
My best regards,
Ivan
> From: mate...@loskot.net
> Date: Thu, 27 Mar 2014 14:05:29 +0100
> To: etourigny@gmail.com
> CC: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Draft GDAL/OGR class hierarchy for GDAL 2.0
>
> On 27
Selon Florent JITIAUX :
> 2014-03-27 11:24 GMT+01:00 Even Rouault :
>
> > Hi,
> >
> > > Hi all,
> > >
> > > MY opinion is that's not a really good way to count how many classes you
> > > will have and trying to have minimal classes.
> > >
> > > Drawing a model with UML is not easy : it's not easy
On 27 March 2014 13:40, Etienne Tourigny wrote:
> How about multiple inheritance for mixed class? Say you have a class for
> rasters and a class for vectors, and a dataset that would support both types
> would inherit from these two base classes. Is that what you mean by
> composite?
I meant se
How about multiple inheritance for mixed class? Say you have a class for
rasters and a class for vectors, and a dataset that would support both
types would inherit from these two base classes. Is that what you mean by
composite?
Etienne
On Thu, Mar 27, 2014 at 9:32 AM, Mateusz Łoskot wrote:
2014-03-27 11:24 GMT+01:00 Even Rouault :
> Hi,
>
> > Hi all,
> >
> > MY opinion is that's not a really good way to count how many classes you
> > will have and trying to have minimal classes.
> >
> > Drawing a model with UML is not easy : it's not easy to have a good model
> > from the beginning,
On 27 March 2014 11:24, Even Rouault wrote:
>>
>> Is it possible to put it as a member in classes ?
>
> That could have been a way of doing it, yes. Always the debate composition vs
> inheritance.
The base classes for raster and vector datasets could have common base class.
The mixed raster/vecto
Hi,
> Hi all,
>
> MY opinion is that's not a really good way to count how many classes you
> will have and trying to have minimal classes.
>
> Drawing a model with UML is not easy : it's not easy to have a good model
> from the beginning, it's not easy to name all members and methods
> correctly,
Hi all,
MY opinion is that's not a really good way to count how many classes you
will have and trying to have minimal classes.
Drawing a model with UML is not easy : it's not easy to have a good model
from the beginning, it's not easy to name all members and methods
correctly, and the worst is in
Selon Etienne Tourigny :
> I also (respectfully) think that there are too many classes (mostly the
> abstract classes and interfaces) which make it a bit hard to understand.
>
> I like Vincent's second suggestion to have 3 base Dataset classes
> (GDALRasterDataset, GDALVectorDataset, GDALHybridDat
I also (respectfully) think that there are too many classes (mostly the
abstract classes and interfaces) which make it a bit hard to understand.
I like Vincent's second suggestion to have 3 base Dataset classes
(GDALRasterDataset, GDALVectorDataset, GDALHybridDataset) which inherit
from GDALDatase
On 25 March 2014 12:37, Dmitriy Baryshnikov wrote:
> According to naming conventions I think, that pure interface classes should
> start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
> For the Abstract class maybe such naming will sute:
> GDALEmptyRasterDataset -> GDALRasterDataset
> GDALA
Partial sound ok to me, but I not so good at naming ?
Considering the number of classes, I gave it some thoughts this morning
and, like Dmitry, thought of merging the Abtract (Partial) into the
interface before realizing that, even if it works (you can overload de
default function in Empty) it
Selon Vincent Mora :
> On 25/03/2014 11:44, Even Rouault wrote:
> > Selon Vincent Mora :
> >
> >> On 24/03/2014 21:46, Even Rouault wrote:
> >>> Hi,
> >>>
> >>> "Release soon, release early", so for people who like UML diagrams (there
> >> is
> >>> also a prototype of C++ classes for those who don
According to naming conventions I think, that pure interface classes
should start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
For the Abstract class maybe such naming will sute:
GDALEmptyRasterDataset -> GDALRasterDataset
GDALAbstractRasterDataset -> GDALRasterDatasetBase
GDALIRasterDat
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora :
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
"Release soon, release early", so for people who like UML diagrams (there
is
also a prototype of C++ classes for those who don't like UML very much),
here's
a blog entry with the out
Selon Vincent Mora :
> On 24/03/2014 21:46, Even Rouault wrote:
> > Hi,
> >
> > "Release soon, release early", so for people who like UML diagrams (there
> is
> > also a prototype of C++ classes for those who don't like UML very much),
> here's
> > a blog entry with the outcome of my thoughts for
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
"Release soon, release early", so for people who like UML diagrams (there is
also a prototype of C++ classes for those who don't like UML very much), here's
a blog entry with the outcome of my thoughts for a possible re-organisation of
the GDAL/OGR cl
Hi,
answering some questions from Dmitry in the comment of
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html#comment-form
:
> A few questions:
> 1) Why the need GDALAbstractXXXDataset and GDALEmptyXXXDataset? May be
Abstract will be enouth?
--> The AbstractXXX has t
Hi,
"Release soon, release early", so for people who like UML diagrams (there is
also a prototype of C++ classes for those who don't like UML very much), here's
a blog entry with the outcome of my thoughts for a possible re-organisation of
the GDAL/OGR class hierarchy
http://erouault.blogspot.ca/
28 matches
Mail list logo
