Posts by nickhod

    Here you go Nick.

    Thanks Mark. I can see that it tried to upgrade the database without actually creating the tables first. It would only do that if it found a database file but it was really an empty file.


    Struggling to understand how that could happen but thanks for sending. I'll see if I can make it happen again and also log out more info around this code.


    I'll also see if I can add an success message on the installer.

    Is there any documentation anywhere of what a toc file can contain?


    Is there any info how to convert a text toc file into the binary toc files found in the Aerofly game folder and 3rd party add-on folders?

    If we can beg/persuade/coerce Nick to consider including the feature I described above,

    Hi Josh qwerty42


    Thanks for all the input on this, I do like the idea. Also thanks for the process outline you PM'd me.


    To build on what we have now it would definitely need to be a kind of "easy mode" that lets the user enter the minimum altitude for the squares they've selected. Behind the scenes it would use all the same options and folder structure, just doing some logic to decide which options to set for each grid square.


    Selfishly I'm going to prioritise USGS elevation data then USGS images first because those are two things I want to use.


    You'll also notice that there's a "Scenery Editor" button on 0.5. I started thinking that it would be cool to be able to edit airports, xref objects and cultivation data in AeroScenery.


    This thing just grows and grows and sadly I only have a few hours here and there to work on this.


    When we get nearer to the time that I can look at implementing this I'll do a few UI mock ups, outline my logic and see what you folks think.

    Hi Mark mdowner


    Was this a clean installation or were you using a previous version of AeroScenery? If so, which version was it?


    If you go to Documents\AeroScenery\database and rename aeroscenery.db to _aeroscenery.db the app will / should create a new one on start. Let me know still throws an exception. (You wont lose anything in the underscore db file).


    If you're still having issues you could send me the database that's causing the issue and I'll debug what's going on. PM me for my email if it wont attach here.

    Hey Nick

    Hi qwerty42


    Thanks for the input. Funny you should post that because I revisited your spreadsheet last night and came to the same conclusion; I need to bring all the coordinates 0.01 degrees closer to the centre point of the square. I should have of course realised that simple rounding up or down doesn't work because this is lat / lon.


    I'm pleased you and another author have come to the same conclusion because I was concerned what else this would break, or whether that would mean in some cases that no tiles are generated.


    Also good to know that the origin of the spreadsheet maths is IPACS, so it's kind of as official as we'll get :)


    I tested it by manually altering TMC files with a few squares last night and it always worked.

    It seems like GeoConvert is more forgiving at snapping "outwards" to the nearest square boundary rather than snapping "inwards".


    I'll keep the existing calculation for drawing grid squares in the software, and use the "inwards" adjusted option for writing TMC files. That way the "on screen" grid squares will be contiguous.


    crispy136  moxeetwo Look out for version v0.5.1 coming before the weekend, maybe, hopefully. This bug should be fixed.

    I think it is a little early in the beta process to be locked into legacy.

    For the long term ease of use, intuitive name conventions are worth their weight in gold.

    On reflection, I don't think it is legacy or a bad decision. AFS grid squares define a specific area, Google and Bing zoom levels are a standardised thing and describe a meters per pixel value. They're totally independent of each other and trying to name them the same might lead to more confusion.


    Currently been building commercial software for 15 years and also know that feeling though!


    Thanks for the words of encouragement.

    I use qwerty42's Excel utility to give me the coordinates for FSET.

    I ported that Excel file's formulae to C# so I'm using the same coordinates. To save anyone else time looking at this...


    I took my random Level 13 size square that was producing an extra "band" with masks at the bottom.


    AeroScenery generated the following coords in the TMC file for that square


    <[vector2_float64] [lonlat_min] [2.15 46.77]>

    <[vector2_float64] [lonlat_max] [2.20 46.74]>


    When I hand tweaked the coords to this


    <[vector2_float64] [lonlat_min] [2.15 46.77]>

    <[vector2_float64] [lonlat_max] [2.20 46.*75*]>


    It worked as expected and just output one ttc file with no masks.


    So, it's a rounding error.


    Question is, if I fix that does it break it for other scenarios? (Pessimistically I'm guessing yes). It'll need some testing.


    The ideal here would just be to be able to lookup "map_13_8188_a608" from a predefined list and get the coords GeoConvert expects.

    I must admit I don't quite understand the reason for the rather confusing Levels naming in Aeroscenery.

    Fair point, but it's just what they're called on the actual Google and Bing map APIs (and on Ortho4XP). I used to use Ortho4XP and so I was used to that terminology.


    In 0.5 you'll see that's it's now called "Image Detail Level" to avoid some confusion.


    Unfortunately too late to change it as everyone's folder names would be wrong.

    Could this be the issue? Just a thought.

    It's possible, yeah.


    One thing to bear in mind is that my stitch files don't match AFS grid tiles. They're just multiples of Google or Bing tiles stuck together (always larger than the AFS grid tile). They probably wont match what FSET is doing at all.


    For each stitch tile, when I last checked the NW lat / lon, SE lat / lon and calculated pixels per step it all checked out, but I will go over it again.


    My guess is still that GeoConvert wants slightly different coordinates in the tmc file. I'm going to try changing them by hand to see if I can get it to snap to a whole grid square and go from there.


    It's a shame that IPACS don't publish a list of gird square coordinates boundaries to avoid the ambiguity.

    Thanks Tom. Yes, the map issue is definitely the decimal comma again.


    In SQLite browser you can go to the "Browse Data" data, select the table in the drop down and see what's in there.


    I would guess that the airports issue is related somehow.

    I did some testing and comparison with the various files created by the manual FSET and automatic AeroScenery processes and after a few false starts I think I have an answer.

    Hi Chris,


    Thanks very much for the detailed test. I can see you spent some time on that. :)


    What I noticed is that as you give GeoConvert more resolution (by increasing the image zoom / detail level) the "overspill" gets less and less for a level 13 size tile.


    For a random level 13 size tile in France:


    At image detail level 17 I get six(!) masks

    At image detail level 19 I just get a small strip at the bottom.

    At image detail level 20 an even smaller strip


    Maybe by limiting size 13 & 14 to image detail level 18+ and tweaking the decimal rounding in the TMC file we can fix this.


    I'll have to look at this more fully later as I'm out of time now, but thanks again for the test.

    Hello Nick,

    sorry the airports do not load, even in higher zoom.

    Hmm, frustrating about the airports as that's (I thought) quite a well tested feature. I'm also testing releases on a clean Virtual Machine and they work on there.


    The log isn't showing me much. If you really want to dig into this you could download SQLite Browser to open up the AeroScenery database. The table is FSCloudPortAirports.


    https://sqlitebrowser.org/


    Does anyone else see airports in 0.5 after clicking the "Show Airports" button and zooming in?


    Please note that "Open In Map" only works when a grid square is selected. I should be greying it out when nothing is selected.

    Currently I have a problem, that the "Show Airports" does not show a single one.

    And installing the converted files into the configurated AFS2 folder did not hppen.

    Also "Open in Map" does open google or bing, but it does not position to the correct location (also did not in earlier versions).


    Hi Tom,


    Thanks!


    The airports only show at higher map zoom levels (it adds too many markers otherwise). "Show Airports", then zoom in somewhere populated and let me know if you see them. Failing that check the log (which is now in My Documents/AeroScenery) to see if there were any errors when populating airports.


    I can't do the install feature until IPACS improve GeoConvert so I know when it's finished. I forgot (again) to grey out the option. Ooops.


    Strange that "Open In Map" doesn't work properly. Can you give me a google maps link and AFS tile name of an an area that doesn't work properly and I'll try to debug.

    I converted San Francisco airport. 4 separate areas were needed, producing only one single (stitched) PNG file each. It is quite difficult to edit these because they are quite burried inton the folders. Can you establish an exeption that you do not split these over 4 folders so that all ongs can be found at one location?

    Probably not on that one unfortunately. It's all been written to put things in individual folders per AFS tile. The level 13 and 14 selection side was a bit of an after thought once I realised how long it would take to download a level 9 square at zoom level 20.


    Those 4 separate areas might correspond to one level 13 tile though, so that's one option. I could add a level 12 selection size easily too.

    The statement that FSET is not an IPACS program is correct. It was developed many years ago and the developer made it crystal clear that FSET was always to be freeware and he has not made any updates for several years.

    Another utility was mentioned in the FSET / GeoConvert process. Either way, I'm interested how accurate coordinates are obtained for the TMC files when using FSET.


    For the maths nerds out there, this is how I'm currently generating them


    https://github.com/nickhod/aer…oScenery/AFS2/AFS2Grid.cs


    That is based on some code from other users of this forum. crispy136 's bug report is correct however, they aren't identical to how GeoConvert is calculating them.

    Couldn't find the disable masks option you mentioned. I thought it was in the settings screen in 0.4, but is missing from that screen in 0.5.

    The settings form now has tabs as it was getting too big. It's there under the "GeoConvert" tab.


    If you could try the old FSET process and see if you get a mask, that would help. Should it work correctly, whatever is generating the coordinates in the .tmc file is the interesting bit.

    Excellent. Thanks for building this special program for us. I am waiting with great anticipation for the USGS edition. We will be able to freely share our scenery with the USGS edition.

    Thanks! USGS images and elevation data will definitely be coming soon. USGS elevation data is something I'm looking forward to personally.


    I've implemented calls to the USGS catalog API and coded a workaround to grab Zip files from there. (They want you to do this manually with a normal account).


    Most of the hard work is done, I just need to put it all together.


    Thanks!


    In 0.5 the zoom / image detail slider now shows you the meters per pixel value. Zoom 20 is 0.146 m/pix.


    I suppose the only disadvantage of using selecting with level 14 size tiles is that you can't generate level 13 ttc files from them.


    However, when you look at commercial scenery like OrbX LOWI all the super detailed stuff is level 14 and level 15 files, so it's probably not an issue for most people.