Posts by Ian C

    Hi Bill


    I've attached a spreadsheet image to show the way I work on scenery. The whole spreadsheet area is basically a Level 7 tile, the small squares are Level 12 tiles, and the intermediate-sized bold squares are level 10 tiles. The co-ordinates shown on the axes are for the SW corners of the Level 12 tiles.


    My procedure is as follows:


    1. Geoconvert the the whole spreadsheet area with Levels 9 & 11 using FSET resolution 4 (Virtual Earth).


    2. Mark in blue all the Level 12 tiles that are completely sea. I do this by going to the AF2 "Location" tab, clicking on places around the coast and reading off the co-ordinates from there.


    3. Geoconvert smaller areas (usually 4 x 5 = 20 small squares) with levels 12, 13, 14 & 15 using FSET resolution -1 (Virtual Earth). Before doing this I carefully check each area for clouds and colour casts by zooming in using the AF2 "Location" tab. Since I've already used Virtual Earth to geconvert the whole area, these defects will be defects in the VE images. Any Level 12 squares with defects are colour coded as shown. They will be geoconverted using Google Earth images (assuming the latter are better). For coastal tiles I use GIMP to colour in the white areas on the BMPs using a bluish-green sea colour, saving the images as TIFFs before geoconverting them.


    Whatever area I geoconvert I always add 0.01 deg all round so that I'm absolutely sure of having tiles filling the whole area. This is necessary because the co-ordinates shown are only approximate (to 2 dp) so you need a little overlap to be sure. I always set geoconvert to reject masked tiles.


    The letters "TA" etc are only relevant to cultivation in the UK using the Ordnance Survey. They mark the SW corners of the Ordnance Survey grid areas.


    Ian

    Hi Stu - thanks for that. This is now getting quite sophisticated!


    I've had a similar problem to you with lakes - which sometimes have a dark greenish tinge and can end up with trees in them if you're not careful. If you then eliminate those pixels you're also losing a bit of lake-coloured forest somewhere else. With a lake (but not really with shadows) you could simply colour it in with a different colour. Images edited with Gimp and saved as TIFs still work with Geoconvert, so I imagine they would also work with Scen Proc? I need to try it some time. I suspect many lakes would actually look better if they were coloured in. Any kind of fixed texture or pattern on water destroys the VR illusion. Until moving waves come along, a block of uniform colour is arguably preferable.


    The variation of vegetation with altitude is a great refinement.

    Hi Stu


    Glad to see that others are having success with this method - it does reflect the natural distribution of trees rather well. In remote areas forest outlines must change somewhat over time anyway, due to felling etc. According to Dave whitav8 Arno is working on a way of detecting buildings from aerial images. Now that would be something! I did try it myself using the histogram filter, repeatedly clicking on roofs - but the problem is that many roads etc are the same colour as roofs - even some parts of the forest are! What it needs is some kind of rectangular pattern recognition as well, which I imagine is what he's trying to do (though I could be wrong).

    Hi Ian:

    Thank you very much for your post. I tried your instructions to the letter and now I'm able to easily generate a lot of trees/woodland in a matter of minutes (had to wait a bit for the first batch of processing with ScenProc -step 11- to produce the SHP file, but everything run just fine until the end!). See picture below of my sample area. I'm very satisfied with the results. Thanks again for your useful post 8)!!!.

    When selecting the area using FSET, sometimes it could include an airport, so I have a question in case you don't want to cultivate your airport with trees. In that case is there a possibility to exclude an entire area insted of deselecting the orange areas by using mouse right-clicks?.

    Cheers, Ed

    Hi Ed


    I'm glad it worked for you. I always wonder, when creating a list of instructions, whether I've left anything out that might not be obvious to the person reading them! I find the method is actually pretty accurate, with relatively few trees on roads etc. With practice the stray trees could probably be reduced even further. I don't know the answer to your specific question - but it seems others have produced a solution using JOSM, if I understand it correctly.


    Ian

    As others have said, use Gimp to edit the BMPs. There are 2 possible approaches: (1) Make the white areas transparent as described in the Wiki. This allows the default AF2 sea to show through. (2) Colour in the white areas with a suitable shade of blue, preferably using a "brush" with a fuzzy edge so as to produce a gradual transition. I use method (2) myself. The only disadvantage of it is that, if ever the default AF2 sea is improved (with waves etc?), I won't see it around my coast. I understand from those who have tried it that the disadvantage of (1) is that it produces a jagged transition between the land and the sea when viewed close up (unless somebody has found a way around that). Also I gather that any FSET tiles generated in the transparent area are classified as "masked". This wouldn't suit my method of working, since I set Geoconvert to reject all masked tiles and, when selecting my area to geoconvert, I allow a 0.01 degree overlap around the approximate (2 dp) positions of level 12 tiles in order to ensure that no level 15 tiles are missed.

    I have preached the use of JOSM for a while, didnt get much attention.

    Ultimately I intend to try both methods and compare them. I think the photo-cultivation is a quick and dirty method for producing lots of trees. JOSM is probably more precise though, as I say, I am pretty happy with photo-cultivation as far as it goes.

    I haven't tried JOSM yet - but I certainly intend to. If it's quicker/easier/more accurate than the above, that would be great!

    Returning to Phil's original question about cultivation from photoscenery, I thought I'd just put down in writing my own experience so far. However, before I carry on, I must first give credit to Dave whitav8 , who made me realise that this was do-able and gave me some lines of script to put into ScenProc.


    The bottom line is that it's actually pretty easy to produce good forest cultivation this way. You still have to rely on OSM (or some other method) for buildings and roads, but in sparsely populated areas where trees are an important feature this may not matter too much. I've been testing it out on Maine (USA) which fits the aforementioned criteria, and I'm very pleased with the results so far.


    In case anybody wants to give it a go, the procedure is as follows:


    1. Obtain a BMP of the area you want to cultivate using FSET in the normal way. I'm currently working on areas which are the size of a level 11 tile - i.e. roughly 8 x 8 nm - but smaller areas would probably give more precise results. It depends how impatient you are to cover a large area!


    2. Open ScenProc, click Tools (at the top) and select Texture Filter Editor.


    3. Click Add Image (at the top) and select your BMP.


    4. Click the down arrow next to NDVI Filter (on the left) and select Histogram Filter instead.


    5. Repeatedly left-click on different parts of the image that look like woodland. The editor is building up a picture of what range of colours are likely to be woodland, so the more you do this the better.


    6. Click Detect (at the top) and the editor will colour in (in orange) areas of the BMP that it considers to be woodland based on the pixels you have clicked.


    7. Check whether these orange areas cover the woodland satisfactorily. If they don't then left-click some more on areas of woodland that are not covered in orange. Check again by clicking Detect.


    8. If you find that the orange colour is covering areas that are not woodland, then right-click on those areas to remove those colours/pixels, and check again using Detect. There are settings in the lower left-hand panel - such as Buffer Size etc - which have some bearing on the way the filter works. The default settings work pretty well for me, but if you want more info have a look at Arno's video here


    9. Obviously if you are a perfectionist you could carry this process on indefinitely (!) but at some point (after about 5-10 mins in my case) you will say "that's good enough". At that point save the filter as a TFC file by clicking Save (at the top). Give it some name that makes sense to you.


    10. Now go back to ScenProc in its normal mode (the other window) and type/copy the lines of script below (courtesy of whitav8 , and only modified a little by me) into the top panel. Change the file paths and names to suit yourself. The INF file comes from the FSET process - I have renamed it, but obviously that's optional. However don't rename or move the original BMP file. Although it's not directly referred to below it does (apparently) need to keep its original name and location.

    ImportINF|D:\039082E7.inf

    SplitGrid|0.25|*|building="*"

    DetectFeatures|FTYPE="RASTER"|D:\039082E7.tfc|String;veg|trees|NONE

    MergeGrid

    ExportOGR|FTYPE="POLYGON"|ESRI Shapefile|D:\039082E7.shp|woodland


    11. Click Run (at the top) to produce the SHP file. A number of other files will be produced at the same time, with extensions such as PRJ etc etc. Put all of these files into one folder. I have called this folder "data".


    12. Staying with ScenProc in the "normal" mode, type/copy the lines of script below into the top panel modifying the file paths and names to suit yourself. Those of you familar with ScenProc may wish to tweak other things as well. (Credit for this code is due to Spit40 and ultimately Rodeo . It is a stripped down version of Spit40 's script for producing a TOC file from SHP files.)


    ImportOGR|D:\data\039082E7.shp|*|*|AUTODETECT

    PlacePointsInPolygon|*|0.00025;0.00025|1.0;1.0

    CreateAF2Plant|FRAND >= 0.25|8;25|broadleaf

    CreateAF2Plant|FRAND < 0.25|10;20|conifer

    ExportTOC|D:\Cultivation|039082E7


    13. Use the TOC file in the normal way to cultivate your area. Because it's such a small area I have a dummy stripped down airport (with no name) at its centre. In my Maine project this small area of photo-generated cultivation is within a larger area (roughly 60 x 60 nm) cultivated using OSM data. This is how I merge my different cultivations - but you may know of a better method.

    Well i have moved this window to my second monitor, and now that you mention it, i don't think it changed since then.


    When i do the math, and about 3 square NM for a level 13 tile. In total i have about 14450 nm² to do, so i should have 4800 tiles of level 13...


    means i'm still only halfway :| (having 2900 tiles alread)

    Only another 15 hours to to go! If money was no object I'd have 2 computers!

    Sometimes the counter doesn't work and the only way to be sure it's finished is to monitor the number of tiles in the "images" folder. I may be wrong about this but I have a hunch it has something to do with moving the geoconvert window or fiddling about with something else on the computer while geoconvert is running.

    I download at FSET -1/0.25 m and convert levels 12-15. I usually work on an area equal to the size of of a level 10 tile (i.e. about 14 x 14 nm). It takes me about 6 hours to download the images and about 4 hours to geoconvert them. Before I do that I put down a base layer of level 9 and 11 tiles over an area equal to the size of a level 7 tile (i.e. about 100 x 100 nm). For this first stage I use FSET resolution 4 - and the downloading and conversion take about 30 mins each.


    My impression is that geoconversion time is roughly proportional to the number of tiles produced, irrespective of their level. In a level 10 tile area there are 1360 level 12-15 tiles (i.e. 16+64+256+1024). So 1360 tiles are taking 4 hours, which is roughly 340 tiles per hour - or one every 10 seconds or so. (My computer is fairly well specified, but not the fastest currently available. CPU usage is well over 50%.)

    Kenneth


    Yes - that's true - I spend more time developing scenery than flying in it, that's for sure. My excuse to myself is that I need a "critical mass" to fly in before I can really enjoy it. Not "fear of missing out" (FOMO) but "fear of running out" (FORO)! Also I'm kind of hoping that some means of taking in the scenery very slowly will come along (eg hot air balloon). It's almost like I don't want to zoom around seeing too much of it at once since it's taken me so long to create it! My way round that problem at the moment is to fly very low and slow so that my horizons are limited. I'm quite weird and unusual in the way I use flight simulators!


    And yes the New Zealand project is very worthwhile. I've noticed with my UK scenery that full cultivation (especially of trees) can compensate to a large extent for shortcomings in the aerial images. This would definitely be true for large areas of forest.

    I have geoconverted a lot of the South Island, and have been disappointed at the lack of detail in the OSM data to bring some 3d to it via Scenproc. If any of you guys do end up with really good .TOC files based on other sources, I would love to have a copy of them.


    - Regards

    Kenneth

    Yes, the OSM data is very hit and miss - especially having experienced the UK cultivation and knowing how good it can potentially be. There are vast areas of forest in NZ (according to the images) but these are poorly represented in the OSM data. Having looked at it a bit more I'm also rather disappointed with the aerial images. They're OK, but not really quite good enough for conversion at level 15. The UK images are typically much better. I'll continue to try to get the TOC working but the image quality has discouraged me slightly.

    I spotted there were PRJ files. The question is whether they are "valid" and ScenProc can extract the necessary projection conversion data from them in the way it was able to with OS data. If you are first able to get this working through a QGIS conversion then, if projection remains the only complication, we can ask Arno for help. Even of the PRJ is not formatted well, once we have the projection conversion formula there's no need to do prior conversion you can just enter that conversion formula to the scenproc import line and scenproc will do it on input.

    OK thanks - I'll concentrate my efforts on the QGIS/KML route and see if I can get that to work.

    According to Arno, if there's a valid PRJ file which i think there is (needs to be checked), then Scenproc Autodetect mode works without converting projection beforehand.

    There are indeed PRJ files along with the SHP files.


    Using the "detectfeatures" function of ScenProc I'm currently trying to create an "forest" SHP file from the green areas on the map (which is a GeoTiff). However this is also going to suffer from projection issues I guess - so maybe it's doomed to failure. Would the same projection problems arise if I created the SHP file from a FSET BMP image? Dave whitav8 was successful with this, so maybe not. Thinking about it, this is probably why I have to do it from an aerial images rather than a map. Either that or get ScenProc to work with the SHP and PRJ files as we've done with the OS data.

    whitav8  


    Many thanks Dave - that's something I can try next. Useful to know that you can use the FSET BMPs.


    I haven't had any success with the SHP files from the NZ map site yet. Phil's right - there are no FEATCODEs in the data, so I tried using one of the other column headings in the data table with values such as "NULL", "SCHOOL" etc - but that didn't work. In fact ScenProc doesn't even get past first base (reading the data).


    Taking on board your experience of "Detect Features" in ScenProc, and having now viewed Arno's video right through, maybe using the Geotiff map isn't such a bad idea after all. In theory even the histogram filter should give 100% accurate results on a map image? I guess there's only one way to find out .....

    Yes I'm interested in that. Its why I started the thread about making autogen from photoscenery.

    Yes - it was your thread that alerted me to this possibility and made me seek out the video. One thing I did notice was that when I opened the NZ GeoTiff in Gimp it isn't actually an aerial image - it's an image of a map. A lot of the first part of the ScenProc video is about trying to pick out areas of woodland (say) on photographic images, which is obviously quite difficult to automate. Maybe I'm being too simplistic here but wouldn't it be a whole lot easier if you had a GeoTiff of a map? One shade of green would definitely be woodland, with no confusion whatsoever. I appreciate that a map isn't going to be quite as precise as an aerial image because there are compromises made to render it legible. The scale would also need to be as large as possible. However it would still be way better than some of the alternatives.


    EDIT: Of course if the data on the map is obtainable (and extractable) anyway from the SHP files, there's no need to bother with this - so maybe it isn't such a brainwave! Actually the more I think about this the more I realise that I'm being a bit daft. It would almost certainly be easier to figure out a way of reading the SHP files than figure out a way of reading the map! (On the other hand, if you had a GeoTiff map but no accompanying data it could conceivably make sense.)

    BTW I also noticed that one of the download options for the maps on the NZ site was "GeoTiff". I mention this because I was looking at a YouTube video on using ScenProc to generate cultivation from aerial images .....



    The video recommends GeoTiff as a suitable format for the images if you want to use them for this purpose. (Maybe the FSET generated images would also work? However I don't think the video mentions FSET.)

    Interesting. Not sure if its a projection issue (co-ordinate system is not understood) or what seems more likely is that the data is simply different. In QGIS you need to work out the codes they use as I suspect the simple FEATCODE field is not used.


    See this link for how to open the attributes table in QGIS.

    OK thanks Phil - I'll investigate that. One thing I did notice is that, when you open the SHP files in QGIS, the map/layer simply consists of points for the woodland rather than polygons. I suppose the clue is in the filename "tree_pnt.shp". That must make a difference. The roads look pretty much the same as OS but you have two types of SHP for buildings: "building_pnt.shp" and "building_poly.shp". I haven't actually tried the "poly" one yet. I used the same save option in QGIS as for OS - viz the 3rd one. I could try one of the others.

    Thanks to Phil Spit40 , it's now possible to cultivate the UK to a very high standard using Ordnance Survey (OS) data. Full instructions are available in the relevant thread. My attention has recently turned to other countries: is it possible to get the same quality of data elsewhere? One place that interests me is New Zealand. I've never been there myself but I know that it has a good variety of spectacular scenery.


    After a bit of research I discovered that it is possible to download SHP files from the NZ equivalent of the OS. The link below is to the map CG10 (Invercargill, in the south). The download link is at the bottom.


    https://www.linz.govt.nz/land/…hooser/map-chooser---cg10


    The first thing I tried was the most recent version of Phil's instructions, whereby you simply load the SHP files directly into ScenProc. For the NZ data there is a folder "CG10" which seems to have similar contents to the folder called "data" in the case of the Ordnance Survey, so I used that folder in place of "data". Unfortunately it didn't work - ScenProc didn't read anything from the SHP files. (I did change the names of the files BTW. The NZ data uses filenames of the form "tree_pnt.shp" rather than "TQ_Woodland.shp" etc.)


    The next thing I tried was Phil's previous method, whereby you open the SHP files in QGIS and save the "layer" as a KML file. When the SHP files are opened in QGIS the maps have a rather different appearance from that of the OS maps, which did make me wonder whether it would work. And indeed it didn't work - ScenProc read nothing from the KML files either.


    So that's the stage I'm at. The whole thing looks tantalisingly similar to the UK Ordnance Survey situation - and I will defintely keep on trying. I'm far from being an expert or experienced at this sort of thing however, so I may well have made a silly mistake or it could be that I'm simply out of my depth. Anybody else who's interested in NZ might want to run with it and see if they can take it further!