Posts by turman

    Yes all that discussion can be applied to road networks as well to rail networks, no real difference.

    And yes we have to distinguish two things: the vehicle movement paths and the rendering.

    About the first point I do not see how we could do without importing OSM vector roads if we want to have paths that cover the whole globe (or pretty much as the OSM data are not yet provided everywhere)

    About the rendering the debate seems more complicated.

    I really think that the rendering of orthophotos at very low altitude is a visual disaster, it is necessarily a mess of pixels.

    Trying to land a helicopter on such a surface is often a mystical experience because we're unable to appreciate the exact distance under the helicopter.

    The "vector display" with generic ultra hires textures is necessarily less bad than a porridge of pixels, even if the generic texture does not correspond exactly to the real color (note that we already have "fake" colors on buildings and vegetation with the cultivation).

    As Thomas has said we could imagine a transition from vector display to ortho display depending on the altitude: the switch from vector display to the ortho display would be when the altitude is above 100 meters if the ortho at a resolution of 0.5m/pixel, 200 meters if 1m/pixel, etc.

    For me it would be a huge improvement in AFS.

    If I have well understood the Life project from Jeff the path of vehicles movement can only be created manually under 3DS Max for now. It is the manual side that bothers me (in addition to the license of the proprietary 3D software). In the long run, could these paths be created automatically, for example from the OSM route network?

    Personally I would dream to have "vector" routes in AFS but unfortunately I do not think that is the idea of IPACS, right ?

    It is true that orthophotos are nicer but only at high altitude. At low altitude (especially for helicopter pilots) it is generally ugly, even with a resolution of 50 cm / pixel. Whereas with vectorial routes we could have generic textures of very high definitions for asphalt on every road around the world (and not only on some detailled aiport area). In addition to having a path network directly exploitable to move land vehicles.

    The ideal would be to have the best of both worlds:

    - low altitude: use of vector roads with generic UHD textures

    - high altitude: use of bitmap roads (orthophotos) only

    The complexity would be to have a transition effect as smooth as possible when switching from one to the other. But that could be done with transparency.

    Hello Rich,

    Thanks a lot, that was exactly what I was looking for !

    I've completely missed this SubtractFeatures statement. I'll test it tonight or tomorow as I'm in office today.

    It should also help to avoid trees on roads, and trees too closed to buildings (like in the scenProc guide example with the 1.5 ratio).

    Many thanks ! :)

    Yes Thomas it is true that I can eliminate the trees manually with AFS2 Scenery Editor. But this would be the last resort because it will be a boring task and it's like I have to redo a job which is already done since I've already manually defined the rocky areas in OSM (which is good because it can be useful for other people and for other contexts than AFS scenery creation).

    I guess I could also use masks based on KML files in scenProc but again it would require duplicate work and it would not be generic.

    So if possible I would like to find a solution that is automatic and generic because I think that the problem itself is very generic (there are often forests in OSM that cover non-forest parts).

    AddAttributeIfInside should really help, I guess it was created for that ...

    While waiting for Arno's return to answer my questions about building creation I would like to know if anyone has ever managed to exclude trees based on natural areas.

    In my living are there are beautiful mountains (well, they should be considered as hills as they barely exceeds 600m), it's called le Massif de l'Estérel. They have some rocks with a very typical orange color:

    The problem is that on OSM the whole area is covered by a forest polygon (landuse = forest) so all the area is populated with trees preveting to see the rocks with real color.

    What I want to do is to exclude tree generation of the area with rocks. It should increase a lot the realism the scenery.

    For that I have created a lof of polygons on OSM with the tag natural=bare_rock (you can see an example here: but now I'm unable to configure scenProc in order to take them into account.

    I've tried to add And NOT natural="bare_rock" for the tree generation of forest:

    1. PlacePointsInPolygon|landuse="forest" And NOT natural="bare_rock"|0.00020;0.00020|1.0;1.0|INHERITPARENTATTR

    But I think it makes non sense because it should only exclude trees on OSM ways which have both landuse="forest" AND natural="bare_rock".

    I imagine that AddAttributeIfInside should my friend but adding the following declaration doesn't help:

    1. AddAttributeIfInside|FTYPE="POINT" And natural="bare_rock"|FROMFILE="*.kml"|String;skip|yes

    Any suggestion ?

    Thanks, Vincent.


    This morning i tried to create the level 15 tiles for the tiles I already created in the last two days for level 9, 11,12,13,14. Unfortunately even having checked only AFSlevel 15, i creates the whole level 9 - 14 again. It ignores level 15.

    Maybe you have unselected the TMC generation step ? (je me suis déjà fait avoir avec ça ;p)

    Thanks Dave ! :thumbup:

    if I try to resume my questions / suggestions:

    - a bug with buildings generated on playgrounds (leisure=pitch) ?

    - a plan to have "generic" buildings (for any footprint and any height) in the future ?

    - a mode that would prevent scenProc from working twice on the same OSM building which could simplify the rules (no need to add the conditions "And Not X=Y") ?

    I have others about vegetation but I'll launch a separate thread for that..

    So we have to wait a little bit I guess...

    About the exclusion there is actually that line in the template file which prevents to have buildings inside aerodrome:

    1. # FILTER out buildings
    2. # The line below automatically removes buildings within your airport area for the majority of airports worldwide.
    3. AddAttributeIfInside|building="*"|aeroway="aerodrome"|String;skip|yes
    4. # The line below removes buildings that are in the area covered by your exclude file. This should only be needed
    5. # if you want to exclude buildings outside an airport area.
    6. AddAttributeIfInside|building="*"|FROMFILE="*.kml"|String;skip|yes

    So if the aerodrome polygon is well defined in OSM there shouldn't be any problem.

    To check it you can edit OSM data with an editor or more simply you can do it from the interface: just click on the button with "?" on the right, and then click on place (anywhere!) in the aerodrome. Select the aerodrome in the item list => its outine is displayed !

    You are so right with your findings!

    Maybe sending a copy of this to arnog s blog directly?…in-scenproc.441173/page-7

    You're right Tom, as I'm not sure that Arno will pass on the Aerofly forum in a near future I have tried ton contact him via But I'm unable to register, no confirmation mail received. If you or other people having an account on his forum could notice him of that thread it would be great !

    It would be a shame to let him go on vacation while we have plenty of work to give to him for working on AFS! ^^

    Apparently it's already the case, see the comment in the template file from Crispy:


    # LOAD SHAPEFILE that will be excluded from processing.

    # - By default this script loads all .kml exclude files in the folder. If you only want specific files, then use

    # the filename in place of "*.kml", You may also need to do the same for any of the "AddAttributeIfInside"

    # lines you are using in the FILTER section below.

    # - Buildings in airport areas are now automatically excluded, so no exclude file is required for these.

    I'd have another suggestion for scenProc (maybe it already exists): it could be usefull if users can define a list of OSM features that must be excluded from the building generation. That way there is no need anymore to make some KML exclusions for all the implementations of that feature ! For example if I want to generate storage tanks with ObjectGen I could add the man_made='storage_tank' feature into that list.

    Thanks for the tip, it's very clever !

    We can have fun working on our local OSM file and then give it to ObjectGen. There are some much things than we can add with all these great tools :)

    Ooh that's alot of boats! That looks like the job of ObjectGen.

    Hi Jake,

    Just for my curiosity: how coud you do that with ObjectGen ?

    For me ObjectGen can generate objects from OSM features only, but obviously these boats do not exist in the OSM DB. So I'm confused...

    Thanks, Vincent.

    Initially it activates the display of locations (the name of cities for example) but when it's used with the developer camera it also allows to turn the camera around a fixed point, very nice !

    Oops sorry I didn't know why I didn't see it but yes there is the backward and forward options in Controllers > Views, sorry for the noise... but at least I've learned the "L" tip when the developer camera is used !