D4Science Infrastructure

Sorry, but I didn't understand the request :
if the issue is in the ISO metadata we should edit that, which resides on GeoNetwork, not Thredds.
If the issue is in the dataset (or in the metadata inside it, being a netcdf) we should republish the dataset (but no idea what you mean by fixing thredds - side).

Also, It would help to know how this layer has been generated. If it has been generated/published programmatically, we should address the generator too, otherwise this situation will repeat.

Yes, @fabio.sinibaldi@isti.cnr.it you're right, I presented the problem incorrectly saying 'Thredds side'.
Precisely, the issue is in the metadata of Thredds layers saved on GN. As above presented, currently, they are not compliant to WMS 1.3 as lat/long (their BBOX is compliant to WMS 1.1 as long/lat).
Who/How is publishing new layers I don't know, @gianpaolo.coro@isti.cnr.it can clarify this question.. However, also old layers published have this problem (they are published as long/lat but Thredds calls are performed using WMS version 1.3 that reads the BBOX as lat/long).

I hope this clarify the issue

Ok, now I understand.
By inspecting the metadata, it seems it is a bit old layer : all publication and creation date reported are from 2013. If that's correct, the logic involved in producing these wrong metadata may be already dismissed, but we should investigate on this.
Anyway, as far as i understand, the viewer simply relies on the wms request in the metadata file. We can have different approaches on this :

• republish the metadata modifying the bbox in the query string : definitely a tricky task for various reasons and it probably doesn't solve (future layers, harvested layers and in general layers that we don't have control on)
• modify the gui/involved servlets in order to use the bounding box declared in the ISO metadata i.e. :

 <gmd:extent>
        <gmd:EX_Extent>
          <gmd:description>
            <gco:CharacterString>Bounding box</gco:CharacterString>
          </gmd:description>
          <gmd:geographicElement>
            <gmd:EX_GeographicBoundingBox>
              <gmd:extentTypeCode>
                <gco:Boolean>true</gco:Boolean>
              </gmd:extentTypeCode>
              <gmd:westBoundLongitude>
                <gco:Decimal>-177.5</gco:Decimal>
              </gmd:westBoundLongitude>
              <gmd:eastBoundLongitude>
                <gco:Decimal>177.5</gco:Decimal>
              </gmd:eastBoundLongitude>
              <gmd:southBoundLatitude>
                <gco:Decimal>-87.5</gco:Decimal>
              </gmd:southBoundLatitude>
              <gmd:northBoundLatitude>
                <gco:Decimal>87.5</gco:Decimal>
              </gmd:northBoundLatitude>
            </gmd:EX_GeographicBoundingBox>
          </gmd:geographicElement>
        </gmd:EX_Extent>
      </gmd:extent>
    </gmd:MD_DataIdentification>

• modify gui/servlets involved in order to use the capabilities method of WMS (if I remember correctly open layers should be able to manage that) like : http://thredds.d4science.org/thredds/wms/public/netcdf/HadCRUT.4.2.0.0.median_CLIMATOLOGY_METEOROLOGY_ATMOSPHERE_.nc?service=WMS&version=1.3.0&request=GetCapabilities

In my opinion the last option is the more robust one, since it doesn't rely on specific details declared in metadata but on the actual managed data by the WMS server.