FSXA Correcting (many) elevated lakes in the Andes

[FlyingAxx]

While flying over the Andes (Peru) I saw a lot of elevated lakes (and some in holes) destroying the overall impression of the 19m mesh terrain. My experience in scenery design is limited to work with ADE , correcting the environment of airports with polygons with or without Terrain Sculptor, and a few islands projects in midst the Pacific.

Everything is in no way produced for any commercial use, most just for my own.

Is there any way finding out the (half the way) correct lake altitudes? I tried comparing dependencies between levels being shown in TmfViewer and Google Earth, but failed dramatically. Contoured maps don't help as they usually show different crossing lines with the shore and no information regarding the lake's surface level.

When searching the forum here, I've learned, there seems to be a professional tool for $$$ helping to do such a job almost automatically. Nice idea, however, I don't want to pimp up an area for money just for myself.

Questions:

• Are those data somewhere available as public domain?
• Is there any other method you can recommend? Trial and error by using iteration seems to be not really effective.

 

[Bavarello]

While flying over the Andes (Peru) I saw a lot of elevated lakes (and some in holes) destroying the overall impression of the 19m mesh terrain.

This is normal, since the water bodies (polygons that represent the lakes) default were drawn at 90% inside FSX with a mesh of the terrain to 900 meters. So, not only the elevation of the water surface is distorted but also the position of the lake is incorrect.

To correct this fault, and then correct the elevation and location of a lake, the program better, in my opinion, is SBuilderX. Before adding new, it would be of you study a bit the use of this powerful tool by Luis Sá.

 

[FlyingAxx]

Thanks Bavarello, misplacing lakes, shorelines or airports and whatever else (in some areas almost everything) is one of the main challenges Microsoft left as a mark. Okay, I know SBuilderX and did the mentioned islands with its help. I know that it can be used eliminating most of those faults. However, my concern is that I'm not aware of a tool, allowing for instance finding out the elevations of smaller lakes. I would have been indeed really nice finding such areas with something like TmfViewer, showing how it is embedded into the installed mesh. In the absence of such a tool it's somehow a game of trial and error and I think I'm too lazy to do that for a couple of dozen waterpolies.

 

[Flattermann]

After installing FSGenesis for Andes I saw this well known problem! Not only for lakes but also for rivers and the Amazonas. It was terrible and I worked for weeks with SBuilderX. Now it looks much better. I can't understand nobody fixes this for free or for money.


Gesendet von meinem iPhone mit Tapatalk

 

[FlyingAxx]

Christian,

There are obviously only a few people in South America doing scenery design. Most efforts I know about are spent from some Argentinian guys who produced excellent freeware airports by using ADE with customised objects and in some cases SBuilder in the vicinity. The main problem for me seems to be that people producing high resolution mesh would need a second, probably even more complex step for including the right flatten data where needed.

BTW, there are other gaps like that in the world where obviously no business is expected generated by native flight simmers. I have no idea what FTX Global Vector is doing in this case as I'm avoiding this application due to their ruthlessness to other scenery add-ons. Unfortunately they are moving quite alone through some parts of this globe.

 

[Bavarello]

However, my concern is that I'm not aware of a tool, allowing for instance finding out the elevations of smaller lakes.

Axel,
You are only interested in small lakes or in general all the lakes?

However, through MICRODEM or other GIS programs you can read data source files SRTM 1 arc sec version 3 (in GeoTIFF format) the altitude of the lake. Note that this value is referred to February 2000 at the time of flight of the Shuttle.

https://lpdaac.usgs.gov/sites/default/files/public/measures/docs/NASA_SRTM_V3.pdf

From page 3 this:
http://dds.cr.usgs.gov/srtm/version2_1/SWBD/SWBD_Documentation/SWDB_Product_Specific_Guidance.pdf

3.6.2. Lake Area Feature
3.6.2.1. Lakes greater than a 600-meter minimum length and 183-meter minimum width
requirement shall be depicted. Lake inlets (arms) shall be depicted until the inlet/arm
reaches a width of 90m.
3.6.2.2. Lakes will be sized by calculating the length of the medial axis; width will be
calculated perpendicular to the medial axis.
3.6.2.3. Lakes are portrayed at a single elevation value.
4. Lake shoreline will be maintained such that it is at least one (1) meter higher
than the lake elevation; containment will include maintaining this relationship
with DTED posts diagonally adjacent to lakes. See figure 1.

 

[JRobinson]

