[Chameleon] tiff hang
Bart van den Eijnden
bartvde at xs4all.nl
Wed Dec 8 16:08:27 EST 2004
Hi Assefa,
my Chameleon app MAP file has the following:
OUTPUTFORMAT
NAME png
MIMETYPE image/png
DRIVER GD/PNG
EXTENSION png
IMAGEMODE RGBA
TRANSPARENT TRUE
END
my Chameleon config has the following:
<context-param>
<param-name>image_type</param-name>
<param-value>PNG24</param-value>
<description>....</description>
</context-param>
So I don't see how this could explain the difference ... okay, maybe the
file goes through my png alpha hack now, since it is a static image now
with extension png. That must be the cause for this.
So using this approach you can use pnghacks to display the image properly.
I could not get the png hack to work using the drawmap approach.
Thanks.
Best regards,
Bart
On Wed, 08 Dec 2004 16:03:05 -0500, Yewondwossen Assefa
<assefa at dmsolutions.ca> wrote:
> Bart,
>
> Here is what could be happening : drawmap.php used the image_type
> parameter set in chamleon.xml to select the output format that will be
> used (just before the rendering). Maybe there is a diffrence between
> what you setup in the map file outputformat and the one which is
> selected by drawmap.php. Could this explain your problem ? (Note that
> $oMapSession->oMap->selectOutputFormat($szImgType) done in drawmap.php
> compares first for the mimetype and then the name for all the
> outputformat defined to do it's selection).
>
> The approch of writing the map to a temporary file does not use the
> selectOutputFormat.
>
> Both approchs use the same php mapscript draw function so the output
> selection seems to be the only diffrence from what I can tell.
>
> Later,
>
>
> Bart van den Eijnden wrote:
>
>> Assefa and list,
>> if I use this approach the 24 bit transparency problems in Internet
>> Explorer (grey background) are also gone.
>> I reported those problems in the Mapserver bugzilla:
>> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1089
>> Is this explainable for you guys?
>> Best regards,
>> Bart
>> On Wed, 08 Dec 2004 15:06:59 -0500, Yewondwossen Assefa
>> <assefa at dmsolutions.ca> wrote:
>>
>>> Ken,
>>>
>>> Thanks for testing.
>>>
>>> AFAIK, the changes would only affect the Query widget if it is used
>>> with the parameters HIGHLIGHTRESULTS and PERSISTENTRESULTS. Maybe
>>> Paul can comment on other widgets that I may have overlooked.
>>>
>>> As for the drawmap.php, It does several functionnalities (every
>>> thing drawn in chamelon like map, scalebar, keymap) pass trough that
>>> function. The idea behind it is that if you assigning a URL to the
>>> image source (http::../drawmap.php?...), the main application page
>>> does not need to wait for the map to be drawn to load completly and
>>> thus It is supposed to give a better "smooth" looking apps.
>>>
>>> Your are the 2nd person who tried this solution and reported that
>>> the application was faster considerably. When using the drawmap.php
>>> method, there is a time cost associated with calling the server,
>>> loading the session and then drawing the map. I would have imagined
>>> that this solution would improve the rendering time slightly (since
>>> session loading and call to the server are cut) but I am surprised a
>>> bit to know that It has considerable effect since I always thought
>>> that the main bulk of the time is taken by the map drawing. I guess
>>> a good profiling might give us a better understanding.
>>>
>>> Anyhow I entered a bug 893 on this :
>>> http://www.maptools.org/bugzilla/show_bug.cgi?id=893
>>>
>>>
>>> Later,
>>>
>>>
>>> Ken-ichi wrote:
>>>
>>>> Wow, not only did that solve my problem, but it increased map
>>>> rendering speed considerably, even with no TIFFs! Thanks, Assefa
>>>> and Paul. Adding a flag in the widget tag to do this would be
>>>> really helpful. Are there any widgets that don't work with this
>>>> adjustment, i.e. can I alter our "production" copy of Chameleon and
>>>> expect other Chameleon projects on the server to work ok? What
>>>> exactly is the purpose of drawmap.php anyway?
>>>> Thanks again.
>>>> -Ken-ichi
>>>> Yewondwossen Assefa wrote:
>>>>
>>>>> The changes are minmal : here is what I did :
>>>>>
>>>>> 1) MapDHTML.widget.php : in function GetJavascriptVariables
>>>>> (around line 468) :
>>>>> comment the 3 lines and add the 3 additional lines :
>>>>>
>>>>> //$url =
>>>>> WEBCOMMON."/wrapper/drawmap.php?map_session_mode=$nMapSessionMode&run_query=0&".SID.$szFatalImage;
>>>>> //if (!$bCWCJSAPI)
>>>>> //$url .= "&dummy=".urlencode(microtime());
>>>>>
>>>>> $oMap = $this->moMapObject->oMap;
>>>>>
>>>>> $img = $oMap->draw();
>>>>> $url = $img->saveWebImage();
>>>>>
>>>>> 2) in MapDHTML.js : function MapLayerDivImgOnLoad
>>>>>
>>>>> comment the line : //url = url + "&UniqId="+unique;
>>>>>
>>>>>
>>>>> Please give it a try and let me know.
>>>>>
>>>>> Paul, I think we can easily make this a configurable thing as far
>>>>> as mapdhtml is concerned. I think there might be a problem though
>>>>> with the new query widget that diplays the selected element (and
>>>>> keep the selection persitently) but It can also be solved with few
>>>>> changes.
>>>>> What I propose is that Ken do the tests and if it solves his
>>>>> problem, I will enter an enhancement bug on this with the changes
>>>>> required and we can implement it after that.
>>>>>
>>>>>
>>>>> Later,
>>>>>
>>>>>
>>>>> Paul Spencer wrote:
>>>>>
>>>>>> Ken,
>>>>>>
>>>>>> this is very strange. Chameleon is not aware of the image formats
>>>>>> of the underlying data, it just uses mapscript to do the drawing.
>>>>>>
>>>>>> Another solution to this problem may be to have the MapDHTML
>>>>>> widget render the map to a file and then load the image source in
>>>>>> the page rather than use drawmap.php.
>>>>>>
>>>>>> We did this for another client who was having a strange problem
>>>>>> with images half loading due to some sort of firewall problem
>>>>>> (only in IE strangely).
>>>>>>
>>>>>> I've cc'd Assefa since he was the one who sorted that out.
>>>>>> Assefa, can you post the solution to getting MapDHTML to render to
>>>>>> a file? Do you think we could make this a configurable parameter
>>>>>> in the MapDHTML widget (like DELAYDRAW="[true|false]" or
>>>>>> something)?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> Ken-ichi wrote:
>>>>>>
>>>>>>> Thanks Paul. I tried loading drawmap.php directly, and that
>>>>>>> usually renders the map even when the Chameleon app hangs (though
>>>>>>> sometimes it hangs too), so I guess drawmap.php may not actually
>>>>>>> be the culprit. I made another, minimal app with just the
>>>>>>> ZoomIn, ZoomOut, Recenter, and MapDHTML widgets, and it still
>>>>>>> hangs on the tiffs, so I don't think it's any of my custom
>>>>>>> widgets that are mucking things up either.
>>>>>>>
>>>>>>> I am really at a loss here. The strangest thing about this is
>>>>>>> that if I convert the TIFF to an Erdas Imagine file (either in
>>>>>>> Erdas or with gdal_translate) everything works fine. What is it
>>>>>>> about tiffs that could possibly hang up Chameleon? Why would
>>>>>>> Chameleon even be aware of input file format? Don't MapServer
>>>>>>> and GDAL handle that? I know they're fine because a
>>>>>>> non-Chameleon phpMapScript app renders the map fine, as does the
>>>>>>> CGI.
>>>>>>>
>>>>>>> Argh.
>>>>>>>
>>>>>>> -Ken-ichi
>>>>>>>
>>>>>>> Paul Spencer wrote:
>>>>>>>
>>>>>>>> Ken,
>>>>>>>>
>>>>>>>> to debug drawmap.php, you need to grab the URL from the image in
>>>>>>>> the chameleon app and load it directly in your browser. You
>>>>>>>> should then see any error messages or debug output directly.
>>>>>>>> Often, problems with a broken map image are related to error
>>>>>>>> messages (or notices) being output before the image contents,
>>>>>>>> thus creating a corrupt image.
>>>>>>>>
>>>>>>>> If nothing shows up immediately on viewing the drawmap.php url,
>>>>>>>> you can then start to add some debugging code (echo) to
>>>>>>>> drawmap.php to try to discover what is going on.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> Ken-ichi wrote:
>>>>>>>>
>>>>>>>>> Hi list. A while ago I posted an issue I'd been having with
>>>>>>>>> rendering TIFFs in Chameleon
>>>>>>>>> (http://lists.maptools.org/pipermail/chameleon/2004-August/thread.html#1245),
>>>>>>>>> but I never really resolved it. Essentially, whenever I zoom
>>>>>>>>> in on a GeoTIFF so that the TIFF fills the whole map, Chameleon
>>>>>>>>> hangs and never displays the map image (I just get the spinner
>>>>>>>>> icon indefinitely and then a broken image icon behind it. Try
>>>>>>>>> zooming in on the DRG (Test Raster) at
>>>>>>>>>
>>>>>>>>> http://fisher.cnr.berkeley.edu/vtm/data/mapbrowse/
>>>>>>>>>
>>>>>>>>> to see what I'm talking about. I'm fairly sure this is a
>>>>>>>>> Chameleon issue, most likely with drawmap.php, because this
>>>>>>>>> mapfile renders just fine via the CGI, and with a rudimentary
>>>>>>>>> phpMapScript app like this one:
>>>>>>>>>
>>>>>>>>> http://fisher.cnr.berkeley.edu/~kueda/mapscript_browse.phtml
>>>>>>>>>
>>>>>>>>> The DRG is a 16M GeoTIFF from the California Spatial
>>>>>>>>> Information Library, so I don't think it's to blame. You can
>>>>>>>>> check out my php and MapScript config at
>>>>>>>>>
>>>>>>>>> http://fisher.cnr.berkeley.edu/~kueda/phpinfo_mapscript.phtml
>>>>>>>>>
>>>>>>>>> I'm running MapServer 4.4.0, GDAL 1.2.5, and PHP 4.3.9. Can
>>>>>>>>> anyone think of a reason this could be happening, or recommend
>>>>>>>>> a way to troubleshoot drawmap.php?
>>>>>>>>>
>>>>>>>>> -Ken-ichi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Chameleon mailing list
>>>>>>>>> Chameleon at lists.maptools.org
>>>>>>>>> http://lists.maptools.org/mailman/listinfo/chameleon
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Chameleon mailing list
>>>>>>> Chameleon at lists.maptools.org
>>>>>>> http://lists.maptools.org/mailman/listinfo/chameleon
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Chameleon mailing list
>>>> Chameleon at lists.maptools.org
>>>> http://lists.maptools.org/mailman/listinfo/chameleon
>>>>
>>>
>>>
>>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
More information about the Chameleon
mailing list