[mapserver-users] Mapserver WMS under IIS 7 x64 serving up blank images

[Daniel Walton]

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 <dgwalton at 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 <szekerest at 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.Lime at 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
>>> <8ab83e650912071247w7b93cb8bt90fe0c6a7a460785 at mail.gmail.com>, Daniel
>>> Walton
>>> <dgwalton at gmail.com> wrote:
>>> > Thanks Daniel. No dice, though, log is empty.
>>> >
>>> > On Mon, Dec 7, 2009 at 2:38 PM, Daniel Morissette
>>> > <dmorissette at 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 at lists.osgeo.org
>>> >> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>> >>
>>>
>>> _______________________________________________
>>> mapserver-users mailing list
>>> mapserver-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20091208/820393b2/attachment.html