SBX - Hole/Water polys become inverted on BGL export?

[Rotornut44]

Hello,
I have been plugging away with my vector data for the Solomon Islands, however an issue arose today. When I am working in SBuilderX 315, all of my data seems to display correctly. Water is where water should be and holes are assigned where land should be. However, when I compile the BGL for the QMID 7 grid, the data seems to become inverted. Land will display where water should and water where land should. It's almost as if the data has become corrupted upon compile. (Or something, polys, lines, whatever is conflicting?) All holes have been assigned to their correct parent polys. (Unless they somehow became unassigned) I have joined some smaller polys together, but I'm not sure why this would cause an issue. (Plus I have successfully exported other QMIDs where I have used this technique)

I have attached a SBX file containing the data of the problem QMID. If anyone could give it a look-over I would highly appreciate it. I could always sort though SBX's numerous backups, however I would hate to start this lengthy process if there is something simple I can do. Scratch that. It seems that the backups from yesterday have disappeared.. Exported my earliest backup and it seems the issue is still there. I really hope there is a simple fix for this.

(Vector as seen in SBX315)

(Vector as seen in TmfViewer)

Any ideas?

If you still use SBuilderX 313, you can convert the SBX file to work in it by opening it in a text program and changing the copyright line to the appropriate version. (The current .SBX will work in v314 and 315)

 

[Rotornut44]

Just some additional information..
I have discovered that all QMID sections have this issue now. Somehow the save file got jacked up. The only fix I have found so far is to go to every single hole, set it to outer, then reassign it as a hole. When I do this and export the area, the BGL displays as it should.

I exported a before and after SBX file to look for the exact change that fixed the problem. The only thing I could find different was the below set of Childs. (Meaning the holes in the QMID square) Even so, it doesn't look like a major change. The same numbers are defined, they have just been reordered. You wouldn't think this would matter so much..?

(Left=Before / Right=After)

 

[GaryGB]

Hi Chris:

When I attempted to import the attached I got this initial error:

[EDITED]

Proceeding with what was otherwise available to import, a cursory inspection showed all objects that are vector Polygons of type: Shorelines_Generic_Ocean.

[END_EDIT]


Is there additional scenery source files or other content which we should have to inspect the intended full project ?

GaryGB

 

[Rotornut44]

Hi Chris:

When I attempted to import the attached I got this initial error:

View attachment 39020


Proceeding with what was otherwise available to import, all objects are vector Polygons of type: Shorelines_Generic_Ocean.

Is there additional scenery source files or other content which we should have to inspect the intended full project ?

GaryGB

Gary,
That error is just popping up because that is the directory I had assigned for the BGL outputs on my PC. Shouldn't mean anything for you. Just right click the main SBX working window, hit properties, and change the link to your desktop or something.

Most of the shorelines are Generic ocean, yes. There should also be a few generic lake and generic river shorelines. There is no other data. What I gave you is all you should need. All QMIDs do have the same problem (There are multiple, not just that single one) but if we can find a solution for one, it will be the same for the others.

 

[GaryGB]

Hi Chris:

Geographic coordinate sequence (ex: clockwise aka "CW" = N-E-S-W) vs. counter-clockwise (aka "CCW" = N-W-S-E) is sometime referred to as the direction in which vertices "wind" along a poly-line or around a polygon, thus the term "winding direction" is used to identify that property of a vector object.

In GIS applications and in the FS SDK, GIS vector object Geographic coordinate sequence is normally CW, and a CCW ("reverse") Geographic coordinate sequence is used with alternating vector objects for specific purposes.

AFAIK, with FS SDK vector objects, shoreline attributes are created with a CCW ("reverse") Geographic coordinate sequence or 'winding'.

IIRC, in SBuilderX, author Luis Sa' implemented a nomenclature of Parent ('Set as Outer') and Child ('Set as Hole') polygon objects when creating "Holes", and uses a GIS vector object Geographic coordinate sequence of CW, for Parent polygons, and CCW for Child polygons to create holes.

