On Fri, Mar 28, 2014 at 3:24 PM, Mateusz Łoskot mate...@loskot.net wrote:
On 28 March 2014 21:04, Tim Keitt tke...@utexas.edu 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
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
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
even.roua...@mines-paris.orgwrote:
Dmitriy,
It is
On 28 March 2014 21:04, Tim Keitt tke...@utexas.edu 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,
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
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, and the
On 27 March 2014 11:24, Even Rouault even.roua...@mines-paris.org 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.
2014-03-27 11:24 GMT+01:00 Even Rouault even.roua...@mines-paris.org:
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
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
On 27 March 2014 13:40, Etienne Tourigny etourigny@gmail.com 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
Selon Florent JITIAUX fjiti...@gmail.com:
2014-03-27 11:24 GMT+01:00 Even Rouault even.roua...@mines-paris.org:
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
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 March 2014 13:40, Etienne
-dataset raster file like HDF, NetCDF
Will the GDAL 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
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 used
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
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
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 the
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
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora vincent.m...@oslandia.com:
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
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
Selon Vincent Mora vincent.m...@oslandia.com:
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora vincent.m...@oslandia.com:
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++
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)
On 25 March 2014 12:37, Dmitriy Baryshnikov bishop@gmail.com 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 -
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
Selon Etienne Tourigny etourigny@gmail.com:
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,
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
26 matches
Mail list logo
