AeroScenery Beta - Help With Testing Required

  • Yes. Auto-cultivation seems to be all OSM based but actually Google and Bing have far more data on building footprints. It's a shame that Google's data isn't available.


    I'll finish up USGS and Elevation data features in AeroScenery then take a fresh look at cultivation.

  • @GR,

    That was fast - OK, then the other files of interest are in C:\Users\YOURUSERNAME\Documents\AeroScenery. Other than that, I don't know.

    Just renamed that also. Still no luck.

    I see that folder re-created after my rename. Task Manager shows the process exit after one second before any window appears.
    Thanks for trying to help. Your suggestions had potential. Mystery remains.

  • Just tried to run AeroScenery today after not using it for a few days.

    The app won't start. No error message, no processes in Task Manager.

    I rebooted, then uninstalled and reinstalled. Still can't get it to work.

    Any ideas?

    This worked for me:


    Use the command - regedit:

    If you already installed a former version of AeroScenery, then it might be needed to delete this (folder) key, which was helpful in my installation:


    Computer\HKEY_CURRENT_USER\Software\AeroScenery


    Be sure to first backup your registry!

  • Just renamed that also. Still no luck.

    I see that folder re-created after my rename. Task Manager shows the process exit after one second before any window appears.
    Thanks for trying to help. Your suggestions had potential. Mystery remains.


    Hi Greg,


    As others mentioned, go to the start menu, type regedit, click Yes to run as Admin

    Go to HKEY_CURRENT_USER > Software > Right click the AeroScenery folder and click delete. (You'll need to re-set your SDK folders etc.)


    Failing that go to the Documents folder on your computer, AeroScenery folder > database folder > rename aeroscenery.db to _aeroscenery.db


    The next version of AeroScenery (5.1) will never fail to start and will always tell you what's wrong.

    I think I've fixed most of these "failed to start" issues in the next version, but being able to copy and paste good error reports will let me fix anything that remains.


    Sorry for the annoyance in the meantime!

  • Thanks for this great tool!

    Everything works great, Selecting Areas, Zoom Levels, downloading, Stitching, creating files for geoconvert.

    Only weak point in the moment is geoconvert. I had to increase swap space significantly to avoid geoconvert system crashes on windows 10. Geconvert needs up to 25 GB when converting. Next point is I have to convert in smaller partitions. When aeroscenery starts too much instances of geoconvert, everything gets unstable and often stops working.

    I think when geoconvert can be started once, writes some protocol and ends itself with a defined exit code and can then be run with the next area and so on, that would be a wonderful workflow.

  • I found that 2 or more simultaneous GeoConvert sessions running maxed the CPU, rendering the PC unresponsive until it had finished. However left alone it finished without causing any problems for Win10. Also that when I was running 9 tiles, GeoConvert didn't produce any output for the 9th tile, although when I reran the GeoConvert step for just that tile it worked. I didn't have any crashes with 20gb RAM, but never exceeded 9 at once. I also noted that I could run more level 14 tiles at once than level 9 tiles at once. I don't think GeoConvert was ever designed to have many instances running at once.

    Thanks, Chris

    Win 10 64-bit, 24GB RAM, i5-9400F @ 3.9, 6GB Nvidia RTX-2060

  • I agree, but sometimes when I leave the pc alone doing many tiles I got reboots. Tested on machine with intel and Ryzen processors. On Ryzen processors the the reboots occurred more often, even with many more cores. I know that GeoConvert isn’t designed for using it this way but if IPACS decides to enhance it with these little improvements, protocols and starting and stopping with exit code for success , then AeroScenery can start a configurable amount of instances and that would make it a great solution avoiding many problems. But as you wrote I was able to run more smaller tiles, too.

  • Found this while doing some source image quality comparisons. I think this may have been mentioned before, but couldn't find the post. Looks like the higher the zoom the more accurate the placement of the tiles. Looking at the airport runway, zoom 19 gave the best match but was still a little out. I repeated the test using map size 13 tiles and got a similar result using either level 14 output or level 13 output. In case there was some issue with GeoConvert I also did an extract using FSET, but encountered no problems. I used Google for the AeroScenery extract but the tiles I had from FSET were Bing, but I don't think this was an issue.


    AeroScenery - map size 14 with GeoConvert output size 14



    AeroScenery - map size 13 with GeoConvert output size 13



    FSET - map size 14 with GeoConvert output size 14



    Thanks, Chris

    Win 10 64-bit, 24GB RAM, i5-9400F @ 3.9, 6GB Nvidia RTX-2060

  • Looks like the higher the zoom the more accurate the placement of the tiles.

    Interesting result and needs some debugging by any willing volunteers!


    There a few variables here to consider:


    - In the "stitched" directory, the .aero files for each image give the top left and bottom right coords. In my testing, these appear to be pixel perfect. (Testing in the Northern hemisphere anyway).


    - Also in the "stitched" directory, the AID files copy that top left value and also give "steps per pixel". I'm not sure why IPACS went with this vs also taking the bottom right coordinate and calculating the value internally. It seems there there's scope for error. I'm doing a simple width (in geo-coords) / pixels and length / pixels calculation. If I should be doing anything more complex, I don't know what it is.


    - The TMC file there's the lat & lon of of image tile. GeoConvert should be snapping to it's own accurate tile boundaries. The tiles are contiguous so that's not the issue.


    As the issue is more pronounced at lower resolutions, the issue is likely to be the "steps per pixel" value. It seems like it may only be out in one direction.


    A good test might be to do one level 13 size square with Bing in AeroScenery, and try to do exactly the same area with Bing in FSET. Then compare the coords and steps per pixel in the relevant files and see where any differences are occurring.

    I think when geoconvert can be started once, writes some protocol and ends itself with a defined exit code and can then be run with the next area and so on, that would be a wonderful workflow.

    I'm currently looking at the feasibility of internally taking a screenshot of the GeoConvert window every 5 seconds and testing for the presence of any green (as seen in the success message).


    Slightly bonkers but would work.


    GeoConvert is definitely not made for running multiple instances. It's surprising it even works given the RAM usage.

  • Interesting result and needs some debugging by any willing volunteers!

    Have attached the results of the map 13 sized tile extracted @ zoom 18 (0.597 m/pixel) in AeroScenery and download res 0 (listed as 0.5 m/pixel) in FSET. Have attached everything except the image files. AeroScenery image file was 8192w x 8704h png, while FSET image file was 6146w x 7258h bmp. TMC files used by both processes had the same values.


    In the FSET zip you'll find a couple of extra files.

    1. txt file (not used, but produced by FSET)

    2. inf file (produced by FSET but only used only to create the tfw file)

    3. tfw file (created from the inf file)


    Looking at the scenery tutorial the tfw file has the pixel steps in it. FSET doesn't produce the tfw file and that has to be done manually or by using a little exe someone developed, before GeoConvert is run. The tutorial gives no details of the purpose of the tfw file, only that it is part of the process.


    I also noticed that AeroScenery generated the aid file, but in the FSET process, the aid file is generated by GeoConvert. So it would appear the aid file is an byproduct of the GeoConvert process, not an input. Perhaps this is the problem, and AeroScenery needs to produce a tfw file not an aid file. Only guessing.


    AeroScenery top, FSET bottom. Note misalignment with Fscloudport runway.


    FSET - both top and bottom

    Files

    • Aeroscenery.zip

      (1.32 kB, downloaded 28 times, last: )
    • FSET.zip

      (2.98 kB, downloaded 29 times, last: )

    Thanks, Chris

    Win 10 64-bit, 24GB RAM, i5-9400F @ 3.9, 6GB Nvidia RTX-2060

  • I also noticed that AeroScenery generated the aid file, but in the FSET process, the aid file is generated by GeoConvert. So it would appear the aid file is an byproduct of the GeoConvert process, not an input. Perhaps this is the problem, and AeroScenery needs to produce a tfw file not an aid file. Only guessing.


    AeroScenery top, FSET bottom. Note misalignment with Fscloudport runway.

    As discussed in an earlier message, I'm afraid there's a bug in AeroScenery image scaling.


    the tfw file is an intermadiate. AID is not a really a byproduct of Geoconvert, it is created by Geoconvert if it isn't yet existing, but it is needed and used by Geoconvert to process images.


    I had the best results by simply having my images and their AID files in the input folder, and remove any inf, twf or whatever from there. That way, Geoconvert just uses the existing AID files (previously they were AIC files, but they were quite similar) and doesn't try re-generating them.


    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 4.00GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

  • Have attached the results of the map 13 sized tile extracted

    Thanks for that. There's nothing wrong with my maths in the AID files, the only difference I can spot it that FEST output is using exponential notation (e,g, "7.15255737304688E-06") whereas I'm not (e.g. "0.00000553205609321594").


    It's possible that the GeoConvert parser is taking the first 16 digits after the decimal marker and so losing precision from my AID output.


    I'll make that change and give this area, with that airport, a try myself.


    As I said, strange that IPACS chose to read in these tiny values rather than calculating internally from lat / lon.

  • I'm currently looking at the feasibility of internally taking a screenshot of the GeoConvert window every 5 seconds and testing for the presence of any green (as seen in the success message).


    Slightly bonkers but would work.

    I am a software developer for over 35 years now, and i think it should be an easy task for ipacs to add a

    • command line parameter like -q(uit) / -e(xit) or
    • an option in the tmc-file like <[bool][exit_when_finished][true]> or something like that to do that.

    I think your idea looks like 'crack a walnut with a sledgehammer', so why not ask ipacs, should be an intermediate task for relaxing from r22 development ;-)