New York City’s Department of City Planning provides a wonderful resource in the LION dataset, which contains lines for streets, paths, railroads, and administrative boundaries. There is one problem with the most recent version– it is only available in ESRI’s proprietary File GeoDatabase (or GDB) format. While the format has some advantages (more on these below), it is not easily accessible in many free/open source tools. I recently had occasion to work on converting LION to a more accessible format for display and light analysis, and this post outlines that methodology and provides the results. Continue reading “Slimming down the LION”
If you’ve done your homework on systems and how they hook up to the Internet, you have encountered the term API. APIs (Application Programming Interfaces) are defined methods for applications to talk to each other. All web users use them daily without knowing; if you load Google Maps or any Webmail page, your computer is first downloading a program that runs in your browser and that program is making ‘calls’ to an API to fill your screen with information. Many, though not all, AVL vendors include APIs with their system for data to be used in novel applications.
That is all well and good, but it might surprise some purchasers of AVL systems that they do not own the rights to data from their own vehicles. Like airline fares, some vendors un-bundle data ownership and the license to re-use it from their standard product, requiring extra payment to get access. This makes any additional applications or analysis very difficult. You shouldn’t let this happen, and many of us in the field are adamant. Further legal opinion on the topic can be found in TCRP Legal Digest 37, which notes that:
Although real-time data as such are not copyrightable, the majority view seems to be that a license or other agreement with provisions restricting access to or use or dissemination of data are not preempted by the Copyright Act. The rationale is that contracts affect the rights of the parties to the contract and do not involve exclusive rights against the world as exist under the copyright laws.
Legal digest 37 also contains sample contractual language to make data ownership clear. Ideally, this would be included in procurement documents.
Now that this is out of the way, I’d like to introduce Sean Barbeau’s presentation from APTA TransitTech 2013, which provides a very good introduction to APIs in the real-time transit context.
User Interfaces (UIs) are by definition the most visible part of any technology project. For brevity, both dispatcher and passenger-facing UIs are lumped together. This is not my specialty; rather than rehashing details, I’ll point out two excellent sources for introductory content, and then cover a couple questions that must be considered when buying an AVL product.
Usability.gov maintains an excellent library of public-sector focused content related to usability, user interfaces, and user experience. This article might be an excellent entry point. If that seemed too simple and you’d like to get your feet wet, check out the lessons at Hack Design.
Before beginning procurement, the most crucial UI-related decision is what are the use cases for the product?
UIs are typically distributed as a client or via a web-interface. Regardless of the choice, the two most crucial technical questions surrounds the dependencies required– are there any required libraries or plugins for it to function, and will it run on a tablet or smartphone? While PCs are currently standard issue, the marketplace is changing rapidly. Even if mobile devices are not in your requirements, during the life of your AVL project someone will want to access the system on one.
Finally, no web-based user interface should be accepted if it does not run on a recent version of Chrome, Safari, or Firefox on a desktop computer. Some AVL vendors are still hocking products that require outdated versions of Internet Explorer, and these should be avoided like the plague. Similarly, plugins such as Flash and Silverlight are slowly dying and are a constant source of security vulnerabilities; any system requiring them should be considered carefully.
The second mistake was to adopt a narrow view of the type of […] people have always […], as if all habits were deeply rooted traditions instead of accumulated accidents.
Clay Shirky, Cognitive Surplus
Traccar is a free, open-source AVL package. If your use case is primarily plotting device locations on a map and you can gather some moderate technical resources, it is a great option for you.
I like it for the following reasons:
- It has comprehensive support for a plethora of devices, including an Android (and soon iOS) client application, purpose-built trackers, and modems with embedded GPS.
- It is very easy to set up on Windows, Mac, or Linux.
- The project author is friendly and very responsive.
- It is reasonably well-architected and easy to modify, unlike its competitor OpenGTS
This post at opensource.com describes one librarian’s experience with getting his employer to use Open Source software. He makes an interesting point:
By choosing my words carefully and avoiding these four words, I successfully brought open source to our team.
Open source … Free … Contribute … Development
I draw the following conclusions:
The first rule about getting an organization to adopt open source software is to not talk about open source.
The second rule is to NOT TALK about open source.
The third rule is to get buy-in and do it.
I had the absolute pleasure of attending the Write The Docs conference in Portland last week. Write the Docs is “a time and a place for this community of documentarians to share information, discuss ideas, and work together to improve the art and science of documentation.” It was one of the best conferences I have ever attended, with interesting presenters and people across the board. A crazy compendium of notes and links on talks and presenters is here.
The top three talks I saw were:
Brian Troutwine’s talk on instrumentation and complex systems is something that anyone who manages a real-time (e.g. AVL, SCADA, etc.) system should watch. He begins with pointing out that complex systems fiendishly difficult to communicate about. This gap of understanding is difficult to bridge in documentation. Instrumentation combined with documentation is really where the magic happens, and where you see the system actually work.
If you don’t know how the system should behave, you can’t say how it shouldn’t.
IF YOU DON’T TRUST A COMPUTER BECAUSE SOMETIMES IT DOESN’T TELL YOU THE TRUTH, TELLING IT TO TELL YOU TO TRUST IT IS ASKING IT TO LIE TO YOU SOMETIMES.
Maxwell Hoffman’s talk on writing for a global audience fit the theme well. He points out that by following
10 rules from standardized aerospace engineering English, our writing can not only be more clear, but better understood in translation. Sadly, the video is not available but notes are.
Millenials are re-incarnated people who died in 60s. They use active voices.
Finally, Christina Elmore’s talk on Death by Documentation takes a hard line on the difference between presentation and documentation, and meetings versus conversation. In it, she references two great (and free!) resources: Nancy Duarte’s Resonance Book, and An Introverts Guide to Better Presentations.
Work to eliminate the presentation within your organization.
My name is Tony and I’ve spent most of my career putting GPS on buses.
This blog exists to introduce transit people to technology, and tech people to transit. I will cover a breadth of topics, from the philosophical, to practical, to deeply technical.
I believe in sharing my experience in a clear, concise, accessible, and vendor-neutral (no sales pitches!) manner.
I will be happy if this blog is a fraction as helpful to the industry as Jarrett Walker’s Human Transit blog.
FAQs are below the fold.
Continue reading “Introduction”