Category: Tools

The best way to store directions on your smartphone is low tech

May 18, 2015 / / 3 Comments
map of southern illinois as seen in the OsmAnd app

OsmAnd has great offline mapping features but it was tedious to ensure I had all of the maps at the desired zoom levels for the three-city bike ride in southern Illinois (pictured).

My friend is going to pick up a unique bicycle in Ohio and ride it back to Chicago. He designed a good route on Google Maps but now he needs to save it to his smartphone so he doesn’t have to constantly load directions and use data and waste battery life.

I gave him these instructions:

The best way to get a mobile view of the route is to use the Google Maps print feature and save it as a PDF. Then transfer that PDF to your phone through the Dropbox app. Then, in the Dropbox app, mark the PDF file as a favorite so that it’s stored offline, onto the phone.

There’s probably an app that can do what he wants, but I don’t know about it. There are hundreds of “maps” apps to sort through in each the App Store for iOS and the Play Store for Android.

In fact, I’ve downloaded OsmAnd, an offline maps app, for my Android tablet. I installed it and tried to learn how to use it in order to follow a downstate, intercity bike camping route. The app, though, required that you zoom in to each part of the map you wanted to store and then press “download”.

 

I spent 30 minutes downloading parts of the map, manually panning to the next section, before I decided to instead obtain one of the Illinois Department of Transportation’s regional bike maps and just draw it on there and write out a “cue sheet” (turn by turn directions).

Why the Slow Roll Chicago working group uses GitHub to collaborate

March 25, 2015 / / 0 Comments

When the Slow Roll Chicago project in the transportation breakout group began in December at Hack Night, the emails started flying right away.

This was mainly because there was a lot to say at the start, as we needed to agree on the group’s mission and plan.

Problems using email started immediately, though. Not only were there many emails going back and forth among people listed on the TO and CC fields, there were people who weren’t able to take part in these discussions.

That happened because it was difficult to keep track of who had been added to the discussion and who hadn’t, especially when it came to integrating new members of the group.

I wanted to overcome these problems by using a proper collaboration tool.

Email wasn’t just limiting our discussion quality and member inclusion, it was also limiting file storage, file sharing, and file versioning (which file is the latest?). Email has tended to demand a lot of attention, and there’s a lot of wasted time typing responses. I wanted to use a tool that didn’t have such demands, and that helped organize responses into actionable requests and delegation.

Using email made it impossible to see what tasks people were working on, and the progress they were making at any given moment.

Finally, email tends to be private but our work needed to be public so that it could be independently verified but also replicated for use in other locales.

I believe that it’s easier to train people on how to use a new tool well than to retrain on how to use an existing tool – email – better.

GitHub has solved all of these problems for our group while also creating a secure and versioned programming code storage system for the final outcome: a website.

Hack Night being a tech-oriented meetup is a good reason to use and teach this modern tool widely used by people in technology industries. Many of our members are still learning it but they have support from people within our group and from others who attend Hack Night.

GitHub handles our discussions, task assignments, task progress, notes, and files. Here’s how:

When you want to discuss a new idea, like using dynamic images to show what a building could look like under certain conditions, you would make a new “issue”, titled, “Use dynamic images to show the user some building design possibilities”. Use rich text and images in the issue to describe and visualize the idea.

GitHub has granular notifications settings that alert project members to this new “issue” after which they can respond to your idea. After it’s decided that the issue should be resolved in a specific way, you can assign the issue a desired milestone (a future project version) and project members.

One milestone could be “Preview to the management team” which is a previously-discussed status that should happen in a couple weeks. A second milestone could be “Post-launch” – things to finish after launching the product – that’s defined offline.

Each milestone tracks the issues that you’ve associated with it so you can see progress. When the assigned members finish a task, they “resolve” the issue by closing it.

Need documentation? For many coding or GIS projects, a data dictionary may be necessary and GitHub provides each project repository with a wiki in which you would describe how the project is set up, and what certain fields or values mean.

Finally, GitHub can store files – any kind, and as many versions. If you need to update a CSV file of street addresses for the project, just make the edits in your preferred editor on the desktop and then “commit” your changes with a short description of what you changed. Sync this commit back to the repository so that all project members now have access to the file.

Use Turf to perform GIS functions in a web browser

March 11, 2015 / / 0 Comments
Turf's merge function joins invisible buffers around each Divvy station into a single, super buffer.

Turf’s merge function joins invisible buffers around each Divvy station into a single, super buffer –all client-side, in your web browser.

I’m leading the development of a website for Slow Roll Chicago that shows the distribution of bike lane infrastructure in Chicago relative to key and specific demographics to demonstrate if the investment has been equitable.

