Posts by turman

    Bonjour Michel,


    Je n'ai pas encore eu le temps de regarder les scripts V7 de Crispy mais normalement tu dois pouvoir changer le nombre d'étages pour les maisons (lorsque celles ci n'ont pas de hauteur définie dans OSM) avec une plage de 1 à 3 par ex au lieu de 3 à 4. Dans le script V6 la détection des maisonsse se basait sur la surface du bâtiments, du coup cela ne marchait pas forcément avec les villas de milliardaires dont la surface pouvaient être trop grande. Mais c'est étrange car là tu parlais de l'ensemble des maisons et pas juste de quelques cas isolés...


    Mis à part la hauteur des bâtiments c'est vrai que ça serait super d'avoir des textures adaptées à la région, surtout pour la couleur des toits...

    Wouahou Paris in AFS ! 8|


    This is an impressive work, thanks a lot ! :thumbup:


    I am particularly sensitive because I am from Paris and I spent the first 30 years of my life in that city.


    And also because I had done a lot of work on OSM to import the height of the Parisian buildings. I had managed to update the height on more than half of the buildings in Paris (itself, not the suburbs): 49,000 out of a total of 86,000 buildings (more info here). When I have time I will have fun comparing what we can see in AFS with what we can see on F4Map (an OSM 3D viewer):

    I tried to have a look at the sport field/pool issue, so I downloaded one of the areas you mentioned. But I can't reproduce the issue. Also without seeing your entire script it is hard to see what is going on. Might be one filter is missing a condition which causes them to be included.

    Sorry for my very late response, real life constraints prevented me from playing with AFS :(


    I've tried the Crispy's technics to get some infos (ExportOGR|osm_way_id=XXX) but the log files were almost the same, no real difference (tags are sorted differently).


    Anyway I found the guilty command by feeding scenProc with an OSM file which contains only one element (a swimming pool). Then I run the script and saw in the logs the exact command which was generating a building and it was:

    Code
    1. CreateAF2Building|NOT building ="roof" And FAREARAT>0.7 And NOT building_levels="*" And NOT height="*" And FAREA>=200 And FAREA<700|2;3|1|gable|residential|0


    This is a stupid command because the conditions are too permissive. In fact I was thinking that only building elements was taken into account by CreateAF2Building. But apparently it's not the case so if there is a NOT building ="roof" condition there must be another condition with building_levels or height, which was not the case in my command.


    So the problem was in scenProc but in my brain ;)


    Now I have to find time to play with the Crispy's V7 scripts and the latest release of scenProc.

    Peut-être dù aux données OSM mais le script version7 me donne une forêt très dense en arbres sur une zone avec végétation de zone humide et très basse ...! inacceptable, et la forêt déborde sur l'étang marin voisin.


    Par contre la version 6 n'affiche aucun arbre !

    Désolé d'être un peu maniaque mais à la base ce thread est dédié à la création de bâtiments ;)


    Pour la création de végétation je vous propose de continuer sur ce fil pour ne pas mélanger tous les sujets: Vegetation creation with scenProc

    Thanks a lot Arno, that looks perfect !


    And thanks also Chris for all your explanations :thumbup:


    I can not wait to get access to my computer so I can test all this stuff..


    Arno : are you able to reproduce my bug on swimming pools and playgrounds ?

    Guys, rather than rework everything (which might confuse some) I feel that we should keep things the same for now. In order to change the forum structure we would have to move a ton of posts around so that it makes sense.

    Personnaly I don't think it's not a big deal if there are some old posts wichh are not well organized (many are already).


    The main thing is to have a better organization for the future, especially considering that the Aerofly forum is expanding.


    What about leaving all posts where they are, but rename the conversion to


    - Developer discussions ( GeoConversion and Scenery )


    So at least future posts will find its correct way.

    Badly there are also tons of threads in the the Developer discussions ( General and aircraft) which are related to sceneries.

    Hello IPACS,


    Currently the AFS2 forum is subdivided into 3 sub-forums:

    - General discussions

    - Developer discussions ( General and aircraft)

    - Developer discussions ( GeoConvert SDK tool )


    But the separation between the 2 development forums is extremely confusing.


    In the one for GeoConverter a lot of threads have nothing to do with GeoConverter (talks about cultivation, scenProc, 3D models, etc.)


    Would not it be simpler and clearer to have:

    - General discussions

    - Developer discussions (aircrafts)

    - Developer discussions (sceneries)

    Sorry Chris but I'm not sure to understand very well as I don't know which bug you're talking about. But in fact my questions was about the "new feature" that we can see of your last screenshot in NewOrleans.


    Normally scenProc is unable to generate buildings if the footprint is exotic and not rectangular. That's why there is the FAREARAT>0.7 condition in order to skip non rectangular buildings.


    But in your screenshot I'm glad to see you've managed to handle a non rectangular building with 3 rectangular "sub buildings". It's not as pretty as "generic buildings" (like in X-Plane / W2XP, sorry for the comparison) but it's much better than nothing, or than an unique rectangular building !

    Hello Chris,


    Thanks a lot for your work on scenProc template files !

    Version 7 will deliver also some improved structure construction methods and a number of other improvements. Here is a little sample showing one of the building enhancements, showing a ferry terminal in New Orleans.

    This is very interesting.


    Is that "feature" due to your changes in your new template file or is it due to the latest version of scenProc ?


    In that another thread I am currently discussing the possibility of having "generic buildings", ie. buildings that correspond roughly to the real footprint (well the footprint which is defined in OSM) and with the correct height/floors of course.

    I understand what you mean with the duplication of the lines. That's not very elegant indeed. Let me think a bit about it, but the only way I see to prevent that is to modify the CreateAF2Building step so that you can specify a level attribute, height attribute and fallback level value in case no attribute exists. But that would make the step a bit more complex to use for some people as well. So let me think about that.tes value in there.

    Yes that's would a good thing to add a new attribute in CreateAF2Building for the height, in addition to the level. I don't think it would make the process more complex if the fallback is well explained.


    In fact we could imagine a "one line" solution with two fallbacks for both levels and height: if (height value exists) use it else if (levels value exists) use it else use the hardcoded value (or hardcoded values range).


    That way we could divide by 3 the number of lines for the creation of buildings (or by 2 for those which take into account only the number of floors). I think it's really worth it!


    Making scenProc only process each feature once does not fit in the concept of how scenProc works. So that will not happen.

    Ok.


    For the "generic buildings" my impression is that AF2 doesn't support them (like FSX/P3D don't). It is only possible to specify rectangular buildings in the TOC file. So that's why i can't export other shapes. Or do you see options for that?

    No sorry I don't know any options. In fact I did not even know that we could only define rectangular buildings in AFS2.


    It should have confirmation from IPACS. Perhaps it's a voluntary choice for performance reasons?


    That said if we look at some commercial sceneries from IPACS or ORBX we can obviously see non-rectangular buildings. But maybe in this case it does not go through TOC files, I admit that I have not dug the subject at all ...


    Do you see that swimming pool issue everywhere or just with some swimming pools? If I know a location where it happens I might be able to reproduce it here.

    I'm not sure it concerns all the swimming pools but most of them.


    Right now I don't have access to my PC with AFS but I'm pretty sure it's the case for theses ones:

    https://www.openstreetmap.org/way/230758739

    https://www.openstreetmap.org/way/69789322


    But note that it doesn't concern swimming pools only but most of sports playgrounds too !

    For example this tennis court: https://www.openstreetmap.org/way/554017742

    Or this beach volley pitch: https://www.openstreetmap.org/way/330042924


    For me it's a major issue and I am really surprised that the problem has not already been notified. Maybe the bug is local to my system. For now I cannot tell you the exact version of scenProc I used but it was a dev version fetched in the begin of the summer.

    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: https://www.openstreetmap.org/#map=14/43.5072/6.8828) 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:

    Code
    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:

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

    Any suggestion ?


    Thanks, Vincent.

    Hi


    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:

    Code
    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 www.openstreetmap.org 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 !