Writing online
I made an effective low fidelity API to the graffiti data.
You can now query with a location and get back results in chunks of 25. You can page through the results via the page attribute.
I’m conscious that there is currently no key/secret pass system. I have what I need for the application feed, so I’ll go from here.
http://www.graffpass.com/find.json?page=4&search=40.714352999999996%2C-74.005973
I set up http://www.graffpass.com/find today. Its a way for people to find the graffiti that is closest to them, based on a pool of instagram photos I scraped over two weeks.
This is an concept experiment for a iPhone app I want to finish next week.
The application currently has a feature for users to find images using two mechanism: type a location or check against current location. When users check against their current location, I am using the browser’s geolocation API to track a person/device’s location.
I am trying to figure out how I want to move forward with this project. Instead of spreading myself too thin, Im considering focusing my attention on a city-by-city launch. Because I dont know the best cities to focus on, Im tracking the use of the “My Location” button.
Instead of building out a way for data to be saved off this service, I am using a very low fidelity database: Google Drive. After finding a wiki on “How to write to Google Docs using JavaScript”, I implemented a quick javascript function to save each location check result.
After pulling streetart and graffiti tagged pictures on Instagram, I quickly realized how unmanageable the pictures were becoming. I was gathering approximately 20,000 pictures a day and didn’t have an effective way of browsing them. There were too many pictures for the traditional ‘grid’ layout design. Since they were pictures, there weren’t too many other ways to show them in bulk.
Based on the sheer amount of data, I explored various ways of filtering the images to increase the percentage of getting an actual picture of graffiti (rather then of something else that was tagged streetart or graffiti). Once I started filtering pictures that were tagged with geo location, I quickly found an improvement in results.
Having more than 200,000 images in my database, I looked for ways to break the image set into smaller chunks. This is where I came up with the idea of using location. When I created the map app that reoriented itself every time a new graffiti picture was uploaded to Instagram with geolocation, I was surprised by the number of people who take pictures of graffiti around the world.
Instagram’s APIs dont allow users to make multi-dimensional queries. They have endpoints for hashtag, location, or user searches, but you can’t do them on top of each other. This prevents any searches that use two of the endpoints together. For example, you can’t search for all the hashtag results in a certain geographic area.
By pulling all of the streetart and graffiti pictures and referencing the results on my own server, I have been able to add additional dimensions of queries onto the hashtag search results. This allows me to do interesting things like find all the other pictures hash-tagged graffiti that are in the same area. In my current case, I can compare a user’s current location to the database of images. This allows me to surface search results that a user can actually go see/find themselves.
The basis of this project is the scraped data that I got through the past few weeks of experimentation. The next part is the mobile interface that makes the search result discovery process relevant to a person who is out and about.
I have a web interface that I can build using a user’s location api in the browser. This is useful, but my end goal is not the graffiti compass. I am simply going through the steps needed to develop a community of people who will document and share graffiti themselves. This is not something that I can start out doing from scratch. The existing Instagram pictures provide me with the astroturfed platform for people to willingly contribute to.
Every 2 seconds, a new graffiti related picture is posted on Instagram. I made a map that visually displays all the geotagged images. About every 10 seconds a new geotagged photo appears.
http://paf-instagram.herokuapp.com/
https://blog.rememberlenny.com/2014/09/24/every-2-seconds-a-new-graffiti-related-picture-is/
Up until now, I struggled with the “empty party” syndrome. I was building a community for content sharing and storing, but didn’t have any content. As a result, I was trying to attract an audience without any reason for them to take Public Artfound.
The value created from the twitter bot I created made me realize I needed to do something with it. I was creating a lot of value for observers but unable to capture much of it for myself.
Since I recognized the IFTTT stream is useful to a wide public audience, I decided to build out my own IFTTT functionality. Instead of using IFTTT to move pictures from Instagram to Twitter, I am pulling them into the Public Artfound.
This solves two major problems I had in past experiments. First, I can curate. Second, I can attract users.
Based on controlling the stream of images, I will be able to throttle the frequency of posts put on Twitter. Before, I depended on IFTTT and didn’t have any control of the content. As a result, the current bot functionality overwhelms many user’s timelines.
The ability to leverage the exposure opportunity from Twitter is important. Until now, I have been receiving 30-100 daily favorites/replies/retweets on twitter. The majority of users are surfacing through search queries related to street art or graffiti. These users are not going to follow my account through twitter, but are likely to click a link with a photo.
The real value here is targeting Google. I’m leverage the images to capture the long tail of Google search traffic for small and mid tier graffiti artists. I’m going to be attempting to present the images in individual web pages. Using the existing tags and geo data, I will generate content to gain Google’s attention. This is a unknown field for me.
