Hi Martin:
Martin Daly wrote:
http://motherlode.ucar.edu:8088/thredds/wcs/testdata/striped.nc
http://motherlode.ucar.edu:8088/thredds/wcs/testdata/sst.nc
http://motherlode.ucar.edu:8088/thredds/wcs/testdata/RUC.nc
I think I have fixed the first round of bugs, so please try again.
There is a slight problem in the capabilities documents. The
onlineResource URLs do not end in '?' or '&' as is mandatory in the spec
(section 6.3.1 again). However, that section also recommends that
clients be prepared for just such a case. Our client is, or at least it
is *now*.
fixed, thanks (ill update server soon)
The RUC.nc service returns GeoTIFF-s with extents much bigger than the
world. Is it really an EPSG:4326 dataset? The RectifiedGrid/origin/pos
from this request
http://motherlode.ucar.edu:8088/thredds/wcs/testdata/RUC.nc?REQUEST=Desc
ribeCoverage&SERVICE=WCS&VERSION=1.0.0&COVERAGE=Geopotential_height
suggests otherwise.
Definitely not a lat/lon dataset. Im not sure where I need to indicate that, and how to
do so. Its a Lambert Conformal projection with arbitrary parameters, theres no fixed EPSG
code that I know of. The geotiff has a "user defined" ProjectedCSTypeGeoKey:
19 IFDEntry == tag = 34735 (GeoKeyDirectoryTag) type = SHORT count = 68
values = 1 1 0 16 1024 0 1 1 1025 0 1 1 2048 0 1 4326 3072 0 1 32767
3073 34737 6 0 3074 0 1 32767 3076 0
geoKey = 1024 (GTModelTypeGeoKey) value = 1 (Projected)
geoKey = 1025 (GTRasterTypeGeoKey) value = 1 (Area)
geoKey = 2048 (GeographicTypeGeoKey) value = 4326 (WGS_84)
geoKey = 3072 (ProjectedCSTypeGeoKey,) value = 32767 (UserDefined)
geoKey = 3073 (PCSCitationGeoKey,) values = Snyder
geoKey = 3074 (ProjectionGeoKey,) values = 32767
geoKey = 3076 (ProjLinearUnitsGeoKey) value = 9001 (Meter)
geoKey = 3075 (GeoKey_ProjCoordTrans) values = 8
geoKey = 3078 (GeoKey_ProjStdParallel1) values = 25.0
geoKey = 3079 (GeoKey_ProjStdParallel2) values = 25.0
geoKey = 3088 (GeoKey_ProjCenterLong) values = -95.0
geoKey = 3081 (GeoKey_ProjNatOriginLat) values = 25.0
geoKey = 3080 (GeoKey_ProjNatOriginLong) values = -95.0
geoKey = 3092 (ProjScaleAtNatOriginGeoKey) values = 1.0
geoKey = 3082 (GeoKey_ProjFalseEasting) values = 0.0
geoKey = 3083 (GeoKey_ProjFalseNorthing) values = 0.0
20 IFDEntry == tag = 34736 (GeoDoubleParamsTag) type = DOUBLE count = 8
values = 25.0 25.0 -95.0 25.0 -95.0 1.0 0.0 0.0
21 IFDEntry == tag = 34737 (GeoAsciiParamsTag) type = ASCII count = 7
values = Snyder
Finally, the 0 to 360 range doesn't seem to be a problem - at least for
our client - because the result of the request, below, is a GeoTIFF with
coords in the -180 to 180 range, and we trust that. I must admit to
being a bit uncomfortable with the discrepancy though, and would prefer
the -180 to 180 range throughout. I think that that would maximise
interoperability.
Sometimes I think half of my code is spent dealing with a cylindrical earth!
One problem with requiring a fixed range like [-180,180], is that its when
representing areas that cross the the seam, the left coordinate is less than
the right. So you need to also clarify that the area included is easternly
from the first point (or something like that). I cant say the schema makes that
clear in my mind:
<xs:element name="lonLatEnvelope" type="LonLatEnvelopeType"/>
<xs:complexType name="LonLatEnvelopeBaseType">
<xs:annotation>
<xs:documentation>
For WCS use, LonLatEnvelopeBaseType restricts gml:Envelope to the WGS84 geographic CRS with Longitude preceding Latitude and both using decimal degrees only. If included, height values are third and use metre units.
</xs:documentation>
<xs:documentation>Envelope defines an extent using a pair of positions
defining opposite corners in arbitrary dimensions.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="gml:EnvelopeType">
<xs:sequence>
<xs:element ref="gml:pos" minOccurs="2" maxOccurs="2"/>
</xs:sequence>
<xs:attribute name="srsName" fixed="WGS84(DD)"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
Generally I allow any values of longitude, and always mod them into the range I
want.
I wonder whether the GML spec says what the valid longitude values are?