On Tue, Apr 1, 2014 at 5:57 PM, Kyle Shannon k...@pobox.com wrote:
On Tue, Apr 1, 2014 at 12:36 PM, Etienne Tourigny
etourigny@gmail.com wrote:
The 2 objections I have with json are :
- it is so verbose that editing by hand is not as easy as .csv
- the xml tags make file size much
On Mon, Mar 31, 2014 at 4:03 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Hi Etienne,
Thanks for your ideas.
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml
The 2 objections I have with json are :
- it is so verbose that editing by hand is not as easy as .csv
- the xml tags make file size much larger than .csv files, unless they
would be stored in a compressed file (gzip)
On the other hand, who messes with theses files on a regular basis anyway?
It
On Tue, Apr 1, 2014 at 12:36 PM, Etienne Tourigny
etourigny@gmail.com wrote:
The 2 objections I have with json are :
- it is so verbose that editing by hand is not as easy as .csv
- the xml tags make file size much larger than .csv files, unless they would
be stored in a compressed file
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml code with a mainstream, modern cross-platform
toolkit such as QT, boost, etc.
While cpl/csl classes are robust and do the job, they
Hi Etienne,
Thanks for your ideas.
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml code with a mainstream, modern cross-platform
toolkit such as QT, boost, etc.
QT is
On 31 March 2014 20:17, Etienne Tourigny etourigny@gmail.com wrote:
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml code with a mainstream, modern cross-platform
toolkit such as
Hi,
I think the JSON format is good for metadata storing and representation.
JSON support to store string, digits, bool, dates, etc. Write such data
and read such data from files.
But need good library or set of classes to work with it in memory
representation.
For example I like wxJSON - it
On 31 March 2014 21:37, Dmitriy Baryshnikov bishop@gmail.com wrote:
Hi,
I think the JSON format is good for metadata storing and representation.
JSON support to store string, digits, bool, dates, etc.
IMO it's great idea.
It consist only 3 files (json reader, json writer and json
Hi Mateus,
That's really what I'm talking about. Good example, but need some testing.
Best regards,
Dmitry
31.03.2014 23:44, Mateusz Łoskot пишет:
On 31 March 2014 21:37, Dmitriy Baryshnikov bishop@gmail.com wrote:
Hi,
I think the JSON format is good for metadata storing and
On 3/31/2014 1:03 PM, Even Rouault wrote:
Hi Etienne,
Thanks for your ideas.
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml code with a mainstream, modern cross-platform
Le mardi 01 avril 2014 00:18:11, David Strip a écrit :
On 3/31/2014 1:03 PM, Even Rouault wrote:
Hi Etienne,
Thanks for your ideas.
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience
in learning to use, enhance and maintain gdal/ogr code.
-
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.
Best regards,
Dmitry
14.02.2014 1:14, Even Rouault пишет:
Hi,
I've confirmed my presence to the
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
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
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
On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
even.roua...@mines-paris.org wrote:
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
Hi, I meant to bring this up in my earlier email, but it slipped my
mind. Or maybe I didn't want to open a can of worms. What exactly
would 'unification' entail? I assume all ogr drivers would have to
inherit GDALMajorObject (and probably OGRDataSource and OGRLayer
maybe?) and then ogr
Even, thanks for the notes.
On Sat, Feb 15, 2014 at 11:57 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Thanks for your thoughs Kyle. I expect more developers and PSC members to
express theirs too.
How long would the stable branches be maintained? Would we handle as
we do now, with
Dmitriy,
What version of cmake is required.
On Sat, Feb 15, 2014 at 1:31 PM, Dmitriy Baryshnikov
bishop@gmail.com wrote:
Hi,
As cmake4gdal developer I think there is no problem with cmake. By now we
main code is cmaked, and deal only with some drivers (GDAL or OGR), which
needed cmake
Hi Kyle,
The minimum version cmake is 2.8.8 because it have some required
functionality:
add_library(name OBJECT src...) and TARGET_OBJECTS:objlib
some discussion can be found here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3379
But in scripts I set VERSION 2.8.10 -
Hi, Just a few thoughts/questions...
On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
even.roua...@mines-paris.org wrote:
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
Thanks for your thoughs Kyle. I expect more developers and PSC members to
express theirs too.
How long would the stable branches be maintained? Would we handle as
we do now, with one stable branch and one development branch, or would
we backport bug fixes to n branches (3.1, 2.4, etc)?
On Thu, Feb 13, 2014 at 1:14 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
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 ?
Even,
I think that 2.0 could be kept for breaking
Hi,
As cmake4gdal developer I think there is no problem with cmake. By now
we main code is cmaked, and deal only with some drivers (GDAL or OGR),
which needed cmake scripts.
I make needed cmake scripts for drivers what I use in may work.
So, with some help we can do all cmake scripts rather
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
26 matches
Mail list logo