Another option (the way I always did it when I needed the elev of maybe just a few small lakes) is to find the lake in Google Earth. Do a "measure distance" across the lake staying well away from the shorelines, save the "line measure" in your temporary places folder then right click it and choose "elevation profile". That will usually show you a basically flat profile and the mean elevation from that has always worked well for me and whatever mesh I was using.

Jim

 

[FlyingAxx]

@Giovanni: An absolute new area for me. I'll see what I can do in order to transfer this information into practical action. Your example picture looks really promising.

@Jim: This seems to be at least a sufficient matching method for those lakes, being drawn by Microsoft. I don't think that they took care for really small ones. I wasn't aware of this possibility. If you're sliding along with the mouse pointer it's a rough ride in most cases. Thanks for the hint.

Now it just has to be the right weather (simming and the work on sceneries is rather winter-sports for me).

However, as there are many lakes in this area I'll first will try to fix those along the one or other planned route. For instance, the Andes region east of Lima (SPIM) is full of lakes and as far as I saw a lot of them flawed in the one or other way. Some are standing like columns side by side. On the other side it's a beautiful and challenging area....

 

[FlyingAxx]

View attachment 24577

Axel,
You are only interested in small lakes or in general all the lakes?

However, through MICRODEM or other GIS programs you can read data source files SRTM 1 arc sec version 3 (in GeoTIFF format) the altitude of the lake. Note that this value is referred to February 2000 at the time of flight of the Shuttle.

https://lpdaac.usgs.gov/sites/default/files/public/measures/docs/NASA_SRTM_V3.pdf

From page 3 this:
http://dds.cr.usgs.gov/srtm/version2_1/SWBD/SWBD_Documentation/SWDB_Product_Specific_Guidance.pdf

3.6.2. Lake Area Feature
3.6.2.1. Lakes greater than a 600-meter minimum length and 183-meter minimum width
requirement shall be depicted. Lake inlets (arms) shall be depicted until the inlet/arm
reaches a width of 90m.
3.6.2.2. Lakes will be sized by calculating the length of the medial axis; width will be
calculated perpendicular to the medial axis.
3.6.2.3. Lakes are portrayed at a single elevation value.
4. Lake shoreline will be maintained such that it is at least one (1) meter higher
than the lake elevation; containment will include maintaining this relationship
with DTED posts diagonally adjacent to lakes. See figure 1.

Giovanni, it seems I trapped myself as I started to download and install the needed files. However, after having a first look into the documentation I got the feeling that I need to see you for a couple of weeks in Italy in order to understand what I should do!

Okay, don't be afraid, but this seems to be a really complex application requiring a lot of reading and a long lasting trial and error period. I think, I'll first give Jim's proposal a go.

Hmm, to answer your question: in cases MS realised even small lakes, this might have to happen, too.

 

[JRobinson]

If you're sliding along with the mouse pointer it's a rough ride in most cases. Thanks for the hint.

I noticed that too for the Andes, they must have poor elevation data for the area because if you do a lake in the states it's usually flat as a pancake. In the upper left corner of the elevation profile is a readout of lowest/average/highest point along the line, maybe that would be useful?


Also there are some .shp files available here that you can append in SBuilderX, the hydro polys have the elevations already:

https://dds.cr.usgs.gov/srtm/version2_1/SWBD/

...but I tried one earlier near Machu Picchu and the shorelines were hideous, most small water bodies were missing, etc. It might look better than lakes on plateaus but I'm skeptical, I didn't even compile a .bgl, lol. I tried some of those .shps earlier around the solomon islands and the shorelines were considerably better, maybe just larger bodies so it didn't show so much. "Smooth" in SBuilderX can sometimes help (and sometimes make it worse).

 

[ollyau]

How exactly are elevations assigned to vector data? According to the SDK, "Whereas most vector types only require 2D co-ordinates, ensure that vector data for AirportBounds and WaterPolys is 3D (that is, includes elevation data)." What does that mean in terms of the data in the shapefile (is the elevation stored as a custom attribute? does it mean the shape type is PolygonZ instead of Polygon?)? And how do SlopeX and SlopeY fit into things? I figure it shouldn't be that hard to retrieve elevations programmatically (especially if you sample the same DEM that's resampled to become scenery), but what to do with that data confuses me.

 

[FlyingAxx]

I noticed that too for the Andes, they must have poor elevation data for the area because if you do a lake in the states it's usually flat as a pancake. In the upper left corner of the elevation profile is a readout of lowest/average/highest point along the line, maybe that would be useful?


