[HN Gopher] Show HN: Public transportation signage based on bloo...
       ___________________________________________________________________
        
       Show HN: Public transportation signage based on bloom filters
       (rough mockup)
        
       Hello, I was running around Germany, hectically navigating public
       transportation, and getting lost all the time. I noticed that every
       station had i platforms, each used lists of n buses (trains,
       whatever) arriving, each has their list of m destinations. That
       means I would be scanning i x n x m items just to see if I was at
       the correct stop. As I was nervous, for every bus that arrived, I
       would rescan the list of stops to double check. I began thinking
       how I could make a better system.  Linked is a very shoddy mockup
       of how bloom filters could be used to allow passengers O(1) lookup
       time for which platform+bus is the correct one. I believe it's
       likely for public transportation to grow increasingly more complex
       in the future, as population grows, and under the current list-
       based system, this will make the signage ever more complex. I think
       some bloom filter mechanism could reduce that complexity.  So, here
       is my fantasy, my day dream. What do you think?
        
       Author : bitsinthesky
       Score  : 63 points
       Date   : 2023-03-21 16:50 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | do-me wrote:
       | Very nice idea!
       | 
       | I think this could be really useful for visually impaired people.
       | Just imagine, that instead of colors and letters you'd have
       | unique shapes or to keep it simple something like a raster with
       | holes. Every bus stop could have one of those raster plates while
       | the people would have a sort of "key", designed to fit in "their
       | bus".
       | 
       | I came up with a very similar approach to explain HyperLogLog a
       | while ago and see some parallels.
       | 
       | Have a look at the (yet very ugly) illustrations I made a while
       | ago: https://geo.rocks/post/hyperloglog-simply-explained/
       | 
       | I guess the key/lock principle is very similar to both, bloom
       | filter and HyperLogLog and could yield other benefits as well,
       | like counting distinct buses passing a stop and map them for
       | city. In this way, one could easily create a heat map of the
       | cities best- and worst-served areas.
        
         | bitsinthesky wrote:
         | That's a very cool idea. Thanks for the blog, it's well
         | written. I love how you've applied the idea of a hashmap to a
         | 2d foam board. I'm on the verge of having a breakthrough of
         | improving my visualization but so far it hasn't arrived. If you
         | think of anything feel free to let me know.
        
       | masukomi wrote:
       | 1. riders must not read signage in a given language or alphabet
       | 
       | it's literally in a specific alphabet. If you were an Arabic
       | speaker these letters would be just as much gibberish to you as
       | Arabic letters would be to an English speaker. Not just
       | gibberish, but hard to tell apart.
       | 
       | 2. very quick to see where you need to be and which bus you
       | should board
       | 
       | I watched the video to just to be sure i wasn't missing something
       | but... no. So very much _no_. I assume that to _you_ this is
       | clear. To me this is modern art. I think if you explained it to
       | 10 non-geeks you'd get... 10 people saying "no, this is not fast
       | or easy" maybe with sufficient training, but even if you got 100%
       | adoption amongst locals any foreigner passing through would be
       | absolutely screwed.
        
         | johtso wrote:
         | I mean to be fair, they're being used as symbols here so the
         | fact that they're latin alphabet doesn't make a particularly
         | big difference. Replacing the letters with very easily
         | distinguishable non-language symbols would probably be better
         | though.
        
           | TylerE wrote:
           | At the very least, pick one case and stick with it, don't mix
           | upper and lower.
        
         | bitsinthesky wrote:
         | Thanks, I've added a note saying the video doesn't add new
         | information. It's just a different avenue of explaining the
         | idea. I think "modern art" isn't so far off the mark, but I'm
         | hoping somebody smarter with more resources will adapt it or
         | improve upon it in some way.
        
       | xg15 wrote:
       | The idea has something - and I'm surprised how fast visually
       | scanning for the pattern actually is (once you got the
       | principle).
       | 
       | However, the visual appearance of it right now is daunting. Keep
       | in mind, people are already overwhelmed by a map with hexagons
       | [1] - I think the chances are slim they will want to engage with
       | a complicated grid full of cryptic letters and symbols (unless
       | they already work in IT or public administration).
       | 
       | I think at the very least, you'd have to style it in a way that
       | makes clear that the graphic _as a whole_ is a visual indicator -
       | and that you _don 't_ have to make sense of each individual
       | symbol or letter.
       | 
       | I'm just wildly guessing here, but I'd get rid of the letters and
       | only use shapes or symbols to prevent confusion with footnotes.
       | Also you could give the entire thing a recognizable shape, e.g.
       | use concentric circles with segments instead of a grid.
       | 
       | A graphical designer would probably have better ideas how to
       | approach this.
       | 
       | The biggest problem I see is that the way bloom filters work
       | doesn't match the intuition of how to use this signage and misuse
       | could easily lead to confusion and disappointment:
       | 
       | If I'm a traveler scanning for my fingerprint, I'd expect that if
       | I found the fingerprint on some bus or platform then I could
       | trust that this is the way to my destination. However, that's not
       | what bloom filters do: They only guarantee that if you _don 't_
       | see the fingerprint, then that way definitely _won 't_ lead to
       | your destination - but they can easily produce false positives,
       | where your fingerprint is present in the signage, but the bus
       | will still be the wrong one.
       | 
       | So imagine you're some traveller, already stressed out and trying
       | to understand an unfamiliar system. You've actually wrapped your
       | head around the system and have finally found your fingerprint -
       | on a bus, which is about to depart, so you jump on it in the last
       | minute with no time to double-check the destinations. You're glad
       | you made it, until you realize that it's in fact the wrong bus,
       | even though the fingerprint said it was the "right" bus. You have
       | never studied CS and have no idea what a bloom filter is, so
       | you're just confused and angry that someone must have put up the
       | wrong sign - and probably not inclined to use the system again
       | for the remainder of the trip.
       | 
       | [1] https://www.vrminfo.de/fahrkarten/tarif/tarifwabenplan/
        
       | tz18 wrote:
       | this feels like some hellish thing you would be faced with when
       | you first try to use a bus in germany. so in that sense you have
       | succeeded!
        
         | TylerE wrote:
         | While not nessesary hellish to me, it is very very very German.
        
         | rafram wrote:
         | German buses are very straightforward in reality. Only issue is
         | the risk of getting on in the wrong direction IME, but that's
         | really on you.
        
       | sitkack wrote:
       | Neat! I also used a bloom filter as a temporal spatial index,
       | different problem but the property that they can be merged into a
       | tree is very nice.
       | 
       | Could be used as an overlay for augmented reality glasses.
        
         | asdff wrote:
         | If we are bringing in AR glasses in the mix, there's no need
         | for the bloom filter. Just highlight the relevant bus if its
         | the one for you. Let the computer handle the mental load of
         | matching schedules.
        
       | Symbiote wrote:
       | It's interesting, but I don't see any way it might be adopted.
       | 
       | The existing directions are "From Osnabruck Hbf platform 11, take
       | train IC2241, IC245, IC141, IC143, IC145, IC147 or IC149 with the
       | direction 'Berlin Hbf'". The old timetables (not sure if these
       | are still present in German stations) would give information like
       | this:                 From Osnabruck Hbf:            ...
       | Stendal Hbf: 06:04 IC2241*, 08:05 IC245**, 10:08 IC141, 12:08
       | IC143, 14:08 IC145, 16:08 IC147, 18:08 IC149. Plat. 11.
       | 
       | (I have made up the * and **, which might annotate things like
       | "Mon-Fri only".)
       | 
       | Given a current time of 16:00, that becomes "From Osnabruck Hbf
       | platform 11, take train IC 147" or "the 16:08 train from platform
       | 11".
       | 
       | The platform number is useful, as they're almost always numbered
       | and signed in order. Once there, matching "IC 147" or "16:08" is
       | easier and more reliable for most people than a collection of
       | shapes and symbols.
       | 
       | You will note that in the 1990s, it was perfectly reasonable to
       | give an 11 year old the directions "take the train from platform
       | 93/4 at 11:00".
       | 
       | Edit: I'm mixed up. German stations seem to have the backward
       | timetable (ordered by time, so I can arrive at the station at
       | 16:00 and can see where I could go). The easy improvement is to
       | format them like the British do.
       | 
       | British stations have an indexed timetable. Every directly-
       | connected station is listed in alphabetical order, the trains
       | listed by departure time. If appropriate, important towns needing
       | a connection will also be listed.
       | 
       | Here's a general image: https://www.alamy.com/stock-image-
       | national-rail-notice-board...
       | 
       | And here's a higher resolution part of a different one:
       | https://www.alamy.com/stock-photo-uk-railway-train-timetable...
       | 
       | Even works at the largest stations:
       | https://www.alamy.com/paddington-railway-station-london-uk-w...
        
         | bitsinthesky wrote:
         | That's a good point. Because of this chaos, there would need to
         | be a way to update track state etc.
         | 
         | Either my implementation would need high-res displays showing
         | current bloom filter data, or there would have to be interns
         | running big printed paper posters all around showing "updates"
         | 
         | EDIT: I misread your comment. The chaos I was referring to was
         | that trains change which platforms that they land on, and the
         | same trains at different times/days may go to different places.
         | 
         | The British way does sound like a cheap improvement. Very
         | obvious, I can't help but laugh. Thanks for the comment :)
        
       | bitsinthesky wrote:
       | For the main idea, basically, you get a small "fingerprint" of
       | the stop you want to go to. Every train that comes has a
       | "fingerprint" of all its stops overlaid. So you can immediately
       | see if this train will take you to your stop by seeing whether
       | all the bits of your fingerprint are displayed within the
       | fingerprint of the train.
       | 
       | Likewise, you can tell if waiting at a bus-stop will bring a bus
       | that will take you to your destination, by overlaying all of the
       | busses' fingerprints together. If any bit of your destination
       | fingerprint is missing from any train or station, then this
       | train/station is irrelevant to getting you to where you want to
       | go.
       | 
       | Thus lookup is now O(1).
        
         | captn3m0 wrote:
         | Wondering if Emoji Sequences would be a more user-friendly
         | approach for visualization.
        
           | bitsinthesky wrote:
           | I was wondering about emoji's too. That could work rather
           | well. I think if you had a 2d array of like 200 unique
           | emojis, with some subsection-ing of like, quartile, you could
           | simply say, "If your train has a crocodile in the top left
           | square, a star eyed in bottom right..."
           | 
           | There's some paper discussing how high dimensional parameters
           | can be visualized with human faces, because aspects of the
           | face are quickly identified by humans. I think they used
           | ideas such as, How far the eyebrows are apart etc. Maybe
           | making (disfigured) human faces with binary features would be
           | easier to parse too.
           | 
           | In any case, what I've come up with is well below optimal.
           | I'm not sure I even need the number of bits I've included,
           | but I show them as some kind of worst case.
        
         | elil17 wrote:
         | It seems to me that the 0.5% false positive rate makes this
         | unusable for practical purposes (since that would mean that 1
         | in 200 passengers gets on the wrong bus). How big would the
         | sign need to be to have no false positives?
        
           | bitsinthesky wrote:
           | The parameters can be configured based upon system complexity
           | etc. but there is always going to be some level of false
           | positive. But that still may be okay if there are still those
           | i x m x n lists posted around, one can quickly focus in on
           | which lists are, let's say, 99.5% likely to be the relevant
           | bus stop lists.
        
             | michaelmior wrote:
             | > there is always going to be some level of false positive
             | 
             | That's not necessarily true. Even if you're dealing with a
             | large number of stops, routes generally aren't changing
             | very frequently. This means you can afford to spend some
             | time tweaking the output to get the false positive rate
             | down to zero.
             | 
             | This isn't strictly a Bloom filter anymore, but I think any
             | level of false positive makes this a non-starter. I can't
             | imagine any transit agency would knowingly to put up signs
             | that will misdirect customers.
        
             | elil17 wrote:
             | Seems like the kind of thing that is great in theory but
             | would end up with a high error rate in practice.
        
               | pavel_lishin wrote:
               | It also seems like it would actually be fairly difficult
               | to explain to a majority of people, especially in a non-
               | verbal way.
        
         | vineyardmike wrote:
         | Technically, the lookup using O(1) since you need to find your
         | fingerprint in a grid. I fail to see how that's much faster
         | than finding your stop in a list. Especially considering the
         | false positives.
        
       | swyx wrote:
       | i mean i assume if you gated things by city, the i x m x n isn't
       | that high that you cant do a naive inefficient implementation
       | rather than using bloom filters. but hey whatever rocks your
       | boat! would be better if you had a live/standing service so pple
       | can try it out
        
         | [deleted]
        
       | UncleEntity wrote:
       | > riders must not read signage in a given language or alphabet
       | 
       | But will have to read a manual in a language they understand on
       | how to read signage.
       | 
       | Confused tourists who doesn't speak German looking at sign in
       | utter confusion...
        
       | crote wrote:
       | It's a nice idea, I quite like how it visualizes how bloom
       | filters works!
       | 
       | In practice it is probably a bit too complicated to be used -
       | especially once you take into account things like routing (you
       | can either travel A-B-D or A-C-D) and indirect lines (One line
       | goes A-B, another goes A-C-D-E-F-G-B. You obviously would prefer
       | the second).
       | 
       | In my experience, the problem has _mostly_ been solved by public
       | transport apps, which simply provide you with an itinerary. For
       | example:
       | 
       | Option 1: At 13:14, take bus 5 heading to Hauptbahnhof. At 13:45,
       | take the train with destination Berlin-Spandau departing from
       | platform 3 until it arrives at Sudkreuz. At 14:15, take bus 30
       | heading towards Tempelhof departing from stop A until you reach
       | Paradestrasse.
       | 
       | Option 2: At 13:20, take bus 6 heading to Hauptbahnhof. At 13:45,
       | ....
       | 
       | Combine that with a neat little GUI and there is zero thinking
       | involved. No need to care about timetables and destinations, just
       | follow the instructions to the letter. It can even auto-update
       | when there are delays if the vehicles have GPS trackers.
        
       | elil17 wrote:
       | I feel like this is a cool idea for a way to visually communicate
       | information that just needs the right application. Seems like it
       | would be a great videogame mechanic (like some sort of hacking or
       | lockpicking minigame)
        
       | [deleted]
        
       | tobr wrote:
       | It's a fun idea but the system would probably be impenetrable to
       | most riders. Wouldn't it make more sense to base it on a map? A
       | map of lines and stops already gives you a pretty good birds-eye
       | view of where you can go from a particular stop, but perhaps
       | there are ways to make it faster to recognize a particular stop.
       | So for example, your bloom filter visualization could be applied
       | to a certain geographic region, and would only need to cover
       | stops in that area.
        
       | [deleted]
        
       | iLoveOncall wrote:
       | [flagged]
        
       ___________________________________________________________________
       (page generated 2023-03-21 23:01 UTC)