This may have been an attempt to reduce the complexity of the learning curve for end users when they work with vectors.

FYI: SBuilderX can quickly reassign the Geographic coordinate sequence of polygons via a (minimally documented !) method:

SBuilderX Menu > Help > {Search} tab > Keyword to find: "Reverse" > [List Topics] > Working with Points, Lines and Polygons

[SBuilderX315 install path]\Help\SBuilderX313.chm

Set Width

"Vector Lines (roads, shorelines, railroads) have a fixed width in FS that is defined in the terrain.cfg file. You can change the displayed width of these Lines in SBuilderX so that they are easier to see in your project, but this will not change the width of the terrain element in FS. You can also define the width of other types of Lines (for example, textured Lines) - just right-click on the Line segment and select Set Width... from the menu:

You can set the width of the entire Line (constant width) or of the Start and End Points. Be sure to press Set to confirm your changes. You can also reverse the direction of the Line in this dialogue."



Also, with regard to the Geographic coordinate sequence or 'winding' for your vectors, I am wondering if the SBuilderX internal processing of Imported / Appended vector objects may be a consequence of how certain "Join" parameter values are configured in your SBuilderX.INI file.:


Note that one may be at risk of incurring an "Auto Join" of vector objects if their names are identical ex: Shorelines_Generic_Ocean.

This could alter Imported / Appended polygon objects as to their vertex count and Geographic coordinate sequence or 'winding'.


You may wish to explore this possibility further via these references:

SBuilderX Menu > Help > {Search} tab > Keyword to find: "NameJoin" > [List Topics] > Working with Points, Lines and Polygons

[SBuilderX315 install path]\Help\SBuilderX313.chm

Joining Lines and Polygons

"...There are different entries in the SBuilder.ini file related to this function:

1. AutoLinePolyJoin=True -- Lines and Polygons will be automatically joined when they are placed together and one is selected;
2. DisplayJoin=True -- Lines and Polygons will be joined as the display changes( for example, by zooming in or out);
3. NameJoin=True -- Lines and Polygons that have the same name will be joined."


Also see:

http://www.ptsim.com/forum/viewtopic.php?f=22&t=2278

[EDITED]

https://www.google.com/search?ei=Pj...psy-ab..0.12.1174...0j0i22i30k1.0.W75nJT9q9Ek

BTW: The first 3 hits in the Google search above seem to involve some of what you report above.


PS: SBuilder *.SBX 'exchange' files are ASCII text, so a exported *.SBX copied to a *.TXT file as a 'backup' can prevent edits / loss of data.

I am not certain whether there may be a re-coding issue with vectors in SBX315, that impacts vector 'winding' during Imports / Appends.

[END_EDIT]


Hope this info might help in troubleshooting the reported issues above until such time as it is addressed by Luis Sa' and/or rhumbaflappy.

GaryGB

 

[GaryGB]

"Bumped" for edits in my post immediately above:

http://www.fsdeveloper.com/forum/th...ome-inverted-on-bgl-export.441991/post-790479

GaryGB

 

[Luis_Sá]

Hello,

I am sorry if there bugs in SBX315. I could try to debug this problem if you can supply me the minimum possible file/project that presents the problem.

Kind Regards, Luis

 

[Rotornut44]

Hello,

I am sorry if there bugs in SBX315. I could try to debug this problem if you can supply me the minimum possible file/project that presents the problem.

Kind Regards, Luis

Hi Luis.
I have an SBX file you could download in the original post above, if that will work for you? If not just tell me what you need and I will export it. I have a feeling it had something to do with the joining poly's operation.

---

Gary,
Thanks for the above information. We should be OK on the shoreline directions and such. I'm pretty good about flipping those. I do not believe that would play a factor in this bug anyways, as I have accidentally left them reversed numerous times. The only thing that happens is the texture (and wave animations) become reversed in the sim.

Looking in my SBuilderX.ini, I have the following:
AutoLinePolyJoin=False
DisplayJoin=True
NameJoin=False

