GIS data to .agn using Rhino 5 and python script

[olee]

Hi all,

I would like to share some scripts that can be used to create autogen forests on the basis of GIS data.

I am using the 3d software Rhino and python scripting to convert GIS data (UTM referenced outlines of forests in Denmark) into autogen forests.
The reason for using Rhino is that it is a powerful CAD application, with many advanced tools for manipulating geometry.
For instance, I could imagine using this technique it is also possible to place large amounts of library objects (eg. distributing points along lines as streetlights) and export them as xml.

Anyway, this example is showing how to generate .agn forests using three different scripts, that:

a)split the polylines by LOD13 cell borders
b)group the objects based on LOD13 cell
c)export the data to the a format that can be compiled into .agn using Arno´s brilliant little txt2agn tool.

Here is my first test (autogen trees throughout Denmark)

download:
http://www.megaupload.com/?d=LNOXLBR0

I have attached the scripts, and a description of the workflow, to this message.
Throughtout the scripts are comments to make it easier to understand whats going on in the code (the lines starting with # are comments)

The drawback is that Rhino is quite expensive, so unless you have access to it through work/studies, this might not be a feasible solution. A 90 day trial version of Rhino is available at: http://download.rhino3d.com/Rhino/5.0/evaluationtimed/download/


regards,
Ole Egholm

a screen of the first script, that splits polygons by LOD13 cells:

a screen of forests in Zealand, Denmark, split by LOD13 cells and grouped (i highlighted some of the cells in yellow for clarity):

 

[GaryGB]

Hello:

Thank you for sharing your work-flow with the FS Development Community.

Presently, the first download link above for your work in progress does not work.

Since the world model in FS is based on Geographic Lon-Lat projected, WGS84 datum coordinates, your poly-line and/or polygon data, as well as any aerial imagery from which such content is manually derived ...should, IMHO, be converted ("re-projected" via a GIS utility) from UTM to that above required GIS format prior to use in FS scenery creation.

[EDITED]

I would recommend doing that conversion before calculating LOD13 Quad vertices; also, use 13 decimal place geographic Lon-Lat coordinates if computing any LOD13 "Area Point" vector coordinates, and all before processing any of that data result via either Arno's utilities or the FS Autogen SDK.


BTW: W.I.P download link is working now... thanks, and best wishes for your project !

[END_EDIT]


Keep up the good work, and please let us know how your project progresses.



GaryGB

 

[olee]

Hi Gary,
Thank you for the reply. I am sorry the test-scenery is so unstable, it the problem persist I will try to reupload elsewhere.

I was unsure whether inaccuracies will be a problem; The conversion is as follows: UTM coordinates are converted into lat/lon, which are used to calculate the LOD cell corners. The functions to perform these steps are included in the code. Here is a screen showing the result in FSX´s annotator. It seems to be fairly accurate, but I will keep an eye out for inaccuracies. If this technique is to be of any use to anybody, it has to be accurate. So I will take your advice and make sure the calculations are done with a 13 decimal precision.

Also, the code is a bit messy since the same functions are used in more than one script. If there is a need, I can refactor it into multiple python files, each holding functions of general use, eg. one file for 'convert from utm to lat/lon'.

Once again, thank you for the feedback!
OleE

 

[GaryGB]

Hello:

A few additional questions may merit consideration, IMHO:

1.) Were both the imagery and vector data sets originally "UTM" for the area of your project ?


2.) Did you first convert (re-project) your aerial imagery to Geographic Lon-Lat projected, WGS84 datum format ?


3.) Are you aware of the distinction between a "Projection" and a "Datum" in working with GIS data, and how they can influence the final "shape" of ones displayed results in FS ?


Hope this helps !

GaryGB

 

[olee]

Hi Gary,

Maybe I didn´t clarify it, but this is a method for placing autogen only. The photoscenery below is a called DanVfr, a payware scenery that someone else has made.
I assume that scenery is accurate, I know many developers in Denmark has used it as a reference for placing objects throught the country, and I have never heard any complaints about inaccuracies. This is why I dare say it looks like the autogen is placed fairly accurate.
Here is a screen of autogen generated with an further developed version of the code, now it destinguishes between polylines on a layer called 'forest' and rectangles or polylines on a layer called 'building'. Object on the 'building' are converted to either AgnGeneric or AgnPolyline buildings. Like Arno, I have some difficulties converting polygonal buildings properly, but still it is better than nothing:

best, Ole

 

[GaryGB]

Hi Ole:

