Posts by Rodeo


    please check my included PDF file to find a description and all the links you need.

    A short description of this workflow:

    Start the nationalmap viewer and define your area.

    Search for imagery NAIP and save the list as a text file.

    Load this textfile as batch into the USGS uget download manager to download the jp2 images.

    Copy the text file and modify the content to download also the related XML files with uget.

    Convert the jp2 to TIF.

    Use aid_create to create the coordinate files for aerofly.

    Run geoconvert.

    Ok, I know, doesn't sound like an easy workflow for everybody. ;)

    This might be the reason, we don't have more USGS coverage.

    But I hope for Nick Hods great aeroscenery tool to work on USGS data as well some time. :)


    Btw, screenshots of your missions in WaN are very welcome. :)


    Ok, got your workflow.

    I do no longer use OSM buildings, I completely rely on the USBuildingFootprints.

    I have a workflow to extract the desired area from the Microsoft data and process them with scenProc.


    Yeah, would be good to have a kind of attribute for scenProc. I think about a polygon around areas with a certain building density, like the city borders. So we could add a value to the streetlines, like 'in locality/outside locality'.


    I'm afraid this will not happen. Think about the enormous dimension of the USA and about the possibility, that aerofly will never cover the entire USA in a higher ground level resolution. We'll have to live with different approaches, but this makes it even interesting. :)



    thanks for addressing this topic.

    I completely agree with you and find a continuous lighting of all streets very disturbing.

    But as you mentioned, changing this means a lot of manual work.

    My current workflow:

    1. Download a certain area from

    2. Open this file with JOSM

    3. Delete just all content between populated areas.

    4. Run scenProc on the remaining streets in cities and towns.

    I don't have separate light spots with this method, but the houses have a slight night lighting texture.

    If someone has a less time consuming workflow, feel free to publish it. ;)


    using free USGS images there is an area of about 450 x 150 sqkm available. Location is Washington North with a basic scenery level of 9 and 11.

    Currently you can find 2 airport packages, starring KOMK Omak and Whidbey Island with 4 airports at levels 12-14.

    Building cultivation has been done up with Microsoft's USBuildingFootprints, with scenProc some hundred thousand trees could be planted.

    Hope you like it.


    WaN: basic scenery files

    WaN: Omak

    WaN: Whidbey Island

    WaN: Lake Chelan Airport

    Hi Republic DC-9,

    sorry to say, but your data are full of mistakes. ;)

    1. Your coordinates are swapped, so we're somewhere in China.
    Please follow lonlat definition.

    Additionally for USA a minus has to be added going to the west from Greenwich, UK.

    Example -117.86822 33.67566

    2. You added the dummy runway, but you did not define this scenery object in the .tsc

    3. You define the scenery_cultivation ksna_1, but in your thread text you name it ktsc_1 -> will not work

    4. You repeat the scenery cultivation file 3 more times, why?

    5. It's hard to read the text file format. Either use the forum function code or attach the TSC as a TXT file to the thread.

    I have edited a file, without testing it, but it eliminates the errors above. Just rename the TXT to TSC.

    Go on with your work, but go thorougly through the TSC. ;)



    • ktsc_1.txt

      (1.61 kB, downloaded 11 times, last: )

    As far as I can tell, the MS data already has height information for each building....

    Really? That would be fantastic. Perhaps the datasets I used lost their attributes during previous splitting processes.

    But I just opened Microsoft Hawaii.json, these are the first lines:






    Unfortunately no height information in the complete file. But maybe there are other databases to be combined with the buildings.


    no, not in this small scale. I suppose the osm buildings shown in the example have been digitized from a slightly misaligned aerial image.

    In other areas the buildings fit very well. See the school building in the image before.


    there exist areas in the USA, where literally no buildings show up in the OSM data.

    Fortunately Microsoft published building footprints for the whole contry.

    US Building Footprints

    Microsoft's files by state are way too large for most systems to process.
    I did find some data splitted by US Census tract boundaries. These files can be handled by most GIS software. See the different colors representing census tract areas.

    Merging them with OSM data reveals the dramatic increase of buildings.

    Pure OSM:

    OSM with US building footprints:

    Another example:

    There is some overlay and even some inaccuracy of the buildings.

    But for our purpose the inaccuracy is negligible.

    I assume, best way is to remove all OSM buildings and keep the Microsoft buildings.

    But next, we have to mass modify the attributes of these buildings.

    Currently I work on the whole process manually, but it would be a significant improvement to find a good workflow.

    What do you think about it?



    I'm wondering how many times we will ask and how many different answers we will get.

    The answer I documented above is from the BING Maps License Manager and definitely not "the neighbor who knows the baker...." :rolleyes:

    Nethertheless his answer was surprisingly positive, but really nobody knows whether we can rely on this statement.

    Hi Ray,

    Whidbey, Lake Chelan, Venice.... they are all done to a certain level but need fine tuning which is more time consuming than the rest.

    But during the summer time I'm more on the model flying field andrepairing my rc models than working on the pc.

    Nethertheless winter will come... ;)

    See you