 |
||||
|
||||
[Chameleon] Pixel to Geo Conversion problemsJeff Hamm jeff@planyukon.caMon, 01 Mar 2004 12:13:39 -0800
|
||||
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Jacob;
<br>Thanks for your reply.
<br>I was doing some modifications to create a Query by Polygon function.
The function performs an initial querybypoint to retrieve the initial shape,
which is then used to querybyshape on other layers.
<br>I was having problems grabbing the current map extents, so I implemented
a similar approach to your suggestion, using the form:
<br>$nMinX = {$this->mszHTMLForm}.MAP_EXTENTS_MINX.value.
<p>In trying the goCWCJSAPI approach you suggested, I found that goCWCJSAPI
was undefined. This might be a more fundamental problem, but for now I
simply scrapped the values off the form. Is there a definitive test so
I can tell if the CWCJSAPI is functioning?
<p>BTW, I also found it necessary to change the value of nInversePix in
the pixeltogeo conversion (around line 225 in the map_query.php wrapper)
from 1 to 0 for the conversion of x coordinates.
<p>I haven't attempted a fix on the printwidget yet, although I'm sure
a similar workaround is doable. Still wondering why the $oMap values aren't
updated by the Zoom widget though :-(
<br>
<p>Jeff
<br>
<p>"J. Delfos" wrote:
<blockquote TYPE=CITE>I have had similar problems, though not exactly the
same. The problems I
<br>had were that changes made to the map extent by javascript parts (e.g.
<br>zooming and recentering) were forgotten as soon as I submitted the
form;
<br>it went back to the original extent. I patched it by pasting this code
<br>into the "clickUpdateMap" function, in Updatemap.Widget.php:
<p> {$this->mszHTMLForm}.MAP_EXTENTS_MINX.value = goCWCJSAPI.oMap.minx;
<br>//custom added, not to lose extents
<br> {$this->mszHTMLForm}.MAP_EXTENTS_MAXX.value = goCWCJSAPI.oMap.maxx;
<br> {$this->mszHTMLForm}.MAP_EXTENTS_MINY.value = goCWCJSAPI.oMap.miny;
<br> {$this->mszHTMLForm}.MAP_EXTENTS_MAXY.value = goCWCJSAPI.oMap.maxy;
<p>This makes sure that the form variables for your extent are up to date
<br>compared to what your javascript did, when you submit the form. Perhaps
<br>you should try having it execute this code prior to using the functions
<br>which currently aren't working, to make sure your form variables are
<br>current before it does any processing.
<p>regards,
<p>Jacob
<p>--- Jeff Hamm <jeff@planyukon.ca> wrote:
<br>>
<br>> I've previously reported that my PrintWidget did not use the updated
<br>> extents of my DHTML map (e.g. after a zoom operation). It appears
that
<br>> my 'stock versions' of Query and ROI widgets are also affected (under
<br>> IE5.5).
<br>> In the case of Query, I used debug messages to discover the values
of
<br>> click coords, and its clearly evident that the min/max extent are
always
<br>> the same. For the ROI widget, defined regions are displayed as though
<br>> the map were displayed at full extent. If I zoom in, define an ROI,
the
<br>> region appears scaled and positioned according to the original extents.
<br>>
<br>> REcenter widget works OK, but it doesn't do a pixeltogeo conversion,
so
<br>> I'm wondering where to look for the problem.
<br>>
<br>> Anyone experiencing similar problems? suggestions?
<br>> To reproduce the problem, try doing a point query at a couple of
<br>> different display extents here: atlas.planyukon.ca/chameleon/htdocs
<br>>
<br>> Thanks
<br>> Jeff Hamm
<br>> YLUPC
<br>> Yukon, CANADA
<br>>
<br><a href="http://antispam.yahoo.com/tools"></a> </blockquote>
</html>
This archive was generated by Pipermail. |
MapTools.org -- Hosted by DM Solutions Group |