Last night I was looking at what it will take to put animated cars back on the roads in X-Plane. (I can’t say if or when they will come back…that’s a subject for another blog entry.) I found something that’s going to be a little tricky.
Simply put, the road data we use in the US (Census TIGER data) does not contain directional information. It might tell us a street is one-way, but it doesn’t tell us which way it goes!
In fact, the data doesn’t even say which highways connect to each other! The road data is “flat”. If two highways cross each other we see this as a four-way intersection. In the original US DSFs the roads were built with this flat pattern – sometimes you’d see a 10-way intersection of limited access highways.
In an attempt to clean up the highways for the global render I wrote some code that attempts to evaluate junctions for traffic flow. Basically it knows that two limited access highways at right angles cannot intersect and it moves one up in the air as a bridge. This process iterates a bit in an attempt to make a junction that is fully real-world navigable.
One advantage of processing the roads in this manner is that often it will remove bogus junctions, allowing us to continue straight roads. This both reduces file size and improves the look of the roads. (Our road junctions still look terrible – a throwback to a time when road-creation paused flying and therefore speed was at a premium over visual quality.) Unfortunately this “layering” code sometimes goes haywire and does some pretty strange things:
- A highway may be put in a high layer in one junction and a low layer in an adjacent one; the result is a highway ramp that “dives” down at a steep angle to try to meet all of its crossing restrictions. The layering code isn’t smart enough to find optimal junction ordering when there are many junctions nearby.
- Sometimes the number of layers just gets huge, creating a massively tall junction. (But then, in Los Angeles perhaps this is realistic!)
How does this relate to cars? Well, what is significant here is that the algorithm does not consider directionality of one-way roads since we do not know it. Furthermore, the DSF optimizer, because it was written under the assumption that we really have no way to know which way a one-way street is going, will flip the direction of one-way roads to reduce file size. (Sometimes changing the direction of a road segment allows for tighter file compression.)
The good news is: DSF files do have a notion of direction, so if we ever get better road data, the sim and file format will be ready. The bad news is: the current DSFs have a road grid that may be similar to driving in Boston.
(As a side note, I grew up driving in Boston, so none of those rules seems even slightly unusual to me. What did surprise me was: when I moved to Washington, DC I found the rule that the cheaper car has the right of way turned on its head. I’ve never been cut off by more reckless BMWs and Mercedes in my life. You can speculate about what this says about the culture of our capital.)
Clearly X-Plane’s car engine needs to address this in some manner. There are two cases that are tricky: one way roads that end at the destination of other one-way roads (leaving the car with no legal route) and one-way roads whose origin is not connected to anything but the origins of other one-way roads (giving cars no way to reach the road). The later case is not really a problem – it just means the road will have no traffic; the later is more of a problem as it requires the car to do something illegal to get out of the situation. I am still looking at what we can do about this but my guess is that cars are going to have to employ some Boston driving to get around the X-World.
Would it be feasible to use openstreetmap (www.openstreetmap.org) data perhaps?