<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 4:03 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 Etienne,<br>
<br>
Thanks for your ideas.<br>
<div class=""><br>
> Hi all,<br>
><br>
> I have a few suggestions for gdal 2.0, based on my personal experience in<br>
> learning to use, enhance and maintain gdal/ogr code.<br>
><br>
> - replace cpl/csl/string/xml code with a mainstream, modern cross-platform<br>
> toolkit such as QT, boost, etc.<br>
<br>
</div>QT is certainly a dependency we wouldn't want to draw. Too big for some<br>
embededded usage, and it would make GDAL to be practially bound by the LGPL.<br>
I guess standard C++ libraries classes, or perhaps boost, should do the job<br>
for what you mention below.<br></blockquote><div><br></div><div>In light of this QT is not a candidate, but on the other hand standard c++ library classes only deal with containers right? </div><div>Are there any cross-platfform, convenience classes? I'm thinking along the lines of things like file paths, xml and csv file reading/writing support.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
><br>
> While cpl/csl classes are robust and "do the job", they are not well<br>
> documented and not very intuitive for a new gdal coder. This is from my<br>
> personal experience, some may not agree.<br>
> They are also not used outside gdal, as such do not benefit from<br>
> enhancements as other toolkits.<br>
<br>
</div>Well, at least, MapServer uses a few CPL functions : CPL minixml,<br>
CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename,<br>
CSLInsertString, etc..<br></blockquote><div><br></div><div>I don't know much about MapServer, but it seems that GDAL is an optional dependency. Could the CPL code be decoupled from GDAL as an external? Would it make sense or just too much a hassle?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> The drawback is that some data/methods would not be easily available in c<br>
> and other bindings. Also it might not be available for all platforms.<br>
> Existing code would still be able to use cpl/csl code but be deprecated<br>
> until a given release.<br>
><br>
><br>
> - upgrade/migrate gdal support file (files in .csv format such as gcs.csv)<br>
> reading to use containers (e.g. hash maps) instead of reading the relevant<br>
> .csv files every time<br>
><br>
> Current reading of gdal support files is sub-optimal as any query for<br>
> support data requires reading the relevant support file(s). It would be<br>
> more efficient to read these once and cache into a container (such as hash<br>
> map). This could be done using a cross-platform toolkit mentioned earlier.<br>
<br>
</div>Another option would be to use a .sqlite database with proper indices. SQLite<br>
would become a runtime requirement, but I don't think that would be a big<br>
problem.<br></blockquote><div><br></div><div>.sqlite wouls be more compact, but not as easy to edit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
><br>
><br>
> - modify metadata treatment to be able to store/retrieve data in formats<br>
> other than strings (e.g. floats, doubles, boolean), and query the actual<br>
> type of a given metadata item.<br>
><br>
> Currently there is no way to know if a given metadata item represents an<br>
> integer, float, double (or string).<br>
><br>
> In the netcdf driver, I overcame this limitation in 2 ways:<br>
> 1) parsing the value to test if it is an int, float or double (potentially<br>
> error-prone)<br>
> 2) add an extra metadata item to specify the type of the data represented<br>
> (cumbersome and non-standard)<br>
><br>
> My suggestion would be to be able to store metadata value along with its<br>
> data type (default string as previously). This would require some kind of<br>
> container for internal representation (e.g. in qt: QMap<QString, QVariant>)<br>
> and a way to represent this on file (as .aux.xml or otherwise in files that<br>
> support metadata) such as gtiff. Values could be stored as strings to avoid<br>
> big/little endian conversion problems. Data type could be stored in a<br>
> (hidden) metadata domain, one item for each "real" metadata key.<br>
<br>
</div>Interesting idea.<br>
<br>
Well, we need coders now ;-)<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>