Thanks for the clarification; I only just now had a chance to look at your project ZIP file "ReadMe.txt", and I see that the DanVFR photoreal aerial imagery was the intended basis for analysis of how the autogen objects fit into the FS terrain.

I was unable to achieve a complete translation of the "Metadata for Areal Informations Systemet.pdf" file using the 'Google Translate' web page, but it appears that data set was maintained in an ESRI "Arc" GIS environment; it is unclear what Projection and Datum may have been used in the distributed data files.

http://www2.dmu.dk/1_viden/2_miljoe-tilstand/3_samfund/ais/3_Metadata/metadata_en.htm


It appears that your Python routines assume input data projected in UTM.

I presume such UTM data would be further localized by "Zone" for the areas of interest for your project to work properly, provided that the "Areal Informations Systemet" (aka "AIS") derived data set UTM projections also utilize the WGS84 Datum (...which seems likely in light of the more recent date of creation from the described sources for the "AIS" data).

http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system


The examples you have shown appear to have a good alignment between the aerial imagery and the autogen data... well done !

Thanks again for sharing your ideas here, and I hope you will keep us informed on how your methods further progress with implementing a semi-automated FS autogen annotation process ...for making custom scenery appear even more realistic.


Regards,

GaryGB

 

[rhumbaflappy]

Hi Gary.

The autogen file format doesn't use geographic coordinates. Instead it uses plus or minus decimal fractions to determine the location of elements as related to LOD13 ( QMID 15 ) tile centers... Arno or Ole can correct me if I'm wrong.

So using a CAD system and a UTM measurement system doesn't require reprojecting anything. Much easier to convert distance in meters to fractional distance from the center of a tile.

The autogen files are located by the QMID-based name. Changing the name changes the location. Internally, there is no latitude or longitude of the autogen elements.

Maybe some day there will be a good dedicated autogen tool, but until then, scripts like Ole's are very useful. The Annotator is pretty convoluted in it's use.

Dick

 

[arno]

Hi Dick,

But since the edges of the tiles are at a certain latitude and longitude, it is still useful to have the data in WGS84. In for example UTM the tile edges would probably not be horizontal or vertical lines.

The autogen coordinates are either from center of the tile or from the bottom left corner. That depends a bit on the type of autogen objects.

I think if you want to cover big areas with autogen, a scripting approach is fine. That's also what I did with my scenProc tool. Nobody wants to cover a huge area manually.

 

[olee]

Hi Arno, Dick, Gary, and others.
I was unaware that wgs84 fix not require rotation. I did have to make the script rotate each lod. To be specific, there is a function in the script i called transformLod, that rotates a cell and scales it to a value between 0 and 1. This probably exactly what you are doing Arno, and probably in a much clever way, I am no wizard in programming. I think your tools are splendid, and very useful. I am very impressed you have managed to write a program that compiles to agn. The reason I thought it might be interesting to share this experiment is what Dick points out, that in some cases it may be useful to have a graphical interface to refine/test/ see the conversion going on. And it is also handy to have access to rhinos large set of functions for linework manipulation.
I used a formula I found online to write a function (a function starts with 'def' in the script and its content is defined by indenting) what converts from utm to lat/lon, then another that generate the lod cell. This first function could be replaced with another if the data is another format, like eg. wgs84.
Regards, ole

 

[arno]

Your results are looking good.

Does your function have a fixed rotation? I think the amount of rotation needed differs with your distance from the middle of the UTM zone (it the convergence angle). So what you found might work for Denmark, but maybe not for other places in the world. I guess that's why Gary made his remark.

A GUI is indeed useful. My current flow is just a script of commands to perform. I sometimes export intermediate results to shapefiles so that I can view them in GIS programs, but it is not really the user friendly interface you would like to have in the end.

 

[olee]

Yes, each cell is rotated differently. To be specific, each LOD rectangle is defined as a list of four points. From this info i get one side of the retangle and calculate the angle between this side and a vertical line. Then all linework within the LOD is rotated by this angle. The rectangle definition, angle calculation and rotation are all build-in rhino functions, so I have not really done that much work.

Actually, I found that the angle variation is quite big; LOD cells in Jutland (western part of Denmark) are pretty much vertical/horizontal, while cells in Zealand (eastern part of Denmark) are rotated more than three degrees...
I also found that a LOD cell is not square at all in these northern latitudes, it is more like 800 x 1200 meters. I guess it makes sense that they get more and more narrow towards north. It makes it hard to position buildings 100% correct, since a rectangle is more like a parallelogram after the cell is transformed into a square. But when flying over a city at 120 kts i guess you do not notice if a building is a little to narrow or wide.

