The only issue with your math is that you assume instant response from HQ :-) If I bombard them with 60 calls at ONCE I will not get all 60 responses right away....

BUT, I agree, 45min is way too slow in any case...

Your 4681 caches are 94 API calls. Spread over 45min is about 30s per call....

I would say that sounds like an API HQ issue. This assumes sequential calls on my end.

I know I do not need 30s for 1 call!

I just tested at home... and the average API call time was under 2s!

So even without any change I will pump out 30+ calls a minute.

Which in your case would result in about 3 minutes update time.

I will see what is going on. Don't even think I need to add the effort since refresh rate of about 25caches/s would be 1500/min which I think is decent enough.

Now I know this is not what you got and I will check why...

it would but I also would have to consider the API quota and pause all calls...

sure more complicated :-)

I suppose I could ;-) Working on some other stuff but will look at that. Makes no difference for small number but for a few thousand it does.

Rate limiting is enforced on all methods of the Geocaching API. The methods are limited on the calling IP, end user, and by partner consumer key. The current limits are set to:

• 60 calls per minute for user per method
• 1200 calls per minute for partner consumer key
• 6000 calls per minute for IP address

The API is slow enough that 1 call should last at least 1s ;-) So the limit should NOT kick in...

for one I will check about the speed even though I know the new API is way slower than the old one.
but I will also add a progress counter. since new API has me do batches of 50 at a time I should know the count.

Will come in one of the next versions. I guess sooner than later :-)

I guess you made a very convincing argument earlier 🙈.

thanks for showing your support and appreciation....

well, I could make anything an option, as long as it is useful....

examples:

- max number of total points

- minimum time AND distance (never add point unless at least minimum time AND distance passed)

 - speed dependent options (complicated)

The location marker on the map updates with 1s/1m as limits

If the track does not follow the same it would look funny, unless I what I think Garmin does which is having the last segment of the track bounce around to wherever I am and then freeze it every x seconds and repeat with the next one,

Also, not using the NeonGeo dot concept... if tracking I want to see what points connect!

So more the Garmin concept of connected line

OK, so I have an implementation... couple questions...

How many 'datapoints' are a good value? currently sampling every 1s if distance is at least 1m.

3600 points/h. So 10000 points are about 3h.

How much tracking history is useful?

I guess there should be some limit.

What about opening/closing the map? I assume I would need to remember the track.

What about screen locked? Keep tracking? For how long? -> currently not tracking. would impact battery!

Many things to consider.

What does the author think? Or anyone that voted?

A standard offline map has 10000s of lines, etc. so drawing a track with let's say the last 5000 points should be very easy....