With respect to privacy of ground station owners, I think it is better to display gps Coordinates as xx.yy°, aa.bb° instead of xx.yyy aa.bbb on the network page. I have been able to pin point location (~100m) of a ground station by using google maps(satellite view) and adding 0 to 9 to the whats displayed.
I suggest that displayed coordinates on station network page be of lower resolution than the values used for prediction calculation.
Let me know what you guys think.
I just rounded off my location to two digits. A few kilometers off has really no practical influence on the tracking.
Interesting… The question is whether we enforce this ambiguity in the web app or let the users decide about the accuracy of the coordinates they provide. I would go for the unrestricted, freedom of choice (latter).
On the current frequencies and setups, I guess not. Is that the case if we work on other frequencies in the future?[quote=“Acinonyx, post:3, topic:1315”]
The question is whether we enforce this ambiguity in the web app or let the users decide about the accuracy of the coordinates they provide.
[/quote]
Indeed that’s a point. Would it make sense to allow the user to choose whether or not the are comfortable with the SatNOGS Network website would show their exact position or their general location on the map?
Good point!
I used gpredict to compare AZI and ELE for the ISS from two different ground stations. You could use pyephem to do a better comparison.
First, comparison of two ground stations in adjacent locators JO55UM and JO55VM, i.e. distance a few km and same order of magnitude as rounding off to one or two decimals in lat/lon:
As you can see, difference is less than 0.1˚ in both AZI and ELE. The typical 3 dB beam width of a 1 meter parabolic reflector at 10 GHz is 2˚ so no problem here. The limiting factor here will be your antenna controller.
Next, I moved the GS ~70 km away:
It’s worse, but still within 0.5˚
It will get worse with a satellite straight overhead and low altitude, but still, 3 km offset is only 1% of 300 km altitude 
ambiguity in network would only matter for the scheduling of passes. The actual tracking and doppler correction are done with the coordinates set within the client.
In other words, you can obfuscate your location a bit, schedule a pass and be a little off on time, rise/set/maxel, but when it comes to the actual capture of the observation it should be spot on.
In any case, I support making the public locations a bit fuzzy while scheduling on the exact locations if we want to make a change to the network to fix this.
The only problem with that is that if we want to provision client settings through Network API at some point location data should match and be accurate.
We could add some ambiguity on the UI only and keep the accurate data on the backend. Another UI privacy issue with that is that we should do something similar with the map.