[mapserver-users] WCS Tile index question

[Carl Godkin]

Hi again Jukka,

Thanks for the speedy response.  I now think that I have the resolution and
extent correct with these.  (I was getting various errors trying other
things but this
set seems okay for GetCoverage, GetCapabilities and DescribeCoverage):

        "ows_extent" "-125 24 -66 50"
        "wcs_resolution" "0.0008333333 0.0008333333"

I actually retrieve a correctly located GeoTIFF (yay!!) out with this query
for instance:

http://localhost:8080/wcs?service=WCS&version=2.0.1& request=GetCoverage&
coverageid=SRTM_3_arc-second_grid& format=geotiff_16&
subset=Lat(43.256274,43.721318)& subset=Long(-112.357549,-111.719135)

but it's all zeros.

My data files are all native SRTM ".hgt" files. (And yes, I did "gdalinfo
-stats" on one tile for the above query and there are good values.)

I could gdal_translate them all to GeoTIFF, but since GDAL supports HGT
files I hoped I could use them as is.

I have tried everything I can think of for the "wcs_native_format" metadata:

      "wcs_native_format" "application/srtmhgt"

and application/hgt, image/hgt, srtmhgt, etc. I don't see errors in
mapserver log though no matter what I try. Is this my problem?

What do you suggest?

Thanks again,
carl









On Wed, Oct 20, 2021 at 3:23 PM Rahkonen Jukka (MML) <
jukka.rahkonen at maanmittauslaitos.fi> wrote:

>
>
> Lähettäjä: MapServer-users <mapserver-users-bounces at lists.osgeo.org>
> Puolesta Carl Godkin
>
>
>
> >> On Tue, Oct 19, 2021 at 5:37 PM Rahkonen Jukka (MML) <mailto:
> jukka.rahkonen at maanmittauslaitos.fi> wrote:
> >> Hi,
>
> >> Here is more accurate documentation but only in the text
> >> https://www.mapserver.org/ogc/wcs_server.html
>
> >> “The convention is that once (wcs|ows)_extent and one of
> >> (wcs|ows)_size and (wcs|ows)_resolution is set in the layer metadata,
> all the coverage specific metadata will be retrieved from there. Otherwise
> the source image is queried via GDAL, if possible.”
>
> >> It seems that only wcs_extent is documented in the list of metadata
> elements but this is what they do:
> >> • wcs_extent defines the bounding box or your coverage -> that will
> >> go into DescribeCoverage • wcs_size is the size of the coverage as
> >> pixels -> pixel size can be computed by extent and size •
> >> wcs_resolution tells the pixel size explicitly -> size of the
> >> coverage in pixels can be computed
>
> > Thanks a lot, Jukka.  That all makes some sense as far as it goes, but
> > I'm still not clear on a few details. I have this range of data: 24N to
> 50N and 125W to 66W which is 26 degrees by 59 degrees.
>
> >  Since the SRTM data has 3 arc-second spacing, that's 1200 pixels per
> > degree plus one for the extra edge so I have tried a number of things
> without success.
>
> What fails? Don't you get anything into DescribeCoverage or is all that
> you get wrong?
>
> > 1. Is wcs_size the size FULL range of the tiles that I have?  And what
> is the order?
>
> You do not need to bother about the size if you set the resolution, but
> yes, it is the full range of the coverage. See this
> https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS&REQUEST=DescribeCoverage&VERSION=2.0.1&COVERAGEID=ortokuva__ortokuva
>
> The size is converted into the pixel space of the coverage
> gml:GridEnvelope>
> <gml:low>0 0</gml:low>
> <gml:high>1348356 2316499</gml:high>
> </gml:GridEnvelope
>
> I would say that the order is left-to-right - down-to-up but I fear that
> by the GML standard it can be something else. You can read about rectified
> grid from the OpenGIS Geography Markup Language (GML) Encoding Standard
> 3.2.1. I have never understood it but there are some images which may
> clarify this: "rectified grid: grid for which there is an affine
> transformation between the grid coordinates and the coordinates of an
> external coordinate reference system"
>
> > 2. Again, what is the order for wcs_resolution?  Are the units degrees
> since the coordinate system of the original data is EPSG:4326?
> With Mapserver the order is easting/longitude - northing/latitude
>
> > I've tried all of these, one at a time, and get various errors.  (1 /
> > 1200 = 0.00083333...)
> What errors?
>
> >        #"wcs_resolution" "0.00083333 0.00083333"
> Looks right
> >        #"wcs_size" "70801 31201"
> Looks right if you prefer to give size instead of resolution
> >        "wcs_size" "31201 70801"
> This is wrong.
>
> > In case it's helpful, here's my LAYER definition (with probably extra
> things I've tried based on my searching and trial & error):
>
>     LAYER
>       NAME SRTM_3_arc-second_grid
>       METADATA
>         "wcs_label"           "SRTM - 3 arc-second grid"  ### required
>         "wcs_rangeset_name"   "Range 1"  ### required to support
> DescribeCoverage request
>         "wcs_rangeset_label"  "Lower 48" ### required to support
> DescribeCoverage request
>         "ows_extent" "-125 24 -66 50"
>         #"wcs_resolution" "0.00083333 0.00083333"    # 1/1200 for 3"
> spacing?
>         #"wcs_size" "70801 31201"                    # Not sure of order
>         "wcs_size" "31201 70801"
>         "wcs_bandcount" "1"
>         "wcs_native_format" "SRTMHGT"    # What should this be?  I can't
> find examples...
>
> It is supposed to be the native format of the layer data, format that
> theoretically requires no processing, just selecting the right pixels. In
> practice the format that you users get by default with GetCoverage. It goes
> into DescribeCoverage about this way:
> <wcs:nativeFormat>image/tiff</wcs:nativeFormat>
> and it is documented in the WCS 2.0.1 Core standard:
> "4.7 Native Format
> encoding format where, in a GetCoverage request, the range set values can
> be obtained unaltered"
>
>         "wcs_srs" "EPSG:4326"
>       END
>
>       TYPE RASTER ### required
>       STATUS ON
>       TILEINDEX "../srtm_3_hgt/srtm_3_hgt-index.shp" # Path is relative to
> SHAPEPATH
>       TILEITEM "Location"
>       PROJECTION
>         "init=epsg:4326"
>       END
>     END
>
> > I feel like I must be close.  Thanks a lot for any further pointers,
>
> -Jukka-
>
> > carl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20211020/e175c59a/attachment-0001.html>