On another note, polyline buildings are harder to draw, and I have not cracked that nut. At least not satisfactory. For now they are drawn as rectangles based on the longest side, and one of the adjecent sides as the extrusion. The problem is that complex houses i GIS data are represented as closed polylines, eg. representing the outline of a L-shaped building. In FS closed polylines are interprited as courtyard houses.. this means an L-shaped building should really be two line segments and an extrusion. So buildings with complex polyline footprints, I think, is going to be abit of a pain to get right. Have you come up with a solution to that Arno?

 

[arno]

Hi,

Yes, I came to the same conclusion for the buildings. I have written an algorithm on paper that should allow me to split those polylines in multiple rectangles. But I haven't had the time to program it yet.

 

[GaryGB]

Hi Gary.

The autogen file format doesn't use geographic coordinates. Instead it uses plus or minus decimal fractions to determine the location of elements as related to LOD13 ( QMID 15 ) tile centers... Arno or Ole can correct me if I'm wrong.

Hi Dick:

Thanks for the additional clarification within the context of this thread.

I have examined the "AGN (FSX) FSDeveloper Wiki" a few times previously:

http://www.fsdeveloper.com/wiki/index.php?title=AGN_(FSX)#AGN2


...But I am still intrigued as to why placement instructions for both the PRDE vegetation polygon vertex and PBDE polygon building footprint vertex "x and y coordinates are given as offset from the top left of the LOD13 square (range 0 till 1)", whereas for other listed objects "x and y coordinates are given as offset from the middle of the LOD13 square (range -0.5 till 0.5)".

I'd welcome seeing additional ideas discussed here (or elsewhere ?) ...on the basis for this parametric difference.


[EDITED]

PS: AFAIK, we are discussing FS Autogen Annotation involving 'multiple imagery tiles' of a LOD13 sized quad (aka "Area" or "Cell"), and annotation info in 'multiple LOD13 sized virtual tiles' as *.AGN files intended to be "aligned" with custom photoreal land class texture tiles ...within the larger LOD8 land class grid.

So, I believe to avoid confusion by some readers new to the subject matter, we should distinguish the FS land class terrain texture tile vertex attachment and blending system from the vertex attachment of a 'virtual' *.AGN tile within which placement instructions are plotted.

Thus, IMHO, it might also be helpful to clarify here... whether a "LOD13 square" referred to in the above cited "AGN (FSX) FSDeveloper Wiki is:

* Centered on the middle of a FS LOD13 quad

...or if instead it is:

* Centered on a NW-NE-SE-SW corner of a FS LOD13 quad

...since AFAIK the "virtual" AGN layer is technically a land class related entity (although IIUC, it might be regarded as a 'single' layer laid over a 'single' layer of custom photoreal imagery land class ...rather than what would otherwise be multiple layers of default-type land class "components" to blended).


I suspect we could all agree the proper answer is that FS Land Class and AGN 'virtual tile' vertex coordinates both coincide with the same quad matrix "tile" vertex coordinates of terrain mesh, and have the same requirements for source data to be submitted based on a WGS84 datum, and for high levels of precision to be used in coordinate calculation ...before the rendering engine can do its job accurately:

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx


IMHO, the "relative" reference point AGN placement scheme for describing 'fractional' offsets from points within a LOD13 structure of 256x256 Area Points further compels higher precision in calculations, since even the NW-NE-SE-SW quad corners and/or mid-points themselves... may be regarded as "vector coordinates" within the FS multi-LOD quad matrix scheme.


After all...

* Precisely calculated LOD5 Area Points define the corner vertices for a LOD13 Quad

* Precisely calculated LOD13 Area Points define the corner vertices for a LOD21 Quad


In my experience, accurately computing ex: LOD13 row and column vector coordinates requires a minimum of 12 decimal places, and I would further allow 1 extra decimal place to allow for some reasonable measure of "rounding" to be implemented; ...thus my preference for using a total of 13 decimal places.

[END_EDIT]


GaryGB

 

[GaryGB]

Hi Ole:

I wanted to better understand the basis for your additional computations to "rotate" the polygon data derived as LOD13 quads from what I assume was ESRI SHP file input data imported to Rhino, so I revisited the the Danish Areal Information System (aka "AIS") website.

From what I can see on the AIS download page, the data is indeed available as ESRI SHP files.

http://www2.dmu.dk/1_viden/2_miljoe-tilstand/3_samfund/ais/4_Download/download_en.htm


