<div dir="ltr">Hi all,<div><br></div><div>I have a few suggestions for gdal 2.0, based on my personal experience in learning to use, enhance and maintain gdal/ogr code.</div><div><br></div><div>- replace cpl/csl/string/xml code with a mainstream, modern cross-platform toolkit such as QT, boost, etc.</div>
<div><br></div><div>While cpl/csl classes are robust and "do the job", they are not well documented and not very intuitive for a new gdal coder. This is from my personal experience, some may not agree.</div><div>
They are also not used outside gdal, as such do not benefit from enhancements as other toolkits. <br></div><div>The drawback is that some data/methods would not be easily available in c and other bindings. Also it might not be available for all platforms.</div>
<div>Existing code would still be able to use cpl/csl code but be deprecated until a given release.</div><div><br></div><div><br></div><div>- upgrade/migrate gdal support file (files in .csv format such as gcs.csv) reading to use containers (e.g. hash maps) instead of reading the relevant .csv files every time</div>
<div><br></div><div>Current reading of gdal support files is sub-optimal as any query for support data requires reading the relevant support file(s). It would be more efficient to read these once and cache into a container (such as hash map). This could be done using a cross-platform toolkit mentioned earlier.</div>
<div><br></div><div><br></div><div>- modify metadata treatment to be able to store/retrieve data in formats other than strings (e.g. floats, doubles, boolean), and query the actual type of a given metadata item.</div><div>
<br></div><div>Currently there is no way to know if a given metadata item represents an integer, float, double (or string). </div><div><br></div><div>In the netcdf driver, I overcame this limitation in 2 ways: </div><div>
1) parsing the value to test if it is an int, float or double (potentially error-prone) </div><div>2) add an extra metadata item to specify the type of the data represented (cumbersome and non-standard)</div><div><br></div>
<div>My suggestion would be to be able to store metadata value along with its data type (default string as previously). This would require some kind of container for internal representation (e.g. in qt: QMap<QString, QVariant>) and a way to represent this on file (as .aux.xml or otherwise in files that support metadata) such as gtiff. Values could be stored as strings to avoid big/little endian conversion problems. Data type could be stored in a (hidden) metadata domain, one item for each "real" metadata key.</div>
<div><br></div><div><br></div><div>cheers,</div><div>Etienne</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 7:14 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've confirmed my presence to the OSGeo Vienna code sprint (<br>
<a href="http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014" target="_blank">http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014</a> ). Are there folks that<br>
will be there and indent doing some work on GDAL ? Any particular topics of<br>
interest ?<br>
<br>
It could be the opportunity to take a crack at some changes that have been<br>
mentionned for some time and are listed at<br>
<a href="http://trac.osgeo.org/gdal/wiki/GDAL20Changes" target="_blank">http://trac.osgeo.org/gdal/wiki/GDAL20Changes</a><br>
<br>
We should decide how to manage the 2.0 transition. I think that the 2.0 number<br>
should be reserved as the opportunity of introducing breaking changes in the<br>
API / ABI. But this might take a long time to implement all that is listed<br>
above, so there's a risk we end up with a trunk that is never ready for<br>
release for years. Not a good thing.<br>
On the other hand, we could just be more modest and take breaking changes as<br>
they are introduced and raise the major version number (so the yearly version<br>
after 2.0 could be 3.0). This will require projects using GDAL to adapt<br>
multiple times.<br>
An alternative would be to prepare the API for new features even if they are<br>
not implemented, but that's a difficult exercise and there's a risk that at<br>
implementation time, the API doesn't fit.<br>
Any thoughts ?<br>
<br>
Currently we have no such breakage in trunk so it could qualify as GDAL 1.11.<br>
Perhaps we should just release it as such for now before the bigger changes ?<br>
<br>
Somes topics I can see for GDAL 2.0 that impact API/ABI :<br>
- well, the mythological unification of OGR driver model with GDAL driver<br>
model.<br>
- XYZM support<br>
- Curve geometries<br>
- 64 bit integer support<br>
<br>
Other possible structural changes :<br>
- Change of master version control system: switch to git / GitHub ?<br>
- New build system : cmake ?<br>
<br>
Of course all of this will more likely happen if contributors or funders show<br>
up !<br>
<span class="HOEnZb"><font color="#888888"><br>
Even<br>
<br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</font></span></blockquote></div><br></div>