We’re using GitHub to store code, publish meeting notes, and host discussions with the issues tracker. Communication is done almost entirely in GitHub issues. I chose GitHub over Slack and Google Groups because:

  1. All of our research and code should be public and open source so it’s clear how we made our assumptions and came to our conclusions (“show your work”).
  2. Using git, GitHub, and version control is a desirable skill and more people should learn it; this project will help people apply that skill.
  3. There are no emails involved. I deplore using email for group communication.*

The website focuses on using empirical research, maps, geographic analysis to tell the story of bike lane distribution and requires processing this data using GIS functions. Normally the data would be transformed in a desktop GIS software like QGIS and then converted to a format that can be used in Leaflet, an open source web mapping library.

Relying on desktop software, though, slows down development of new ways to slice and dice geographic data, which, in our map, includes bike lanes, wards, Census tracts, Divvy stations, and grocery stores (so far). One would have to generate a new dataset if our goals or needs changed .

I’ve built maps for images and the web that way enough in the past and I wanted to move away from that method for this project and we’re using Turf.js to replicate many GIS functions – but in the browser.

Yep, Turf makes it possible to merge, buffer, contain, calculate distance, transform, dissolve, and perform dozens of other functions all within the browser, “on the fly”, without any software.

After dilly-dallying in Turf for several weeks, our group started making progress this month. We have now pushed to our in-progress website a map with three features made possible by Turf:

  1. Buffer and dissolving buffers to show the Divvy station walk shed, the distance a reasonable person would walk from their home or office to check out a Divvy station. A buffer of 0.25 miles (two Chicago blocks) is created around each of the 300 Divvy stations, hidden from display, and then merged (dissolved in traditional GIS parlance) into a single buffer. The single buffer –called a “super buffer” in our source code – is used for another feature. Currently the projection is messed up and you see ellipsoid shapes instead of circles.
  2. Counting grocery stores in the Divvy station walk shed. We use the “feature collection” function to convert the super buffer into an object that the “within” function can use to compare to a GeoJSON object of grocery stores. This process is similar to the “select by location” function in GIS software. Right now this number is printed only to the console as we look for the best way to display stats like this to the user. A future version of the map could allow the user to change the 0.25 miles distance to an arbitrary distance they prefer.
  3. Find the nearest Divvy station from any place on the map. Using Turf’s “nearest” function and the Context Menu plugin for Leaflet, the user can right-click anywhere on the map and choose “Find nearby Divvy stations”. The “nearest” function compares the place where the user clicked against the GeoJSON object of Divvy stations to select the nearest one. The problem of locating 2+ nearby Divvy stations remains. The original issue asked to find the number of Divvy stations near the point; we’ll likely accomplish this by drawing an invisible, temporary buffer around the point and then using “within” to count the number of stations inside that buffer and then destroy the buffer.
Right-click the map and select "Find nearby Divvy stations" and Turf will locate the nearest Divvy station.

Right-click the map and select “Find nearby Divvy stations” and Turf will locate the nearest Divvy station.

* I send one email to new people who join us at Open Gov Hack Night on Tuesdays at the Mart to send them a link to our GitHub repository, and to invite them to a Dropbox folder to share large files for those who don’t learn to use git for file management.

Meet Chicago’s newest street view fleet: bikes

March 2, 2015 / / 0 Comments
Bicycle holds an iPhone to take street view-style images

This position gives the smartphone an unimpeded view of the street but prevents the user from manipulating it.

I first used the Mapillary app on iPhone last fall, in August, and I uploaded one photo, of my arm, which I can’t delete from the website. I uploaded a couple more photos from a street in Roscoe Village in November.

This week, though, I uploaded 500 photos from a three mile journey on California and Milwaukee Avenues in Chicago – streets that no one else had photographed for the Mapillary street view service.

Mapillary is an open source (sort of) street view service, originally developed in Sweden, which allows the public to contribute photos taken with their smartphone app.

What’s “sort of” about Mapillary being open source is that it appears that the company owns the photos once you upload them. People are free to use the photos to edit OpenStreetMap, or publish elsewhere – for personal use only – with attribution that adheres to Creative Commons 4.0. People who want to use the photos in a commercial application must subscribe to a pay service.

Mounting an iPhone to a bicycle

I took the jump from contributing nothing to uploading a whole lot because I bought an iPhone mount for my bicycle. After months of research – okay, chalk it up to my being lazy and it being really cold outside – I settled on the DgRock Universal Bicycle Mount from Amazon for $9. I was perplexed that there was a gap in choices between this decent $9 product and the next group, hovering around $30-40.

