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:
One cheat would be to use/abuse the "Engineering" or "Image" CRS-s that are allowed alternatives to
"EPSG:xxxx". We could certainly modify our client to allow that to be used. As I said in my previous response, at the
moment we trust the extents of the response GeoTIFF, rather than the request BBOX (not sure why come to think of it). We could
extend this to also trust the response GeoTIFF CRS in the case of "Engineering" or "Image".
Sometimes I think half of my code is spent dealing with a
cylindrical earth!
Just wait until someone brings up the lat/lon-vs-lon/lat thing. Then you know
that you've been assimilated into OGC.
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:
I'm not sure that schema can do this, but look forward to seeing you try!
My interoperability concern is more for the case when the extents don't go
outside to [0,180] and [0,90] range. How can a client know whether this is
right or left of the prime meridian, or above or below the Equator?
Perhaps the correct answer is that the extents should be relative to the origin
of the CRS which, for EPSG:4326, is the intersection of the Equator and the
Greenwich meridian. That might be unfairly weighted in the [-,+] camp though,
because I'm not sure that there is a way of specifiying the latitudnal origin
in GeoTIFF CRS-s (or anywhere else for that matter). The longitudnal origin is
taken care of by the prime meridian, of course.
Regards,
Martin