Looking at transit data with street view

Using google earth can also give a sense for the quality of the data, for instance the positions of transit stops. The data I get looks quite different depending on where in the country you are. Here are three examples.

The first image is Park Allé in Århus. There is a handful (if not more) individual stops there but as you can tell, in the data I have they’ve all been mashed into just one stop whose position, according to the data, is in the middle of the road.

The second image is in Roskilde. There are two stops, one on either side of the road, and the data does include them as two different places. That’s why there are two lines, one for the one route that visits the stop on the one side of the road and one for the other route that visits the stop on the other side. Unfortunately the actual location of the stops is inaccurate, they’re shown as if they’re both in the middle of the road.

The last image is from Frederikshavn. There the stop’s location in the data I have is on the side of the road, as it should be, but it’s still some way away from where the stop really is.

I’ve looked for an example where the data I have gives the exact correct location of a stop. I haven’t found it. As far as I can tell all the data looks something like these examples. I’m not sure if that’s something that can be fixed automatically (I have some ideas) or if I just have to accept that I can’t rely too much on stop positions.

My beta testers ❤️

As I’m working on this I’m lucky enough to have some dedicated and patient beta testers. In some cases I could have figured out that a fix or improvement was necessary but more often it’s stuff I’m not aware of myself. That’s where they come in and it’s been really great for the quality of the app already, even though there’s still work to do there.

Intro pages live demo

Another thing I’ve been working on is the initial flow, what happens when you first start the app. It’s still a little placeholder-y but I’m okay with what’s there now. The intro slides look a little smushed but the screen on the test device is quite small, it looks nicer on a larger phone.

New UI live demo

For the last while I’ve been working on UI, UI, UI. A lot has happened, both superficial and fundamental.

The most visible change probably is that the bookmarks list has become cleaner and simpler – now you have to click a bookmark to see the next departure but that extra information right on the bookmarks page made it look a mess. Also a ton of small things have changed: now the icons show the right kind of transport symbol, I’ve added different colors to make them easier to distinguish, they can now be rearranged and deleted by dragging. I’m getting to a point where I’m actually quite happy with how it looks and works.

On the nearest stops front I’ve added a new card, departures from the nearest stop. There’s still some work left there – the logic for deciding whether you’re near a stop gets it wrong sometimes and it doesn’t refresh properly. But it’s getting closer.

What took the most work was the new add-bookmark flow. That required figuring out where all the stops are located and how the different subdivisions are located relative to each other – regions, cities, localities within cities, etc. I ended up relying on data from DAWA, Danmarks Adressers Web API. From that I got the nearest address in the country to each stop and then I used the components of the address for the subdivisions. I think the result is pretty decent – there needs to be a search function for it to be really useful but it’s a good place to start. One problem is evident in the screencapture though: stops in other countries end up all wrong because DAWA only handles Danish addresses, if you plug in a place outside the country you’ll get the nearest address within the country. That’s why right now Hamburg is listed as being on Langeland. I’ll fix that eventually.