After three days of use, I’m satisfied, despite limitations that are present in all mounts I surveyed. The DgRock mount is solid, barely moves even as the bike bounces along Chicago’s pothole-ridden streets, and securely holds the iPhone with a strong, spring-loaded grip. It’s universal in two ways: it holds nearly any smartphone (it probably can’t hold one with a screen 5″ or larger) and it attaches to most bicycle handlebars.

The first day I used the DgRock mount Mapillary complained with a red icon that it couldn’t get a proper fix on its location and therefore it wouldn’t start photographing. Fine, I was in downtown Chicago where connecting to GPS satellites can be hard. I figured the wifi positioning system that all smartphones and tablets use would suffice.

There are problems with the mount, but I think these apply to all bicycle smartphone mounts: When the phone is in position to take photos, meaning its horizontal and level to the ground, you can’t see the screen. That’s because the screen, mounted on the handlebars, is much lower than your eyes and faces vertically, instead of angled towards your face. The only way around this, I believe, is to either get an upright bicycle (like my WorkCycles Fr8) or an adjustable lens (I can’t find any).

Smartphone mount holding an iPhone on a bicycle

This position allows the user to manipulate the smartphone but you cannot take street view-style images.

The possible position angles of the smartphone when held by the mount was my main concern as I was shopping on Amazon: The mount need to have the flexibility to position the smartphone so its rear camera could be level with the ground. Smartphone mounts, though, are made to put the device in a position to be used and viewed frequently by the bicycle rider – it was unclear if many of the other smartphone mounts could accommodate the street view angles requirement.

The DgRock has no issue moving the iPhone into the right position, as you can see in the photos from my journey (or scroll to the end). Its issue, though, is that you have to put the smartphone in “backwards” so that the claw covers up part of the screen. I call it an issue but it doesn’t disturb the mount’s primary purpose when using Mapillary – the phone still has a clear view of the street.

Even with an upright bike like mine, though, it’s difficult to see the screen. I believe that Mapillary can actually design its app to help overcome this physical limitation.

Using Mapillary

The Mapillary app has improved greatly since the first version. It allows you to delete bad or undesired photos before uploading, and it has a simpler interface to go from opening the app to making your own street view. There are a couple changes I think would improve the user experience and lead to more contributions.

I would like to be able to turn off the screen while using Mapillary to save battery life. I think that the screen could fade to black and a small white dot or halo appears frequently to remind you that it’s working. I’d also like it to chime when iOS throws the “low storage” warning. Otherwise I may be riding along, thinking Mapillary is capturing the street, when iOS had actually run out of storage 10 minutes ago.

This is why we need more people editing OpenStreetMap

February 16, 2015 / / 1 Comment
Unmapped homes in the Irving Park community area

These homes were built after the City of Chicago’s building footprints dataset was created (2010?). Ian Dees imported the dataset in 2012. Many of the buildings that you can now see on Bing Maps have not been present on Bing’s satellite imagery since at least 2012.

1. OpenStreetMap is the world’s most complete free map, to which anyone can contribute their “ground truth” data (the location of wells and convenience stores, road names, and whether Lula Café at 2537 N Kedzie Boulevard in Logan Square has outdoor seating).

2. OpenStreetMap is used by thousands of non-profit and non-governmental organizations, corporations, apps, and people daily to locate themselves, locate others, get directions, and find places.

3. Nearly every map is out of date the moment it is published, including online, “current” maps like Google Maps, Bing Maps, their competitors, and OpenStreetMap.

4. Bing Maps provides its satellite imagery to OpenStreetMap editors – you and me – so that we can trace (copy) things on the planet to be things on the map. Google Maps doesn’t allow tracing (copying).

5. Bing updated its satellite imagery for Chicago (and probably a lot of other places) within the last six weeks…and there are hundreds of objects that aren’t yet mapped in OpenStreetMap. In Chicago most of these buildings are newly constructed houses.

Those hundreds of houses now need to be added to OpenStreetMap, with addresses, to complete the buildings collection in Chicago, and to expand the gazetteer (an address book) of places in Chicago.

I’m glad you want to help me do it! Here are two helpful things you can do:

  1. Start tracing the buildings yourself (here’s how new mappers can get started), or
  2. Leave notes at buildings which aren’t yet mapped so that map editors like myself know where to look to trace buildings.

Update: There’s a bonus third thing you can do, and that’s come to the next MaptimeCHI event on Thursday, February 26th, at the Chicago Community Trust (225 N Michigan, 22nd floor). RSVP for Anatomy of a Web Map. The Trust will also provide food and beverages. I’ll be there to teach new mappers and assist generally.

Adding notes is extremely helpful

You can contribute without editing by adding notes describing new things, or identifying problems with existing things. Click the “Add a note” button on OpenStreetMap.org.