Dealing with Z Generating OSM data from centerline map for use in Graphhopper

I have a proprietary centerline map in Shape File format. I have decided to try to convert it into OSM format, which will then feed Graphhopper. I have my own code to generate nodes for all the points in each line segment, and I have a table of the start and end points for each segment. I will not use my data with “real” osm data, so I’m arbitrarily assigning node IDs and Way IDs.

My problem is that I’ve extracted the end points of each way using three dimensions - X, Y, Z, where Z is between -1 and 4. Most nodes are at zero. But at a tunnel or overpass, segments can and do start/end at the same lat/long, but above/below each other based on this z-level. The issue is that now I have multiple nodes at the exact same X, Y coordinate, but different z-levels, which I’m not convinced is at all ok.

Well that’s the question, really. If I create multiple nodes at the same lat/long, one for each z-level, and I put them properly in my ways, will Graphhopper work with that? Or will having nodes in exactly the same location be an issue. If allowed, my problem is solved…

Alternatively, is there a way to use a single node for the lat/long, but in each way can I specify the z level of the first or last node, so that will in effect create a “turn restriction” (because you cannot turn left onto a bridge above you!).

Another project apparently tried to “bury” such nodes into a street segment by merging two segments together. So this eliminates the endpoints that could be right above or right below another. But there is no easy way to automate this - it is hard to tell what is a legitimate intersection, and what is a continuation of the same street…

Any suggestions would be appreciated!

If I create multiple nodes at the same lat/long, one for each z-level, and I put them properly in my ways, will Graphhopper work with that

There should be no issue. Do you observe one?

I’ll give you an example here in Connecticut. It’s where Rt 8 and I84 exchange in Waterbury, and there are lots of flyovers involved. I can’t tell you how the OSM looks at this location, because I’m dealing with a proprietary shape file. The long/lat of the point is about 41.551822, -73.051569 if you want to just take a look. There is an exit from one expressway going one way, an exit from another expressway going along above in the other direction, and a street named Riverside underneath both of them at this point. So when I queried the endpoints of all the line segments, I get 6 segments (equivalent of 6 Ways) all sharing the same lat/long, but two are at z=0, two are at z=1, and two are at z=2… So none “intersect”, they just continue along. I guess the reason these all terminate here is to point out that they “cross” at this point, but because we have the z value, we know they don’t intersect. If I can go ahead and create three nodes at that location, and feed that into Graphhopper, that would make my life a lot easier. I’ll go ahead and try it then…

As a follow up question - I assume Graphhopper considers intersections only where Way end points share a node. If two Ways share a node in the middle (like one is crossing over the other) this is not considered an “intersection” in Graphhopper node/edge graph, right? So Nodes in the node/edge graph are at either end of a way?

Nodes are separate if they have a different ID. If the have the same ID they’ll considered as identical and thus even connected if it is in the middle of a way. E.g. you have 1-2-3 and 5-2-10 then 2 is a new junction node in GraphHopper.

1 Like

Ok, great! Since SHP files only deal with intersections at their endpoints, I’ll just be sure to create a unique node for every point on each segment that is not the first or last node.