Add option to increase scan point distance about rocketmap HOT 14 CLOSED

In fact:

with the normal 0.070 (70m step):

Hack that value over to 0.500 (500m) and FWOOSH:

Way, WAY more gyms/pokestops, zero extra server load.

from rocketmap.

Is what you're describing different from what can be done using -st?

from rocketmap.

1. If by spacing you mean increase the space between each step, have fun missing that 100 iv dragonite in those spaces.
2. You can't just toggle the pokemon detection radius to that of gyms and pokestops, can you spot a pokemon as far as you can see pokestops/gyms?

3.there is a way to keep gyms up to date, run with -nk and -np

from rocketmap.

No, st defines the amount of scan points from the current position. I mean the distance between those.

@JZ6 It's not for scanning pokemons. It's to have a supplemental scanning task keeping a larger area of gyms up to date, because they are reported over a far longer distance than pokemons.

I think you are misunderstanding what I'm saying. I am talking about a supplemental scanning process (-ns) on top of a much smaller pokemon scanning area. The idea is to have the map be accurate over a wider radius for gyms than for pokemons.

from rocketmap.

Isn't that one of the purposes of the Issues tab on GitHub and the reason that the enhancements tag is there by default?

from rocketmap.

I think this is a legitimate, but sorta naunced, request.

Essentially, we can only get 70m worth of pokemons per scan point, but the gyms/pokestops show much, much further away points.

If you could setup a thread to change our algorithm for each step from 70m to, say, 500m, the same -st value would cover a much, much larger area of gyms/pokestops.

This can be achieved right now by adding a ton of -st 1 threads, but that'd be rather tedious.

from rocketmap.

so we should implment a different limit for just pokestops and gyms? might be a good idea for scraping data for the server i guess.

from rocketmap.

Nah, just add an option that let's you futz with the point distance between steps for just the python code*. Something like --step-length with a default of 0.070. Then a person could run the main app normally, but start an extra -ns thread with a way higher --step-length to cover the wider area of gyms/pokestops.

* You don't want the JS code to follow suit, otherwise the green "scanned area" circles would cover the whole area and a boat load of people would think that we somehow are missing a ton of pokemons....

from rocketmap.

^seems like a good addition but useful ness might be limited.

from rocketmap.

Will there be a benefit other than pokestop/gym update speed? Will it reduce cycles/data or anything if a dedicated thread is used for stops/gyms only? I've never tried no stop/no gym options.

from rocketmap.

The regular scan also catches gyms and in a wider area, too. This is neat if you'd like to have, say, an updated view of all gyms in your city, without requiring 20 accounts.

This is fairly simple, already added it, but can't test, because the front end doesn't seem to work. Did Google pull the plug on the maps?

from rocketmap.

I did it on my private fork, max distance to not losing any pokestop/gym is 1km (1000m), but I use pulse_radius = 0.999 because the script was freaking out when it was an integer (I am no python developer but maybe I should've used 1.0 instead of 1, but 0.99 works for me :P).

I also wrote in the PR about changing the scan radius on the frontend.

from rocketmap.

+1

from rocketmap.

For feature requests please migrate this to the new feature page
http://feathub.com/PokemonGoMap/PokemonGo-Map/
Thankyou!

from rocketmap.