I don't think there should be a problem there..
I did just happen to think that I may have accidentally tried joining a river poly with the hole of the main island, (thinking the poly edge was the water) however I thought that I had closed without saving when I realized what I did. (to avoid any issues) Maybe I did not? But why would this affect the other islands?

 

[GaryGB]

http://www.fsdeveloper.com/forum/th...ome-inverted-on-bgl-export.441991/post-790495

Gary,
Thanks for the above information. We should be OK on the shoreline directions and such. I'm pretty good about flipping those. I do not believe that would play a factor in this bug anyways, as I have accidentally left them reversed numerous times. The only thing that happens is the texture (and wave animations) become reversed in the sim.

Looking in my SBuilderX.ini, I have the following:
AutoLinePolyJoin=False
DisplayJoin=True
NameJoin=False

I don't think there should be a problem there..
I did just happen to think that I may have accidentally tried joining a river poly with the hole of the main island, (thinking the poly edge was the water) however I thought that I had closed without saving when I realized what I did. (to avoid any issues) Maybe I did not?

But why would this affect the other islands?

Hi Chris:

If you can find an original SBX file, or decompile a compiled CVX vector BGL from the original project (using Patrick Germain's CVXExtractor ...to output a ex: ESRI *.SHP file), you could perhaps compare it to a latter version of your project after Import / Append, to further analyze 'screen' for possible "Join"-induced changes in your vector project scenario by evaluating 'before' and 'after' versions of the vector object counts which we otherwise might have been able to see in:

SBuilderX Menu > File > Properties > {General} tab > Existing Items

http://www.fsdeveloper.com/forum/th...ome-inverted-on-bgl-export.441991/post-790495

But why would this affect the other islands?

Perhaps we may be able to discern a cause for anomalous results reported above, pending further analysis by you, Luis and others.

GaryGB

 

[Rotornut44]

Hi Gary.
I have looked into CVXExtractor. Unfortunately, reverse engineering the BGLs means that they will get split up into QMID 11 squares. This would require a lot of cleanup to get it to the easier to work QMID 7 grid squares.
I'm going to manually fix one of my less populated QMIDs and see if I can intentionally break it to narrow down what may have caused it.

[EDIT]
Just a quick note. I have a few small islands in a lake that are showing as inverted. (Water instead of land) When I set this area (which displays as a hole in SBX) to outer, I noticed that a few other of the smaller islands also change to outer. When I set it back to a hole, those other islands also go back to being holes in the lake poly.
[/EDIT]

 

[rhumbaflappy]

Hi Chris.

I'm guessing your source file was not hand-drawn, but derived from a shapefile that you downloaded.

I suspect that shapefile contained errors, and those were transferred to the SBX file, and reproduced in the shapefile used to make the BGL by SBX15.

I took the shapefile made from your SBX file by SBuilderX and entered it to QGIS.

You can see the obvious errors.

I used QGis' Vector | Geometry Tools | Check Geometries menu item, and selected Polygons, Check for duplicates, and Check for features within other features. Here is the resulting Shapefile:

And this shapefile, when imported to SBX315, compiles just fine.

SBX doesn't check for geometry errors, so a GIS program like QGis can save some headaches. I remember I had some problems with the SWDB waterbody files in the past.

 

[Rotornut44]

Hi Dick.
I'll have to check that out! To answer your question, the base data was downloaded. (SRTM I think? It's been a while..) However, I have been reworking quite a bit of it by hand to make it more accurate. The bug was caused by something gone wrong in SBX though, as I have compiled this data multiple times over the last year or so without any problems. The above problems just started in the last few days.

I'll export a master Shape file and run it through QGis.

 

[Rotornut44]

Dick,
I'm not seeing Check Geometries under that QGis menu. I can only guess that it has changed to Check validity?

[EDIT]
I went back to the website and downloaded your exact version. It looks exactly the same as the version I was using previously, but I wanted to check if anything had changed. I don't see where you did the following: "selected Polygons, Check for duplicates, and Check for features within other features." If I run the check as is, nothing happens.
[/EDIT]

 

[roger-wilco-66]

Hi,

