Monday, April 4, 2016

Trying to get back on the horse

I want to incorporate this additional preferential parking data:

https://data.smgov.net/browse?category=Transportation

Questions:

  • Is some or all of this data already in the existing dataset?

Tuesday, January 12, 2016

Approaching the deadline

Only small progress was made since my last post. A major factor was moving, which only took about a week but killed a lot of momentum. Fortunately I am settled in and back on track.

I had mentioned pre populating the Core Data storage in my app to avoid loading it on the client side, which was causing minutes long initial startup times. After much Googling I discovered such a technique was not supported. It seemed the only way to accomplish this was to write a separate app, load to the Core Data storage there, then copy over that data blob into my real app. Generally I prefer not to do things in a hack-y way, especially since future iOS, Xcode, or Swift updates could break something.

After struggling to find another solution, a random Stack Overflow comment recommended simply using a SQLite database. There was no good reason for me to use Core Data; I only went that route because I thought it was the normal storage method for iOS apps. I don't think that's the case, Core Data seems more about user specific storage (settings, etc). Once I settled on the database route it was smooth sailing.

Some of the implementation details had to change. The main difference is I'm no longer loading all the data. Instead I quickly load only the locations' latitude and longitude upfront. When determining the annotations' colors (allowed or not), two database queries give me exactly what I need.

With this change my app loads very quickly after install, and I've noticed no slowdowns when the annotations update every minute.

The issue of performance from too many annotations still exists however. I'm still only displaying 1000 points, and performance is already not great. I'm perpetually frustrated by this. How is it that Safari on my iPhone can use the web (javascript) version of my app and it works fairly well, yet this native app that is showing much fewer points runs so poorly? Makes me question my decision to go with Apple Maps over Google Maps.

Tuesday, November 24, 2015

Too many annotations

As with all my previous parking app implementations, the problem of "too many annotations" is a tough nut to crack once again. It's been a while since my last post, so let me describe out some of the progress I've made.

Swift doesn't have a natively easy way to work with JSON. I found an open source package online called SwiftyJSON that did a lot of the leg work. With it I was able to quickly parse my JSON file.

Loading the JSON takes a long time, on the order of minutes. It made sense to save this data using Core Data. The first time the app runs it spends a long time parsing the JSON, but subsequent app loads are much quicker. There must be a way to not have to do any JSON parsing in my app, and instead do it offline and save that data directly into my app. Worth exploring.

This brought us to the current problem. Displaying the approximately 10,000 parking signs as annotations causes the app to perform extremely poorly. I would classify it as unusable. My first instinct was to do some sort of clustering. Unfortunately Apple provides no implementation of such a feature, so I tried out several open source packages before settling on kingpin. It works okay, but it's implementation makes it hard to customize the annotations. And frankly it actually isn't very fast anyway.

In my search for inspiration I happened upon an app called Plane Finder. This app displays commercial flights in semi real time, displaying a plane icon at the purported location of the actual plane. On screen at any time are upwards of 5,000 plane icons, which I assume are annotations with custom art. Although it never displayed as many points as I did at once, the app is clearly doing something interesting that causes it to be very performant. I emailed the company asking if they'd be willing to share their technique. To my surprise they actually replied, but declined to share anything.

I considered going an underground route and reverse engineering their app, in hopes of figuring out how they're accomplishing their impressive annotation performance. The worst part about going that route is the need to jailbreak my device, which I really don't want to do. There's also no guarantee I'd actually learn anything valuable, so it's a gamble on my time. And of course there's the whole legal and ethical boundaries I'd be tiptoeing.

In the meantime I can work on other aspects of the app.

  • App icon / logo. 
  • Improved splash screen
  • UI elements
    • pan to user's current location
    • pan to Santa Monica
  • Preprocessing JSON data and saving to Core Data

Thursday, November 5, 2015

Making my iOS app

My project was selected as one of the finalists in the Hack The Beach competition. As such I will continue working on it until the winner is chosen. The next logical step was to create an actual mobile app. I chose iOS because it's my preferred platform.

