briantruong777
commented
9 years ago If we make an algorithm that doesn't use location, it might not be considered an advanced feature anymore; although I pretty much agree with your thinking.
Making a separate _location would probably be fine, but it still makes sense to sort based on a combination of user, time, rating and sorting by those properties might require receiving information from the client.
If it makes things simpler, feel free to make a separate _location, but it should still have some ability for advanced sorting (like finding a specific user's posts in the area).
wlodarczykj
So I'm "writing" the scoring function, I'm taking heavy inspiration from reddit's algorithm. So that settles time and rating. However, as far as location is concerned, I am not 100% sure if we should rank by location. An even spread out amount of posts would be optimal I think.
For example, lets say I go outside open up my app. I walk into an area that coincidentally has 1000 spotposts with the same reputation and all made at the same time. Lets say they are spread out evenly everywhere, but I want 100. What will show on your screen is a map with you in the middle a circle around you, and a clutter of spotposts huddled around you, with the rest of the map blank. So I think location shouldn't change which to show, assuming we are bounding the circle by a set radius.
Also on another note. I am debating eliminating the location search in the
_get. Instead I was thinking of adding this into its own function_location. This would mean you cant search through the spotposts returned by the location query. As in no looking for specific usernames within the circle or ratings or id.