Posts by turman

    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.

    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 !

    Hi turman,

    I'm pretty sure I came across a discussion on another forum about this subject of a script to import the heights of OSM data buildings about the city of Nice. It was a few years ago and it was in French if I remember correctly.

    It must be a discussion with me because I had actually discussed this a lot on the french OSM forums or mailing list in summer 2016. Internet is a small village ! ;)

    Here are some screenshots showing the results.

    Nice:

    Montpellier:

    Paris (but in that case it was a very different process because the height infos was already available as open data):


    The above screenshot are taken from https://demo.f4map.com which is for me the best way to visualize OSM buildings in 3D. Off course there's no details and textures but the footprints and heights are fully respected. I'd love to have the same thing in AFS !

    First I want to congratulate Arno the author of scenProc for his powerfull tool. And thanks him to have extended it with AFS features knowing it was initialy a tool focused on FSX/P3D.

    I am particularly attached to the building generation because it is for me a crucial point to be able to generate realistic scenes.

    And in th generation of buildings an essential point is to be able to have the heights of buildings closest to reality.

    That is why some time ago I put a lot of effort in the information of the heights of buildings in OSM. At the time, I developed scritps allowing the automatic import of these data into OSM. My scripts were based on DEM + DSM sources available in open data and by doing the subtraction I managed to determine a maximum height for each building already imported into OSM (thanks to the cadastre). There were some difficulties to manage like trees or antennae that had to be ignored to not have false values. But in the end it worked pretty well and I managed to inform the heights for all the buildings of the cities of Nice and Montpellier in France. I had also done a script that had allowed me to fill the height on almost half of the Parisian buildings, in this case it was the number of floors and not the height that I filled.

    The good news is that sceneProc is able to handle the height attribute in addition to the building: levels attribute by using a scale ratio of 0.3 (assuming that a floor is about 3 meters high).

    On the other hand, it implies having to split all the building rules in sceneProc. There is already a doubling of rules to manage the existence or not of the attribute building: levels, but we must add another one to also manage the existence or not of the attribute height.

    If we consider the following rule:

    Code
    CreateAF2Building | building = "apartments" And FAREARAT> 0.7 And FAREA> = 700 | building_levels | 1 | gable | residential | 0

    It becomes:

    Code
    CreateAF2Building | building = "apartments" And FAREARAT> 0.7 And building_levels = "*" And FAREA> = 700 | building_levels | 1 | gable | residential | 0
    CreateAF2Building | building = "apartments" And FAREARAT> 0.7 And NOT building_levels = "*" And height = "*" And FAREA> = 700 | height | 0.3 | gable | residential | 0
    CreateAF2Building | building = "apartments" And FAREARAT> 0.7 And NOT building_levels = "*" And NOT height = "*" And FAREA> = 700 | 3; 6 | 1 | gable | residential | 0

    But at the end it makes a lot of rules and it's not very readable. Would not there be a better way?

    Also if sceneProc could have a mode that would prevent it from working twice on the same OSM entity it would also simplify the rules (no need to add the conditions "And Not XXX").

    Another question if Arno read that thread: no plan to support "generic" buildings ? By generic I mean buildings which can adapt to any footprint and any height. Of course this is not a trivial point and it will be difficult to have buildings as pretty as those that are "pre-calculated" but at least we would have all buildings that exist in AFS even when their shape / footprint is not standard (ie. rectangular). So we could have in our AFS sceneries ALL the buildings that exist in the real world (well, in OSM) and with the correct shape and correct height! But currently a lot of them are ignored because they have a non rectangular footprint (I guess that most of us use the FAREARAT>0.7 condition).

    Otherwise I noticed a strange behavior: the swimming pools in OSM generate buildings ! The pools have nothing to do with the buildings (there is just leisure = swimming_pool, no building tag) so it really looks like a bug.


    Otherwise I noticed a strange behavior: the swimming pools in OSM generate buildings ! The pools have nothing to do with the buildings (there is just leisure = swimming_pool, no building tag) so it really looks like a bug.

    I can see the same issue with playgrounds (leisure=pitch) but only for certain sports such as tennis or beach volley (not for other such as football, athletics..)

    This is not exactly what I was looking for but it's a nice workaround, thanks Rodeo !


    But do we agree there is no "forward" or "backward" actions in Controls > View settings so it's not possible (at least from the UI) to assign keys for these movements ?

    Sorry but I haven't found any "forward" or "backward" actions it in the Controls > View settings, I guess they should be here ? For me these 2 movements are specific to the developer camera.

    And about the "strafing", is it something that we could hope to have in a next release ? I allow myself to insist because I don't think it's something complicated to add while it would make navigation in AFS world much more easier (with the strafing you can turn around a point / object while keeping it in the center of his field of vision).

    Is it possible to customize them in the conf file ? I'd like to assign other keys for the forward and backward movement (currently it is "w" and "s" by default which is not natural at all with AZERTY keyboard).

    And it would be SO COOL if we can "strafe" (ie. sideways movement) with the developer camera. That way we could navigate in the AFS world like in a FPS ! :thumbup:

    Yes it's true I'll try it on my SSD this WE, I need some cleanup before...

    But listent that, yesterday I was out of my home and with my laptop only, not my desktop where I use AFS. It's a very recent laptop under Linux but I have a Windows 10 partition that I never use (no AFS2 installed) so I've installed the AFS SDK and AereoScenery. It's a totally fresh install on another hardware and guess what, I got exactly the same slowness !!! It is just amazing ! 8|

    My TPS (tile per second ;p) is still around 0.5, so only ~30 tiles per minute.

    I guess that on a normal installation it must be something around ~10 tps, right ?

    Antoine: it's right you wrote a gorgeous section about slighty grids ! But if the "write image with mask" option is set to false then the "Shrink TMC grid squares" option in AeroScenery has non sense, am I correct ?


    The problem was the skrink option issue in AeroScenery. I guess I have relaunched only the geoconvert step after having fixed the value (in Windows regional settings) so the TMC had not been regenerated with correct coordinates. And it was normal that my geoconversion was so slow because 1 degree means tens of kilometers so at the end I had "reverse coordinates" of huge surface of 1*1 degree. Even if I was a building a single grid square of size 12, more 700 tiles was generated for level 12 and more than 40 000 tiles for the level 15 ! Now it's only 2 for level 12 and 48 for level 15, so it takes slightly less time ;)

    Good to know !

    But I'm now pretty sure that my slowness doesn't come from that setting. I mean it could help to have a faster generation but not x10 or x20, right ?

    I have 2 other small questions:

    - I'd like to apply the Antoine's hint but I don't see the "always overwrite" option in Aeroscenery > Settings > Geoconvert, is it in your todo list Nick ? ;)

    - Even if I check only AFS Level 12 in Aeroscenery, Geoconvert starts at level 14 and then do the level 15.

    Thank you, now I've understood the meaning of that option which allows to not build useless nearby tiles.

    Effectively my settings was set to 1. After having changed my Windows regional settings I can now set 0.1 or 0.001 values but... the result is the same, I cannot see any visible gain !

    I've also tried other Geoconvert options ("not write images with mask" and "use geoconvert wrapper") but without any success...

    Geoconvert still continues to generate only ~30 tiles per minutes :(

    Note that the generation is not very smooth: 2 tiles are generated, 4s of delay, 2 tiles are generated, 4s of delay, etc.

    Yes but as I fly only with helicopters (at very low altitude) I really want ZL18 ;)

    So I need to generate AFS levels from 12 (?) to 15.

    And thanks Nick, it's clearer now. I guess my Windows has the french settings with comma as decimal separator so the 0 value should help me until your next release. Results tonight if I have time...

    But could you please explain a bit what that option means exactly ? Why 0.01 could be the optimal setting ?