One of the future requests was to have city-wide competition, almost to a city-block-by-city-block level. I didn't want to go quite that fine grained (a city block might be ~200m), so the compromise is 500m grid cells. It is possible that no one contributes a leaderboard website feature that makes use of this, in which case we did go too small. The only front-end web implementation I am planning to do is to have country-by-county leaderboards.
I don't think I mentioned in the first email that the backend is supposed to support future leaderboard 'gameification' initiatives by the community. It is up to an interested party to contribute the front end for these ideas. Gameification ideas tend to focus around highly localized competitions and time-based competition (which is supported in the db with 500m grids, and weekly observation counts). This reminds me, one idea I am not planning to support on the backend is having members be part of a stumbling group. I think that is getting into unnecessary complexity. (It is a cool idea, so if a contributor wants to add that, I would support it). > On Apr 30, 2015, at 5:52 PM, Robert Kaiser <[email protected]> wrote: > > Garvan Keeley schrieb: >> Implementation-wise, the backend will store user observation counts in 500m >> grid cells, and per-week. The possible concern here is that the leaderboard >> is now tracking users more that it was previously. The opt-in for the >> leaderboards will have to indicate that Mozilla is storing this granularity >> of data, so users can make an informed decision about participation. > > How did you get to thew 500m value? It feels overly small to me. > > KaiRo > > _______________________________________________ > dev-geolocation mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-geolocation _______________________________________________ dev-geolocation mailing list [email protected] https://lists.mozilla.org/listinfo/dev-geolocation
