Re: 'notify' signal handler

[Robert Park <rbpark exolucere ca>]

On Mon, Nov 29, 2010 at 2:17 AM, Quikee <quikee gmail com> wrote:
> I have calculated that the threshold of 0.001 is about
> 150m/515feet

Obviously this varies with latitude.

> which is the distance the map center has to move that the
> threshold fires. If zoom is at maximum this could be a problem but not
> at other zoom settings as the resolution is low. This is why I
> wondered if this should be pixel/meter dependent (for example you have
> to move 5 pixels in the current zoom level to fire an event).

I like the idea of it being pixel dependant, because the application
I'm writing is for geotagging photos, and I don't like the idea that
libchamplain itself is introducing a margin of error of 150 METERS
into the location tags (the GPS unit I'm using is accurate to 3
meters).

Granted, 3m accuracy is not required at zoom level 0, that's
understandable. But I frequently do zoom in to the maximum and make
precise adjustments, so something more accurate than 150m is necessary
at higher zoom levels.

I guess what I'm trying to say is that it would be nice if you could
make the threshold be "4 pixels at current zoom level" rather than a
fixed degree measurement, which will be too precise at low zoom level
and too coarse at high zoom level.

> I have also tought about to make it time dependent but in 1/10s you
> still could move the map for quite some distance if you are zoomed out
> from the map.

So 1/100s then? Obviously somebody more familiar with the inner
workings of libchamplain should decide this threshold. But I feel that
rate limiting by a time threshold rather than a distance threshold
will result in more accurate results without firing so often as to
cause performance problems.

> To overcome this you would have to fire one update event
> on map "idle" - when you don't move the map for a certain time - for
> example 1s.

1s is wayyyyy too long to wait for the notify signal to fire. I don't
want my coordinate display to show where the user was 1s ago ;-)

> This is more complicated to implement that is why I did
> not implement it in this way. I will try to implement this solution
> also, but it may take some time.

Thanks for your efforts, I really appreciate this issue being resolved.

-- 
http://exolucere.ca