Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harvest content from Instagram based on location #46

Open
tmaiaroto opened this issue Aug 28, 2014 · 0 comments
Open

Harvest content from Instagram based on location #46

tmaiaroto opened this issue Aug 28, 2014 · 0 comments

Comments

@tmaiaroto
Copy link
Member

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).

@tmaiaroto tmaiaroto added this to the Backlog milestone Aug 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant