“survey” in the meaning of OpenStreetMap
For a survey to a specific object. This means the author was physically nearby the object.
where instead of “was” it should be “is”
This means the author is physically in the object (store).
A user gives permission to the app for checking physical location. After that, when this user wants to add prices with this method, the app gets current location once and returns list of stores nearby to this user (radius of available stores for choosing should be small, something like <0.5km or even less). That’s it, after getting list of stores, user’s location is not used anymore and perhaps shouldn’t be stored/recorded even for prices.
The user chooses one store from this returned list of nearby stores and starts to add prices just by entering “barcode - price” couples.
Why:
- It can be illegal to take pictures in stores of some countries. In countries where it is legal, many people still can be against of that and be aggressive to the shooter.
- Both current types of proofs are really limited in collecting: it is hard to make many pictures of shelves and there is a risk of aggression from other people (see upper), in the same time receipts are really limited because most of people don’t buy same products many times in different stores, don’t buy thousands products and there is a privacy risk if you forget to blur your personal information (as last card digits, names etc) even in one receipt proof it will be enough. The survey method is quick and fast, doesn’t need too much efforts from user (there is no need making tons of pictures), can be used for collecting even without purchasing things (users easily can collects prices for same products in the same one day in different stores) and don’t need to reveal personal data (except for one-time search per session only for verifying reasons).
- Doesn’t need terabytes for storing proofs, which will be a problem, when the project will grow and will be more popular.
The key problem here is data reliability:
- As I proposed, every time some user wants to use this method of adding, the app gets user location for search and return list of stores in radius of <0.5km or less and the user can add prices only to stores from that returned list near to this user. It prevents adding prices to just random shops.
- This method can be unblocked after some conditions as “The user have loaded 3/5/10 proofs of other types” or similar.
- Anyone who is not interested in prices without photo proof, can ignore them, because it will be a separate type of proof, that can be removed from downloaded data easily.
- Vandalism
-
Vandalism for random stores all over the World will be hard, because of this verifying system. The potential vandals will be need to fake their GPS every time, which already cleans the project from lazy vandals. And if someone just adds prices to random stores from different countries every next day, it is easily recognizable suspicious pattern.
-
Vandalism in stores nearby vandals also can be found with growing price DB with method I described here:
We have some product X with 200 prices from 10$ to 20$. And if suddenly DB gets a price where this X product costs 100$, it can be marked “suspicious” by the system and sended automatically to moderators, and only moderator can clear/remove “suspicious” tag.
So even if someone adds incorrect prices systematically, it will be possible to find these suspicious users thanks to data added by other users.
-
In conclusion, I want to say it looks like this method of collecting has more pros than cons. It will allow significantly to grow amount of prices in DB, will make it easier to add them for basic and new users, decrease privacy issues partly and needs much less storage on servers because it is just text. The only one problem is potential vandalism, but it can be countered and the more users the project will have, the less impact will have these potential vandals.