"The Danish Areal Information System


Downloading of AIS data:

You may now download all data from the Areal Information System!

* Areal Information System data in ESRI Shape format.


* Areal Information System data in MapInfo format.

* Test data for you who wish to explore a limited section of the various themes."


Following the link on that page for:

"Test data for you who wish to explore a limited section of the various themes:

http://www2.dmu.dk/1_viden/2_miljoe-tilstand/3_samfund/ais/4_Download/TESTdownload/testdata_en.htm


The linked page states:

"From the table below you may download test data from the Areal Information System:

The test data includes an area at Horsens Fjord."

< GoogleEarth "jump to" coordinates: 55°51 N, 10°0 E >


Clicking the link for Land Use Map - ESRI Shape, I downloaded "AAK_5_6.zip"


I noted this geo-reference info at:

http://toolserver.org/~geohack/geoh..._E_region:DK_type:waterbody_source:GNS-enwiki

Then, I opened the "aak_5_6.shp" shape file enclosed in AAK_5_6.zip in my Global Mapper GIS application "Overlay Control Center", corrected the UTM Zone Projection type to Zone 32"U" ...which shows this Metadata:

Metadata Tab:

FILENAME=[my download path]\AAK_5_6\aak_5_6.shp
DESCRIPTION=aak_5_6.shp <[my download path]\AAK_5_6\aak_5_6.shp>
FILENAME=R:\Downloads\AAK_5_6\aak_5_6.shp
DESCRIPTION=aak_5_6.shp <R:\Downloads\AAK_5_6\aak_5_6.shp>
AREA COUNT=7884
AREA VERTEX COUNT=296874
LINE COUNT=0
POINT COUNT=0
UPPER LEFT X=549999.622
UPPER LEFT Y=6200000.000
LOWER RIGHT X=575000.000
LOWER RIGHT Y=6174999.732
WEST LONGITUDE=9.79591654° E
NORTH LATITUDE=55.94277486° N
EAST LONGITUDE=10.20070183° E
SOUTH LATITUDE=55.71494173° N
PROJ_DESC=UTM Zone 32 / NAD83 / meters
PROJ_DATUM=NAD83
PROJ_UNITS=meters
COVERED AREA=625016255 sq m

Projection Tab / Projection *.PRJ file info:

Projection UTM
Datum NAD83
Zunits NO
Units METERS
Zone 32 (6° E - 12° E - Northern Hemisphere) <--- CORRECTED (after Global Mapper default Zone was already applied on import)
Xshift 0.000000
Yshift 0.000000

Projection Tab 'Parameters':

CENTRAL MERIDIAN SCALE FACTOR 0.999600000
CENTRAL MERIDIAN 9.00000000
ORIGIN LATITUDE 0.00000000
FALSE EASTING (m) 500000
FALSE NORTHING (m) 0


This confirmed that the AIS distributed data files are formatted in:

* ESRI Shape (aka "SHP") data format (standard X-Y type)
* UTM Zone 32 "U" Projection
* NAD83 Datum

http://en.wikipedia.org/wiki/North_American_Datum

NOTE: By default my Global Mapper configuration opens AIS distributed data using a "North American Datum" to format data for Denmark

CORRECTION: An over-ride of my Global Mapper default Datum assignment from UTM / NAD83 to UTM / WGS84 yields this Metadata:

Metadata Tab:

FILENAME=[my download path]\AAK_5_6\aak_5_6.shp
DESCRIPTION=aak_5_6.shp <[my download path]\AAK_5_6\aak_5_6.shp>AREA COUNT=7884
AREA VERTEX COUNT=296874
LINE COUNT=0
POINT COUNT=0
UPPER LEFT X=549999.622
UPPER LEFT Y=6200000.000
LOWER RIGHT X=575000.000
LOWER RIGHT Y=6174999.732
WEST LONGITUDE=9.79591654° E
NORTH LATITUDE=55.94277486° N
EAST LONGITUDE=10.20070183° E
SOUTH LATITUDE=55.71494173° N
PROJ_DESC=UTM Zone 32 / WGS84 / meters
PROJ_DATUM=WGS84 <--- CORRECTED
PROJ_UNITS=meters
EPSG_CODE=32632 <-- UPDATED (after WGS84 over-ride of my Global Mapper default Datum assignment)
COVERED AREA=625016255 sq m

Projection Tab / Projection *.PRJ file info:

