moveTo code

4 views
Skip to first unread message

Matt Priour

unread,
Sep 25, 2012, 9:33:42 AM9/25/12
to j...@opengeo.org
I've discovered that I need to call some kind of inRange checking function and appropriately toggle display (but not visibility) when a layer goes in to or out of temporal range when doing a dimensional playback in the map.
There is already a temporal layer specific 'calculateInRange' function. Unfortunately, it is only called when zoom or pan has changed enough to cause a layer redraw. However, I would like to toggle the layer(s) display when in / out of dimensional range and ideally  trigger a layer change event when the display is toggled.

Basically, I'd like to call this portion of the OpenLayers.Map code:

However, calling map.moveTo at each time tick seems like an expensive procedure (& experiments with Chrome's Profiler function seem to confirm that, as it takes 11 - 24ms per call). On the other hand, it seems like overkill to re-implement those 15 lines of code elsewhere is our code base. The other approach of calling OpenLayers.Layer.moveTo is very fast and modifies the layer display but doesn't trigger any events.

What do you think the best approach would be?

--
Matt Priour
Expert service straight from the developers

Andreas Hocevar

unread,
Oct 9, 2012, 5:27:27 AM10/9/12
to j...@opengeo.org
Hey Matt,

sorry for the late reply. I think you should just call the
Layer::display() API method. A pull request to have the display()
method fire a changelayer event would be welcome, because right now
this event is fired in several places (Map.js and Layer.js) right
after calling display(), so this would even mean a simplification.

Andreas.
> --
> http://groups.google.com/a/opengeo.org/group/js



--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

Andreas Hocevar

unread,
Oct 9, 2012, 5:35:18 AM10/9/12
to j...@opengeo.org
Ah, and I forgot to add that I would not use inRange for temporal
range. It is really only meant for the resolution range of the layer,
and is not part of the API.

Andreas.

Bart van den Eijnden

unread,
Oct 9, 2012, 5:39:30 AM10/9/12
to j...@opengeo.org
Hey Andreas,

so have you changed your mind on this, since on Feb 26 you wrote:

"Hey Matt,

wouldn't it make sense to override Layer.WMS::calculateInRange for
this purpose? If the layer is not in the temporal range,
calculateInRange woulds simply return false.

Hope this helps,
Andreas."

?

Best regards,
Bart

-- 
Bart van den Eijnden
OpenGeo - http://opengeo.org

Expert service straight from the developers.

Andreas Hocevar

unread,
Oct 9, 2012, 6:15:52 AM10/9/12
to j...@opengeo.org
Indeed. Back then I hadn't thought about the implications of
re-purposing calculateInRange: inRange is a property that is only
about resolutions range, so there is no need to recalculate in the
context of moveTo. When calculateInRange does more than just deal with
resolutions range, it doesn't seem to be the right place for this kind
of change.

Andreas.

Matt Priour

unread,
Oct 9, 2012, 7:31:52 AM10/9/12
to j...@opengeo.org

Thanks for the response.
So would we add a different dimensional range calculation function?
I personally think that the calculateInRange function was the right choice. Since adding dimensional range checking doesn't affect the normal operation of the function. If a layer is out of resolution, then the dimensional range testing is skipped completely.

Andreas Hocevar

unread,
Oct 9, 2012, 7:41:19 AM10/9/12
to j...@opengeo.org
Wouldn't it be a nice solution to have the time manager just call

layer.display(layer.inTemporalRange)

from a function that is called at every tick? If the layer.display()
function fires a layerchange event, you have everything in place you
need, and I don't see much code duplication. Or am I missing
something?

Andreas.

Matt Priour

unread,
Oct 9, 2012, 7:49:15 AM10/9/12
to j...@opengeo.org

You're right that is a better approach.

Reply all
Reply to author
Forward
0 new messages