AeroScenery Beta - Help With Testing Required

  • :/:S ... comme quoi j'en apprend tous les jours... Je ne sais pas comment j'ai réussi à m'en sortir jusque là

    Il y a plusieurs conventions/formulations pas très heureuses dans le SDK, à commencer par ces lonlat_min et lonlat_max qui sont en réalité des lon_min_lat_max et lon_max_lat_min, ou encore les steps par pixels qui deviennent négatifs en y ...


    lonlat_NW et lonlat_SE auraient été plus justes et n'auraient pas prêté à confusion...


    C'est une des raisons qui m'ont poussé à programmer mes propres outils pour générer les AID et TMC, cela évite bien des erreurs...


    A+

    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.

  • à Antoine,


    Compilation terminée en 2h.35 et ... !


    tout y est ! quasiment aucun défaut si ce n'est quelques uns sur les raccords entre maps, normal, il faut y attacher beaucoup d'attention pour la suite.


    Aucun défaut de texture, ma texture perso s'adapte parfaitement, plus de zones floues, impeccable en survol à tous les niveau depuis 200 pieds à 10 000 pieds !, les fondus de hauts-fonds sont bien rendus ... que du bonheur, je vais pouvoir poursuivre.


    Néanmoins, reste un gros doute : excepté le choix "False"ou True sur les masques, je n'ai rien changé de particulier à mes autres essais.

    Alors, il faut croire que tout viendrait de cela.


    Les images Bing sont moins contrastées que celles de Google mais :

    + pas de logo Google à retoucher

    + les hauts-fonds sont exceptionnellement meilleurs, plus étendus et mieux retouchés quand nécessaire.

    + beaucoup moins de zones à couleurs divergentes

    + pas d'effets de bandes verticales des captures

    - mais dates des images bien antérieures (je crois Google 2012) et Bing bien avant...autoroute proche aéroport en cours de travaux.


    Merci pour l'aide apportée, a+.


    Merci aussi à Nickhod pour son aide et surtout pour AeroScenery qui semble bien apporter ce que l'on attends, la simplicité.

  • Question à Nickhod,


    pour sauvegarder provisoirement une map (en cas de retouches ultérieures), que sauvegarder :


    - le dossier complet AeroScenery

    - ou, le dossier "Working" seul (mais manqueraient aeroscenery.txt et database)

    - ou, le dossier map_09_8680 xxx ...


    Merci pour votre aide ... et pour AeroScenery (génial).

    CPU Intel Core I7 6700 K @4.00 Ghz + BiQuiet Pure Rock - CM Asusteck MAXIMUS VIII RANGER - RAM GSkill Ripjaws4 DDR4 3000 16 GB - NVidia GeForce GTX 1060 3GB - 2x SSD Samsung 500 GB 850 EVO - DD WD 2 TO.

  • Question to Nickhod,


    to temporarily save a map (in case of later retouching), save that:

    The easiest would be the database and plus the stitched folder for the relevant squares. The tiles folder, the raw images folder and the ttc folder can be deleted (after you've installed the ttc files of course).


    You can then retouch and re-run the GeoConvert steps.

  • A few days ago lenidcamper and I identified a problem with the tile numbering in AeroScenery. I also noticed that there was a problem with the placement of the level 9 & 13 squares on the map. Since then I've played around with it a bit more and got it a bit clearer in my mind. This is my latest thinking on the subject:


    If you select a level 9 area on the map the tile number to the right of "grid square" above the map is wrong. What you see there is the number of the next level 9 tile to the north of the one selected. i.e. The latitude number is greater than it should be by 80 in hex (128 in decimal). The longitude number is OK. This incorrect number is also used as the title of the folder generated by AeroScenery. Furthermore the placement of the level 9 square on the map is also wrong. It is one level 14 tile too far north of where a level 9 tile should be. However the geoconverted tiles in the folder are "correct" in the sense that they are the ones that you would expect to find in the more southerly level 9 area.


    If you select a level 13 area on the map the tile number to the right of "grid square" above the map is again wrong. Again, what you see there is the number of the next level 13 tile to the north of the one selected. i.e. The latitude number is greater than it should be by 8 in hex (or decimal). The longitude number is OK. This incorrect number is also used as the title of the folder generated by AeroScenery. The placement of the level 13 square on the map is again wrong. It is one level 14 tile too far north of where a level 13 tile should be. Again, the geoconverted tiles in the folder are "correct" in the sense that they are the ones that you would expect to find in the more southerly level 13 area.


    If you select a level 14 area on the map everything works fine. The tile number above the map is correct, as are the folder title and the placement of the square on the map. This of course means that the level 14 squares on the map are out of alignment with the level 9 and 13 squares, but you will only notice this is you look at the tile numbers. As I wrote in a previous post, to see this you need to select level 9, 13 & 14 areas all with a common SW corner. They should all have the same tile number - but they don't.


    I have encountered a couple of other problems with geoconvert which may, or may not, be related to the above:


    1. If I geoconvert a level 13 area I get 1x level 13 tile, 4x level 14 tiles and 8x level 15 tiles. I should get 16x level 15 tiles.


    2. If I geoconvert a level 9 area with tiles up to level 13 I only get the correct numbers of tiles if I go with the suggested levels (viz 9, 10, 12 and 13). When I tried to generate level 9, 11, 12 and 13 tiles I got the wrong numbers of tiles (too few). This may be a feature rather than a bug - I'm not sure.


    Processing a level 14 area (generating level 14 and 15 tiles) works perfectly.


    Perhaps I should add that I set geoconvert so as not to generate any masked tiles. According to my understanding there shouldn't be any anyway provided you are either away from the coast or - if you are near the coast - you have processed the stitched images so as to fill in any blanks. And, of course, provided you only generate tiles equal to or smaller than the area you have selected.

  • A few days ago lenidcamper and I identified a problem with the tile numbering in AeroScenery.

    Thanks for reporting this. Yes, you're right.


    There's no official documentation on how to generate tile boundaries and tile hex names from IPACS. The closest I could find was a thread on here, where a forum member maintains an Excel sheet that people were using to calculate tile boundaries for use with FSET.


    Image tile coordinates


    In turn that spreadsheet seems to have been based on C++ code from the game itself posted by Rodeo here


    Scenery Loading Distance


    I ported the formulae of that sheet to C# and did several spot checks that it was generating the same numbers, which it is.

    The spreadsheet must be wrong though.


    The hex numbers are derived from the lat and lon, so those also being incorrect makes sense.


    I'll try to figure out where the calculation is wrong and fix this for version 1.0, but I'll have to write something to fix everyone's database and folder names, or it'll result in a mess. :(

  • Thanks for reporting this.

    Hi Nick


    Many thanks for all the work you're doing. AeroScenery is far more user-friendly than FSET - and about twice as quick by my reckoning.


    I have a spreadsheet that calculates lat-lon co-ordinates from tile numbers. It will also tell you which tile you are in if you input co-ordinates. I don't know whether that was the kind of thing you meant? It originally came from Rodeo - though I have modified it a bit myself.


    Cheers


    Ian

  • I used this spreadsheet as my reference:


    Image tile coordinates


    If yours is different to that, send it over so I can compare numbers and formulae and figure out what's going wrong.


    Thanks.

  • 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 ??

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

    Edited once, last by lenidcamper: update ().

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

    I've not experienced this, but Google does whatever it can to stop people bulk downloading map tiles. AeroScenery makes itself appear as a regular browser and introduces a variable delay to try to combat this.


    Either this is part of Google's rate limiting / bulk download prevention strategy or just that you're randomly being pushed to a server that's serving up older map tiles.


    AeroScenery uses the following Google Maps url template.


    http://mt1.google.com/vt/lyrs=s&x={0}&y={1}&z={2}


    In the next version I'll make this configurable.


    mt0.google.com and mts0.google.com also exist which might have given different results here.

  • Nick,


    Speaking of the "next version" . . .


    I would really appreciate a couple of more size choices. Especially, the one that is 4 times larger than your Small (grid 13). Not sure which way the numbers go. But, between the Small and Large.


    I am also looking forward to see your magic with the USGS. Some of the images are staggeringly beautiful - almost like a photo.


    Is there some method of editing these images prior to GeoCruching without have to edit several hundred small files? The water in the Puget Sound area is a real mess, both the deep water which may be 50% of a grid 9 tile and also around most of the smaller islands. I started trying to clean them up, but there are so many, I would probably lose interest in the area before I could finish.


    Regards,

    Ray

    When Pigs Fly.

    A steely-eyed Sierra Hotel record setting F-15E Strike Eagle simulator pilot. 8o

  • Is there some method of editing these images prior to GeoCruching without have to edit several hundred small files? The water in the Puget Sound area is a real mess, both the deep water which may be 50% of a grid 9 tile and also around most of the smaller islands. I started trying to clean them up, but there are so many, I would probably lose interest in the area before I could finish.

    You need to be editing the files in the "stitched" folder. There should be a manageable number per level 9 square depending the image detail level. You're probably looking at all the 100s or 1000s of map image tiles.


    The stitched files are around 8000px square by default.


    Sadly I'm not getting much time for either AeroScenery or Aerofly at the moment. Hopefully soon though.

  • Nick,


    I guess because I am choosing level zoom level 17 and 9 - 14, the number of stitched images is unmanageable for editing say half the tiles with semi-matching colors to overwrite the bright white tiles for the water. :/ Thanks.


    We have a saying that goes something like this. There are a few creative programmers that work for free, and there are a few programmers that are really good at what they do, but it is truly rare to find a really good, creative programmer that works for free. We will just have to wait until you have the time for the next version. :P

    Regards,

    Ray

    When Pigs Fly.

    A steely-eyed Sierra Hotel record setting F-15E Strike Eagle simulator pilot. 8o

  • I would really appreciate a couple of more size choices. Especially, the one that is 4 times larger than your Small (grid 13). Not sure which way the numbers go. But, between the Small and Large.

    Just to second that. I'm a bit unusual in that I cover my whole territory with level 15 tiles. (A level 10 area would be good for me.) The level 9 area is too big for level 15 processing, and levels 13 and 14 are too small unless some way is found of running geoconvert sequentially rather than simultaneously. (In that case I could have multiple (more than 6) small tiles selected - which would be a reasonable workaround.)

  • ...

    The hex numbers are derived from the lat and lon, so those also being incorrect makes sense.

    ...

    Hey Nick, I could be wrong and just taking a wild guess here, but if you're calculating the filename hex from the lat and lon decimal degrees values that might be the problem. The size of the tiles in terms of degrees latitude are not uniform as you get further north or further south of the equator. For example (assuming my spreadsheet is correct), a level 9 tile is ~0.70 deg 'tall' at the equator, but only ~0.11 deg 'tall' at the north pole. If you've assumed uniform spacing and are converting from degrees to hex from that, it might explain the issue...?

    If you did port all that code from my excel sheet (ugh!), and this really is the problem, you can get the grid coord numbers directly from rows 26 & 27 and rows 46 & 47 in that spreadsheet on the 'DONT_EDIT' tab. They are the number of the tile before it is converted into lat and long decimal degrees. Note that I split them into NW corner and SE corner (because of the area expansion feature I had in that spreadsheet) so you may need to offset them by 1 before converting to hex.

  • Hey Nick, I could be wrong and just taking a wild guess here, but if you're calculating the filename hex from the lat and lon decimal degrees values that might be the problem. The size of the tiles in terms of degrees latitude are not uniform as you get further north or further south of the equator. For example (assuming my spreadsheet is correct), a level 9 tile is ~0.70 deg 'tall' at the equator, but only ~0.11 deg 'tall' at the north pole. If you've assumed uniform spacing and are converting from degrees to hex from that, it might explain the issue...?

    If you did port all that code from my excel sheet (ugh!), and this really is the problem, you can get the grid coord numbers directly from rows 26 & 27 and rows 46 & 47 in that spreadsheet on the 'DONT_EDIT' tab. They are the number of the tile before it is converted into lat and long decimal degrees. Note that I split them into NW corner and SE corner (because of the area expansion feature I had in that spreadsheet) so you may need to offset them by 1 before converting to hex.

    Thanks for the info. I haven't looked at this fully yet, but it's on my list before I release the next version.


    I'm either calculating the just the hex tile name wrong, or the hex tile name and the lat and lon wrong. I'll let you know what I find.

  • Thanks for the info. I haven't looked at this fully yet, but it's on my list before I release the next version.


    I'm either calculating the just the hex tile name wrong, or the hex tile name and the lat and lon wrong. I'll let you know what I find.

    Thanks, curious to know what you figure out. I won't deny the possibility that there's an error in my spreadsheet, since it's an ugly translation of programming code into spreadsheet logic, but I have previously converted some pretty huge areas from levels 9 thru 15 using it and FSET and never noticed any tile offset problems between the various levels. I've also compared the coordinates my spreadsheet calculates to the level 9 coordinates that GeoConvertHelper calculates, and they've agreed to 12 decimal places (if you account for the .1 degree inward offset that GeoConvertHelper automatically adds in). It's not a guarantee it's right, but if it's not then I'd suspect it may be an issue with the original code snip Rodeo posted...

  • question à Nickhod,


    si l'on a qu'une seule ou quelques images stitched modifiées existe-t-il une possibilité de relancer AeroScenery ou GeoConvert seul afin de créer le fichier ttc sans relancer l'ensemble du processus de la map entière ?


    Merci à vous.

    Cordialement.

    CPU Intel Core I7 6700 K @4.00 Ghz + BiQuiet Pure Rock - CM Asusteck MAXIMUS VIII RANGER - RAM GSkill Ripjaws4 DDR4 3000 16 GB - NVidia GeForce GTX 1060 3GB - 2x SSD Samsung 500 GB 850 EVO - DD WD 2 TO.

  • question à Nickhod,


    si l'on a qu'une seule ou quelques images stitched modifiées existe-t-il une possibilité de relancer AeroScenery ou GeoConvert seul afin de créer le fichier ttc sans relancer l'ensemble du processus de la map entière ?

    Not via the UI...


    The tmc file in the stitched images directory defines a level 9 size area (if you're using level 9). When you run GeoConvert it will always use all the stitched images to generate all levels requested.


    However, you can make GeoConvert do what you want by editing the tmc file.

    You could specify the region that you've changed in the lat lon, then have it generate ttc files smaller than this size.

    You'd need to set masks to off if you tried this.


    May be more effort than just running it again though.