In my previous post I announced that we have the ability to recut DSF tiles in an update and that we have already started doing this. I pointed out that we’re not signing up to recut the whole planet because we don’t how we will manage distribution yet.
This sets us up to talk about OpenStreetMap (OSM). First the basics:
- The X-Plane 10 global scenery gets its vector data from OSM – that would be roads and water.
- X-Plane 10 does not get its raster data from OSM – we get land class and elevation data from a composite of sources , both integrated by Alpilotx using a mix of tools I wrote and some GDAL/GRASS voodoo. (I think he may have had to sacrifice a live goat. I try to not ask questions about what goes on with the raster data!)
- OSM is the only source of water body data in X-Plane 10.
The result is a lateral move for water body data quality and an ironic one: for the first time the US isn’t the area of the world with the best data sources. OSM coverage in Western Europe is often near complete. By comparison, the US is still quite sparse.* The result is that water bodies that were present in the US in version 9 are now missing in version 10.
(To make matters a bit worse, the OSM extract for the global scenery is from July. I had to take an extract and stop updating to stabilize the scenery development process. We’ll take new extracts in the future but what you see now is months older than the current OSM data, not weeks.)
Why didn’t we use multiple water data sources? There were two problems:
- We ran out of time. It’s really tricky to integrate multiple data sources that don’t line up spatially, and while we had some promising tech, it made the DSFs worse as often as it made them better.
- Because all other sources of water were not in OSM, we had the potential for road/water conflicts, which makes the integration very tricky. In the old days when we used terrible VMAP0 data for roads, we could just nuke the road if the water didn’t match. But OSM road data is quite accurate and we didn’t want to manually edit it.
So my thinking is that what we really need to do is make OSM as good as possible and then recut tiles. Improving OSM improves the global scenery in the long term, everyone can participate, it helps everyone using OSM, and once OSM has the correct water data, getting it into a DSF is just a matter of recutting the tile. If the water data is all in OSM, then we don’t have to worry about water/road conflicts. This is the true power of using OSM: for the first time we can all focus on the source data, because the source data is public and community owned.
I did some work a few months ago to prepare NHD (the US national hydrography dataset) for OSM use. I am hoping to find a little bit of time to continue with this effort – my goal was to make it easier for people to import high quality NHD water into OSM, but there were some unsolved workflow problems when I left off to focus 110% on getting v10 out the door.
What Other OSM Data?
One question that comes up over and over is: what other OSM data will you use? The short answer is that I don’t know, but I think individual building shapes is not on the short list. The problem is that I don’t think we can adopt our autogen at the quality level we like to such arbitrary shapes.
That doesn’t mean that other third party scenery can’t use the data now, or that we won’t use it someday. But it’s not next on my list.
One type of data that I do think we could make good use of is “point of interest” data – e.g. we there is a school tagged in the OSM data, we could drop in a school autogen art asset for a given location – this kind of “shaping” of the autogen could, I think, provide another level of richness and accuracy while leveraging the existing autogen and DSF generation technology.
OSM vs. Airport
One last note on OSM and recuts: in the past we have cut out roads near airports. Our older road data was often very inaccurate and would run right over a runway. The cutting process tried to minimize the insanity.
OSM data is often very good and there are many cases where the OSM data could be left alone for perfect perimeter roads. I do not yet know how we will modify the cutting code to ‘preserve’ such road data, but I would like to get this right in future renders.
One problem that makes this difficult: often the on-airport roadways are modeled in OSM, but without any tagging. The result (when road cutting is off) is a city street down the middle of the tarmac, often where the vehicle paths should be. So we need a way to know whether a given OSM road is okay or not.
* The US road grid was first seeded by integrating TIGER road data into OSM. This gives the illusion of total mapping when in fact some areas have never been hand edited. The TIGER water was not brought in during the initial import, hence areas with roads but no water.