v0 landclasses

[statto]

Pasdro, is it too late for me to make new shapefiles? I don't know what Florida is like, but I was quite disappointed when I flew into KMIA. There were entire islands missing in the Miami Beach area -- could I make those in QGIS? The area is just not the best, and I'd like to improve it.

I am sure that SHM would also like India to get in.

Try this, it's a bit old though: http://stattosoftware.com/flightgear/miami.zip

[Thorsten]

It sounds like the current Earthview visuals should be quite easy to combine with and merge into the lowest level mesh LOD If a moon landing is considered a serious goal for the future, then maybe an even simpler mesh for large distances from the Earth would be a good idea? This would allow WS 3.0 to seamlessly integrate with deep space operations.

I think I have said this before, but I don't see how a textured sphere makes any sort of sense as lowest LOD level from airliner cruise altitude. Forward visibility even in perfectly clear air doesn't exceed 200-300 km ever due to Rayleigh scattering, so you can never distinguish terrain color (aka texture) in the distance - the only thing you can distinguish is elevation (you see a mountain range against the sky, though it is pretty heavily fogged). So we would rather need an untextured elevation mesh for flight.

Of course for orbital visuals it'd be convenient, but doesn't really add any benefits I can see. Earthview has the performance impact of a modestly complex airport terminal - close to none and it takes a simple Nasal script of less than five lines to automatically switch it on and off if so desired. And it's not clear to me how the geometry is supposed to blend, because the renderer really doesn't like large numbers, so you can't ask it to render something 1000 km distant without running into numerical crap, you have to use projection trickery - which won't really work in a straightforward way because you want normal terrain over the textured sphere, which then leads into explicit juggling with depth ordering, i.e. we have to render different LOD stages with different effects,...

Okay, maybe I'm not seeing something here. I'd actually like to be proven wrong with that one, it'd be cool of there was a better way to do this.

[wlbragg]

Also, as I said before, if we don't do something about the smaller chunks of deciduous forest, "add them back in", then there will be miles and miles of very boring scenery that might otherwise be spectacular.
Maybe some regional shader magic along river/stream class would do the trick?

Speaking of, I revisited the USGS NLCD and found something I either overlooked or has been created since I last visited the site. That is an excellent hydro and woodland layer/s for the entire USA.

Here is an example of the data compared to the tiff NLCD that we are using to get the shapes for rounding.

This is the new Woodland data.


This is the same data overlapped with the NLCD tiff2shp that I used to gen my scenery.


As you can see this new data is exceptional (cleaner and smoothed) compared to what you get from the NLCD layers.


This is the hydro layer and after reviewing it I can say it is on par with the water layer I created for my custom scenery from multiple sources.


Overall coverage for the entire state of Kansas.


The rounding script, as is, eliminates the vast majority of this particular layer in this part of the country because of it's size or resolution being too small. In other parts of the country where woodlands are larger tracts it was smoothed and included.

[Johan G]

An interesting fact about the VMAP0 data is that it primarily is digitized from 1:1,000,000 scale aeronautical charts,* the operational navigation charts (ONCs)**. And the detail there is is probably focused on the needs for navigation (hydrographic features, larger cities, larger roads and railroads).

Also since we are mentioning land classing in this topic I am going to quote myself and owenpsmith regarding power lines:

When flying VFR in the heavily forested areas of western Canada, it is never the power lines you look for, it is the clearing through the trees made for the power lines. They stick out like a sore thumb.

Goes for Sweden as well. In the about 60% of Sweden's area covered by forest no other line features, except for rivers and highways, sticks out like a 25-50 m (80-160 ft) wide clear cut that stretches for mile after mile.

While the landscape below is in British Columbia (Canada I guess), it could just as well be in the northern half of Sweden:


Altered landscape: electricity transmission line by Jon Dev, on Flickr

Sometimes in the winter, after a day that has been just sunny and warm enough to have melted some snow off the trees (mostly spruce and pine), they would be like white bands through a dark green forest.

* Vector Map Level 0, US National Geo-intelligence Agency (NGA)
** All of which are in the public domain (if not classified) and available from sources like for example the Perry-Castañeda Library Map Collection of University of Texas

[bugman]

Thorsten, for an in built LOD-based transition from the world scenery to an earthview-like rendering, which may just be possible with the WS 3.0 LOD design, how would you design this? Of course this is not for airliners, but it might be useful for the X-15, really high altitude attempts by jet fighters, and any rocket-based aircraft. Should the LOD algorithm be based on angle rather than distance?

Regards,
Edward

[Thorsten]

I'm not sure.

