<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 5:57 PM, Kyle Shannon <span dir="ltr"><<a href="mailto:kyle@pobox.com" target="_blank">kyle@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Apr 1, 2014 at 12:36 PM, Etienne Tourigny<br>
<<a href="mailto:etourigny.dev@gmail.com">etourigny.dev@gmail.com</a>> wrote:<br>
> The 2 objections I have with json are :<br>
><br>
> - it is so verbose that editing by hand is not as easy as .csv<br>
> - the xml tags make file size much larger than .csv files, unless they would<br>
> be stored in a compressed file (gzip)<br>
><br>
> On the other hand, who messes with theses files on a regular basis anyway?<br>
><br>
> It seems like a nice idea. In what ways would it be better than Even's<br>
> suggestion to use sqlite?<br>
><br>
><br>
> On Mon, Mar 31, 2014 at 4:37 PM, Dmitriy Baryshnikov <<a href="mailto:bishop.dev@gmail.com">bishop.dev@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I think the JSON format is good for metadata storing and representation.<br>
>> JSON support to store string, digits, bool, dates, etc. Write such data and<br>
>> read such data from files.<br>
>> But need good library or set of classes to work with it in memory<br>
>> representation.<br>
>> For example I like  wxJSON - it support to get value by name or iterate<br>
>> values by index.<br>
>><br>
>> int majorVer = root["wxWidgets"]["Version"]["Major"].AsInt();<br>
>><br>
>><br>
>> root["wxWidgets"]["Authors"][0] = "J. Smart";<br>
>> root["wxWidgets"]["Authors"][1] = "V. Zeitling";<br>
>> root["wxWidgets"]["Authors"][2] = "R. Roebling";<br>
>><br>
>><br>
>> It consist only 3 files (json reader, json writer and json value).<br>
>><br>
>> It seems to me that json-c library is more complicated. Unfortunately<br>
>> wxJSON cannot be used in GDAL as it have bindings to wxWidgets library, but<br>
>> the approach is interesting. By the way wxWidgets have more democratic<br>
>> license instead of qt.<br>
>><br>
>> Best regards,<br>
>>     Dmitry<br>
>><br>
>> 31.03.2014 23:03, Even Rouault пишет:<br>
>><br>
>> Hi Etienne,<br>
>><br>
>> Thanks for your ideas.<br>
>><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>
>> 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<br>
>> LGPL.<br>
>> I guess standard C++ libraries classes, or perhaps boost, should do the<br>
>> job<br>
>> for what you mention below.<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>
>> Well, at least, MapServer uses a few CPL functions : CPL minixml,<br>
>> CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename,<br>
>> CSLInsertString, etc..<br>
>><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>
>> Another option would be to use a .sqlite database with proper indices.<br>
>> SQLite<br>
>> would become a runtime requirement, but I don't think that would be a big<br>
>> problem.<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,<br>
>> QVariant>)<br>
>> and a way to represent this on file (as .aux.xml or otherwise in files<br>
>> that<br>
>> support metadata) such as gtiff. Values could be stored as strings to<br>
>> 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>
>> Interesting idea.<br>
>><br>
>> Well, we need coders now ;-)<br>
>><br>
>> Even<br>
>><br>
>><br>
>><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>
><br>
><br>
><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>
<br>
</div></div>What problem are we trying to solve exactly?  Is CPL* thought to be<br>
buggy because it isn't exposed to the wild?  </blockquote><div><br></div><div>I thought that gdal 2.0 could be a good occasion to upgrade/modernize some of the legacy code in gdal, which is a bit hard to learn for newcomers and not that well documented.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as the csv and<br>
support files, is it a performance issue we are trying to solve?.  </blockquote><div><br></div><div>Although I don't have any benchmarks to support this, I perceive that the way the .csv reading is handled is not very efficient. I recall reading some comments in the code that this should be fixed, but that never happened.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is<br>
the metadata system insufficient for some purposes?  It may be in<br>
Etienne's case, due to typing, but are there other examples?  I'm just<br>
curious.  Thanks.<br></blockquote><div><br></div><div>I find that having metadata values as strings can be limiting and can induce errors an inaccuracies due to rounding.</div><div><br></div><div>But again - these are merely suggestions - I think things work well as they are but could need some improvements and modernizing/standardization.</div>
<div><br></div><div>cheers</div><div>Etienne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Kyle<br>
</font></span></blockquote></div><br></div></div>