Projection UTM
Datum WGS84 <--- CORRECTED
Zunits NO
Units METERS
Zone 32 (6° E - 12° E - Northern Hemisphere)
Xshift 0.000000
Yshift 0.000000

Projection Tab 'Parameters':

CENTRAL MERIDIAN SCALE FACTOR 0.999600000
CENTRAL MERIDIAN 9.00000000
ORIGIN LATITUDE 0.00000000
FALSE EASTING (m) 500000
FALSE NORTHING (m) 0


This confirmed that the AIS distributed data files are formatted in:

* ESRI Shape (aka "SHP") data format (standard X-Y type)
* UTM Zone 32 "U" Projection
* WGS84 Datum <--- CORRECTED





Regardless, AFAIK, this data format must still be re-projected to Geographic Lon-Lat Projection, WGS84 (aka "EPSG 4326") Datum ...prior to use in creating scenery content / placement instructions FS in order to "fit" the overall FS world model.


FYI: This can be done via a GIS application or by other methods as discussed in:

"OGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2 – July 2011", alternatively titled:

"Coordinate Conversions and Transformations including Formulas - Revised - July 2011"

http://www.epsg.org/guides/docs/g7-2.pdf

...or one may follow procedures described by MS Game Studios / ACES author Adam Szofran in his "Global Terrain" treatise on FSX terrain development:

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx



BTW: In an interesting and perhaps topically related document:

http://140.194.76.129/publications/eng-manuals/em1110-1-1003/basdoc.pdf


"NAVSTAR Global Positioning System Surveying ENGINEER MANUAL"

Section 1-9. Metrics and Accuracy Definitions states:

"GPS-derived geographical or metric Cartesian coordinates are generally transformed to English units of measurements for use in local project reference and design systems, such as State Plane Coordinate System (SPCS) grids."

Section 3-2. Geodetic Coordinate Systems states:

"The absolute positions obtained directly from GPS pseudorange measurements are based on the 3-D, earth-centered WGS 84 ellipsoid (Figure 3-1). Coordinate outputs are on a Cartesian system (X-Y-Z) relative to an Earth-Centered Earth-Fixed (ECEF) rectangular coordinate system having the same origin as the WGS 84 ellipsoid, i.e. geocentric. This geocentric X-Y-Z coordinate system should not be confused with the X-Y plane coordinates established on local grids; local systems usually have entirely different definitions, origins, and orientations which require certain transformations to be performed.

WGS 84 geocentric X-Y-Z Cartesian coordinates can easily be converted into WGS 84 ellipsoid coordinates (i.e. f, l, and h--geodetic latitude, longitude, and ellipsoidal height, respectively). GPS baseline distances are computed on the geocentric coordinate system, not ellipsoidal coordinates. It is critical to note that the WGS 84 ellipsoidal height (h) is not the orthometric elevation used for civil works projects. Performing these transformations (also known as "site calibrations") from WGS 84 to local reference systems is a critical, and sometimes complicated, part of GPS surveying."


PS: I am unfamiliar with the GIS file format output options that Rhino offers, but as an alternative suggestion, if Rhino offered KML/KMZ export, that post-processed file could be re-projected via a GIS application or other method to achieve a Geographic Lon-Lat Projection, WGS84 (aka "EPSG 4326") Datum ...prior to further processing for use in FS scenery development to ensure a proper "fit" with the overall FS world model.


Hope these ideas might prove to be worthy of consideration in your further development !

GaryGB

 

[arno]

Hi Gary,

On the Wiki it is meant that a LOD13 square is a LOD13 quad. So they they allign with the corners of the quad, not with the centers. I could not imagine it to be different.

 

[GaryGB]

Hi Arno:

Thanks for the clarification; that certainly makes sense to those more familiar with the subject matter.


PS: Will you be further updating that "AGN (FSX) FSDeveloper Wiki" in question ?

http://www.fsdeveloper.com/wiki/index.php?title=AGN_(FSX)#AGN2


NOTE: I also added some edits for clarity in my posts above to correct for Global Mapper default Projection / Datum settings I had initially missed.


GaryGB

 

[olee]

Hi Gary.
Thank you for the input on coordinate systems. That was informative. If it is of interest to you, you can see the actual conversion from utm to lat/lon in the code, it is in a def called UtmToLatLon. I made it made on the basis of an Excel sheet I found online that did the same. I got the data in the mapInfo format, and did actually at first import it into rhino as lat/lon. But as you know the y coordinate comes first in lat/lon, so the data represents flipped and distorted in a x y coordinate system. Therefore it made more sense to import it as utm and do the conversion in rhino.
Regards, ole

 