I initially dabbled in embedding a Google Maps view into the app. But after playing around, it just seemed a lot easier and more straightforward to use Apple Maps.

Through a mix of Youtube videos, Lynda.com tutorials and various online posts, I've gotten a simple app running. It displays a map, finds the user's location (after asking for permission), and plots a single parking point on the map.

Next, I want to plot all the points. There's probably a way to read a CSV or JSON file into the app.

Monday, October 12, 2015

Back on the horse

Since submitting my project to Challenge LA, I had completely stopped working on it. Barely gave it a thought actually. I figured I'd start looking for a job while waiting to hear back. The announcement of the winner(s) was to be on October 10th, which was this past Saturday. Did I win? Well, I don't know. Through a series of questionable circumstances the event was cancelled, with no future date given for any further developments. Government programs, am I right?

Luckily Santa Monica came through, in a way. They've created their own civic tech competition dubbed Hack the Beach. Very similar setup to Challenge LA, with the areas of focus being "community, mobility, and civic engagement".

I went to both events last week. I met a number of individuals from the City, including Francie and Kegan. They were helpful in pointing me to some existing datasets regarding street parking regulations. One dataset in particular looks very promising. I'll take a deeper look later.

Now the plan is to restart work on my project. I plan to do a 50/50 split between working on it while continuing interview prep. Deadline for the application is October 30th.

Tuesday, September 15, 2015

LA Street Park

I found a decent URL that I plan to stick with: lastreetpark.com !

I thought I needed to have a whole separate server. I went through some of the motions of cloning my existing AWS virtual machine. Turns out I didn't need to. I can set some configurations in the Apache server, and based on what hostname is pointing to my IP, I can serve files from my desired location. (Once configurations are changed, I needed to restart the server.)

For reference:
  • Apache configurations live in /etc/apache2 , at least for my setup.
  • I added a new VirtualHost tag in the ./sites-enabled/000-.... file. 
My configurations in Hover were apparently incorrect. URLs of the form like lastreetpark.com pointed to my server fine, but www.lastreetpark.com didn't. Instead it would redirect to a default Hover page about not having redirects enabled or something.

The fix was to modify both the "A" values in the DNS settings. There are two: the "@", and the "*". I had only set the "@" setting to my IP, but also setting the "*" seems to allow all URLs of the form *.lastreetpark.com to work. I needed to have a chat session with Hover to learn about this.

Tuesday, September 8, 2015

Fusion Table frustrations

As previously stated, I created a new column that encompasses all "no parking" and "other" type signs. I use this column in the filtering. Again, this is because Fusion Tables doesn't support OR operators. I didn't explore the possibility of using IN.

Now that I'm able to select between showing different types of signs, I wanted to represent the points as different colors. Red for no parking, green for other (I hesitate to call it "parking allowed" because there are some signs like "Taxi only" and what not, that isn't categorized properly yet.). I looked at many examples of other people's code, but couldn't figure out how to do it. I found that Derek's tutorial did talk about it. Essentially there's an interface within Fusion Tables that allows me to create "buckets", which are different values of a column. I can assign different colors to different buckets. Perfect! or so I thought. For some reason, I'm only able to choose between two buckets, "x" and "id". How utterly useless! I can't find any logical reason why that might be. I saw in the "select columns" chooser that "x" and "id" were the 10th and 11th columns respectively. I tried moving a different column in there, but no luck.

Another thing. Whenever I make a change to the data, whether its reordering the columns or setting colors for different buckets, there seems to be a delay before the data becomes usable. For example, if I load my map immediately after making a change, instead of my points I might see error messages across the map about how the data isn't available yet.

You can praise Google for a lot of things, but you can criticize a lot as well. Maybe I should look into CartoDB, just pay for it and be done with it.

--
The question is: now what? I don't know what features I'd want to add in the short time between now and the September 20th deadline.

Maybe an app to take photos and record the GPS location? Here's a quick and dirty pipeline idea:

photo of sign and GPS location -> OCR text from picture -> store in CSV -> run in normal pipeline