Message-ID: <1250902912.299769.1369013736870.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_299768_142929583.1369013736870" ------=_Part_299768_142929583.1369013736870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There exists a set of applications which require a toolkit which works w= ith n-Dimensional data, where n is greater than 2. This s= et of applications have traditionally been the domain of data visualization= packages. These packages perform very well and permit many forms of data = exploration which typical GIS packages (including GeoTools) do not support.= However, geospatial support in these packages tends to be very sparse. T= his is important when the data being processed or visualized is strongly ge= ospatial (e.g., numerical weather prediction). One can either use the cust= om programs developed by a specific community for specific purposes (and pe= rform no other analyses), or one can "dumb down" the data so that= a lowly GIS can understand it (and perform some basic analyses).
We (the USDA Forest Service) have been presented with a data integrat= ion problem whereby several models from different domains are required = to interoperate. This project also requires that we set up a distributed m= odeling system, whereby the output of the course-scale model run at our cen= ter must be used as input to the high-resolution regional modeling centers.= Without going into more detail, I hope it is possible to see that the pat= h of least resistance led us to augment GeoTools' current coverage function= ality using pre-existing international standards. The alternative is to co= bble together a data integration, processing, and distribution system uniqu= e to our needs which could probably never be re-used with any other combina= tion of models or tools.
Our partners (the Naval Undersea Research Center, a division of NATO) ha= ve a similar problem in a different application domain. Additional informa= tion about that project should be given by them in order to avoid any misre= presentation, omission, embellishments, or misunderstandings. But specific= s aside, both NURC and the USDA Forest Service recognize the value of produ= cing a toolkit instead of a non-reusable unique solution.
Therefore, I write this wiki page.
It is common to require 5D data in fields like computational fluid dynam= ics and numerical weather prediction. Of these five dimensions, three are = spatial, one is temporal, and one is a "category" axis, which rep= resents many different quantities (e.g., component of a wind vector, concen= tration of a chemical, pressure, temperature, etc.) Generalizing this prob= lem to n-Dimensional data, we can see that of the "n" dimensions,= some dimensions are spatial, some are temporal, and the remainder are &quo= t;other". The essential problem is that OGC specifications only conta= in a vocabulary for describing spatial or temporal dimensions, leaving the = case of "other" unhandled. The root cause of this is stated in T= opic 2, which is also ISO 19111:<= /p>
Any dimension which is not spatial or temporal is not representable in t= he OGC/ISO CRS framework. Assuming the maximum of 3 spatial and 1 temporal= dimension, this allows us to represent, at most, a 4D + bands configuratio= n. It also leaves us unable to use an axis with units of Volts, Mass, Velo= city, etc. This shortcoming is important because it means that derived prod= ucts (like histograms) are not expressable in the OGC framework. One canno= t even write valid metadata to describe the dataset because ISO 19115 is ba= sed upon the same CRS framework.
The essential problem is that OGC specifications only contain a vocabula= ry for describing spatial or temporal dimensions, leaving the case of "= ;other" unhandled.
One could choose to represent the fifth dimension as a series of bands. = Alternatively, one could create one 4D dataset for each value present in t= he fifth axis. Both schemes lead directly to the problem of mapping values= along the fifth dimension into 4 dimensional space. One either maps value= s along the fifth axis to a particular band or to a particular 4D coverage.=
The problem with representing the fifth dimension as a sample band is th= at it fragments the index into the grid. The fifth dimension is the result= of the evaluate() operation on the other four dimensions. One maintains a= 4D index, then retrieves only the i-th property of the query. Th= ere is no easy way to subset using the fifth dimension.
Likewise, the index is fragmented when the fifth axis is represented by = completely independent 4D grids. Data selection becomes complex.
Unfortunately, no. This topic was investigated because our current effo= rt involves revisiting coverages. Our immediate needs are not for generic = N dimensional functionality, but for 4D + bands functionality. We were hop= ing to create a system whereby our 4D + bands requirement was just a subset= of the capabilities of a more general data processing and visualization sy= stem.
|Scope of the Multidimensional Grid Project|
This page should be taken to define the scope of the multidimensional co= verage effort within GeoTools. At the completion of this project, GeoTools= will implement as much coverage functionality as the OGC/ISO 191xx specifi= cations permit. To go further and produce a truly N dimensional data proce= ssing system will require changes to the specifications upon which GeoTools= is based. No such changes are being proposed at this time.