Connecting the dots - Nodes, Edges, Intersections & Sections

Here's how we start the processing of turning dots and lines into cycling routes at Huli

5 mins
Written by
Chris Lowe

In a previous blog, Huli's CEO, Steve, talked about some of the data we use to generate routes in Huli. Specifically the nodes, which are defined by their unique latitude, longitude and altitude. In this post we're going to expand a little more on Nodes, but also introduce some of the other data we use, specifically Edges, Intersections and Sections. These all help us to generate great cycling routes, using publicly available data, that meet your riding needs.


To recap, a Node is a point that represents part of the road and trail network. We pull these in from Open Street Map, which gives us their latitude and longitude, and add detail such as the "altitude" or "height above sea level" from other sources. Nodes aren't simply a location though, and can include additional info that we use. For example if there's a traffic light or gate at a particular point. It's the Nodes that hold information about specific points on the ground. We'll go deeper into the OSM information in another post, so stay tuned for that! But Nodes are only half the equation when it comes to our raw data set. We need to get between them. Welcome, Edges!


Every Node in our network has at least one Edge that connects it to a neighbouring Node. Edges represent the short (and sometimes not so short) segments of footpath, road, bridleway or other "highway" element and are straight lines. Because Edges are straight, a bit of technical singletrack, snaking its way down a hillside, would be made up of lots of relatively short Edges, whereas a long, straight, uninterrupted major road would comprise relatively fewer, but much longer Edges. Because of this, no road or path in our network is actually curved, it's just lots of short straight lines joined together to look curved. Here's a snippet of some mountain bike trails near Falkirk, from Open Street Map, showing the Edges and Nodes as they appear in the raw data (the little black arrows, in this case, show the "direction" of this trail).

How Nodes and Edges look in OpenStreetMap

Nodes and edges provide the shape details of the network, giving us information about distances, surface types, gates, bridges, road classification, blah blah blah, loads of stuff! However, at Huli we take things a step further as a lot of this information can be condensed while still being useful for route planning. We pick out the stuff that's important, and ignore the rest. Think about it this way, if you need to get between two junctions in a road, do you need to know that the first 10m are straight, all on tarmac, with 1m of elevation gain, and then for the next 15m you turn to the left by 15 degrees, still on tarmac, now going slightly downhill...etc? YAWN!!! Of course not. Knowing the section of road is 800m long, mainly flat and all on tarmac" is plenty of info for now, so that's basically the level we get it to.


For route building, the thing we're MOST interested in are the points at which a decision can be made, i.e. junctions. This is where we have choice, and routing algorithms LOOOVE choice! We call these decision points Intersections, and are basically all the Nodes that have more than 2 edges coming out of/going in to them. When we come to build routes, whenever an Intersection is reached a decision is made to go one of a number of directions, and it's the combination of all these tiny decisions that form the whole route. Here's a GIF showing the Nodes (blue) and Intersections (red) at Black Law Windfarm. Notice how some of the Nodes are quite far apart, joining long sections of straight service road in the Wind Farm. And yes, some of the Intersections are at dead-ends, but don't worry we filter them out later so we're not constantly including them in our routes 😊

Nodes (bue) and Intersections (red) at Black Law Windfarm


In the same way that we join Nodes together, we need to join Intersections together so that they form a connected network that we can route through. We do this using Sections, which are effectively just sequences of Edges. Once you're on a Section, there's really nothing you can do but ride it all the way to the next Intersection, since it's the Intersections that are the "decision points". All of the vital statistics and details from the Nodes and Edges that exist between either end of a Section are captured on the Sections themselves, so nothing is lost. As you can hopefully imagine, working with Sections and Intersections rather than Nodes and Edges really reduces the number of elements in our network, which helps a lot to keep the route creation FAST. For context, we've got a whopping 41.7 million Nodes and  80 million Edges in our UK & Ireland network, but only 8.1 million Intersections and 19.6 million Sections! Still big, sure, but much more manageable. We actually break this down more to simplify things even further, but I'll tackle that in another post.

Below is a before and after image of what a small network segment might look like as Nodes/Edges (left) vs Intersections/Sections (right). Remember, all of the important details are stored on the Sections and Intersections, so we don't lose anything by simplifying the network, but we do gain a LOT. The sum of the edge distances, the total elevation gain, the total elevation loss, surface types, any barriers or obstructions, and much more, are all retained.

The transition from Nodes & Edges, to Intersections & Sections

I think that's plenty to take in for today's blog, I hope you've enjoyed learning a little more about how we process, create and store information about our network. If you have any questions or comments, I'd love for you to get in touch at, or you can get me on Twitter, Instagram or LinkedIn. Thanks so much for reading and enjoy the ride!

Try out Huli now and see the Nodes and Edges come to life by downloading the app on Android or iOS 🤟

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.