• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v5 Water Detection idea (work-around)

From a "layman's" point of view, Why are we trying to match the resolution of the image to the DEM? Couldn't scenProc compare the water polys it has created against the DEM (in my mind I see this like an overlay), and the slope is determined from that comparison? Yhen the filter is applied.

My concern from your answer above is memory and processing time. I have 64GB memory on my PC. And would the resulting DEM be the same size as my images which is approximately 1GB per image? If the image and DEM have to match, would/could it be better to run a separate script to first match the two up and save output in some form? Again, throwing out ideas.
 
If we use it as a mask the resolution doesn't have to be matched, that's only if we want to feed the slope data into the texture filter as well.

What you propose is also possible, but that is sampling each created water feature on the slope raster afterwards and then filtering them out. If you use the mask in the feature detection step less polygons are created to start with.
 
Once in back from my short vacation I'll add a step for the elevation data processing. Once that is there you can use it for a mask or for post processing the water features. You can see what works best.

I'm not going to modify the texture filter itself to use multiple rasters, as I think that makes things to complex and also doesn't add that much.

But we'll see where the testing goes...
 
Looking forward to give 'er a try. When ready maybe place a few step-by-steps on how to use it, or a sample step posted that I can follow/adapt for my script.
 
Hi,

I have made a start on implementing this, but I have hit an obstacle now that the GDAL DEM processing works asynchronously and that the output is not available on time. As I will be travelling for work the next couple of days, I think it will have to wait a bit longer before this goes into the development release.
 
Hi,

I got it to work now. I still need to update the manual, but I hope to get a release out in one or two days.
 
I have pushed the new development release now. I'll try to post some examples later today on how to use it.
 