[GaryGB]

Hi Ole:

Thanks for that explanation.

[EDITED]

Based on '#comments' I observed in your project Python code linked for download above via "Rhino_Python_GIStoAGN.zip" inside "splitByLODcells.py":

#check if object spans more than two cells:
#if the span of the forest is more than 0,8 km in width and 1,2 km in height, calculate division points to evaluate:
if (width < 800 and height < 1200):

...I wanted to better understand (since I am not a programmer), whether your calculations are precisely defining LOD vertices / Area Points based on the actual 'known' FS quad span sizes which can be computed; such a process would reference info listed in the FS SDK Docs at:

[FSX SDK install path]\Environment Kit\Terrain SDK\Terrain and Scenery.html under "QMID and LOD Values"

QMID LOD Block size (degrees) One Pixel (degrees) Meters/pixel
2    0   90                   0.350194553         38913.62
3    1   45                   0.175097276 	  19456.81
4    2   22.5                 0.087548638 	  9728.40
5    3   11.25                0.043774319 	  4864.20
6    4   5.625                0.02188716 	  2432.10
7    5   2.8125               0.01094358 	  1216.05
8    6   1.40625              0.00547179 	  608.03
9    7   0.703125             0.002735895 	  304.01
10   8   0.3515625            0.001367947 	  152.01
11   9   0.17578125           0.000683974 	  76.00
12   10  0.087890625          0.000341987 	  38.00
13   11  0.043945313          0.000170993 	  19.00
14   12  0.021972656          8.54967E-05 	  9.50
15   13  0.010986328          4.27484E-05 	  4.75
16   14  0.005493164          2.13742E-05 	  2.38
17   15  0.002746582          1.06871E-05 	  1.19
18   16  0.001373291          5.34354E-06 	  0.59
19   17  0.000686646          2.67177E-06 	  0.30
20   18  0.000343323          1.33589E-06 	  0.15
21   19  0.000171661          6.67943E-07 	  0.07
22   20  8.58307E-05          3.33972E-07 	  0.04
23   21  4.29153E-05          1.66986E-07 	  0.02
24   22  2.14577E-05          8.34929E-08 	  0.01
25   23  1.07288E-05          4.17464E-08 	  0.00
26   24  5.36442E-06          2.08732E-08 	  0.00
27   25  2.68221E-06          1.04366E-08 	  0.00
28   26  1.3411E-06           5.21831E-09 	  0.00
29   27  6.70552E-07          2.60915E-09 	  0.00

FYI: A sightly different reference layout adapted from info in the above table ...for a LOD13 / QMID15 quad;

Note that the actual span size in Meters for a LOD 13 / QMID 15 quad is 1,223 Meters (...not 1,200 Meters or 1.2 km)

The example below is centered on assumed GoogleEarth "jump to" coordinates for Horsens Fjord at: 55°51'N, 10°00'E

LOD  QMID  Span Size  Quad Lat Span   Quad Lon Span  Quad Span    Area Point Span  Nearest True LOD13 Quad NW Corner
           Meters/Px  Size Degrees    Size Degrees   Size Meters  Size Meters      Geographic Coordinates

13   15    4.8        0.010986328125  0.0146484375   1223         4.777343750      55.854492187500°N, 9.990234375000°E

BTW: Have you considered a version of your project using Shape (SHP) or DXF files as output from Rhino, since Arno's ScenProc utility accepts both of those files as input ?


< Hmmm... it would be interesting to see if a scripted output for use in Arno's autogen utilities might also be achieved in Global Mapper, or in Sketchup via Ruby code! >

[END_EDIT]

Thanks again for sharing your insights on this aspect of FS scenery design.

GaryGB

 

[arno]

Hi Gary,

Go ahead and improve the Wiki article as much as you want. Everybody is free to contribute to it.

 

[GaryGB]

Thanks for the vote of confidence, Arno !


I'd still consider that W.I.P. (aka "Wiki_In_Progress") to be under your benevolent auspices.

I was just curious if you might add further info to it as you gain additional insights.


FYI: I especially anticipate we might come to better understand:

...why placement instructions for both the PRDE vegetation polygon vertex and PBDE polygon building footprint vertex "x and y coordinates are given as offset from the top left of the LOD13 square (range 0 till 1)", whereas for other listed objects "x and y coordinates are given as offset from the middle of the LOD13 square (range -0.5 till 0.5)".

PS: I edited my post above < ...again ! >

Regards,

GaryGB