Dear Steve,
Thanks for your reply. And this is my first time posting, so forgive my lack of information. I'm running mapserver 6.0.3 with gdal 1.9.0 (compiled with libecwj) on Ubuntu 12.04. In both QGis 1.7.0 and Mapinfo 10.5 I tried to load both the original image (both as tif and ecw), and the served image in the same viewer. As I toggled between the images (after drawing some reference points) I could see the image shifted slightly in relation to the reference point. I did for several corners, and the shift seems to be somewhat inconsistent, moving in several directions in different areas of the image. But assuming a bounding box model problem, how would I be able to find such a thing out? Fritz ________________________________ Van: Lime, Steve D (DNR) [mailto:steve.l...@state.mn.us] Verzonden: maandag 4 juni 2012 23:35 Aan: Fritz van Deventer; mapserver-users@lists.osgeo.org Onderwerp: RE: Shift of half a pixel What version are you talking about? How do you know there is a shift? That is, what is your reference? Is it possible there's a difference in the bounding box model? For WMS the bbox represents the outside dimensions of the pixels in an image. Steve Note: MapServer uses a pixel center bbox model but that difference (with WMS's representation) is taken into account in the WMS code. From: mapserver-users-boun...@lists.osgeo.org [mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Fritz van Deventer Sent: Monday, June 04, 2012 9:27 AM To: mapserver-users@lists.osgeo.org Subject: [mapserver-users] Shift of half a pixel Hi all, We are trying to get VHR satellite imagery to run as a WMS in different GIS clients. When we compare the original image (we tried different formats, tif, ecw, virtual formats etc.) to the hosted image we see a shift in the pixels. Looks like a minor warp or transform. We are unable to find what is causing this error. We tried using different output drivers, and different output and input formats. It looks like serving with GDAL as output format and Imagemode on FLOAT32 gives the best result, however in black and white. If this is a known issue, is anyone able to tell me the (in)accuracy of the shift? Or is it not supposed to happen altogether? Regards, Fritz van Deventer - http://neo.nl
_______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
