On 06/27/2012 01:59 PM, Andrea Aime wrote:On Tue, Jun 26, 2012 at 10:26
PM, Michael Romero
Nice. Is this store something that could be of general use? What kind
of data source does it use? (just curious)
The data is in the form of GeoTiffs so there's nothing new in terms of
data processing. The reason we needed a custom store is because we are
dealing with 300,000+ files that change every 6 hours. These files are
stored at a METOC data center and we download the files on demand when
the user requests a layer. We added time and elevation modeled after the
Image Mosaic store but using a DB instead of shape file and that got the
number of layers down to about 1,500. I don't think it would be much use
to the community because of how specific the data source is. However,
I'll put some more thought into how to generalize the concept.
Makes sense, but wondering if it would not be better to have a single
drop down with the list of the ISO units.
Isn't the unit symbol implied by the chosen unit?
I thought about doing that at first but there is no finite list because
the WMS specification is pretty flexible:
If the dimensional quantity has units, unit names should be taken from
the Unified Code for Units of Measure
(UCUM) if UCUM has an appropriate entry. When UCUM is used, the
mandatory units attribute shall be an
appropriate entry from the UCUM "name" column.
If present, the unitSymbol shall be a 7-bit ASCII character string. When
UCUM is used, the unitSymbol shall
be the entry from the UCUM "c/s" column (case-sensitive abbreviation)
corresponding to the UCUM name.
UCUM prefix names and symbols may be present as well.
The specification actually allows anything but suggests using units from
the UCUM.
Sigh... yes, there are, it is a combination of bad design on my part
and bad timing vs the 2.2.0 release.
The above would be API changes, since you'd need new fields,
which are not allowed anymore now since we are releasing a RC this week,
tomorrow if all goes well, which means trunk is becoming the new
stable series and its API is cast in stone.
In particular we have to ensure that it's possible to move forwards
and backwards within the stable
series using the same data dir, so no new explicit configuration
fields can be added
No worries, I wasn't planning on getting this into the 2.2.0 release.
I've been following the emails on the devel list :)
Normally we handle that by using the open ended MetadataMap that is
available in most CatalogInfo
objects, sticking the new values in it on the stable series, and add
the new fields on the unstable one
so that the XML persistence format does not change along a stable series
... unfortunately I forgot to add that into DimensionInfo, and doing
that now is yet another API change...
I can go ahead and add this to the DimensionInfo while I'm at it.
The only clean way to handle this now is to make it happen on the new
trunk, which is going to become
2.3.0 in six months, once we branch off the current one to a new 2.2.x
branch
(see also GSIP 77, time boxed releases, on how we are going to handle API
changes from now on).
That's the plan.
Thanks for the input,
Michael Romero
Forward Slope Inc.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
