Mesh resampling DEM ACSII data and coordinates

#1
Hello.

I worked with mesh in geotiff format before with 1 arc second data 30m from USGS with succes. It seems that geotiff format is WGS84 datum as well as ASC ( ASCII ) data.
My problem is that I have download 5m mesh ( huge files ) in that .asc format. I tried to export is at it is to geotiff but as I know this data doesn`t have coordinates inside and no other files with coordinates are to download for this files.
My knowledge about GIS programs is let`s say basic. I use Global Mapper. Could anyone give me a tip how to handle with that data to resample to bgl. First thing when i load file in global mapper is this image below:

I suppose it`s something related with projection and should be LON LAT projection. I tried to find thred about this issue without succes.






Przechwytywanie.PNG
 
#2
Hi Rafal:

*.ASC files derived from LiDAR point data may be Geo-rectified according to the Metadata for the data file or its file name.

One may be able to project it initially as UTM by finding its Zone, and then re-projecting it to Geographic (Lat-Lon) / WGS84.

What is the central Geographic coordinates for this Canary Islands project area ? :scratchch

GaryGB
 
Last edited:
#4
Hi Rafal:

I have been trying to find the file-specific online metadata from that web portal to verify the local UTM Zone for your project area (no luck so far).

What is the central Geographic coordinates for this Canary Islands project area ?

[EDITED]

Assuming your project is within the central Canary Islands area and your UTM Zone is indeed 28 in the Northern Hemisphere you may be able to proceed normally.

You may wish to review these threads that discuss a work-flow in Global Mapper to process source data and output GeoTIFFs for FS terrain mesh : :idea:

https://www.fsdeveloper.com/forum/threads/help-with-global-mapper-and-scenery-use.439100/

https://www.fsdeveloper.com/forum/threads/about-geotiff-resmaple.430118/


PS: A useful reference to verify UTM Zones:

http://www.dmap.co.uk/utmworld.htm

[END_EDIT]

GaryGB
 
Last edited:

HolgerSandmann

Resource contributor
#9
Hi there,

the DEM download page states "ETRS89 for the Iberian Peninsula, Balearic Islands, Ceuta and Melilla, and REGCAN95 for the Canary Islands": http://centrodedescargas.cnig.es/CentroDescargas/locale?request_locale=en#

REGCAN95 for the Canary Islands equals EPSG code 4083; see https://epsg.io/4083 . EPSGs are pre-defined sets of parameters for specific georeferencing systems. For example, the geographic/WGS84 projection used by FSX & P3D is also named "EPSG:4326"

Global Mapper has a whole bunch of these EPSG codes built in so you can try to initiate it via the "Init from Epsg ..." button seen on your screenshot above. Type in the "4083" code and the corresponding parameters should get auto-filled and then you can proceed loading the elevation data and re-project it to Geographic/WGS84 before saving and compiling. If that EPSG code doesn't exist then you can manually create a new set for it as shown on this page: https://digimapas.blogspot.ca/2015/06/mdt-de-global-mapper-compegps.html

Cheers, Holger
 
#10
Holger I think it`s done allready but read
. Thanks once again GaryGB for support. Unfortunatelly default mesh in my FSX looks terrible as seen below on the screens for comprasion becaouse I did it and works. I hope you notice which one is default ;)



fsx 2018-04-10 05-22-02.png
fsx 2018-04-10 05-23-03.png
fsx 2018-04-10 05-25-56.png
fsx 2018-04-10 05-24-28.png
 
#11
https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796664

Hi there,

the DEM download page states "ETRS89 for the Iberian Peninsula, Balearic Islands, Ceuta and Melilla, and REGCAN95 for the Canary Islands": http://centrodedescargas.cnig.es/CentroDescargas/locale?request_locale=en#

REGCAN95 for the Canary Islands equals EPSG code 4083; see https://epsg.io/4083 . EPSGs are pre-defined sets of parameters for specific georeferencing systems. For example, the geographic/WGS84 projection used by FSX & P3D is also named "EPSG:4326"

