P3D v5 create accurate water polys using scenProc?

[Clutch Cargo]

I have started research on methods for the creation of water bodies that match up precisely to aerial imagery, much like how your TFE uses IR detection for vegetation. Quite interesting, founld one article and code where they use GDAL to accomplish this. Have you ever entertained the idea of something like this in scenProc? In the past I use to hand-annotate which was the most accurate but way too time consuming so I started testing with data that is available out there. Good but never matches up precisely with imagery... as I would expect since both the imagery and data will always be collected at different dates/seasons, etc.

There's current post I see here titled "Can't make water anymore" in the scenPro forum. I need to read up on that.... am I missing something, scenProc can already create water?

marcus

 

[arno]

Hi,

Can you share that article maybe?

After your posts a few weeks ago I have started playing with other indices than NDVI, there are indices for water and such as well. So those might help for this.

 

[Clutch Cargo]

ooooh, that could be fun. Let me know when you need a guinea pig.

Here is the link to the article.

https://towardsdatascience.com/wate...g-the-waterdetect-python-package-7c5a031e3d16

The link for the code is there to. It is on GitHub: https://github.com/cordmaur/WaterDetect

 

[arno]

Once I have the steps relatively stable I'll put them in the development release.

 

[Clutch Cargo]

So you believe it is doable in scenProc?! That would be quite a game changer in water development.

 

[MyPC8MyBrain]

i have attempted long time ago on a global level, it is possible from a technical standpoint,
the issues i was encountering were noise and incomplete data causing too many errors that were impossible to fix by hand,

 

[Clutch Cargo]

So Chris, how did you end up creating water polys? As I said, I was hand-annotating but now I am trying different data sources like the USGS, OSM... trying to massage them a bit but getting mixed results. I can only imagin data might have been worse in other parts of the world if non existent.

 

[MyPC8MyBrain]

there is an on going project effort to isolate water/land bodies globally,
they have base data you can use instead of sifting through OSM data,
see --> https://osmdata.openstreetmap.de/

these sets are extracted from latest OSM, they update their data sets regularly,
high res data is indeed still lacking in some regions like Australia, Asia, Russia, and some Nordic areas,
these sets are far from perfect, some polygon errors could render unexpected/unintended results with complex shoreline or water bodies,

came across this interesting GIT project as i was searching for the link above,

GitHub - global-hydrodynamics/OSM_WaterLayer: The scripts to generate OSM Water Layer

The scripts to generate OSM Water Layer . Contribute to global-hydrodynamics/OSM_WaterLayer development by creating an account on GitHub.

github.com

 

[arno]

For the US the NHD dataset is the best I have been able to find. It is quite accurate, so that's why I did never try to detect water myself.

 

[MyPC8MyBrain]

I believe the NHD dataset is for inland water bodies,
I don't think it covers coastlines in detail,

 

[arno]

No, correct. But the coastline data in OSM is quite good. For the US OSM is mainly lacking in inland data.

 

[MyPC8MyBrain]

i think it comes down to the desired resolution and definition of water bodies for the project,
i have seen very high res datasets with every creek and seasonal river in the continental US,
that could be bit too much data to render in sim,

 

[Clutch Cargo]

Just ran a test with NHD/USGA. I would say it's OK but not great. For our needs we are sometimes close to water so alignment is important. I had one area where a river was pretty darn good and then no data at all for this river! I'm not talking about a stream, but a very noticeable river which would be quite jarring to the pilot. I even bought Orbx's Oregon State to see what they were doing. Was not overwhelmed. I remember flying over an entire large town that was under water, ha!

Was hoping your link, Chris, would help. Looks really good for the coastlines, which we will also need but sadly, no inland water bodies. Arno, hope you are onto something with your testing (fingers crossed). Think my fingers will fall off if I have to go back to hand annotation.

 

[MyPC8MyBrain]

in that case you are looking for a very high res water bodies dataset,
you can expect sim to not be happy rendering high res polygons as such,
you will likely end up simplifying your polygons,

 

[arno]

If the water polygons are put in the water mask of the photoreal I don't think complex polygons matter anything for performance.

 

[MyPC8MyBrain]

it really depends on the area topology, if the area has one or two high res water bodies, no big deal indeed,
if the area is full of high res water bodies you can expect sim to choke when preloading the area,
high res polygons are more susceptive with holes and transparency effect,
while polylines not so much,

banking over a dense high res polygons area will likely induce some stutters,
it all depends on the rendered resolution of the data,

disclosure: my experience shared above is while working with DX10 not 11 or 12,
its also been a while, maybe things have improved by now in that department,

 

[MyPC8MyBrain]

a hybrid approach to simplify step could potentially provide a solution for high res polygons,
if we had the ability to simplify a polygon by specifying a variable spacing/tolerances vs. existing rigid/linear simplify,
a smart algorithm that will mimic a manual editing where in complex shaped areas will allow tighter spacing,
while in "relaxed" or less complex sections a loosen spacing policy,
maybe a complexity index that can be used to filter/preserve certain intricate sections,
thoughts?

 

[arno]

Well isn't that what the simplify features step does?

But I'm still confused if you are talking about terrain vector water or photoreal watermasks.

 

[MyPC8MyBrain]

i was referring to photoreal watermask,
the default simplify algorithm needs some work to get the type of results we are looking for,
it is too linear by default,

 

[Clutch Cargo]

Just wanted to get back with you Arno on this topic. If you want some accurate high resolution data (.60 meters per pixel), just let me know if this helps rather than having you gather a test scenario package.