I exported the file in the top post to ESRI shape (actually two exports - lines and polys) and imported them into GlobalMapper. The line file was good, but the poly file was a mess. I'm still trying to sort out what gives.

I think Dick is right with his assessment. I also had problems with importing third party poly shape files in the past.

I'm the creator of Solomon 1943, by the way, and know the area well

Cheers,
Mark

 

[rhumbaflappy]

Hi Chris.

I'll need to see if I have a plugin for that tool. Not at home ...

Edited:

I think this is the plugin:

https://docs.qgis.org/2.14/en/docs/user_manual/plugins/plugins_geometry_checker.html

 

[Rotornut44]

Hi Chris.

I'll need to see if I have a plugin for that tool. Not at home ...

Edited:

I think this is the plugin:

https://docs.qgis.org/2.14/en/docs/user_manual/plugins/plugins_geometry_checker.html

Dick,
I went to the plugins menu of QGIS to search for that plugin and it said it was already installed. I went back to the Vector tab and now there is another Geometry Tools sub tab with a Check Geometries option.. I have no words to explain why this is so.. Maybe the plugin needed to be reminded that it existed? It clearly wasn't there last night though.. I'm messing with the tool as I speak. We'll see what happens.

 

[rhumbaflappy]

Also, check if your elevations for polys are still OK after saving the shapefile. I'm not sure QGis saves elevations.

 

[GaryGB]

Dick:

Thanks for the heads-up on the option to use this "QGIS Geometry Checker plugin" (...I like having more tools for my tool-kit ! )

BTW: Would you please tell us what settings you used in QGIS Geometry Checker plugin for your test with Chris' vector data file ?


PS: It will be interesting to compare the functions and results for the above cited QGIS Geometry Checker plugin ...with what might be achieved via the Global Mapper "Find and Fix Invalid Area Features" option:

http://www.globalmapperforum.com/discussion/11534/automatically-repairing-invalid-polygons

http://www.bluemarblegeo.com/knowledgebase/global-mapper-19/Find_and_Fix_Invalid_Area_Features.htm

http://www.globalmapperforum.com/discussion/7668/find-intersections-of-selected-area-features

https://www.google.com/search?biw=1......0...1c.1.64.psy-ab..0.0.0....0.Q8ndPqIdTGg

https://www.google.com/search?biw=1......0...1c.1.64.psy-ab..0.0.0....0.9Mr0N7fd0fs

GaryGB

 

[Rotornut44]

Also, check if your elevations for polys are still OK after saving the shapefile. I'm not sure QGis saves elevations.

Dick,
I can report that the Geometry Checker plugin did wonders. I did have to run it twice as everything wasn't fixed on the first pass, but it fixed the bulk of the issues. I just had one poly hole that it refused to fix, but I just edited it by hand in SBuilderX. Thank you for bringing that plugin to my attention. It definitely saved the day for me. Altitudes are also unaffected.

For now I need to concentrate on getting everything together to push an update on the 1st, but I still want to figure out exactly what caused all this mess in the first place. I'll try to break it again in the name of debugging. lol

 

[Rotornut44]

Hi,

I exported the file in the top post to ESRI shape (actually two exports - lines and polys) and imported them into GlobalMapper. The line file was good, but the poly file was a mess. I'm still trying to sort out what gives.

I think Dick is right with his assessment. I also had problems with importing third party poly shape files in the past.

I'm the creator of Solomon 1943, by the way, and know the area well

Cheers,
Mark

Hi Mark,
I remember when I first downloaded some data from OSM I had a ton of issues. There is a post floating around here somewhere on it. I wrote that data off as it seemed beyond repair. If I remember correctly, the data I'm using now is from the SRTM. I had to clean up the data a little in Global Mapper, but luckily this is the first issue I have ever had with it. (And it really wasn't the data's fault, but how it was handled)

I remember seeing posts on your Solomon 1943 scenery on Avsim a few months after I started my own project. I must admit, I have never installed it, but it looks very well done and it's definitely on my list of things to install. I just need to figure out which of my warbirds work in P3Dv4.