SocialHarvest / harvester

The Social Harvest server that exposes an API and harvests data from the web to be analyzed.
Other
112 stars 43 forks source link

Harvest content from Instagram based on location #46

Open tmaiaroto opened 10 years ago

tmaiaroto commented 10 years ago

Initially only keywords/tags were used, but Instagram allows media discovery by location as well. It's just not so easy to automate.

The reason is because you must use a location id within Instagram's system - which first must be identified by a user (and there's a search endpoint for getting these ids through a variety of means including Facebook places id, lat/lng, and even Foursquare). See: http://instagram.com/developer/endpoints/locations/

The problem is we can't just take the first result like we did with tags (which was the most used tag for a successfully found keyword). There could be inaccuracies. It's hard to configure because it requires an API call to search to get that id to go into a config file. Annoying for a user to config.

Consider the example from Instagram's documentation:

{
    "data": [{
        "id": "788029",
        "latitude": 48.858844300000001,
        "longitude": 2.2943506,
        "name": "Eiffel Tower, Paris"
    },
    {
        "id": "545331",
        "latitude": 48.858334059662262,
        "longitude": 2.2943401336669909,
        "name": "Restaurant 58 Tour Eiffel"
    },
    {
        "id": "421930",
        "latitude": 48.858325999999998,
        "longitude": 2.294505,
        "name": "American Library in Paris"
    }]
}

If the harvester was configured for 48.858,2.294 ... It would be difficult to know which location the user wanted. Higher lat/lng precision would help, but there would always be the potential for inaccuracies and confusion.

Better UX (and harvest accuracy) would be to have the dashboard let the user add this criteria to the territory by performing a search, looking through the results, and then choosing the proper location. Since locations have names (which provides that human check element).

Since the dashboard (and any configuration via API) is optional, it just may end up being annoying to configure via server config file. That just may be the answer there.

I left this in the backlog and am tagging it as an enhancement because I'm not sure how often search by location will even be used. People should weigh in on the value (and I'll conduct surveys).