OPEN BETA/COMMUNITY PROJECT: OSM World

[Luis Hernandez 571]

A quick analysis shows some geometry errors in the VTPP landuse files... these are generally corrected easily by moving points that are "kissing" the LOD8 borders a tad away from the border...

 

Now I'm lost here....

 

What texture did you use for universities and parks? note that national parks may be very varied in nature (woods, mountains, deserts, swaps...) and since sometimes these appear to cover massive areas the result may be a giant single-texture region...

 

For parks, I used texture 134 (parks); golf courses, 135 (obviously); and for universities, that was tough: after comparing all FS9 texture types in Sbuilder with aerial views of universities, I had to settle with texture type 106.

 

Now, when I speak of parks, I'm not meaning national parks but city parks such as Central Park in NY and smaller ones. What I did was, from both the Natural and POI shapefiles (I obtained then at OSM X-tractor), I filtered them and checked for size at QGIS. For the Natural shapefile, my filter was "natural"='park', while for the POI I used "amenity"='park' and "leisure"='park'. In the afternoon I'll be uploading the QGIS file so you can see what I mean.

[Mariopilot 9]

You filtered them by size... excellent!

What I mean by geometry defect is that occasionally a LOD8 square is erroneusly entirely cobvered by a bogus SBuilder-invented square polygon. This is due to polygons meeting very precise and unfortunate conditions. You can check this via LWMViewer (although making a huge file for the whole area makes investigating them slower...). For land-use polygons these cover a whole LOD8 area making them generally easy to spot and way less common than LWM where they are per LOD-13 area and far more common. There is a chapter in the how-to guide on how to fix these errors. For the land-use part it only invilves getting an offending vertex out of the LOD8 border a tad. If you can not figure this out, just upload the SBP (Sbuilder Project) files and I wil lfix them. I am currently working on coastlines and I'm about 1/6 done. These involve a lot of fixing geometry errors of this kind...

[Mariopilot 9]

 

 

For parks, I used texture 134 (parks); golf courses, 135 (obviously); and for universities, that was tough: after comparing all FS9 texture types in Sbuilder with aerial views of universities, I had to settle with texture type 106.

 

Luis, What VTP layer you added the landuse polys to? they appear to run over airport skirting polys!

Also, If you do not know how to fix the geometry artyefacts (SBuilder bug)  you can send m3e the SBuilder files and I'll do it for you

[Luis Hernandez 571]

I used layer 4, as instructed by the DevKit. I'll read this for checking and fixing the artifacts. Does this only happen with polys, or also with lines?

[ematheson 19]

Perhaps the airport polys are wrong...

But also relevant: airport polys are "assembled" classes, whereas your landuse polys are defined classes. In FS9, defined vtp classes always override assembled classes, regardless of what layer they are defined in... This happens for polys and lines, both.

[Mariopilot 9]

Copy that Ematheson! Thanks a lot you learn something new every day!

 

Luis, these errors occur only with polygons. Lines may occasionally crash SBuilder and there is a troubleshoot procedure but it is a rare happening! When it comes to land-use polygons, the geometry errors are usually just limited to a point you need to move away from the LOD8 cell border. Also, they are very sparse compared to the hellish nightmare that is fixing up LWM...

You can easily spot them via LWMViewer 1. Just turn grid on in both LWMViewer and SBuilder.

 

 

Interesting there... lines go over airport polys and I was just happy with that... roads leading straight into the terminal! Never encountered a plygon invading an airport until I flew around a small tiny airfield in peru... it is just a corner, and since we will anyway implement the exclude rectangles to kill objects close to airports for safety reasons, we may just not worry... the poly will stay, but no objects inside... anyway they get auto-excluded by the airport polygons themselves!(or we could perform a subtraction operation with the airport polys (that can be imported into SBuilder, exported as BLN, and converted to shapefile with SCenProc or SBuilderX...) but it is probably just not worth it

[Mariopilot 9]

On further investigation, I found an airport entirely surrounded in a Landuse polygon (SPLP). since we want to avoid considering holes ("rings") in the landuse polygon geometries for simplicity, I will opt for a layer4 VTP exclude technique. This was tested previously to exclude VTP items from invading airports, but was later replaced by object excludes to let roads come into terminals... We will have to utilize this but only removing layer 4 this time. Will report back on the results...

[Mariopilot 9]

So something is off with the command prompt... do you have windows 8 by chance? It seems this happens in Windows 8 for reasons i can not determine (I bdo not have any Win 8 system available)

 

For it to work you need to move the scenery areas as low as possible, but above "default scenery" in order. If you place it on top of other scenery, trouble is guaranteed!

This is how the scenery areas look in the FS menu:

 

 

since the .BAT& did not work, also create a folder called EURW Backup. Inside there you need to move the following files located in Scenery/Eurw/Scenery (MOVE, not copy. You can then re-activate the if you wish to remove OSM world Europe from your FS9). asterisk means "any file starting with" in its name:

• BR9EURW*.bgl
• HP*.bgl
• HL*.bgl
• RD*.bgl
• RR*.bgl
• ST*.bgl
• UT*.bgl

Let me know if this helps!

[Mariopilot 9]

Hi!

I suspect FlyTampa Vienna may be adding things to default scenery location. The "Core" section tries to exclude everything from airport areas so that no light poles/autogen objects invade airports (the new detailed roads may place light poles in very uncomfortable places like across runways...). You may want to try and remove "EURW_libobj_excl.bgl form the core section. attempt leaving the land class mask file, it will avoid water filled areas in the new coastlines...

 

The scenery is in the process of expansion, next releases will be south America and Oceania (although the guy working on Oceania has not shown up for a while...). hopefully one day it will be worldwide!

[sascha 314]

Great show! I'll jump in when South America and Asia are on. I also wish the roads were a bit smaller - is it possible to globally reduce all roads width by about 15%?

 

Cheers,

Sascha

[Mariopilot 9]

South America has smaller orads already, and land cover data is a bit more varied (city parks, univerisity campuses...)... perhaps I will reduce width in Western Europe after I'm done with south America, that is about 60% done maybe... About Asia I do not know, it is just so vast it scares me to death... I need more people in for that!

[sascha 314]

perhaps I will reduce width in Western Europe after I'm done with south America, that is about 60% done maybe...

 

You would make at least one person (me) very happy with this :wub:

 

Cheers,

Sascha

[Mariopilot 9]

A few days ago we were discussing land-use polygons overlapping airport polys. As I had an airport with its base polygon completely gone, I figured it must have been OSM South America at fault. Nope! OSM polys may overlap airports, but as far as I can see they tend to just cut on corners, generally with a small service road separating the two areas (it looks great! It is supposed to be like that in reality). My problem was related to a Lima airport scenery adding a humongous VTP polygon for the whole city... BAD idea... Removing it sorted it out... so OSM land use polys will stay as-is ...

[Luis Hernandez 571]

Mario, I apologize for not having answered regarding the South American land polys. Real life issues, you know. What do you mean with your latest post?

[Mariopilot 9]

No worries! of course Christmas vacations are busy family time!

 

hat do you mean with your latest post?

 

 

I do not know what you mean, by this... we left where we needed to check the VTP polys for Sbuilder generated errors...the process involving inspection of the files via LWMViewer...