Also there are some .shp files available here that you can append in SBuilderX, the hydro polys have the elevations already:

https://dds.cr.usgs.gov/srtm/version2_1/SWBD/

...but I tried one earlier near Machu Picchu and the shorelines were hideous, most small water bodies were missing, etc. It might look better than lakes on plateaus but I'm skeptical, I didn't even compile a .bgl, lol. I tried some of those .shps earlier around the solomon islands and the shorelines were considerably better, maybe just larger bodies so it didn't show so much. "Smooth" in SBuilderX can sometimes help (and sometimes make it worse).

Jim, thanks for this hint, too. At the moment I'm quite puzzled nonetheless, as I read some stuff behind Giovanni's links above. Following this trail, I ended up with data sets that might fit, but up to now I'm unable to read them.

I'll fire up SBX tomorrow, sorry, today and hope that I'm able (first) identifying the correct .shp files and (second) finding the way how to make use of them. However, compared to MicroDEM it seems to be a piece of a cake...

Well, I need my beauty sleep now.

 

[FlyingAxx]

How exactly are elevations assigned to vector data? According to the SDK, "Whereas most vector types only require 2D co-ordinates, ensure that vector data for AirportBounds and WaterPolys is 3D (that is, includes elevation data)." What does that mean in terms of the data in the shapefile (is the elevation stored as a custom attribute? does it mean the shape type is PolygonZ instead of Polygon?)? And how do SlopeX and SlopeY fit into things? I figure it shouldn't be that hard to retrieve elevations programmatically (especially if you sample the same DEM that's resampled to become scenery), but what to do with that data confuses me.

Good questions, even more as FSG had used NEXT LOD 11 data (19m). probably similar source are not public domain and I'm not sure what is going to happen when mixing e.g. 30m based vector data and elevation data with mesh like this. At the moment I feel like a duck in a thunderstorm - quite overwhelmed.

 

[JRobinson]

How exactly are elevations assigned to vector data? According to the SDK, "Whereas most vector types only require 2D co-ordinates, ensure that vector data for AirportBounds and WaterPolys is 3D (that is, includes elevation data)." What does that mean in terms of the data in the shapefile (is the elevation stored as a custom attribute? does it mean the shape type is PolygonZ instead of Polygon?)? And how do SlopeX and SlopeY fit into things? I figure it shouldn't be that hard to retrieve elevations programmatically (especially if you sample the same DEM that's resampled to become scenery), but what to do with that data confuses me.

Each point must have an elevation embedded in the .shp? If I import one of these hydro .shps I get this option to get the elevations from the shape file or apparently the only attribute:

...and then after I've imported the .shp I can hover the cursor in polygon mode over each point and read an elevation. I haven't looked at any sloped polys I guess, all the points I've checked are the same for the entire poly.

These fire perimeters I've been doing are apparently 2D shapes, these are the options I get when I import one of those, of course none of them have anything to do with elevations, maybe you could set them all to 2015m if you selected YEAR, lol:

I don't know the difference between Polygon and PolygonZ, how do I tell?

 

[ollyau]

Good questions, even more as FSG had used NEXT LOD 11 data (19m). probably similar source are not public domain and I'm not sure what is going to happen when mixing e.g. 30m based vector data and elevation data with mesh like this. At the moment I feel like a duck in a thunderstorm - quite overwhelmed.

Yeah, that might not necessarily go so well -- in that situation you'll probably end up with plateaus unless things happen to coincide nicely. What I'm considering is a situation where a developer has some DEM dataset to make both elevation scenery and corrected vector data at the same time.

Each point must have an elevation embedded in the .shp? [...] I don't know the difference between Polygon and PolygonZ, how do I tell?

That's what I figure -- I was looking at the Wikipedia page for the file format (https://en.wikipedia.org/wiki/Shapefile) and ESRI's shapefile specification (http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf) and they seem to refer to additional shape types that include elevation data (e.g. PolygonZ as opposed to Polygon). I tried using ogrinfo -ro -al -geom=SUMMARY <path to shp> to get some information on the SDK's HPX7824.shp example, but I wasn't sure what to make of the information.

