GeoDAP
Introduction
It seems like the basic problem that we encounter again and again these days is that the DAP lacks the explicit semantics to link geo-location information to data values. If we were to address this issue in the DAP data model (say as part of DAP4, or a GeoDAP extension/profile) I think a lot of good could come out of it. I imagine that a lot of people would be enthusiastic about it.
My basic idea is that we would add to the DAP a location version of each data type. Thus a GeoFloat32 would contain the explicit information to associate that value (whatever the value represents, say temperature) with a location on the planet. The real meat for us would probably lie in the more complex structural types like GeoGrid, in that subsampling and other geo-functions could then become part of the naive API for the type. Since older clients wouldn't be asking for DAP4 responses, I imagine the location information would get pushed in to the Attribute space for them.
I can see this being implemented as a kind of object design. And one where the higher level 'Geo' objects are returned only for clients that ask for them. We might make this a DAP4 thing - that is, return the Geo objects when a client announces it's DAP4 savvy, or we might make it a separate thing from DAP4. the latter would open up an avenue for other things besides Geographic specializations. In either case, the idea is that the more basic classes would hold the same information but using attributes. Effectively the server could be implemented so as to return the Geo classes when
- it gets the correct Accept: header from a client
- the necessary attributes are present for the given type.
This kind of a design is significantly different from the 'profile' concept because it has a fallback mode so unsavvy clients can still access all of the data. We're using attributes to add support for new operations.
Downside: I think there are issues with units lurking here, but if we can figure that out we will really have something huge - and without a magic bullet for units, we still will have an important step forward.
We would probably want to work up a design, and then see how it might impact the various software components in our library. I think that we could modify the netcdf and hdf4/5 handlers to recognize conventions (like CF-1.0) so that they would produce GeoDAP data sets whenever possible. We might even look to the work with Benno and the semantic ontologies as an intermediate mechanism for promoting DAP data using new conventions (CF-2.0 or whatever) into GeoDAP prior to the handlers getting updated.
This could make server side functions like geogrid() very straight forward. We might also wish to look at the CE syntax and see if these types might also allow for extensions to the CE to support geo-related activities. I think WCS work would be greatly simplified, and we might be able to add more complex server features such as CRS transformations in the future. The new types could add new operations - since that's what new types generally do. The advantage of new operations for new types is that we get away from the problem of sorting out which functions are present. Now we have a type system to use that determines which operations are present.
Types
Simple
- GeoByte
- GeoInt16
- GeoInt32
- GeoInt32
- GeoFloat32
- GeoFloat64
- GeoString
- GeoURL
Complex
- GeoArray
- GeoStruct
- GeoSequence
- GeoGrid