Global Mapper has a whole bunch of these EPSG codes built in so you can try to initiate it via the "Init from Epsg ..." button seen on your screenshot above. Type in the "4083" code and the corresponding parameters should get auto-filled and then you can proceed loading the elevation data and re-project it to Geographic/WGS84 before saving and compiling. If that EPSG code doesn't exist then you can manually create a new set for it as shown on this page: https://digimapas.blogspot.ca/2015/06/mdt-de-global-mapper-compegps.html

Cheers, Holger
Hi Holger:

Thanks for explaining that option to simplify (somewhat) the work-flow in Global Mapper via use of EPSG codes, as that may be easier for folks to use. :)

I should properly update my older mini-tutorials in the 2 threads I cited above in the near future to implement that helpful EPSG option that I now also use. :pushpin:


BTW: To help a few folks that are not yet aware of the translate option in Google, here's one of the Spanish links in your quote ...translated to English:


PS: I have not had time to test the above source data yet, but I assume we must still re-project from ETRS89 to WGS84 or Resample will reject that data ? :scratchch

GaryGB
 
Last edited:
#12
https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796665

Thanks once again GaryGB for support.

Unfortunately default mesh in my FSX looks terrible as seen below on the screens for comparison because I did it and works. I hope you notice which one is default ;)
Looking good overall, Rafal ! :)

Hmmm... looks like the top image you attached would be the FS default. ;)


However, for the middle image mesh, I wonder if you tried Holger's often-utilized FractionBits method to smooth out "terracing' of the source data ? :scratchch

That would require Global Mapper to output a 32-Bit Floating Point- instead of a 16-Bit- Raster Elevation GeoTIFF. :idea:

GaryGB
 
Last edited:
#13
Interesting issue ! I was wondering how to reduce terracing. I used 32-bit method but not floating. Also I used fractionbits=2 in inf. file to resample. Mesh looks identicaly to the freeware I found with whole Canary Islands but my purpose was to make just one to ensure everyone and myself :) that it`s my work in case of and kind of distribution. I will try floating point when exporting to geotiff and let know . By the way photoscenery you see is my work as well in LOD-16 60cm/px resolution and lot of work in PS with water and blend. Photoscenery avaliable on Rickoo is 1 or 2m.px and different worse imagery data sets. One more screen afer 4 hours of sleep ( whole night with this stuff ). As for as resamling and method I used it`s slightly different as described above. The data I`ve download was in 5 parts so I figured that I need to merge them alltogether in order to enter center coordinates of island in inf file for resampling. Ofcourse I exported merged ( one file ) to geotiff and wgs84 datum. I`m wondering if it will work in P3D as well lon and lat centrall coordinates . Also I have one more question. How to optimize photoscenery for better loading time and further visibility? Compression 85 or maybe less or more like 100 ? I believe that visibility from distance might be different if i out LOD=auto or 0,16. Maybe 10,16 would improve distance visibility ? I could check myself but would like to save some time and/or know other tip for that thing....
fsx 2018-04-10 10-06-11.png
 
Last edited:
#14
https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680

Interesting issue ! I was wondering how to reduce terracing. I used 32-bit method but not floating point. Also I used FractionBits=2 in inf. file to resample.

Mesh looks identical to the freeware I found with whole Canary Islands, but my purpose was to make just one to ensure everyone and myself :) that it`s my work in case of and kind of distribution. I will try floating point when exporting to geotiff and let know .

By the way photo-scenery you see is my work as well in LOD-16 60cm/px resolution and lot of work in PS with water and blend. Photoscenery available on Rickoo is 1 or 2m/px and different worse imagery data sets. One more screen after 4 hours of sleep ( whole night with this stuff ).
FractionBits=2 in SDK Resample *.INF file with a 32-Bit Floating Point raster elevation data source file may be sufficient to minimize "terracing" for Gran Canaria.


Looks like a good scenery ! :cool:


https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680

As for as resampling and method I used, it`s slightly different as described above. The data I've download was in 5 parts so I figured that I need to merge them all together in order to enter center coordinates of island in inf file for resampling. Of course I exported merged ( one file ) to geotiff and wgs84 datum. I`m wondering if it will work in P3D as well lon and lat central coordinates .
I'm not certain that I understand what you meant by the use of "center coordinates of island in inf file for resampling"; would you please post the INF file here ?

