Observed iPhone location accuracy

Our Wanderings project uploads location fixes with the iOS significant location changes APIs. It includes an accuracy number, distance in meters, and occasionally we get points with accuracies > 1000m. We’re about to stop displaying those, but before I do here’s what the data looks like:


That shows most points have an accuracy of 10m, a significant number have an accuracy of 65m, and a few have 1414m. This histogram tool is misleading, there are also 15 points with an accuracy > 1414m. (Shout out to 7094 meters; you did your best, little iPhone).

If I had to guess, I’d say 1414m means “location from a single cell tower” and 65m means “location from a single wifi access point”. But who knows. It’s possible to ask the iPhone to give you more accurate fixes, we’re deliberately only using the most low power location monitoring to conserve battery life.


Browser unit testing Javascript

I wanted to do some simple unit testing in a Browser context; no NodeJS. I decided to use Mocha and Chai, then found it remarkably difficult to figure out how to just get it working without a bunch of complicated setup.

I finally figured it out: demo here. It’s pretty simple really, grab the CSS and JS from a CDN, then write the tests.

Boy there’s a lot of stuff in these frameworks. Mocha + Chai is literally 26k lines of code, 820k bytes. Minified it’s more like 300k but that’s still huge. I see why folks like tape instead. I wasn’t sure tape really supports running in a browser though.


Launched Wanderin.gs!

My friend Brad and I launched Wanderings, a simple location tracker app for iPhone and Web. Put it on your phone and forget about it, come back a few weeks later to have a nice heatmap of where you’ve been. It was inspired by the late lamented OpenPaths. See also Google Timeline, which is much fancier but doesn’t have a heatmap.

I was inspired to start working on this while traveling in Berlin. I just want to know where I’ve been, you know? I don’t know anything about building iPhone apps but fortunately Brad does.

The best part of the app is that we went serverless; we don’t have our own database or server processing location points anywhere. The iPhone app uploads directly to iCloud. Javascript in the web page downloads it directly and renders it. That’s good for privacy and also simplicity. I seem to be building all my web apps this way these days; Logs of Lag, Wind History, etc all work without significant server components. Sure is easy to scale and maintain.

Some of the interesting stuff we use:

We have lots of ideas for future features. Some particular ideas I’m excited to do:

  • Import of data from other sources
  • Some sort of time-based visualization
  • Android app (not me!)

It’s a modest project but I’m proud of it.



Snowfall hillshades

Garrett Dash Nelson has a lovely visualization of snowfall for 2017-2018; take a look! His code is very simple. A Python script to download data from NOAA, then some bits of shell scripts using GDAL to reproject, hill shade, and convert to an animated GIF.

I wanted to see what this treatment would look like over years so I did my own little thing based on his. Here’s the image processing script I used

set -eux
for y in 2014 2015 2016 2017 2018; do
  gdalwarp -t_srs "EPSG:5069" -srcnodata "-99999" sfav2*to_$y*.tif $d-warped.tif
  gdaldem hillshade -z 1500 $d-warped.tif $d-hillshade.tif
  gdal_translate -of JPEG $d-hillshade.tif $d-hillshade.jpg

And the images below. Starting at 2013-2014, and the final image is just a partial year of 2017-today. It’s not a great result TBH; the years end up looking pretty much the same and not that different from an altitude graph. In California you can’t see the low snowfall years of 2014-2015 and 2015-2016 vs the high snowfall 2016-2017, for instance.






What do sites used IndexedDB for?

Some notes on a survey of what all I find in IndexedDB storage in Firefox. That’s something like cookies, a way for a website to store data on your computer, only in this case it’s a fancy NoSQL database. I’m using it myself and have found Firefox’s Storage Inspector unreliable and limited, so I built my own tool to look through my profile directory and tell me what it finds.

Example report from the tool:

https://twitter.com            dm_typeahead               20160920      98304
  conversations title
  metadata -
  users name_lowercase, screen_name

https://www.smithsonianmag.com ONE_SIGNAL_SDK_DB                 1      49152
  Ids -
  NotificationOpened -
  Options -

https://www.theguardian.com    test                              1      49152

