Martin Daly wrote:
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".
My preferrence would also be to trust the returned dataset. It seems
like there may be some good reasons why the return may not match exactly
the request.
Of course, this assumes that the returned dataset is self-describing,
which is still a goal rather than a fact.
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.
I cant wait.
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!
i was just thinking it could be added to the schema documentation, as a
clarification to the meaning
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?
we always assume + means north, east, and - means south, west