There's two problems:

a) For fogging, we always assume we're in the atmosphere and Earth curvature doesn't matter. Both assumptions are wrong from orbit because line of sight through the atmosphere from outside becomes a pure function of angle with the mean terrain level which depends on curvature.

b) GLSL operates on floating point precision and we have coordinates in meters, and passing distances in numbers of a million (or a few) is bound to lead to trouble.

a) requires that we introduce a transition fogging for the farthest LOD level (Earthview computes different fog than default terrain) and match it in some region, b) requires that we somehow pull the farthest LOD level closer (I really don't see this working in real coordinates).

It's the same trickery as done with the skydome, the skydome vertex mesh is ~30 km away from you, but the renderer is instructed to show it behind everything else. I suspect similar trickery would have to be used.

So at some point we probably want to do fogging as a function of angle rather than distance. There's the chance that this may be the only large number numerical issue, in which case we don't need further trickery, but I simply don't know. I think this may be a genuinely hard problem to solve with lots of custom code for the transition region if you want a smooth blending of the visuals from one region into the other.

Actually, I've never seen it done on any software I have - Orbiter uses photo-texturing from orbit which looks bad for most places on the planet from close up. Google-Earth has a visible transition from satellite imagery to aerial imagery. Not sure how X-plane handles it - supposedly there is a Space Shuttle, but I've never seen many space visuals.

[bugman]

This seems like a natural progression towards a good end solution for the earthview, and for having seamless transitions between flight, upper atmosphere, and space, and for merging it into the world scenery. A lot of trickery will obviously be needed, though probably worth it in the end. There is a obvious region right now between the normal rendering and earthview rendering - flying in the upper atmosphere - that would benefit.

Anyway, let me add one more problem to the list: Clouds. I wonder if there is a way of rendering whole globe clouds based on current weather reports? As for the fogging and GLSL floating point problems, there must be a way to solve these. I would suggest more than one level of LOD transition for the fog as well, optimised for flying in the upper atmosphere (e.g. the X-15 at 50 km up). In the case of fog though, would it not make more sense to smoothly transition between the different solutions based solely on altitude? The terrain mesh transitioning might be better based on angle and the fog on height.

I'm under no allusion that this is a difficult problem and that it might be breaking new ground. But merging earthview and world scenery, and then using other visual tricks for fog, clouds, skydome, and the atmosphere might be a good goal to have.

Regards,
Edward

[Hooray]

Anyway, let me add one more problem to the list: Clouds. I wonder if there is a way of rendering whole globe clouds based on current weather reports?

Are you suggesting to run the equivalent of a foreach() loop to fetch METAR reports for all visibile airports to render plausible cloud textures to some kind of overlay texture ?

Even if so, note that something like this should probably not be done client-side, but by some kind of server-scheme, so that you'd only have to fetch the precomputed texture overlay, at which point you could just as well fetch actual live satellite imagery and then add that to the EarthView textures, instead of procedurally processing all METAR info and try to come up with cloud coverage heuristics ...

http://meteoradar.co.uk/clouds-sun-UK-Ireland

FWIW, FG/Nasal and the Canvas system already provide built-in support for fetching live textures, which is how the spaceshuttle/trajectory map works basically:

[Thorsten]

Clouds. I wonder if there is a way of rendering whole globe clouds based on current weather reports?

Basically yes - the technology is in place, I've tested the impostors of AW from low Earth orbit and they work in principle (in practice there's too much repetition, so we need better textures, more variation, improved placement algorithms, you name it... but the proof of concept has been done).

Of course, getting the fancy low pressure swirls from orbit is tricksy again...

In the case of fog though, would it not make more sense to smoothly transition between the different solutions based solely on altitude?

ALS (sort of) does that already - it takes into account that fog is largely confined to the lower atmosphere, so a visibility of 200 km means something different for ALS on the ground and 50 km up.

Again, the function can be refined, but in principle that's tested technology.

