Hi Daniele,
Thanks for your answer. I understand it better now.
My first goal was to get these aggregation files actually published. I
can publish them by ignoring the runtime dimension, but of course, that
does not create actual support to query the dimension. That is a way
bigger task, that is going to involve a lot more work. I will discuss
how to move forward.
Niels
On 23-09-16 15:36, Daniele Romagnoli wrote:
Hi Niels,
Nuno fixed a bug in the NetCDF machinery a couple of days ago. (I have
merged that PR right now).
At the very beginning of the NetCDF development, we started to support
what was able with the available NetCDF version (I thin 2.x or
something similar... a very old one).
Therefore the NetCDF reader also internally deal with a binary index
containing Time,Zeta based indexes for quick slices retrieval.
https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/Slice2DIndex.java
Basically, re-using the table I have put in the JIRA, for each 2D pair
a global index may be defined:
global Index =(Time index, Zeta Index)
0 = (0,0)
1 = (0,1)
2 = (0,2)
3 = (1,0)
4 = (1,1)
5 = (1,2)
6 = (2,0)
7 = (2,1)
8 = (2,2)
9 = (3,0)
10= (3,1)
11= (3,2)
The NetCDF internal catalog is similar to the ImageMosaic GranuleCatalog.
For each 2D slice available, it stores a global index, as well as the
timestamp/date (it T dimension is available) and the elevation value
(it Z dimension is available) related to that imageIndex.
(https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/coverage-api/src/main/java/org/geotools/coverage/io/catalog/CoverageSlicesCatalog.java)
So, when requesting a read operation on a specific time and specific
elevation, the reader performs a query on the CoverageSlicesCatalog to
get the related imageIndex.
Then the imageIndex is provided to the Slice2DIndexManager in order to
get the proper integer indexes to be used as values for the
Section/Ranges to be provided to the underlying UCAR reader.
https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/NetCDFImageReader.java#L584
https://github.com/geotools/geotools/blob/master/modules/plugin/coverage-multidim/netcdf/src/main/java/org/geotools/imageio/netcdf/NetCDFImageReader.java#L651-L658
We also thought about revisiting/removing the binary index machinery
and include it somehow this information in the CoverageSlicesCatalog
itself and investigate on the indexing objects automatically generated
by the UCAR library. However we never had time or resources to work on
that.
Therefore, right now, an additional real dimension for runtime isn't
fully supported. (We somehow support different runtimes for different
NetCDF through ImageMosaic store). Not sure to remember from which
version UCAR started exposing it as a separate dimension.
You may want to extend the Slice2DIndex machinery or remove that in
favor of a better management of additional dimensions.
Does it helps?
Cheers,
Daniele
On Fri, Sep 23, 2016 at 2:34 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
Hello Daniele,
As you know, I am working on support for aggregation on runtime
dimension in netcdf. I am now looking into what needs to happen in
VariableAdaptor.
I am very new at netcdf, so I do not yet understand everything
that is happening to the fullest extent in this class.
I have found a way to make it work, basically by ignoring the
runtime dimension altogether. Apart from adding it as an ignored
dimension, I also had to take into account the possibility of
there being four dimensions of which one is the runtime dimension.
This is the commit:
https://github.com/NielsCharlier/geotools/commit/5278115bd43a77c6509881d59a582e69c8bbe182
<https://github.com/NielsCharlier/geotools/commit/5278115bd43a77c6509881d59a582e69c8bbe182>
The aggregation files now pass and I can publish the layers. But I
am still wondering if this is the right approach. Or should
perhaps the runtime dimension be treated in the same way as the t-
and z-dimensions? Or should there actually be logic in
VariableAdaptor for the R-dimension, similar to the logic that
exists for the Z- and T-dimensions?
What is your opinion? Thanks for your assistance.
Kind Regards,
Niels
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Daniele Romagnoli
Senior Software Engineer
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate.
Il loro utilizzo è consentito esclusivamente al destinatario del
messaggio, per le finalità indicate nel messaggio stesso. Qualora
riceviate questo messaggio senza esserne il destinatario, Vi preghiamo
cortesemente di darcene notizia via e-mail e di procedere alla
distruzione del messaggio stesso, cancellandolo dal Vostro sistema.
Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità
diverse, costituisce comportamento contrario ai principi dettati dal
D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely
for the attention and use of the named addressee(s) and may be
confidential or proprietary in nature or covered by the provisions of
privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New
Data Protection Code).Any use not in accord with its purpose, any
disclosure, reproduction, copying, distribution, or either
dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the
intended recipient, please contact immediately the sender by
telephone, fax or e-mail and delete the information in this message
that has been received in error. The sender does not give any warranty
or accept liability as the content, accuracy or completeness of sent
messages and accepts no responsibility for changes made after they
were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
