[thredds] Problems with lonLatEnvelope using WCS with a stereographic file

[Heiko Klein]

Hi John,

I would express it a bit different: lat/lon boxes are difficult for 
everything but equatorial cylindrical projections. As soon as you select 
the projection parameter latitude_of_projection_origin to be different 
from 0, you can span data across the pole and mapping of the 
corner-points to latLon boxes will give strange results.

For practical reasons, I prefer to have 'false positives' (i.e. bounding 
box larger than data area) than to have 'false negatives' (i.e. data 
outside the bounding box). I solve this by using 100x100 samples of the 
data-area and converting it to latLon. (see attached 
getExpensiveLatLonBoundingBox in GridCoordSys.java, which is the method 
used in thredds4.0/WCS/getCapabilities). With this, the false negatives 
is below 1% and performance is still restricted by IO.

Since all CF-1.2 projections (except latLon) allow to change 
latitude_of_projection_origin, all projections might fail to retrieve 
the BB. So, something similar to the attached method should rather be 
the default than the exception.

Currently thredds/WCS doesn't use ProjectionImpl.latLonToProjBB in 
GridCoordSys.java for BB, but I aggree that it should.

Best regards,

Heiko

John Caron wrote:
> Hi Heiko:
> 
> the problem is that lat/lon boxes dont work well for polar projections. We have 
> a framework to add specializations, using a method on 
> ucar.unidata.geoloc.ProjectionImpl:
> 
>    /**
>     * Convert a lat/lon bounding box to a world coordinate bounding box,
>     * by finding the minimum enclosing box.
>     * Handles lat/lon points that do not intersect the projection panel.
>     *
>     * @param latlonRect input lat,lon bounding box
>     * @return minimum enclosing box in world coordinates, or null if no part of 
> the LatLonRect intersects the projection plane
>     */
>    public ProjectionRect latLonToProjBB(LatLonRect latlonRect);
> 
> if you have source, you can see what the generic algorithm does. We have one 
> projection (VerticalPerspective) that overrides it. A similar override should be 
> done in Stereographic (I think thats the one you use?).
> 
> It would be great to have some code that we can fit into this. let me know if 
> this makes sense.
> 
> thanks!
> 
> 
> 
> Heiko Klein wrote:
>> Hi,
>>
>> I just tested the 4.0 snapshot Ethan send me last week. I see, you put 
>> some effort testing if the pole is inside the dataset and the 
>> bounding-box is now:
>> <lonLatEnvelope srsName="WGS84(DD)">
>> <gml:pos>-76.99999999999999 28.263336016688474</gml:pos>
>> <gml:pos>153.9644871012531 90.0</gml:pos>
>> </lonLatEnvelope>
>>
>> So, one of 4 points is as I expect ;-) The values are stable, that is 
>> the problem with axes in m seems to have disappeared.
>>
>> I don't think it is possible to detect the bounding-boxes 'correctly' by 
>> just projecting the corner-points. I would either project the axes and 
>> use some polygons, or map the complete data-region. But this is of 
>> course a greater computational effort. If you're interested, I can try 
>> to come up with some code.
>>
>> Best regards,
>>
>> Heiko
>>
>>
>> John Caron wrote:
>>> Ah yes, thanks, that makes a lot of sense. We've had a lot of trouble 
>>> getting the km/m conversion correct. Ill try to get it fixed.
>>>
>>> Heiko Klein wrote:
>>>> Hi,
>>>>
>>>> I just made another observation: when changing the units of the 
>>>> projection_?_axis from m to km, the results are stable and stay those 
>>>> of the first try.
>>>>
>>>> Heiko
>>>>
>>>> Heiko Klein wrote:
>>>>  
>>>>> Hi,
>>>>>
>>>>> I have a file with gridded polar-stereographic data in CF-1.0, which
>>>>> shows nicely in IDV. When putting the file on thredds and requesting 
>>>>> WCS
>>>>> GetCapabilites, I receive the following:
>>>>>
>>>>> First try:
>>>>>
>>>>> <lonLatEnvelope srsName="WGS84(DD)">
>>>>> <gml:pos>-77.0 43.95245311362685</gml:pos>
>>>>> <gml:pos>103.0 43.95245311362685</gml:pos>
>>>>> </lonLatEnvelope>
>>>>>
>>>>>
>>>>> Second try:
>>>>> no envelope
>>>>>
>>>>> Third try:
>>>>> <lonLatEnvelope srsName="WGS84(DD)">
>>>>> <gml:pos>-32.0 90.0</gml:pos>
>>>>> <gml:pos>-32.0 90.0</gml:pos>
>>>>> </lonLatEnvelope>
>>>>>
>>>>> And it stays at the values of the third try, which are the definitions
>>>>> of the projections (polar-stereographic, view at -32 degree) rather 
>>>>> than
>>>>> the envelope.
>>>>>
>>>>> The data spans over the northpole, so longitude is from 0-360 while
>>>>> latitute starts at 90 and has a minimum value of 43 degree.
>>>>>
>>>>> The file can be found at ftp://ftp.met.no/pub/emep/heikok/testShort.nc
>>>>> (1.6MB)
>>>>> I'm running thredds 3.16 on linux with java 1.6 and tomcat 6
>>>>>
>>>>> Does anybody know how I can solve the problem of the wrong envelope?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Heiko
>>>>>     
>>>>   
> _______________________________________________
> thredds mailing list
> thredds at unidata.ucar.edu
> For list information or to unsubscribe,  visit: http://www.unidata.ucar.edu/mailing_lists/ 

-- 
Dr. Heiko Klein                              Tel. + 47 22 96 32 58
Development Section / IT Department          Fax. + 47 22 69 63 55
Norwegian Meteorological Institute           http://www.met.no
P.O. Box 43 Blindern  0313 Oslo NORWAY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GridCoordSys.java
Type: text/x-java
Size: 47896 bytes
Desc: not available
Url : http://mailman.unidata.ucar.edu/mailing_lists/archives/thredds/attachments/20080618/67bac409/attachment-0001.java