Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
I am using map tiles (as opposed to imagery tiles) for generation of building footprint vector features from raster and not using them directly, and yes, it's an extremely large area at a high zoom to get finer resolution for the raster to vector algorithms in Global Mapper. I have free imagery from the Tasmanian Government for my photo-real imagery. Thus my PM to you guys about the GoogleAPIs and a tool to gather up tiles without some of the GM feature layers. SBX is the only tool to get and compile the tiles at the moment via your plugin, but it is onerous doing it in ~500m x 300m chunks for several thousand square kilometres. If SBX could write BigTIFF and a GIS application standard world file or a BigTIFF Geotiff it would save weeks of work, but then it would have trouble managing the file in memory to display it.
I do a lot of the heavy lifting in Global Mapper, but there are some things specific to MSFS/P3D that need to be done in SBX as it is the only tool that does it. The lack of seamless interoperability with standard formats (Geotiff, standard world files, etc) is just another thing that adds to the workload. Thus my interest in the potential for a v4.0...
http://www.fsdeveloper.com/forum/threads/sbuilderx-source-code.441176/#post-785394
Considering the statements posted by Sean Isom and Dick earlier in this same thread:
http://www.fsdeveloper.com/forum/threads/sbuilderx-source-code.441176/#post-782734
http://www.fsdeveloper.com/forum/threads/sbuilderx-source-code.441176/#post-782738
...one certainly might wonder whether there may be potential to increase the input, working set, and output data sizes that MSFS / LM-P3D SDK Resample will accommodate.
However, since FS SDK Resample is a stand-alone application which does not rely on external libraries / DLLs etc., I am still curious as to whether we actually may be able to push the envelope of available USERVA for SDK Resample a 'bit' (or many 'bytes' !) ...further.
If it would be possible at some point within your limited available time, I would be very grateful if you would test something that might prove useful to the FS Developer knowledge base for Resample.
After making a ZIP backup of SDK Resample.exe, set the "LARGE_ADDRESS_AWARE" flag in the executable for that original Resample.exe file, by applying the "4GB Patch" (and specifically not via MS "CorFlags") ...following the procedure described recently for patching CvxExtractor.exe in this thread:
http://www.fsdeveloper.com/forum/th...porting-vector-data.432918/page-5#post-783986
BTW: This test uses '4GB Patch', as I am not certain whether Resample is in a fully compatible Portable Executable (aka "PE") file format that may be patched via 'MS CorFlags' ...which may- or may not- be intended only for use with 'certain' Win32/64 GUI executables.
https://en.wikipedia.org/wiki/Portable_Executable
Then, if you would please, submit to that copy of Resample with the "4GB Patch" applied to it, a:
* 'Larger than 3-GB' (ex: 4-GB ?) multi-source INF source data set of GeoTIFF files (either LZW-compressed or not)
...to see if Resample will accommodate that data set, and then successfully output a 'larger than 2-GB' output BGL.
PS: I hope we 'may' be able to increase the size of both working and output data sets submitted by SBuilderX315 to SDK Resample.
Thanks in advance for considering a quick test of whether we 'may' be able to extend 64-Bit USERVA for SDK Resample task sessions.
GaryGB