One of the big differentiators between humans and computers is that humans need to interact with the world. This gives us a huge head start to defeat our computer overlords before they rise against us.
Catch up and read Part 1!
Challenge #2 - Useful Paths of the World
When I look out my window I can see sidewalks, mountains, streets, trees, and buildings. Our senses perceive real-world objects with which we can infer uses and challenges.
Computers, satellites, and cellphones are blissfully ignorant of these items, their properties, and functions. Your cellphone camera, too, lacks useful comprehension of the world. For electronic devices to interpret the world, they need models of functional classes with attributes and methods. We need to tell teach computers how we interact with the world so that they can help us navigate it.
Computer pathing needs barriers and other helper classes. The device can use direction information with software objects to generate useable instructions for us.
All of this seems complicated, but don’t be intimidated. The concepts are within all of our reach even if few of us have the skills to actually program it. Let’s start with the waypoint class.
Waypoints
Waypoints are an extremely simple class. All they do is highlight the location of an area where a person can walk/drive to and change direction at. Each of these points are defined with a GPS coordinate. Because they determine areas where direction can change, they must be carefully chosen for the computer to create useable paths.
From a developer’s perspective, the most challenging part of waypoints is getting someone to determine where they actually are. You can either spend hours on Google maps clicking on individual points and recording their values, or you can physically go there (and take pretty pictures of your dog while you're at it):
The story from the GIF above is that Google needed to hire a person to hike and map an island in Korea wtih a camera and geolocation device. This can get expensive for corporations since professional hikers are hard to come by. To a vitamin D deficient cubicle rat, like me, professional hiking seems like an enviable job. A 70 lb. satellite transceiver payload, is beyond my level of athleticism sadly... I must remember the sour grapes!
Paths
Paths are important because they define where a person will need to go. They connect waypoints like a “connect the dots” childrens game. These “dots” use “direction” established in part 1 with the rule that the software must identify the closest path waypoint to the user’s GPS device (preferably going closer to the destination). Conceptually this is simple to understand:
- Give a child a connect-the-dots page
- The page includes a dot with instruction “begin here”
- The page includes a dot with instruction “end here”
- Inform the child that they must connect the dots using the constraint that “only the two closest points can connect”
- As a final rule: if two dots are the same distance away, the child must select the dot which moves most directly towards the final destination
Since we are using “Direction” from part 1, the direction class and waypoint class are interacting to create an instance of the “path” class, which has its own attributes and functions. The 5 rules outlined in the connect-the-dots game are obvious to humans; therefore, simple for a developer to conceptualize.
We are getting close, but a computer program such as this could still provide instructions for you to walk into a tree. So there is at least one more layer of complexity required == the barrier class:
Barriers
Barriers are more complex than waypoints as they could be defined as a list of points, vector shapes, or something else. They serve a critical function as an additional constraint to pathing way-points. More simply put: barriers tell software that something is in the way, and force it to select a waypoint that seems less ideal mathematically. Unconsciously, you make these types of decisions every day.
The decision to avoid barriers is simple. When you walk toward an ice cream cone or other desirable item, you walk around, climb over, or crawl under barriers that impede access. Contrastingly, video gamers remember the early GTA games like 3 and “Vice City” where non-playable characters walked into brick walls while attempting to get to their destination. I walk into walls all the time after my morning coffee... unlike for computer characters, it hurts. Computers are entities without bodies, they do not feel pain when they navigate humans or robots to injurious environments.
Barrier classes preempt a computer’s navigational mistakes by helping pathing functions to generate “closest actual waypoints” rather than theoretically closer waypoints. This function helps prevent users from walking through brick walls, ice-cream stands… or off cliffs.
Complications
And this is where GPS begins to get complicated on several levels. From a graphic design perspective, the software should display informative cartology to a system user: people avoid ugly things and are attracted to beauty. On a computational level, the developers must define the interaction of at least 3 software classes (and likely 5 or more) to deliver the results people are looking for. This means that there are many potential connection points and interactions between classes!
Fortunately, we can disregard the inner-workings of the software or artistic thought process and leave them to the experts. We should, however, remain diligent of the Dunning-Kruger effect as these things are more complicated than you and I fully imagine. It is best not to promise a 3 day developmental timeline on a project like GPS navigation.
Thanks for reading. To move on to the last part of the series, Part 3, click here!