Disclaimer: nothing you read in this blog is even remotely like a “promise” about what future X-Plane patches or releases will do. This blog contains my ramblings, not a commitment to future features.

I am looking at allowing road networks in overlay DSFs for X-Plane 9. I’m not sure if this will be possible (this is just an investigation right now). But I realize that…

  • The road data in the default scenery isn’t much good. Even in the US, where we have nice data, the roads are chunky, not smoothed, contain invalid flow information, and can have lateral error of up to 200 meters (enough to cause chaos). Of course the non-US road data comes from VMAP0 and is just as good as you’d expect from digitized 1:1,000,000 maps from WWII (which is to say, they’re awful.)
  • Therefore there is a lot of interest in replacing the road grid using overlays. This isn’t possible in X-Plane 8 (put a road into an overlay and I think X-Plane will crash pretty hard). If roads could be in overlays, this would let you correct them and exclude the entire underlying layer.

There’s another hitch to this…for historical reasons, the road system uses MSL heights (that is, it exists in absolute space and is pre-placed to “hug” the road grid). At the time, when all scenery load involved a giant pause and y-testing was expensive and the entire road grid was built at once, this helped performance. A number of those fundamental problems have been solved.

But if a road grid is pre-placed (and not “draped” like a .pol file or OBJ) then the roads must be built to a specific set of global scenery mesh. I’d like to see custom meshes start to emerge, and hopefully I’ll have some time in the future to work on tools to make this a lot easier.

So the feature that would go hand-in-hand with overlay roads is AGL-based road heights (that is, the roads only specify when there is a bridge and not exactly how to hug the ground). As far as I can tell from my initial investigation, this is quite a bit more complicated to implement and is probably still a while off. I think that overlay roads could be useful even in their MSL form though.

(One interesting use would be: create roads with no geometry, just car definitions, and use them to overlay routes for ground vehicles in airports.)

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

2 comments on “Future Road Features

  1. Hi Ben,

    I take this way – instead of the “usual” mails 😉 – to comment on this stuff. First of all – of course – I’m very happy to see your plans for the new roads. Having the draping – instead of absolute 3D placement – will make so many things easier (and more compatible) and should encourage more scenery development. Especially when I think of custom mesh – as you already pointed out – that should be great …
    BUT (i always come up with a but 🙂 I’m now thinking about the forests (what else). You know, there will be an issue, if we handle them as we do it today. Namely, forests have to be “prefabricated” to make place for roads (we cut them out in advance). So, what do we do, when people begin to place/move new/existing roads en mass??? You know, suddenly there are many trenches in the forests that are empty, and highways totally overgrown …. this is not so simple … one solution would be, if (you know what comes now 🙂 could clear forests at scenery load time in X-Plane (and I wouldn’t have to “pre cut” them) .. but we also know, that this isn’t simple either.
    OH, and if I think about it further, I realize that there are even more “prefabricated” features which rely on prior knowledge about the road networks: your global scenery city objects. So, I’m afraid there is a lot to be considered when thinking about roads …

    By the way, I was lately looking around in the goedata domain again, and found some interesting new stuff for road data (though, still none of them is complete enough for use in global scenery):

    – kind of an improved VMAP0. I have already access to their data, and it seems to be a bit ahead of VMAP0 in terms of accuracy (for example when I looked how roads go along the shores of SWBD data – though, it has its imperfections too). If you are interested, I can make some comparisons for you. BUT, ISCGM data is still not available for the whole globe (but they are actively working on it and bring out new countries every 2-3 weeks)

    – this is a very interesting open source project. They try to map the planet via GPS – through the help of many many many volunteers. AND they also seem to get (data) donations from some organizations. The city areas of Germany for example do look very promising already … though, they still have a long way to go.

  2. AlpilotX, I think (from reading some of your posts on GIS-based scenery development) that you understand the fundamental problem here: as soon as we break the sim into layers (allowing each layer to be separately improved) the risk of layer conflicts goes way up.

    But what we have now (you can only correct the whole DSF) isn’t the greatest solution – it’s sort of like curing a tooth-ache by cutting off one’s head. 🙂

    I see this kind of issue come up in MSFS, where reviewers say “I like add-on X, but I didn’t like that it mismatches add-on Y”, when of course the two add-ons were developed against the default scenery and not each other.

Comments are closed.