(You may notice that I've always been interested in high altitude flight...)

[statto]

What is going on right now?

I popped over to the FGMEMBERS forum just to find out what's going on and found this response to my post:

viewtopic. ... 85#p284047

statto wrote:
Also, I created the cs_ sources for the United States,



viewtopic. ... 94#p278598

statto wrote:
I'm interested in this as well since the Mapserver went down.



So, were you really who created those cs_sources that you are interested on since "the mapserver went down"?
You call me a liar!?!?
I find it extremely inconsistent. Just saying!

Now, if for once we (read as YOU) stop lying and trying to falsely pretend we are protecting the project, and instead make those cs sources readily available.... that' ll be protecting the GPL fair status of the project instead.
And no. Wllbragg does not have the cs classes. He has the v0 as well... which as you can see, luckily and happily we can access from multiple sources now

Unlike 2 days ago, before I re-release them in FGMEMBERS it happens you couldn't find them anywhere!!

I'm not really sure what's going on here - I created the code to generate the cs_ layer for the USA, Martin tweaked and ran the code on a server to generate the cs_ layers, the cs_ layers were available but were never part of the main project and there's no GPL requirement to continue to make that data available as a result, notwithstanding the fact data is different than source code.

I'm also stunned as v0_ data can be freely downloaded from a variety of different sources... in fact, I am using v0_ I downloaded from a third-party site as the base for the scenery I'm currently working on.

I'm planning on releasing beta Australia scenery very soon, looks like I'm going to have to release it under a more restrictive copyright, which gives me no pleasure.

[wlbragg]

@statto, I wouldn't worry about any of that garbage. So much of that statement is misleading and flat out false it isn't funny.Not worth the time to read.

and instead make those cs sources readily available.... that' ll be protecting the GPL fair status of the project instead

This makes no sense at all. No one is obligated to produce GPL material "on demand". It simply doesn't work that way. Are they trying to say if I make something and release it somewhere as GPL that I am "obligated" to keep it available until the end of time? Get real.

And no. Wllbragg does not have the cs classes. He has the v0 as well... which as you can see, luckily and happily we can access from multiple sources now
Unlike 2 days ago, before I re-release them in FGMEMBERS it happens you couldn't find them anywhere!!

This was all a total misunderstanding on their part as far as I am concerned. I just happened to copy that source from the map server to have it in case I ever want access to it. I didn't really even know what data I had and what its technical name was. I believe I gave out two semi-private links to it (solely for bandwidth considerations), one to statto (he was the first one to ask) and then one to Israel, both on request. So am I now bound to provide it for all of time? I would have happily uploaded it to any FG server on request for all to have access to. It's all just gibberish and I wouldn't give it a second thought.

And no. Wllbragg does not have the cs classes. He has the v0 as well...

I don't even think this is a correct statement. I think what I have is what would be the equivalent of the ws2.0 cs data.

The new "rounded" data that was never used for anything I believe was also called cs and that is where the confusion is coming from. That is the data that everyone is looking for. But I don't think ANYONE is "obligated" to provide it to anyone, GPL or not. GPL is not a guarantee of access.

statto, I am not sure of your concern and reasoning you feel a need to change the way you do things. ie: licensing?

[statto]

@statto, I wouldn't worry about any of that garbage. So much of that statement is misleading and flat out false it isn't funny.Not worth the time to read.

It's just ... fun. I don't remember the last time I was personally attacked online before

statto, I am not sure of your concern and reasoning you feel a need to change the way you do things. ie: licensing?

My goal is to create data for release into the main FlightGear channels, ie TerraSync - however, I'm currently of the mindset that I don't want to release any beta versions under a non-restrictive copyright, so they don't end up in non-official channels.

[PINTO]

and instead make those cs sources readily available.... that' ll be protecting the GPL fair status of the project instead

This makes no sense at all. No one is obligated to produce GPL material "on demand". It simply doesn't work that way. Are they trying to say if I make something and release it somewhere as GPL that I am "obligated" to keep it available until the end of time? Get real.

If you are distributing your scenery/work/whatever, you are obligated to have the source code available too, under GPLv2, Section 3. (didn't check GPLv3).

But, as the FG project doesn't use cs_, it isn't under any obligation to provide the source. Also, per section 3, FG is under obligation to also supply the vmap0 source itself, irregardless of if it is available freely elsewhere. To quote section 3,

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

(emphasis mine)
vmap0 data does not come in source or binary form of the major components of any operating system that I am aware of.

[wlbragg]

The source code for a work means the preferred form of the work for making modifications to it.

Not a lawyer here but the "preferred form of the work" for all our scenery to me means v0 from the "original" source, NLCD from the "original" source. All the scripts used to round and smooth the NLCD is still available. Plus, like you said, the "smoothed/rounded NLCD" is not distributed in any form what so ever at the moment, so "on demand" still seems to be in play here and I'm not so sure FG has any obligation to provide raw v0 "data", it's not code.

There is also the spirit of the GPL we're talking about here. I have no clue how one would interpret or argue that.

[statto]

(emphasis mine)
vmap0 data does not come in source or binary form of the major components of any operating system that I am aware of.

This actually raises a different issue: does vmap0 data constitute "source code"?