back
13 comments
Hey HN, I’m the author of GeoFire 2.0. We built GeoFire to provide Firebase users with a client-side solution to querying geolocations in an efficient manner. You can use it to store geolocation data about items (e.g. cars, restaurants, hotel rooms) and then do location-based queries on that data in realtime. The library is built entirely on top of Firebase and has no extra server-side components. And its API will now feel right at home for anyone who is familiar with the API for the Firebase web client. It is backed by a comprehensive test suite and fixes some long-standing bugs in the original implementation. I would love to hear and respond to any feedback or questions you’ve got. And also to see what you create with it!
I'm a (very) novice web dev and have been poking around Forge[0]. I noticed all your time data is expressed in unix time. Do most real-time web apps express time this way? Is it a conventional best-practice?

[0] for example, https://publicdata-weather.firebaseio.com/chicago

Epoch (UNIX, or POSIX) time is how computers keep track of time internally. Programmers like it because it easy to do math on and requires no formatting.
Can we expect GeoFire for Swift anytime soon? :)
GeoFire for Obj-C and Java has been heavily requested for a while now. You may be the first to ask for a Swift version though! It's not on the schedule at the moment but we definitely hope to port the library to other languages at some point in the future.
Where are you getting the location data for the buses from?

AFAICT, the location data coming from Muni isn't live. That, or there are invisible buses roaming SF, that don't stop for me and teleport about.

It's being populated from a Firebase Open Data Set: https://www.firebase.com/docs/data/index.html

The open data sets are in turn being populated by a script we (Firebase) operates that pulls data from the NextBus API. It is live, real-time data, though the API does have inaccurate data from time-to-time.

Thanks. Though if you are able to actually check the routes on the ground, I believe that you will find that it's lying somewhere in SF, most of the time.

Why would something that was pulling data from buses only lie from time-to-time? The answer is that it's not live, I'm afraid. It's freaking.

Lie is a strong word. What you are seeing likely the result of lost connectivity to the bus, which NextBus compensates for with dead reckoning. Busses also deviate from planned routes to deal with construction, head to depots, or other random things.
That doesn't explain the ones that are continually leave the station, with the prediction constantly resetting as the bus doesn't leave. Or the ones that don't show up, and then the next one does, right on time.

If you don't know where something is, you don't know where it is. To give a number anyway is disengenuous, and breaks trust. To do it all the time, and call your data 'real-time' without caveat - lying may be a strong word for it, but it's still appropriate.

NextBus always uses a straight-line estimate for the vehicle position within a few stops from the terminal. This is based on the departure times in the Muni published schedule. However, Muni operators and dispatchers do not adhere to this schedule in any way, so the estimates that NextBus gives near the beginning of Muni lines are pure fabrications. Lies, you might say.
-1 for mis-use of "Real-time". This appears to just be a visualization of NextBus data, which as we know is a pack of lies.
Someone has certainly taken umbrage at having this pointed out for them.