DSF Recuts – Some Basics

29 comments on “DSF Recuts – Some Basics”

1. Oops, typo:

   “lot on
   import.”
   … loSt … I guess?

   By the way that’s great news Ben!
   Cheers.“

   1. Fixed!

2. This is great news. Thanks for the update!

3. I assume in bullet 3 you actually mean the airport data from March 2013, not 2012?

   Good news indeed.

   Can you pass along word of how (*if at all) you’d like users to lobby for certain geographic areas to have work done? I’ve done lots of water related OSM edits (and WED airports with proper boundaries) in my flying region which (in my opinion, of course) need to get into X-Plane, and I’m sure you’d prefer not to use the blog comments as that vehicle for that.

   1. 2013, yes – typo corrected, thanks.

      Re: how to lobby…for now the answer is “please do _not_ lobby”. The reason for this is that we need to go through our big pile of bug reports for now and we have plenty to do for the very first round. There will be instructions on how to lobby effectively (and I will be biased toward recutting areas where the recut request contains all of the information we want 🙂 but I’ll post that later once we’re ready to receive the input.

      Considerations for recuts will include the amount of improvement we’ll get in the area, the data size of the recut, the importance of the area to the entire flight sim community, dependencies on the area for third party products, and the amount of recut work people put in, plus a fair amount of arbitrary selection. It may be possible to get an area considered for recut via bribery.

      1. Does this means that small towns with local airports are likely to not get updated? I’m asking this because i’m much of a VFR person and would like to fly around my region with accurate towns and such. Currently there is nothing there besides the airport, but the OSM data is pretty much 90% accurate now and i’d like to be able to use it.
         It’s Rio Grande/Brazil.

         1. No, not exactly. It means they aren’t as likely to get updated in the very first batch. But I think they are likely to get updated at some point. It’s too soon to tell how quickly we’ll get through airports, etc.

4. “Better land-class allocation … I am trying to fix as many of the algorithmic problems that we’re not happy with as I can in the short amount of time I have been allocated.”

   Since you are re-cutting individual areas are there plans to eventually include OSM building data?

   1. No. I don’t know what future data we will take — OSM is rich with all sorts of tagged stuff — so anything is possible, but generally we do not expect to use the -specific- footprint shapes of polygonal buildings to create autogen for the default scenery.

      Autogen is a trade-off of accuracy vs. visual quality vs. scope, and we think we’d have to go too far backward on the visual quality to get this minor increase in accuracy while maintaining our global scope.

      I think we could use info derived from those buildings, e.g.
      “hey, there is a big building in this block!” and
      “hey, it is a hospital” and
      “hey, it is 200m tall” and
      “hey, it’s big – it’s footprint area is 20,000 square meters.”
      All of those _derived_ parameters could be used to make the autogen process more accurate.

      But when you actually take the exact polygonal footprint, you give up the ability to have things like a really clean visual link between the road grid and the building itself, or good integration between the shape of the building and the side textures, etc.

      Fortunately, global scenery isn’t the only way to get OSM data – you can use something like Benny’s osm2xp to convert OSM building data into facades. So we (LR and friends) aren’t looking to do this, but it can certainly be done!

      1. > But when you actually take the exact polygonal footprint, you give up the ability to have things like a really clean visual link between the road grid and the building itself, or good integration between the shape of the building and the side textures, etc.

         Ben, please can you explain a bit more about this? I just discovered OS2XP, and I was wondering whether its worth the effort. If the files I generate using this software are going to be used to create some kind compromised graphical impression in the sim, as you hint, then I’d be more inclined not to bother.

         On the other hand, OS2XP seems to be very popular, so I’m sure I’m missing something here!

         Thanks

         1. I can’t go into it in a ton of detail now. But basically what I am saying is that:
            – The osm2xp facades are higher in accuracy – with osm2xp the building follows the shape the data dictates to the maximum extent.
            – The v10 autogen is much looser in placement, but higher in visual detail – you have driveways connecting houses to the sidewalks and buildings that form complete blocks with no ‘wasted’ space.

            So it’s a trade-off – there isn’t a right or wrong. The LR approach (autogen) makes sense for what we try to solve with the global scenery.

            It was an intentional design decision of the scenery system that the global scenery is NOT the only way that OSM data (or any data) can be brought into the scenery system; the scenery system is very flexible and can do lots of things that we (LR) will never do with it.

            1. Thanks for that, Ben.

               I applaud you for not just writing an interesting blog, but for engaging in dialogue with us lot. Its refreshing to get personal responses from a company distributing a mass, worldwide product.

5. you mentioned chicago’s runways having trees. ORD, MDW, smaller airports in the Chicago area, kcgx

   – wil recuts address why some cities are empty of buildings basically, such a Denver ?

   thanks

6. Interesting.
   Yet I wonder if we will (in this version cycle – V10) eventually move to a more “live” DSF update policy. I don’t mean periodic. Not even the “train every 15 minutes” example you gave.
   I mean actually “live” (maybe filtered to actually do it once per fly session, or once a day or something like that).
   I can see this done in two ways in the future:
   – Have a server that does this on demand on client update request when there is a flight plan (for those tiles) or at least a starting airport (for those tiles and around).
   – Eventually move the translation code IN the program and actually let it request OSM and convert them to DSF.

   This of course will present problems, but the… “PROPER” problems; i.e. making the translator better, not manually debugging all translation. Of course manual intervention (by Laminar) will probably still need to be there, but this should already be in the internal file tags (like “don’t touch this tile” or “this tile has priority such from Laminar”). I hope I am getting through with what I mean (sometimes language barrier is harder to overcome, esp. stupid Mondays with little sleep last night).

   Something else. I realise that terrain generation cannot include actual building data, but as you already said can and will take “advice” on what to render based on those data. This is “good enough” for the trade between realism and performance indeed. YET I strongly believe world landmarks (haven’t looked if OSM can actually classify something like that or relative to that), SHOULD be in the stock world scenery. I think I am saying this for years actually. Even with render engine all notches down and completely stock, you cannot have an NYC without ESB or Chrysler building, or Paris without Eiffel tower or Athens without Acropolis. They are actually used for visual orientation, so I consider them PART of the simulation (I wonder how you are not).

   Anyway keep up the good work.

   1. > Something else…. world landmarks

      +1 to the question. There’s got to be a better way of incorporating significant landmarks in the scenery, than relying on users to import models made by other users manually. Ben?

7. Very exciting new indeed! Of course, the only bit missing is from this roadmap is a time scale. Are we looking at May or June or July for the first recut to appear? Should I hold my breath?

8. Hi Ben,

   great news! Just my two cents on the subject: since a relevant part of the scenery updates comes from the contribution of users all around the world, and their submission is “asynchronous” with respect to Your update schedule… I wonder if it would be convenient to keep the scenery update and main application update as two separate processes. Maybe enhancing the X-Plane installer, in order to offer the possibility to look for updates to either scenery, application or both of them could be viable?

   Best regards,
   Filippo

9. *Reads the interesting new post*

   *Comes across the section: “This recut is not a global world-wide recut; I do not know when or even if this will happen.”*

   *Stares at the monitor and starts to cry*

   Seriously, no? :O No, this can not be true? Since 2006 I have probably spent hundreds after hundreds of hours mapping Sweden for better quality in X-plane. I’ve always gotten down to detail with regard to how sweet the experience would then be in this future global scenery update. Now, it will not be global? Oh my god, Ben 😀

   Pretty please, pretty pretty please do eventually a global refresh of everything. I spent days doing just northern very high res fjords, lakes and rivers. I would cry a river not to see them included in the next scenery update :O

   Not to mention hundreds of effective hours just editing, researching and trimming:
   http://osm.org/go/0NcqV8
   http://osm.org/go/0NctR2K

   Kindly, Ben, please give a global DSF recut another thought. Just the thought of having spent so much spare time at OSM and risk not having it “prioritized” in the scenery updates makes me want to just give it all up. I just loved the thought of having all the new edits updated in X-plane. This is just a total anticlimax.. At the same time I feel I should just shut myself because I know in the end you guys are smart and are pretty surely doing the right thing anyway… I just so badly was looking forward to at last see all those nice updates I’ve done all over the contry…

   1. Hi,

      First: why would we not recut Sweden? I think Sweden is a valid recut target…I am told the land of Sweden has people living there…they call them…Swedes — and I have even met one or two of these legendary creatures. (They look nothing like the muppet chef!)

      So a recut not being global isn’t really an issue for a European or Scandanavian country. It might be an issue for one of those random 50m rocks in the middle of the pacific that seems to crop up in the SRTM, or perhaps some of the middle of the Sahara (as long as we out ‘sand’ there it can stay).

      But please: no lobbying for a given area just yet. I can’t promise specific areas right now and I can’t take more bug reports than we have.

      Cheers
      ben

10. In this DSF restructuring flurry I am wondering if the difficulty with autogened roads and their overlay of sections of airport taxiways, ramps, and aircraft parking pads is being addressed. The Excludes which are available do eliminate these interferences from sight, but sadly, any aircraft taxiing over these excluded roads’ edges cause a crash and a restart of the simulator. We BADLY need a method to both eliminate them from sight AND the means for eliminating their hard surface actions which are the cause of the crashes. Am I missing some means that exists from doing this?? For an example, see the airport at KPGD…

    1. The exclusion zone should remove hard surfaces. Please file a bug – attach a MINIMAL scenery pack that can repro this (it should literally just take one exclusion zone) and the runway/taxiway to drive on.

11. Hello Ben,

    Do you know if the buggy mesh of Rio de Janeiro will be fixed? It has terrible problems since v9.

    1. I do not want to promise to much, or jump the gun … but a test with Rio showed (after changing elevation data source) that it has vastly improved (yes, I know how bad the original XP10 version looks).

12. Are differential file patches unworkable for DSFs? I’m assuming the algorithms used to convert the various geo data sources (including OSM) need a clean run at tile generation and the differences between old and new so great that diffing isn’t an option? It’d be ideal if the update engine didn’t need to replace entire DSF tiles that have changed but I can see why it needs to.

    1. I’m not sure – we’d have to try it. But my guess is that the patches will be low efficiency — final DSFs are heavily bit-packed and even small changes in source data can ripple through and bit-pattern changes in the entire file.

       Jonathan Morton used deltas on the v6 ENVs to make a patched update cheap to download, but ENVs are a much simpler format and the data changes were localized (in a format where the locality was preserved).

13. “…Due to a last-minute data screw-up by me, many airports in the original DSFs were cut with very old airport data …”
    U-huh! Guessed as much when I discovered that the boundary data that I had submitted for all Irish airports ahead of Robin’s deadline was not reflected in the v10 DSF cut. I also notice that the edge of the airfield ground texture can be somewhat soft/blended. In some of the small grass strips I’ve submitted (and no doubt others), the boundary is wrapped fairly tightly around the runway(s), within maybe 2-3 metres at times. This reflects real world cases where the runway may just be a stretch of grass inside an electric fence in the middle of an agricultural field. Will the algorithm throw a hissy fit at this? An example would be EIKH.
    (and if you have to recut the Irish tiles sooner rather than later to test this, so be it, there’s lots of updated OSM data there too 😉 )

    1. Well, the border-handling algorithm is changing….so…it probably won’t have a fit, but more notes coming soon.

14. Will a dam in OSM show up in X-Plane or is it just rivers and lakes?

    1. We don’t show dams right now.

Comments are closed.