P3D v5 Can scenProc detect round polygons?

[Clutch Cargo]

Seeking a way to create storage tanks automatically. MS footprints show round polys but contain no "Types" or "values" to pull out these type of polys. OSM does have a category for these but are sparsely ever populated, at least hear in the USA. I came across one thread on the subject here in the forums however the value data was provided ( and Arno added a new option to include scaling which is nice).

So I was hoping I could add an attribute if scenProc comes across a round poly... any possible way? thx

 

[arno]

Hi,

At the moment scenProc does not have special logic for this, but I think it might be a good idea to add something for it. Something along similar lines as the FAREARAT attribute, which compares the area with the bounding rectangle. If instead the area would be compared with the area of the bounding circle I think circular features can be filtered out.

 

[Clutch Cargo]

As a follow-up, researching an old post I found here in the forums, I was able to create storage tanks with the following code:

ImportOGR|B:\CA Data\OSM Data 2023\socal-latest.osm|*|building|NOREPROJ

SplitGrid|AGN|*|building="*"

PolygonToPoint|building="*" And man_made="storage_tank"|CENTER|0.0;0.0|0.0;0.0|String;Type|storage_tank|hdg

PointToPolygon|Type="storage_tank"|25;25|hdg|String;Type|storage_tank

CreateAGNLibObject|Type="storage_tank"|{32f3ed34-c508-44c7-b1fe-d9343c68f17b}

ExportAGN|P3D v4|B:\Storage Tanks test\texture

They look good, however some are too big. Which leads me to the next couple of questions:

Question 1 - Arno, It appears back in that old post

