Opened 8 years ago

Closed 7 years ago

#1497 closed enhancement (fixed)

WCS_Client shows coverage's extents in a dropdown box — at Version 9

Reported by: Vlad Merticariu Owned by: Bang Pham Huu
Priority: major Milestone: 9.5
Component: wcsclient Version: development
Keywords: Cc: Dimitar Misev, Bang Pham Huu
Complexity: Medium

Description (last modified by Bang Pham Huu)

The task is to add a section similar to Avaialble coverages on the first page of the client. It should contain a map (WebWorldWind) displaying rectangles which represent the extents of the available coverages, which can be extracted from a made-up service localhost:8080/rasdaman/ows/GetCoveragesExtents (returns all the coverages's extents which can be reprojected to EPSG:4326, non geo-referenced coverage is not available in the result from service).

On hovering over a rectangle, a tooltip showing the name and extent of the coverage should be displayed.

Change History (9)

comment:1 by Vlad Merticariu, 8 years ago

Cc: Andrei Badoi added
Owner: changed from Ahmed Elshayeb to drusu
Status: newassigned

comment:2 by Bang Pham Huu, 7 years ago

Cc: Bang Pham Huu added
Milestone: 9.5

comment:3 by Bang Pham Huu, 7 years ago

Owner: changed from drusu to Bang Pham Huu

comment:4 by Bang Pham Huu, 7 years ago

Cc: Andrei Badoi removed
Summary: enhance wcs-client with map drop downWCS_Client shows coverage's extents in a dropdown box

The ticket's idea seems easy, however, it is hard as DescribeCoverage returns nothing about the XY extent, in case of 3D, 4D coverage, no idea to parse geo-domains.

Also, for getting the extents of all coverages by DescribeCoverage (it is not efficient to load all the metadata from the database just for these extents when starting web application).

Finally, coverage can be different CRS for XY geo-domains (CRS:4326, CRS:3857, CRS:32630,…) so it is not always to be able to show the coverages' extents if the CRS reprojection cannot do it.

My suggestion is make up a WCS request like this:

localhost:8080/rasdaman/ows?service=WCS&version=2.0.1&request=GetCoveragesExtents

then it will return a list of geo-referenced coverages which could be displayed in Openlayers (by default CRS is EPSG:4326). The coverages's extents are reprojected to EPSG:4326 in Petascope, in case of cannot reproject, just don't add it to the result list.

"coverageExtents": [
  { "name": "coverage1",
    "Lat": 20.2422,
    "Long": 23.4664
  }, { "name": "coverage2",
    "Lat": 30.2422,
    "Long": 43.4664
  }, { "name": "coverage3",
    "Lat": 26.2422,
    "Long": 28.4664
  },...
]

in reply to:  4 ; comment:5 by Dimitar Misev, 7 years ago

Replying to bphamhuu:

The ticket's idea seems easy, however, it is hard as DescribeCoverage returns nothing about the XY extent, in case of 3D, 4D coverage, no idea to parse geo-domains.

I think this should not be so hard. You have the CRS of the coverage. Typically it's some compound CRS, of one or more 1D CRS (e.g. Index1D, AnsiDate, etc.) and a 2D geographic one. It should be easy to determine which one is the geo-crs.

I remember that the GetCapabilities has an optional geo-bbox output:

# purpose:       true/false switch for enabling/disabling the insertion of wcs:BoundingBox elements
#                in every wcs:CoverageSummary (capabilities document).
bbox_in_covsummary=true

Doesn't the DescribeCoverage have something similar?

in reply to:  5 comment:6 by Bang Pham Huu, 7 years ago

Replying to dmisev:

Replying to bphamhuu:

The ticket's idea seems easy, however, it is hard as DescribeCoverage returns nothing about the XY extent, in case of 3D, 4D coverage, no idea to parse geo-domains.

I think this should not be so hard. You have the CRS of the coverage. Typically it's some compound CRS, of one or more 1D CRS (e.g. Index1D, AnsiDate, etc.) and a 2D geographic one. It should be easy to determine which one is the geo-crs.

I remember that the GetCapabilities has an optional geo-bbox output:

# purpose:       true/false switch for enabling/disabling the insertion of wcs:BoundingBox elements
#                in every wcs:CoverageSummary (capabilities document).
bbox_in_covsummary=true

Doesn't the DescribeCoverage have something similar?

The BoundingBox of GetCapabilities (no option in new Petascope anymore, always appear) for example 3D like this:

 <wcs:CoverageSummary>
            <CoverageId xmlns="http://www.opengis.net/wcs/2.0">test_aggregated_ansidate_netcdf</CoverageId>
            <CoverageSubtype xmlns="http://www.opengis.net/wcs/2.0">ReferenceableGridCoverage</CoverageSubtype>
            <ows:BoundingBox
                crs="http://localhost:8080/def/crs-compound?1=http://localhost:8080/def/crs/EPSG/0/3577&amp;2=http://localhost:8080/def/crs/OGC/0/AnsiDate"
                dimensions="3" xmlns:ows="http://www.opengis.net/ows/2.0">
                <ows:LowerCorner>75042.7273594 5094865.5579399997 "2008-01-01T02:01:19.999Z"</ows:LowerCorner>
                <ows:UpperCorner>705042.7273594 5454865.5579399997 "2008-01-08T00:02:57.999Z"</ows:UpperCorner>
            </ows:BoundingBox>
        </wcs:CoverageSummary>

which one is X, Y axis? from WCS DescribeCoverage is the same, here is 5D

        <lowerCorner>-60.000003 -180 -0.5 -0.5 "2008-03-31T12:00:00.000Z"</lowerCorner>
        <upperCorner>89.999997 180 30.5 50.5 "2008-04-01T12:00:00.000Z"</upperCorner>

It is cumbersome to determine X,Y axes in WCS-Client just based on these information from DescribeCoverage/GetCapabilties from CompoundCrs. It is much easier to handle in Petascope and WCS-Client just display the possible extents.

comment:7 by Dimitar Misev, 7 years ago

The BoundingBox of GetCapabilities (no option in new Petascope anymore, always appear)

why, is it mandatory in WCS? seems like a backwards incompatible change for petascope..

in reply to:  7 comment:8 by Bang Pham Huu, 7 years ago

Replying to dmisev:

The BoundingBox of GetCapabilities (no option in new Petascope anymore, always appear)

why, is it mandatory in WCS? seems like a backwards incompatible change for petascope..

WCS GetCapabilities without BoundingBox for coverage is invalid result, before it is set because it queries the sdom to rasserver so it was slow and disable it to make Petascope starts much faster.

comment:9 by Bang Pham Huu, 7 years ago

Description: modified (diff)
Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.