In my previous post I announced that we are using OSM for our vector data for the version 10 global scenery.  But what data are we using exactly?

The short answer is: we are using road/rail/powerline data for our road grid and coastline/lake/polygonal river data for water bodies.  This data replaces our use of TIGER and VMAP0 for those vector features.

We are not planning on using individual building data in the first global scenery cut from OSM; we don’t have the infrastructure for this yet.  OSM has a lot of data, and it will take time to find ways to use it all in the global scenery.  The distribution requirements of the global scenery also imply that we may not be able to use all of the data to its full potential due to the limits of DSF size.

OSM data comes with a tag scheme: a given way (line) or node (point) comes with one or more key/value pairs.  The tag scheme is not limited or controlled; anyone can put any tag on any piece of data.  (This usually shocks experienced GIS users when they first see it…it certainly astonished me.  You really have to think of OSM as more of a Wiki and less of a database.)  We only use certain tags for the global scenery.

The road tags we care most about are the tags that define:

  • Road type (e.g. highway=)
  • Bridges and tunnels (bridge, and layer – layers are important for getting stacking right).
  • Oneway (which defines the traffic flow direction).

We may someday get clever and start using width, speed limits, surface, and the other interesting tags, but for getting a first version of the global scenery done, those are the big ones.

We try to use any area-style waterbody (e.g. natural=land/water, landuse=lake, etc.) as well as the coastlines defined by the natural=coastline tag.

Our general strategy is: if you can see land/water and road type on the map, we try to use it.  In other words, we try to use the same tags the maps show so that people can see what the effects of their editing are.

We may have to augment water data with other data sources; OSM is often missing data, and while an area without roads is no worse than the old VMAP0 data, we don’t want to lose water that was visible in version 9.  I do not know precisely how we will cope with this, but we will probably have to mix in other water data to complete the global scenery.

(We had to do the same thing in version 9: we combined the SWBD and VMAP0 water data to make complete world water, a strategy that gave acceptable but not beautiful results.)

There’s a lot of other interesting data we can use, and I do not know how far we will get with it in the first version.  For example, vector polygonal parks are notated via the leisure=park tag; this can include giant state forests, so we can’t simply make all of these areas green.  But we might be able to use them as a “hint” that the land class data should be interpreted with parks in mind.

I see our work with OSM data for the version 10 global scenery as the first step in what will be an ongoing process to include more and more data in the global scenery.  But given the huge amount of ‘interactivity’ we pick up from OSM (e.g. for the first time, anyone can change the data we use, and for the first time, anyone can get their own complete copy of the data we use) we’ll need to evolve the global scenery process.

  • I would like to make it possible for other people to render global scenery tiles; that way if you improve OSM data, you don’t have to wait 2-4 years for Laminar Research to recut the world.  With a short cycle of editing, we need a short cycle of publishing.  (This already exists for apt.dat – you can submit contributions to Robin and he publishes them in monthly data cycles.)
  • I would like to make it possible for third parties to share their use of OSM tags with us and us to share our tags with them.  Since the scenery tools have always been open source, this shouldn’t be a problem – our code to process OSM data is actually in our public source code repository now.  (I will need to post the config files that have the OSM tags at some point.)
  • The line between global scenery and custom scenery may become blurry. For example, if you download OSM data, carefully edit and tune it, recut a global scenery tile with it, and then add some custom buildings, is it global scenery or custom?  I don’t know which it is, but OSM may make new ways to make custom scenery possible by making huge amounts of vector data available to everyone.

 

 

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.

10 comments on “OSM: What Data Will the Global Scenery Use

  1. Do you have, or will you report, a final date for when you’ll cut the version 10 scenery? I’d like to know how much time I have to cram as many improvements into my home area as possible.

    1. I’ll try to give some guidance as to when we’re closing in, but I think coordinating changes with the global scenery cut may be very difficult…we can’t know when we might need to re-grab the planet dump for some reason.

  2. Frankly speaking, I think you can throw away old water data. It was a true pain in many many area, in France at least. OSM database is wayyyy much better.
    What do you think of the Terraserver fonctionnality for FlightGear. You donwload scenery up-to-date where you fly, on the fly. Multicore support should be perfect for this, no (I’m not a programmer, just a dreamer ;-)?
    Great job anyway. Looking for V10 😉
    Olivier

    1. Water data is pretty sporadic in the United States in OSM. There’s high resolution data available, but it’s difficult to import. The TIGER data only has major rivers. Most lakes are even missing.

  3. Couple of questions, will the code generating water bodies pick-up attributes of that water and render variations accordingly? For example, will attributes identifying a glacial lake or river allow that lake to render as milky aquamarine? It really would lift scenery if there were some geographic variations in water colour possible. Secondly, will the data formats currently accepted by Meshtool and the DSFs generated still work in XP10?

  4. I just can’t wait to land a heli on my street! With the new version of the online OSM editor Potlach, everyone can EASILY edit their neighborhood. X-Plane gives me one more reason to tidy up my corner of the world. Hope you find a suitable “fast publish” cyle method. Publishing your tools would probably be the simplest way.

    Wow, this has so much potential!

  5. Ben, how often will the global OSM based data be updated? As you’ve mentioned, will it be only every 2-3 yrs, or could it be quarterly/half yearly? If not, then the local updating of tiles would be a good approach. It is a large world, after all

    1. Hi Simon,

      I think this has mostly been covered in the other comments: we don’t know, we don’t have a process for updating in between major releases, and we’re not committing to updating between major releases at this time.

      OSM solves the first problem: how to accept change _at all_ and allows us to start thinking about potential improvements in distribution.

  6. Will somebody remake the “world map view” in XP10? Because, honestly, what we have presently it is the whorst airport finder i never used.

    Tx and Good luck!

Comments are closed.