<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
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. <br>
But need good library or set of classes to work with it in memory
representation. <br>
For example I like wxJSON - it support to get value by name or
iterate values by index. <br>
<pre class="fragment" style="font-family: monospace, fixed; font-size: 13px; border: 1px solid rgb(204, 204, 204); background-color: rgb(245, 245, 245); margin: 4px 8px 4px 2px; padding: 4px 6px; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="keywordtype" style="color: rgb(96, 64, 32);">int</span> majorVer = root[<span class="stringliteral" style="color: rgb(0, 32, 128);">"wxWidgets"</span>][<span class="stringliteral" style="color: rgb(0, 32, 128);">"Version"</span>][<span class="stringliteral" style="color: rgb(0, 32, 128);">"Major"</span>].<a class="code" href="http://wxcode.sourceforge.net/docs/wxjson/classwxJSONValue.html#9223209e7eea4dd4d668869b69560acb" title="Return the stored value as an integer." style="color: rgb(0, 0, 255); text-decor
ation: none; font-weight: normal;">AsInt</a>();</pre>
<br>
<pre class="fragment" style="font-family: monospace, fixed; font-size: 13px; border: 1px solid rgb(204, 204, 204); background-color: rgb(245, 245, 245); margin: 4px 8px 4px 2px; padding: 4px 6px; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">root[<span class="stringliteral" style="color: rgb(0, 32, 128);">"wxWidgets"</span>][<span class="stringliteral" style="color: rgb(0, 32, 128);">"Authors"</span>][0] = <span class="stringliteral" style="color: rgb(0, 32, 128);">"J. Smart"</span>;
root[<span class="stringliteral" style="color: rgb(0, 32, 128);">"wxWidgets"</span>][<span class="stringliteral" style="color: rgb(0, 32, 128);">"Authors"</span>][1] = <span class="stringliteral" style="color: rgb(0, 32, 128);">"V. Zeitling"</span>;
root[<span class="stringliteral" style="color: rgb(0, 32, 128);">"wxWidgets"</span>][<span class="stringliteral" style="color: rgb(0, 32, 128);">"Authors"</span>][2] = <span class="stringliteral" style="color: rgb(0, 32, 128);">"R. Roebling"</span>;</pre>
<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 wxJSON cannot be used in GDAL as it have bindings
to wxWidgets library, but the approach is interesting. By the way
wxWidgets have more democratic license instead of qt.<br>
<pre class="moz-signature" cols="72">Best regards,
Dmitry</pre>
31.03.2014 23:03, Even Rouault пишет:<br>
</div>
<blockquote
cite="mid:201403312103.00978.even.rouault@mines-paris.org"
type="cite">
<pre wrap="">Hi Etienne,
Thanks for your ideas.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
QT is certainly a dependency we wouldn't want to draw. Too big for some
embededded usage, and it would make GDAL to be practially bound by the LGPL.
I guess standard C++ libraries classes, or perhaps boost, should do the job
for what you mention below.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
They are also not used outside gdal, as such do not benefit from
enhancements as other toolkits.
</pre>
</blockquote>
<pre wrap="">
Well, at least, MapServer uses a few CPL functions : CPL minixml,
CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename,
CSLInsertString, etc..
</pre>
<blockquote type="cite">
<pre wrap="">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.
Existing code would still be able to use cpl/csl code but be deprecated
until a given release.
- 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
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.
</pre>
</blockquote>
<pre wrap="">
Another option would be to use a .sqlite database with proper indices. SQLite
would become a runtime requirement, but I don't think that would be a big
problem.
</pre>
<blockquote type="cite">
<pre wrap="">
- 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.
Currently there is no way to know if a given metadata item represents an
integer, float, double (or string).
In the netcdf driver, I overcame this limitation in 2 ways:
1) parsing the value to test if it is an int, float or double (potentially
error-prone)
2) add an extra metadata item to specify the type of the data represented
(cumbersome and non-standard)
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.
</pre>
</blockquote>
<pre wrap="">
Interesting idea.
Well, we need coders now ;-)
Even
</pre>
</blockquote>
<br>
</body>
</html>