Presumably the elevation of the point just goes into the Z Array member of the PolygonZ structure which seems logical and straightforward. That still leaves the question of what the FSX SDK SlopeX and SlopeY are supposed to be set to, though. The SDK says "Slope in vertical meters per degree of longitude. 13 char floating point number." for SlopeX and the same but with latitude for SlopeY, but that doesn't make a whole lot of sense to me. Does SlopeX have some latitude dependence because 1 degree of longitude at the equator will be longer than 1 degree of longitude near the poles?

Edit: These posts by Doug Matthews seem relevant:

We compute those slopes within our water sloping code. We have broken the water polygons up into sloped triangles and dissolved adjacent triangles with very similar slopes into the shapes you can see examining the default CVX BGL files in TmfViewer. We determine the unit normal of those result polygons and convert to be meters per degree.

The first part (breaking the source polygon up) may be difficult to do with off-the-shelf application.

I recommend trying two things:

1) If you have achieved 3D polygonal water already, try just setting slope x and y to 0. See how it looks. These values are used for extrapolating flattening to nearest mesh points. At reasonable terrain setting it may turn out to be acceptable.

2) If you have NOT achieved 3D polygonal water already, try using the texture Dick pointed out in this thread to drape your water on the terrain. See how it looks.

-Doug

(http://www.fsdeveloper.com/forum/th...x-and-slopey-for-hydro-polys-in-arcgis.12913/)

The slopes are a pre-computed normal vector for a planar 3D polygon. I took a look at the source code for our water sloper and it appears that the coordinate system is plain old WGS84 - positive X is east, positive Y is north. Positive Z is up.

Many of the river polygons in our source data are very large (geographically) and very complex (lots of islands). The prospect of having that large polygon be planar would yield a very unsatisfying result. So we break the river polygon up into sub-polygons, each of which is (essentially) planar. These sub-polygon vertices are 3D and are intended to blend with the elevation data such that the collection of sub-polygons, explicitly placed in 3D space, model a believable river surface.

This is not an easy problem. This is the first version of FS where we have attempted water in this fashion. To have attempted sloping water via the FS9 process would have been a disaster, due to the drastic increase in the quantity of polygonal rivers AND the complexity and size of those rivers. The current results, shipped with FSX, is admittedly rough in some areas, but taken as a whole is much preferable to the FS9 method. Our current algorithm for creating sloped water needs some work (the compiler - Shp2Vec - is fine), which unfortunately was not able to be accomplished in time for shipping. It is currently being looked at.

Your shoreline approach of "water to the right" sounds just fine. This holds for all types of polygonal water.

-Doug

(http://www.fsdeveloper.com/forum/threads/slope-parameter-in-water-polys.3383/)

Finding the unit normal to a polygon shouldn't be too hard, but where do the polygons come from? I don't expect any given PolygonZ shape to necessarily be planar, and I'm not sure how you subdivide it into polygons. And how is the unit normal vector converted to the SlopeX and SlopeY values? Why would we even want a unit normal (that would only have direction information) when the SDK seems to want a magnitude of slope?

Edit 2: Oh, I think I get it now. Basically SlopeX and SlopeY are the directional derivatives of the terrain in the direction of X and Y?

 

[GHD]

SlopeX and SlopeY must be present but they are ignored by Shp2Vec.

 

[Bavarello]

Only a parenthesis.

now entering the field engineers, the discussion became hot and started to struggle to follow . Despite everything I am more and more fascinated by what he is capable the community FsDeveloper.

Now excuse me if I simplify a lot. Files SRTM Water Body Data in ESRI (shp, dbf and shx) give mainly just a geometric shape and a very rough (low resolution) with no indication of the natural or artificial lakes very small.
For myself, I gather from Google Earth you have to extract all the information you need.

For some time I am working on this project about the natural and artificial lakes large and small for Morocco.

 

[FlyingAxx]

Hmm, I see, I should have started with this kind of specific development about 20 years ago. I'm not sure whether my remaining life time will be sufficient for eating all that stuff.

However, you guys gave me a lot for trying, but I think I got a feeling about the direction to go. You guys are wonderful and Giovanni is absolutely right with his statement following the "headbanger". I think I'll start with a few lakes close to Jauja (SPJJ) just in order to see how to make use of the above mentioned methods, specifically the shapefiles.

 

[rhumbaflappy]

Hi Axel.

Is there any way finding out the (half the way) correct lake altitudes?

Why not try Google Earth? The altitude is read as you hover over the terrain.

Dick

 

[GHD]

Is there any way finding out the (half the way) correct lake altitudes?

There is not much point in finding the true altitudes, they must be consistent with your mesh.

It is worth finding the true position and shape.