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.rahko...@maanmittauslaitos.fi> wrote: > > > Lähettäjä: MapServer-users <mapserver-users-boun...@lists.osgeo.org> > Puolesta Carl Godkin > > > > >> On Tue, Oct 19, 2021 at 5:37 PM Rahkonen Jukka (MML) <mailto: > jukka.rahko...@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 > >
_______________________________________________ MapServer-users mailing list MapServer-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users