(https://www.fsdeveloper.com/forum/threads/creating-storage-tanks-circular-objects.447766/),

you added coding to automatically scale the object… I take it to match the size of the polygon? Did you complete that?

Question 2 – If yes, do I need to use CreateXMLLibObj in order to have the scale adjusted automatically? Not sure how I would create the step?

Question 3 – Would it be possible to have a scenProc step something to the effect of “If radius is >XX meters then use GUID {}” OR if <XX meters use GUID {}, this way to use a selection of different storage tanks?

Question 4 – The .osm files are HUGE! Do you by chance have a tool to break down the osm file into smaller files, like you did with your json splitter?

Hope you had a nice holiday! Oh... your back!

 

[arno]

As a follow-up, researching an old post I found here in the forums, I was able to create storage tanks with the following code:

If the features have attributes that define they are tanks it is easy indeed. I thought you also wanted to detect those that do not have such an attribute.

Question 1 - Arno, It appears back in that old post

(https://www.fsdeveloper.com/forum/threads/creating-storage-tanks-circular-objects.447766/),

you added coding to automatically scale the object… I take it to match the size of the polygon? Did you complete that?

Yes, there is a sample in that same thread. But it only refers to placing XML objects, AGN library objects can't be scaled:

Creating storage tanks / circular objects

Hi, I've searched the manual but can't seem to find any info. I am wondering how I could get Scenproc to recognise and build Storage tanks as can be seen in the attached OSM data? Many thanks

www.fsdeveloper.com

Question 2 – If yes, do I need to use CreateXMLLibObj in order to have the scale adjusted automatically? Not sure how I would create the step?

Yes, it requires the use of XML objects. See the sample I referenced above.

Question 3 – Would it be possible to have a scenProc step something to the effect of “If radius is >XX meters then use GUID {}” OR if <XX meters use GUID {}, this way to use a selection of different storage tanks?

Sure, you can use the FLENGTH attribute to get the diameter of the circle and then use different GUID based on that (assuming you have the different sizes in your AGN library objects in default.xml.

Question 4 – The .osm files are HUGE! Do you by chance have a tool to break down the osm file into smaller files, like you did with your json splitter?

No, I don't have a tool for that. What I do myself on bigger projects is load all the OSM data in a database server and then let scenProc only read the section of the world I am interesting in at that moment.

 

[Clutch Cargo]

Ok, let me see if I can gather my thoughts clearly. Yes, that post you answered in Question 1 is what I tried. However, it appears the step:

CreateXMLLibObj|man_made="storage_tank"|8aaabdf2-4496-483a-8df1-86ea13aa950d|0|0|0|FLENGTH/20

Is based on knowing the size of the storage tank object. What I seek is to scale automatically the storage tank to match the OSM polygon size, which for me is an unknown. This way, I don't need to know the object's size or even the polygon footprint size. scenProc would do a comparison of the object's size against the polygon footprint and scale accordingly... a perfect fit! And then to add to that, I would have tanks in various sizes (Large, Medium, Small), all based on different GUIDs to give a better looking fit to start and then scales those a tad to match footprint. That way the objects would not be stretched, skewed or sized looking strange.

You said above:
"Yes, there is a sample in that same thread. But it only refers to placing XML objects, AGN library objects can't be scaled"

I see, I thought there was a step to create autogen objects from an xml or I can only create a librayy object from that? My end goal is to create autogen objects on their own or from default or our own custom made library objects. Or so long as I scale in "xml" mode first and then convert to an autogen object?

You also said:
"If the features have attributes that define they are tanks it is easy indeed. I thought you also wanted to detect those that do not have such an attribute."

So I did discover the osm data file does indeed have storage tank attributes (discovered different OSM file types have different attributes). But it could be nice to also detect if there are no attributes?


Also, can you tell me what these stand for:
FLENGTH = fixed length?
FAREARAT = ?

Starting to ramble on here so I will get back to testing and create more concise questions.

 

[arno]

Hi,

Is based on knowing the size of the storage tank object. What I seek is to scale automatically the storage tank to match the OSM polygon size, which for me is an unknown. This way, I don't need to know the object's size or even the polygon footprint size. scenProc would do a comparison of the object's size against the polygon footprint and scale accordingly... a perfect fit! And then to add to that, I would have tanks in various sizes (Large, Medium, Small), all based on different GUIDs to give a better looking fit to start and then scales those a tad to match footprint. That way the objects would not be stretched, skewed or sized looking strange.

But you are placing a specific library object by specifying the GUID of it. It would not be weird to know the size of that library object in that case as well. For scenProc to lookup that size it would need to find the library BGL that contains the object and parse that file. At the moment scenProc does not have such logic, it is the task of the developer to add such information in the script.

I see, I thought there was a step to create autogen objects from an xml or I can only create a librayy object from that? My end goal is to create autogen objects on their own or from default or our own custom made library objects. Or so long as I scale in "xml" mode first and then convert to an autogen object?

Not sure if I understand you here. scenProc can place XML library objects and autogen library objects. The first are compiled with BGLComp and can be scaled. The second are the library classes that are defined in the default.xml file in the autogen definitions folder. Each library object in the default.xml file has a specific size and you can only place it at that size. There is no way to scale them.

There is no logic to convert from XML library objects to AGN library objects. That would require that you add all your objects to the default.xml file.

So I did discover the osm data file does indeed have storage tank attributes (discovered different OSM file types have different attributes). But it could be nice to also detect if there are no attributes?

OK, I have put that idea on the wishlist and already have an idea how to implement it.

Also, can you tell me what these stand for:
FLENGTH = fixed length?
FAREARAT = ?

I should have to say RTFM .

There are a number of special feature attributes that scenProc can calculate for you for a feature. These all start with a F. I have listed them below:

FLENGTH	Length of the minimum area polygon around the feature.
FWIDTH	Width of the minimum area polygon around the feature.
FTYPE	Feature type (POINT, LINE, POLYGON or RASTER).
FRAND	Random value.
FHEADING	Heading of the minimum area polygon around the feature.
FCIRCUM	Circumference of the feature (for a line feature this is the length of the line).
FAREA	Area of the minimum polygon around the feature.
FAREARAT	Ratio of the area of the feature and the area of the minimum polygon around the feature. This can be used to see how close to a rectangle the feature is when selecting polygons for autogen buildings.
FMINSIDE	Length of the shortest edge of the feature.
FNUMVERT	Number of vertices of the feature.
FNUMPERPANG	Number of 90 degree angles in the feature.
FNUMNOTPAR	Number of edges in the feature that do not have another edge that is parallel to them.
FCONVEX	1 if the feature is convex, 0 if it is concave.
FRATIO	Ratio between the length and the width of the minimum area polygon around the feature.
FLAYER	Name of the layer in the GIS file from which the feature was read.
FROMFILE	Filename from which the feature was read.
FROMPATH	Full path of the file from which the feature was read.

 

[Clutch Cargo]

Wanted to come back to this:

But you are placing a specific library object by specifying the GUID of it. It would not be weird to know the size of that library object in that case as well. For scenProc to lookup that size it would need to find the library BGL that contains the object and parse that file. At the moment scenProc does not have such logic, it is the task of the developer to add such information in the script.

Ok, I have to agree that we would know/should know the size of the object we make and that would be used in the step. So, if scenProc now knows our storage tank size could it now then compare it to the footprints that represent storage tanks? After all, we now know it is a storage tank footprint because we have the Type field and Value (man_made="storage_tank"). Just need the smarts for scenProc to measure that footprint and then scale our storage-tank object to match that measurement. Possible?

Not sure what the step would look like. I assume it would take place at the PointToPolygon step? Something like an attribute called COMPARE? and then something like:

CreateAGNLibObject|Type="storage_tank" AND COMPARISON RADIUS <15 |{32f3ed34-c508-44c7-b1fe-d9343c68f17b}
CreateAGNLibObject|Type="storage_tank" AND COMPARISON RADIUS <30 |{42f3ed34-c508-44c7-b1fe-d9343c68f17b}
CreateAGNLibObject|Type="storage_tank" AND COMPARISON RADIUS >30 |{52f3ed34-c508-44c7-b1fe-d9343c68f17b}

Just throwing out ideas.

I should have to say RTFM

I-know, I-know. I did. I just did not understand the "F" means Feature in those Attributes.

 

[arno]

Hi,

The FLENGTH/20 in the sample script does that scaling. It takes the size of the current footprint and devides it by 20 to calculate the needed scale. So scenproc can do that.

 

[Clutch Cargo]

Jumping back into this thread, just like I am trying to give myself/developers more "power" over autogen objects like in our LineToPoint thread, I wish to add more options in round polygon detection's.

1. You state XML objects can be scaled and agn objects can not.

If I understand you correctly you added this step:
CreateXMLLibObj|man_made="storage_tank"|{32f3ed34-c508-44c7-b1fe-d9343c68f17b}|0|0|0|FLENGTH/20
which will scale the object of 20 meters to match the size of the underlying round polygon footprint?

2. If this is correct, could we not apply the same type of coding to scale an object BEFORE it becomes an autogen object?
CreateAGNLibObj|man_made="storage_tank"|{32f3ed34-c508-44c7-b1fe-d9343c68f17b}|0|0|0|FLENGTH/20
Perhaps in some manner with an added attribute or step?

3. If that is not possible, could we have scenProc capture and store the size of the round polygon (the OSM footprints), say in the PolyGonToPoint step, which can then be used in the CreateAgnLibObject step? In other words, scenProc would use the size of the OSM polygon and NOT the size of the object in it decision making process of what object to use.


For example, right now I am using the following code to create storage tanks:

ImportOGR|B:\CA Data\OSM Data 2023\CA_63_BX46.osm|*|building|NOREPROJ
ImportOGR|B:\CA\Section_63\Masks\CA_BX46_mask.shp|*|*|NOREPROJ

SplitGrid|AGN|*|building="*"

PolygonToPoint|building="*" And man_made="storage_tank"|CENTER|0.0;0.0|0.0;0.0|String;Type|storage_tank|hdg
PointToPolygon|Type="storage_tank"|0;0|hdg|String;Type|storage_tank
BooleanFeatures|INTERSECTION|Type="storage_tank"|FROMFILE="CA_BX46_mask.shp"|1

CreateAGNLibObject|Type="storage_tank" AND FLENGTH >30|{32f3ed34-c508-44c7-b1fe-d9343c68f17b}
CreateAGNLibObject|Type="storage_tank" AND FLENGTH <30|{84667a96-0e95-46d3-92ca-87a16c9d0e4c}

ExportAGN|P3D v4|B:\CA\Section_63\CA_BX46\Test Objects AGN\texture

However, and correct me if I am wrong, the GUID decision is based on the size of the storage_tank object. I would like the GUID decision to be based on the size of the OSM polygon. Since I might not be able to scale an object automatically, I could have a whole set of objects created at different sizes (each with their own GUID), to closely match the size of the OSM polygon. Possible?

 

[arno]

Hi,

The approach you describe at the end should work. If you have multiple AGN library object classes that each have a different size of storage tank, you can se hte FLENGTH attribute to select the one that is closest in size.

Doing the trick with scaling as can be done for the XML objects won't work. AGN library objects are made based on polygons. But if you draw a smaller or bigger polygon, still the same size of library object is shown. I have already tried that many years ago. It is just not supported to scale AGN library objects.

 

[Clutch Cargo]

I finally understand that scaling the poly will not scale the object... gotcha. And you say...

The approach you describe at the end should work. If you have multiple AGN library object classes that each have a different size of storage tank, you can set the FLENGTH attribute to select the one that is closest in size.

That I understand but in order to have it process the way I envision (that is select the correct GUID automatically), we have to know the OSM ground poly size. Are you saying the FLENTH is already taking the ground poly into the equation? From my tests that is not the case. It is taking the storage_tank size. But if so I will test more.

 

[arno]

The FLENGTH attribute takes the length of the bounding rectangle of the feature. So it's calculated by scenproc and does not come from the ism data. For a circle the length of the bounding rectangle is the diameter of the circle.