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

[John Caron]

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
>>>>     
>>>
>>>   
>