Sorry, I was wrong in the previous message; the resx and resy settings do show up in the capabilities document. They make no difference, however; the bounding box requested by QGis is still in error.
SixDegrees wrote > > Thank you. I added wms_resx and wms_resy to my mapfile with reasonable > values (and some unreasonable ones, just as tests). This makes no > difference. When I make a GetCapabilities request, the layer's bounding > box is correct but it does NOT contain the resx or resy settings, as I > believe it should. > > I don't know if this is a problem in my mapfile or in MapServer. My > mapfile layer looks like this (file names changed for proprietary > reasons): > > LAYER > NAME "MyImage" > GROUP "MyGroup" > EXTENT 75.80425 35.304 76.01625 35.476 > METADATA > "wms_title" "MyImage" > "wms_group_title" "MyGroup" > "wms_extent" "75.80425 35.304 76.01625 35.476" > "wms_srs" "EPSG:4326" > "wms_resx" "1.0" # Note: these values are for testing only. The > actual values have > "wms_resy" "1.0" # also been tried, with no success. They are > 5.90139233796e-06, -4.85244300668e-06 > END > PROCESSING "SCALE=AUTO" > PROCESSING "SCALE_BUCKETS=256" > TYPE RASTER > DATA "MyImage.vrt" > PROJECTION > "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs" > END > END > > > > > Rahkonen Jukka wrote >> >> Hi, >> >> WMS does not advertise by default the native resolution of the data. I >> have never tried but perhaps adding wms_resx, wms_resy metadata into >> layer metadata would add that information into GetCapabilities >> http://mapserver.org/ogc/wms_server.html. >> I do not know if QGis can utilise that information even if it exists. >> >> -Jukka Rahkonen- >> >> SixDegrees wrote: >> >>> I'm not sure if this is a QGis problem or a problem with my >> Mapserver-generated WMS layer. When I load a WMS image in QGis, >> everything >> works as expected except when I select 'Zoom to best scale' I get a >> Mapserver error stating that the bounding box is illegal. And it is - the >> bounding box corner points in the getmap request are identical. This >> selections is supposed to zoom in so the pixels displayed are 1:1 or 100% >> >>> A look at the capabilities request returned by Mapserver and the mapfile >>> and >> images involved don't show anything obviously wrong. Is it possible that >> QGis is sending the wrong request? Or is something missing from either >> the >> capabilities document or the mapfile layer? >> >>> I'm not really sure where to start looking to isolate the problem. Note >>> that >> if I load images directly instead of through Mapserver WMS I am able to >> zoom >> to scale without any problem, which suggests a problem with Mapserver, >> likely in the mapfile. I am using VRT files as intermediaries between the >> Mapfile and the underlying NITF files; it seems that Mapserver should be >> using the affine transform contained in the VRT to determine proper >> scaling, >> but I'm not sure if that is sufficient. Are there arguments that need to >> be >> placed in the Mapfile metadata to help WMS generation along? Or something >> that would cause items in the capabilities document to be left out? >> >>> Using QGis 1.7.0 on Linux. >> >> -- >> View this message in context: >> http://osgeo-org.1803224.n2.nabble.com/QGis-Zoom-to-best-scale-Not-Working-tp7017776p7017776.html >> Sent from the Mapserver - User mailing list archive at Nabble.com. >> _______________________________________________ >> mapserver-users mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> _______________________________________________ >> mapserver-users mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> > -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/QGis-Zoom-to-best-scale-Not-Working-tp7017776p7020066.html Sent from the Mapserver - User mailing list archive at Nabble.com. _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
