I figured out what was going on. It was an easting-northing mixup in the map and layer extents. Apparently earlier versions of mapserver/mapscript tolerated the bug. Anyway it's all working now under Windows Server 2008 x64 and IIS 7 FastCGI. A big thanks to the mapserver community. Open source rocks!
Regards, Dan Walton GIS Fire Tools <http://gisfiretools.com> On Mon, Dec 7, 2009 at 4:25 PM, Daniel Walton <dgwal...@gmail.com> wrote: > Tamas, > > Thanks for the tip. I used process monitor and everything looks OK in the > permissions department. I think the problem relates to the fact that > mapserver doesn't calculate an overlap between map and layer. I'm not sure > what would cause this. > > -Dan > > > > On Mon, Dec 7, 2009 at 3:22 PM, Tamas Szekeres <szeker...@gmail.com>wrote: > >> Daniel, >> >> This may also be an issue if GDAL couldn't actually open this file bacause >> of any reason (permission?). >> Make sure about this, by using a file monitoring tool, like SysInternals >> filemon for instance. >> >> Best regards, >> >> Tamas >> >> >> >> 2009/12/7 Steve Lime <steve.l...@state.mn.us> >> >> If I take the request out of WMS context to straight CGI with this >>> request: >>> >>> http://www.fireimagery.com/ms/mapserv.exe?map=C >>> :\maps\A091207074551.map&mode=map&mapsize=300+300&layer=ZZ >>> >>> I get the following error: >>> >>> msDrawMap(): Image handling error. Failed to draw layer named 'ZZ'. >>> msDrawRaster(): Image handling error. Unrecognized or unsupported image >>> format drawEPP(): Image handling error. EPPL7 support is not available. >>> >>> Typically you'll see that when GDAL failed to identify the filetype. >>> EPPL7 is the last thing checked so that's not relevant by itself. I guess >>> I'd start >>> by making sure the image is valid. >>> >>> Steve >>> >>> >>> On 12/7/2009 at 2:47 PM, in message >>> <8ab83e650912071247w7b93cb8bt90fe0c6a7a460...@mail.gmail.com>, Daniel >>> Walton >>> <dgwal...@gmail.com> wrote: >>> > Thanks Daniel. No dice, though, log is empty. >>> > >>> > On Mon, Dec 7, 2009 at 2:38 PM, Daniel Morissette >>> > <dmorisse...@mapgears.com>wrote: >>> > >>> >> Daniel Walton wrote: >>> >> >>> >>> >>> >>> Yes, the same mapfile worked under MS4W on a 32-bit machine. I have >>> >>> verified that this same problem occurs using the x86 binaries from >>> Tamas' >>> >>> site run in the current x64 environment. The source image is in PNG >>> format >>> >>> in order to make transparency work well on the client. (My client is >>> >>> Silverlight-based, and PNG is the only supported format that supports >>> >>> transparency). The source image does have a world (*.WLD) file which >>> >>> contains these values (file is generated by running gdal_translate on >>> a >>> >>> geotiff image): >>> >>> >>> >>> >>> >> Um... perhaps try using DEBUG/MS_ERRORFILE and look for hints in the >>> log >>> >> output, if you haven't tried that already. >>> >> >>> >> >>> >> -- >>> >> Daniel Morissette >>> >> http://www.mapgears.com/ >>> >> _______________________________________________ >>> >> mapserver-users mailing list >>> >> mapserver-users@lists.osgeo.org >>> >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >> >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >> >> >
_______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users