That tells me

  • Twitter has a database called “dm_typeahead” with three tables; conversations, metadata, and users. Users has two columns, name_lowercase and screen_name. It has a version string of “20160920” and was 98304 bytes big when last vacuumed.
  • Smithsonian is using some SDK to create some tables about notifications, but they contain no columns at all.
  • The Guardian created a database named “test” with no tables at all.

So what’d I find?

  • A bunch of empty “test” databases,  presumably testing the browser can do IndexedDB at all. This may be for detecting if the browser is in private mode.
  • A bunch of sites use One Signal, which I guess manages those horrible HTML5 website notifications that spam pop ups. I’m religious about never allowing that, which is probably why I have no data.
  • Several sites using Augur, a web tracking system.
  • Things called LPSecureStorage and fibet; trackers?
  • archive.org seems to be storing PC emulator state
  • Amazon is caching a lot of data about books, maybe for Kindle Cloud?
  • Twitter has extensive app-specific usage
  • WordPress’ Calypso
  • broadwayworld.com, a pretty spammy site, has a database named J7bhwj9e with some user tracking stats.
  • ft.com has a bunch of databases named next:ads-v1 and next:image-v1 and the like
  • wired.com has something called workbox.

The tool I built is in this gist.


I hate 2018 favicons

I just added a favicon to a new web app I’m building. Check out this 1500 bytes of boilerplate I just added to every page:

<link rel="apple-touch-icon-precomposed" sizes="57x57" href="/images/favicon/apple-touch-icon-57x57.png" />
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="/images/favicon/apple-touch-icon-114x114.png" />
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="/images/favicon/apple-touch-icon-72x72.png" />
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="/images/favicon/apple-touch-icon-144x144.png" />
<link rel="apple-touch-icon-precomposed" sizes="60x60" href="/images/favicon/apple-touch-icon-60x60.png" />
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="/images/favicon/apple-touch-icon-120x120.png" />
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="/images/favicon/apple-touch-icon-76x76.png" />
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="/images/favicon/apple-touch-icon-152x152.png" />
<link rel="icon" type="image/png" href="/images/favicon/favicon-196x196.png" sizes="196x196" />
<link rel="icon" type="image/png" href="/images/favicon/favicon-96x96.png" sizes="96x96" />
<link rel="icon" type="image/png" href="/images/favicon/favicon-32x32.png" sizes="32x32" />
<link rel="icon" type="image/png" href="/images/favicon/favicon-16x16.png" sizes="16x16" />
<link rel="icon" type="image/png" href="/images/favicon/favicon-128.png" sizes="128x128" />
<meta name="msapplication-TileColor" content="#FFFFFF" />
<meta name="msapplication-TileImage" content="/images/favicon/mstile-144x144.png" />
<meta name="msapplication-square70x70logo" content="/images/favicon/mstile-70x70.png" />
<meta name="msapplication-square150x150logo" content="/images/favicon/mstile-150x150.png" />
<meta name="msapplication-wide310x150logo" content="/images/favicon/mstile-310x150.png" />
<meta name="msapplication-square310x310logo" content="/images/favicon/mstile-310x310.png" />

How awesome is that! And I have no idea if it’s correct and no practical way to test it. I’m trusting Favic-o-Matic here. I tried reading docs about what to do online but every single website says something different. And who knows; maybe Apple will innovate with a new 79×79 size next week. (To be fair, Favic-o-Matic does offer the option to have fewer sizes; 16 / 32 / 144 / 152 is the minimal set.)

The original favicon standard wasn’t so bad. Nothing in the HTML at all, and a single /favicon.ico file in your root directory. That format was weird and semi-proprietary but it had the advantage it could hold multiple resolutions in a single file. Simple and done.

Then Apple screwed it up by starting to fetch random weird URLs on the website for its precious iOS icons. Then webmasters complained and so this linking standard started. Apple went overboard in supporting every single possible pixel-perfect resolution. Then Microsoft decided that was neat and added their own new incompatible formats for the stupid Start menu tiles no one uses anyway. And here we are.

Really want I want is to publish a single reasonable image, maybe 256×256, and just let the desktop clients auto-scale them. Yeah it won’t be pixel perfect but it’s not like I’m redrawing these icons at every size anyway. Either that or modernize the old favicon.ico idea so a single file has all the icons. A zip container would do nicely.