Great to hear. I will be traveling for the next two weeks so I will not be able to test it until I get back :( Don't want you to think I have nudged you so much only to push the topic to the side.
 
You shouldn't have said that before I posted the examples, now I might get distracted again and I know it's not needed right away :p
 
Hi,

Here are two samples that show how to use the new step.

The first adds a slope attribute to each water feature and allows you to filter on it:

Code: 
# Import elevation and imagery raster
ImportOGR|elev.tif|*|*|NOREPROJ|String;type|elev
ImportOGR|imagery.tif|*|*|NOREPROJ|String;type|imagery
#
# Calculate slope raster from elevation
ProcessElevationRaster|type="elev"|SLOPE|String;type|slope
#
# Use feature detection to detect water polygons
DetectFeatures|type="imagery"|water_detect.tfc|String;type|water|NONE
#
# Add average slope over the water polygon as attribute to each water polygon
# You could also use CENTER to sample the slope at the center of the polygon
AddAttributeSampleRaster|type="water"|type="slope"|AVERAGE|slope
#
# Unload all features where the slope is above a certain threshold
UnloadFeatures|slope_0>5

The second approach calculates a mask of the area with low slope and passes that to the detect step, so that only water polygons in those areas are returned:

Code: 
# Import elevation and imagery raster
ImportOGR|elev.tif|*|*|NOREPROJ|String;type|elev
ImportOGR|imagery.tif|*|*|NOREPROJ|String;type|imagery
#
# Calculate slope raster from elevation. Since we will use it in a texture
# filter we want to get it as a byte raster
ProcessElevationRaster|type="elev"|SLOPE|String;type|slope|1;0
#
# Generate polygons for areas with low slope. The texture filter just needs
# a threshold step to select the area with a slope below the desired threshold.
DetectFeatures|type="slope"|slope_threshold.tfc|String;type|mask|NONE
#
# Detect the water polygons using the mask
DetectFeatures|type="imagery"|water_detect.tfc|String;type|water|type="mask"
 
Oh, this is good stuff!
At first look I believe I see where one alters the filter in degrees in the first method above:

UnloadFeatures|slope_0>5

So the 0>5 means it will filter out areas greater than 5%?

Not sure where the filter amount is inserted in the second method? Or maybe I am not understanding correctly? Dang, want to try this out but I am packing as we speak (or should I say type), ha!
 
Hi,

Yes, in the first example the filter is a slope of 5 degrees indeed (it's not in percentage).

In the second example the filter is in the tfc file used to make the mask. So that tfc file will have the limit in the threshold step of the filter.
 
I am back (at least a few days before my next trip), so I was able to try the new slope step. Had a fatal crash (I sent in the error report).

So here is my script:

ImportGDAL|B:\CA\Section_74\Images\CA_BS32_DEM.tif|*|NOREPROJ|String;CENTER|elev
ImportOGR|B:\CA\Section_74\Images\CA_BS32.tif|*|*|NOREPROJ|String;type|imagery
###ImportGDAL|B:\CA\Section_74\Images\CA_BS32.tif|*|AUTODETECT

#
# Calculate slope raster from elevation
ProcessElevationRaster|type="elev"|SLOPE|String;type|slope
SplitGrid|LOD13|*
#
# Use feature detection to detect water polygons
DetectFeatures|FTYPE="RASTER"|B:\CA\Section_74\_Control Data\CA_Section_74_TFE_Water.tf2|String;WatType|water|NONE|DONTPROCESSHOLES
#
# Add average slope over the water polygon as attribute to each water polygon
# You could also use CENTER to sample the slope at the center of the polygon
AddAttributeSampleRaster|type="water"|type="slope"|AVERAGE|slope
#
# Unload all features where the slope is above a certain threshold
UnloadFeatures|slope_0>3

MergeGrid

ExportOGR|WatType="water" AND FAREA>100|ESRI Shapefile|B:\CA\Section_74\Masks Water Tests\CA_BS32_WM.shp|water

This script created two errors:
1. Failed to open B:\CA\Section_74\Images\CA_BS32.tif
2.
7:17 AM SceneryProcessor Error System.IO.InvalidDataException: Unexpected image type Emgu.CV.Image`2[Emgu.CV.Structure.Gray,System.Int16]
at ASToFra.scenProc.Steps.DetectFeatures.Process(List`1 cells, String[] arguments)
at ASToFra.scenProc.Processor.SceneryProcessor.Process()
at ASToFra.scenProc.Processor.SceneryProcessor.ProcessConfig(String filename, List`1 commands)

I then changed the import TIF step to how I normally do. The line that starts with the three ###'s. It reduced the errors by one. My way seemed to import the TIF image correctly this time:
1.
7:20 AM SceneryProcessor Error System.IO.InvalidDataException: Unexpected image type Emgu.CV.Image`2[Emgu.CV.Structure.Gray,System.Int16]
at ASToFra.scenProc.Steps.DetectFeatures.Process(List`1 cells, String[] arguments)
at ASToFra.scenProc.Processor.SceneryProcessor.Process()
at ASToFra.scenProc.Processor.SceneryProcessor.ProcessConfig(String filename, List`1 commands)
 
Hi,

The problem is that you use a filter that selects all rasters in the detect features step. That means you also select the elevation data, which is not of data type byte. You need to select only the imagery.
 
Ah, I see... yea because before I was only importing the raster image and not the DEM. Will make the changes.
 
I should make it give a warning instead of crashing as well.
 
I have tried both methods. I am getting results on the first method but want to test more before showing my results. So let's start with the second method that I cannot seem to get it to work. I start out by trying to use your script exactly as close as I can but using my filenames, paths, etc. Here is my script:

# Import elevation and imagery raster
ImportOGR|B:\CA\Section_74\Images\CA_BS32_DEM.tif|*|*|NOREPROJ|String;type|elev
ImportOGR|B:\CA\Section_74\Images\CA_BS32.tif|*|*|NOREPROJ|String;type|image

# Calculate slope raster from elevation. Since we will use it in a texture
# filter we want to get it as a byte raster
ProcessElevationRaster|Type="elev"|SLOPE|String;type|slope|1;0

# Generate polygons for areas with low slope. The texture filter just needs
# a threshold step to select the area with a slope below the desired threshold.
DetectFeatures|type="slope"|B:\CA\Section_74\_Control Data\CA_Section_74_TFE_Water.tf2|String;type|mask|NONE

ExportOGR|Type="water"|ESRI Shapefile|B:\CA\Section_74\Masks Water Tests\CA_BS32_WM.shp|water


The script shows two errors on failing to open the tif files. Shouldn't those steps be ImportGDAL and not ImportOGR? So I switched to ImportGDAL and reduced the number of arguments by one, else another error, like so:

ImportGDAL|B:\CA\Section_74\Images\CA_BS32_DEM.tif|*|NOREPROJ|String;type|elev
ImportGDAL|B:\CA\Section_74\Images\CA_BS32.tif|*|NOREPROJ|String;type|image

This shows no errors however I get no output. What I also noticed is there is no line item message for ProcessElevationRaster. Not sure what you call the bottom portion of scenProc where it shows the Time/Sender/Message. The process takes less than a second which in not correct. The typical time to process is seven minutes. Should I also include the steps SplitGrid and Mergerid? I have tried it both ways but no change either way.
 
Hi,

It should be ImportGDAL indeed for raster data.

I think you have a bug in your filter. You select Type="elev", while you have assigned an attribute named type (not Type).

I probably forgot to add some status messages in the event log from the ProcessElevationRaster step, let me check that.
 
You must log in or register to reply here.
Back
Top