[EDITED]

FYI: I asked about central Geographic coordinates of your project area to verify a UTM Zone number to be used when displayed in a GIS application. :alert:

AFAIK, for a source file specified in the *.INF file submitted to SDK Resample, one should only use Geographic coordinates from the GIS Metadata AFTER it is re-projected from its original distribution format (ex: REGCAN95 for the Canary Islands) to EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) ...and not arbitrarily the central Geographic coordinates of a GIS source data file. :pushpin:

IIUC, this is because EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) required by FS SDK Resample, is variable in "shape and orientation" of pixel coordinates compared to UTM or other similar 'local' non-warped GIS cartographic projections, which are not variable in "shape and orientation" of pixel coordinates (when sample data extents are considered in 'tiles' of no more than 1 Kilometer at at time).

Please note that Gran Canaria Island is between 48 and 52 Kilometers in diameter, thus shorelines are between 24 and 26 Kilometers from its center point.

While it is true that "warping" of GIS data is visibly greater farther North or South from the Equator when formatted in a EPSG:4326 (aka: Geographic Lat-Lon projection / WGS84 Ellipsoid Datum) GIS cartographic projection, at distances of 24 and 26 Kilometers from the center point of Gran Canaria Island, there is likely to be 'some' variability in "shape and orientation" of pixel coordinates (aka: "warping") ...even at its location within 28 degrees North of the Equator.

Thus, IMHO, the importance of using Geo-referencing coordinates from GIS Metadata for source data files submitted to SDK Resample via a *.INF file. :duck:

If such source data files submitted to SDK Resample have been properly re-projected to EPSG:4326 and exported as GeoTIFFs, the *.INF file can be much less complex, and SDK Resample will automatically read the required Geo-referencing coordinates from GIS Metadata within the GeoTIFF and its *.TFW file. :idea:

If Masks and Seasonal / Night source files are derived from the GeoTIFF and edited, provided one always keeps the original total Pixel Row and Column numbers unchanged (and therefore the Geo-referencing) for such mapped images unchanged), one can read and write out a *.INF for such images to be used for their entries in the *.INF file ...which match the geo-referencing coordinates within the GeoTIFF from which they are originally derived.

To do this, one may use Ollyau's "GeoTIFF to INF" utility to read the GeoTIFF projected in EPSG:4386, then use "GeoTIFF to INF" to write out a INF for use with FS SDK Resample via the 'manual' compilation method.

The resulting INF includes the Geo-referencing info for the NW and SE corners derived from the [filename].TIF 'GeoTIFF file header' and the accompanying [filename].TFW 'world' file for that GeoTIFF image in Geographic Lat-Lon projection / WGS84 Ellipsoid Datum required by FS SDK Resample.

[END_EDIT]

https://www.fsdeveloper.com/forum/t...acsii-data-and-coordinates.442564/post-796680

Also I have one more question. How to optimize photo-scenery for better loading time and further visibility?

Compression 85 or maybe less or more like 100 ?

I believe that visibility from distance might be different if i out LOD=auto or 0,16. Maybe 10,16 would improve distance visibility ?

I could check myself but would like to save some time and/or know other tip for that thing....
I personally prefer the greater detail of CompressionQuality=100.

But, it has been reported that CompressionQuality=97 for terrain mesh still looks good, but results in Resample output of a significantly smaller BGL size.


The recent consensus is to not include photo-real LODs below 4, so LOD-4,16 or LOD-4,Auto should be a more practical range for visibility of an island.

NOTE: Data density in lower LODs requires progressively less file size, so it usually does not become a problem to extend LODs down to 4 or lower, as in some cases where one may need to increase the Geographical extent of coverage for a terrain mesh BGL to force display on top of other loaded mesh BGLs. ;)


Looking forward to seeing more screenies ! :)

GaryGB
 
Last edited:
Top