First, please read these posts regarding OSM water and recuts. I’ll be here when you’re done.
Okay good! So the short version of it is that there are three reasons* why water might be missing from the global scenery:
- Our OSM data importer had a bug. What can you do to help in this case? Nothing; it’s on us to fix the bug.
- The OSM base map was missing water back in July of 2011, but the water is in OSM now. What can you do to help in this case? Nothing; we just need to get this new data. (Or perhaps it is because of you that the water is in OSM, in which case thanks!)
- The OSM base map is missing water now!
In this last case, you can help; if the OSM water data is wrong, the global scenery will be wrong in the exact same way. Our goal is: if it looks blue on the OSM main map, it should be wet in X-Plane.
With that in mind, I was surprised to find out about this edit: http://www.openstreetmap.org/browse/way/80118306. That’s a change to the dry lake bed in Edwards Air Force Base by alpilotx. Surprisingly, as of 24 hours ago the tagging in OSM was still wrong, just as it was in July of 2011. I had assumed that Edwarads was ‘wet’ due to an import bug by us, but apparently it was due to incorrect tagging.
So if the base map doesn’t look blue, you know what to do: add the missing water. It’s good for OSM, it’s good for X-Plane, it’s good for pretty much any project using OSM data (and there are a lot of them!) and once OSM is fixed, the bug can be fixed in X-Plane forever because OSM is the data we use to get water/land/coastline info.
* There’s actually a forth reason: intentional removal of water that we thought was too small/detailed for the data size of the global scenery. In that cases there’s nothing to be done to put it back — the global scenery has to be able to cover the whole world without being too many tens of GB.
Hi Ben, I’m not sure whether the OSM-to-DSF water heuristics will keep a small river around my favourite airport (YSCN). It’s never been in X-Plane but is in OSM. If the heuristics remove an important VFR water landmark, is there any way for a 3rd party developer to overlay it post hoc?
Regards,
Dr Ropeless
Right now the only third party option is the nuclear one: recut the whole DSF mesh tile with new custom water polygons.
Once we get the first round of recuts done, _then_ if the water is still missing, this would be a good thing to file.
where do we report osm issues in relating to a recut? will we have the weekend to test 10.21 to submit items?
As I said in the previous posts on recuts, please do _not_ report OSM issues right now. We have a lot of bugs to work through before we will be ready to accept new bugs.
Hi Ben,
i really apreciate X-Plane 10 and your efforts to make things better.
Did i understand it right you said that the osm data is from 2011?
I just wondering why you don’t do some small updates from time to time. Would make the environment much better…
Yes, 2011. The product shipped in November of 2011, so we took the last raw import in July of 2011. We didn’t take small imports after that because we didn’t want to introduce unknown issues at the last minute. So we’re taking an update now.
Ben,
What about airports built partially on water like Macao (VMMC)?
osm map
airliners.net photo
It would be awesome if there was a taxiway-bridge object in the library.
There are quite a few airports where it would come handy.
It could even be used to bridge ravines or highways.
EHAM, KJFK, LGGW, MMUN, RJBB to name just a few.
The current state of Macao International is eye-watering, JFK could win substantially if the taxiway would pass over the highway.
I’m aware this often needs dsf mesh changes and a bridge to produce convincing results but wouldn’t now be a perfect time to lay the groundwork?
cheers
peter
Too soon – we gotta walk before we run.
+1 should be named.
EDDP 🙂
gruss
mroe
“There’s actually a forth reason: intentional removal of water that we thought was too small/detailed for the data size of the global scenery. In that cases there’s nothing to be done to put it back — the global scenery has to be able to cover the whole world without being too many tens of GB.”
Not entirely true, small missing water that users wish in their scenery but not deemed large enough to warrant the data addition can be done in scenery packages using a .pol set to water. you need to make a water texture and it wont reflect but i’ve had great success with water .pol files as long as the terrain in level.
I even think you can set surface attr to water but am yet to try and dip a sea king in a roof top swimming pool.
What would be nice is if there was a pol directive that said, “this poly should really look like water.”
I’ve been avoiding that. The reason: the rendering currently can ‘overlay’ water (e.g. via a polygon) with complete accuracy, but we have features that are already in the lab stage that we want to someday ship that would -not- work with this. So I’m trying to avoid releasing an extension to the scenery system that would conflict with future work.