Posts by lenidcamper

  • OSM feature detection in SceneProc

    There is a fix for the "tree_row" issue

    In the scenProc\gdal-data\osmconf.ini

    In the [lines] section replace

    attributes=name,highway,waterway,aerialway,barrier,man_made,power,tunnel,bridge,railway

    with

    attributes=name,highway,waterway,aerialway,barrier,man_made,power,tunnel,bridge,railway,natural

    Arno said he will update the config for the next release

    cheers

    /Stu

  • Variation of vegetation with altitude

    Most of my flying in AFS2 is soaring with the ASG29 in mountainous areas, therefore I often find myself flying close to the trees on the mountainside.

    scenProc is a fabulous tool for cultivating large ares (thanks Arno), however I do find it annoying that if you want mixed forest on the valley floor you end up with broadleafed trees at 2000m next to a scree slope.

    If only there was a way to get altitude data into scenProc.

    That's when I discovered a great little utility called srtm2osm which will generate contour lines from srtm data in the OSM format.

    srtm2osm can generate very large amounts of data (ie a portion of the Alps can produce a 1.5 Gb OSM file).

    Files that large are unwieldy to edit and contain too many nodes for scenProc to process.

    My approach is to provide a bounding box to srtm2osm that matches the scenery tile I am cultivating.

    The first image shows the raw contours generated by srtm2osm.

    It is obvious there are data glitches in the srtm data that must be cleaned up.

    I wrote a Powershell script that runs srtm2osm for the bounding box and does a first pass at removing extraneous contours such as contours above 2000m which are irrelevant for distinguishing tree species, and small contours that represent data glitches rather than a real elevation gradient.

    The script also adds a bounding box way and some additional tags to aid in OSM editing and scenProc configuration.


    After running the script there is some manual cleanup with an OSM editor (I use JOSM)

    Small jagged contours are an indicator of bogus contours around bad data.

    If you select and delete one of these and there is another contour right underneath that is indicative of bogus data and they can all be deleted.

    If there are no underlying contours it is your choice at that point if you want to undelete the last contour.

    Small contours will not add much to the end result and can be deleted.

    With bogus contours removed the next step is to close the contour polygons. Find all ways (ctrl F) with the lowest elevation (ie ele="500" or height="MidFoothills" in my example script.)

    Draw a new way joining the lowest contour segments head to tail to enclose the upper level contours. The contours obey the right hand rule.

    It helps to have the satellite imagry loaded behind the contours to sort out complicated terain. JOSM will shade the inside border of polygons when they are closed

    Use shift + select to multi-select way segements and join via Tools>Combine Ways if they do not automatically merge.

    Then repeat for the the higher altitude contours. If your cultivation area spans a valley you will have 2 groups of nested contours.


    Once you have cleaned and closed contour polygons the next step is to get scenProc to make use of this data.

    Add an ImportOGR command to load the vegetation zones OSM file

    In your spc after you have placed points in landuse="forest" polygons add the following

    ##-----------------------------------------------------------------------

    ##

    ## Create AF2 plants

    ##

    ## stunted conifers in Sub Alpine Zone

    AddAttributeIfInside|FTYPE="POINT" And landuse="forest"|height="SubAlpine"|String;SubAlpineZone|yes

    CreateAF2Plant|SubAlpineZone="yes"|1;2|0|conifer

    UnloadFeatures|SubAlpineZone="yes"

    ## Upper Montane Zone 100% conifer

    AddAttributeIfInside|FTYPE="POINT" And landuse="forest"|height="MidMontane"|String;UpperMontaneZone|yes

    CreateAF2Plant|UpperMontaneZone="yes"|3;6|0|conifer

    UnloadFeatures|UpperMontaneZone="yes"

    ## Lower Montane Zone 80% conifer

    AddAttributeIfInside|FTYPE="POINT" And landuse="forest"|height="LowerMontane"|String;LowerMontaneZone|yes

    CreateAF2Plant|LowerMontaneZone="yes" And FRAND <= 0.8|5;10|0|conifer

    CreateAF2Plant|LowerMontaneZone="yes" And FRAND > 0.8|4;8|0|broadleaf

    UnloadFeatures|LowerMontaneZone="yes"

    ## Upper Foothills Zone50/50 conifer broadleaf

    AddAttributeIfInside|FTYPE="POINT" And landuse="forest"|height="MidFoothill"|String;UpperFoothillsZone|yes

    CreateAF2Plant|UpperFoothillsZone="yes" And FRAND > 0.5|5;10|0|conifer

    CreateAF2Plant|UpperFoothillsZone="yes" And FRAND <= 0.5|4;8|0|broadleaf

    UnloadFeatures|UpperFoothillsZone="yes"

    ## The remaining trees are Lower Foothills Zone 80% broadleaf

    CreateAF2Plant|landuse="forest" And FRAND < 0.2|5;10|0|conifer

    CreateAF2Plant|landuse="forest" And FRAND >= 0.2|4;12|0|broadleaf

    ##-------------------------------------------------------------------------

    With this mechanism you can vary tree species and tree height to more accurately reflect the natural vegetation at altitude.

    I picked the altitude and zone definitions to roughly match the south face of the central Alps from the wiki, your mountains may differ.

    It does take some effort to process the elevation data but I think it adds a lot to the realism.

    cheers

    /Stu


    srtm2osm_and_cleanup.ps1.txt

  • Swiss cultivation free from ORBX

    Quote from TomB

    Or by having the orthophotos and run the detection process from ScenProc.

    scenProc autodetection works well for sparse alpine forests where OSM data is incomplete or roughly defined over-inclusive polygons but has major problems in areas where you have a mix of trees and cultivated farmland. No matter what histogram you choose there are some portions of the cauliflower or leek field that match the histogram and you end up with spurious trees in crop areas.

    As far as variation of tree species with altitude I did experiment with defining rough elevation "contours" and varying the conifer/broadleaf percentages accordingly. i.e. points inside the "high-alpine" polygon are generated with 100% conifer, then tagged and unloaded. Points within the "alpine" polygon were generated with 50/50 conifer/broadleaf etc.

    This worked well at preventing broadleaf trees showing up right next to a scree slope, however this was rather tedious to define the elevation polygons. I did not find any elevation dataset amenable to automating the task.

    For urban/farmland areas I think the best approach is to collaborate by improving individual tree and tree row definitions in the OSM data. Improving the OSM data is to the benefit of everyone (even outside the flight sim community).

    /Stu

  • Thermalling in the new version

    Set up your final glide path for landing and you are guaranteed to find a thermal!

    Seriously, if you set thermal activity to max and moderate to strong wind conditions to allow ridge soaring you will eventually encounter a thermal.

    They are relatively tight so it does take some effort to core.

    I have not had much success with flat land thermal flights. They are just too sparse for consistent flights.

    They are not associated with cumulus (we need to wait for the weather upgrade for that). Nor are the thermals associated with ground features. Although I did encounter a thermal low on the ridge right over some sewage treatment ponds, which brought to mind soaring at Dansville NY where the treatment ponds at one end of the ridge were a consistent source of a weak thermal on cool days. We just need the Smell-o-Matic plugin for added realism. :)

    cheers

    Stu

  • towerProcTL

    Hi Ken

    I agree that there is the generic class and the iconic class of objects

    I was sort of thinking ahead to power pylons.

    They certainly add to the realism of ORBX Netherlands TrueEarth.

    They fall into the generic class and would be tedious to position and orient by hand. There is already a lot of power transmission info in OSM that could be leveraged with the appropriate scenProc extensions and object library. There is voltage and strand info that could be used to determine correct tower type.

    I don't know if there are other generic object types that are worthwhile cultivating rather than placing.

    cheers

    Stu

    PS have not had a chance to try TowerProc yet, but it looks interesting.

  • towerProcTL

    Quote from Jetjockey10

    As good as this is, I immediately wish for a more varied choices of water towers. If Santa is making a list of wishes, I would like to add some big box stores complete with signage, maybe a McDonald's corner store with the tall interstate sign. These things make a world of difference in the vfr world.


    Thomas made us a power plant cooling tower that could be added to the choices. If interested, I will pm for permission to use the files. Maybe even add the windmills?

    As much as I applaud kenventions et al for moving forward on automating tower placement (three cheers :thumbup::thumbup::thumbup:)

    If the vision is a generic CreateAF2Object would it not make more sense to look at OSM and scenProc extensions (sorry Arno) where there is already infrastructure for definition and placement of objects within the scenery context.

    /Stu

  • AeroScenery Beta - Help With Testing Required

    I found that with 16 gig of memory more than 2 concurrent GeoConvert instances are thrashing away in the page file.

    So I doubt more than 2 instances are actually gaining any performance benefit over dual instances run sequentially.

    Eight concurrent instances eventually cause a pagefile crash.

    Hopefully v1.0 of AeroScenery will have some configuration for MaxConcurrentGeoConvert instances.

    /Stu

  • AeroScenery Beta - Help With Testing Required

    Hi Nick

    I am experiencing some unusual tile "dropouts" with AeroScenery images

    The left stitched image was downloaded yesterday from G and the right image was from today's retry.

    The dropouts are 256x256 pixels. Looking at the dropouts in detail

    they appear to be the same tile from a different dataset rather than a fetch failure.

    At first I thought the dataset had been prepared by G with substitutions for problem tiles.

    But if the dropout tiles vary from run to run is there somehow a runtime selection of dataset version per tile??

    Has anyone else experienced this?

    cheers

    Stu

    PS

    Have downloaded several tiles since then without any issue.

    G just having a bad day ??

  • AeroScenery Beta - Help With Testing Required

    Hi Nick

    I have been playing with AeroScenery and thinking about "production mode" use.

    The issue arises in tiling out high resolution areas of interest.

    I am building soaring scenery with level 9-12 scenery in the general area and level 13-14/15 for significant valley floors and walls. The geoconvert integration challenges make a single pass approach unworkable. Selecting a dozen tiles for an all Actions pass overnight always fails at the geoconvert stage as 12 concurrent geoconvert jobs crash the pagefile (and in reality with 16G more than two concurrent geoconvert are just thrashing away at each other anyway). Imposing a limit on concurrent geoconvert jobs stalls on the lack of a geoconvert completion event.

    Based on this issue I have been doing download only "batch" jobs overnight and then geoconvert individual tiles the next day. It is not possible to tell from the map view which tiles have been converted and which are download only.

    So it would be nice to have additional tile states such as "Converted" and "Installed" to make it easier to manage an incremental build process from the map view.

    When the geoconvert integration can be tightened the batch production scenario will be less of an problem, but the same issue arises if you want to do an intermediate inspection and color correction before geoconvert.

    thanks

    Stu

    PS

    It is possible to "schedule" AeroScenery for the wee hours (when bandwidth is free) using the pssuspend command from the MS pstools pack.

    After selecting tiles and starting the download, the AeroScenery process can be suspended.

    A batch job at the designated hour resumes the process without any apparent problems.:thumbup:

  • Hand and finger tracking

    I agree direct hand tracking can give better immersion than hanging on to a controller.

    The lack of haptic feed back is not a big deal to me. An audio cue on "touch" would be an acceptable substitute.

    There would have to be some sort of gesture mapping to provide the equivalent of controller button selection.

    Looking forward to developments in this area. :thumbup:

  • AeroScenery Beta - Help With Testing Required

    Hi Nick

    AeroScenery continues downloading after the loss of the internet connection.

    Some of us have to get by with flaky wireless broadband internet providers. The signal will drop out intermittently (more frequent on windy days).

    I simulated this by manually disabling the ethernet adapter after AeroScenery started the download phase. The progress bars continued to 100%. The partially downloaded tiles were stitched and geoconverted.

    There are entries in the log file indicating errors on all download requests following the loss of connection, but the incomplete tile shows as downloaded in the map view. If there were more than one tile in the download it is difficult to work backwards from the error entry to which tile or tiles have download problems.

    I cannot think of any scenario where a partially downloaded tile is useful.

    There several ways to handle this scenario that would be easier to manage

    • hard stop on connection fail.
    • (better) leave partially downloaded tiles with status of "Not Downloaded" (assuming some tiles may have downloaded completely)
    • (even better) a pause and restart on reestablishing a connection (as FSET does).

    thanks

    /Stu