I have loaded a Mercator Projection which is expecting bounds in spherical units. Previously, I was able to specify the LAT_LON_BOUNDS and it would export correctly. Now, it is giving me a "no data exists" error, presumable because it is interpreting -86.86426,33.38086, etc... as spherical units instead of lat/lon degrees.

I've attached the complete script ... let me know if you need the datasets as well or if this is enough for you to recreate the problem. I am using Global Mapper 12.01, 64 bit, Build time Jan 20 2011

Comments

At first glance I'm not seeing anything wrong. If you run this in Global Mapper with the File->Run Script command what are the bounds of the data that end up loaded in the main view? What do the contents of your mercator.prj file look like? It could be a problem in that file preventing the specified lat/lon bounds from being converted to the export projection.

In case it helps, I have attached the Mercator projection file. This file was working correctly before without changes. Is there a way using the scripting language to switch the global projection to one of the built-in projections?

Based on the reported bounds your data wouldn't intersect the LAT_LON_BOUNDS that you provided. If you run the script and then run the cursor over the coordinates, is the data correctly placed where you expect in terms of lat/lon?

You can use the LOAD_PROJECTION script command to change the current global/export/view projection.

OK, I think we are getting closer to the problem, but it is not a problem with EXPORT_RASTER but rather the LOAD_PROJECTION command which I was already using. I still think this is a bug because I haven't made any changes on my end to the system that I am using to generate the Global Mapper Script. All I did was update to the latest build 12.01 and all of a sudden my scripts stopped working.

Here is how to recreate the problem.

1. This one works (note the commented out third line)
The zip file is a GMG elevation file exported using a geographic projection.

3. Interestingly, though, if I manually load the projection file from within Global Mapper before doing the export, the export works fine. I have attached all the necessary files to recreate the problem. (See working.gms and nonworking.gms which both reference elev.zip) I have attached the mercator projection file which was created by clicking "Save as File" from the Configure -> Projection menu

Very strange I just ran you 'nonworking.gms' and it worked perfectly for me. I checked the JPG and it is fine. I wonder if you have a strange build or something. Can you try getting the latest build and see if that helps? I have placed a new build at http://www.globalmapper.com/global_mapper12.zip with the latest changes for you to try. Simply download that file and extract the contents into your existing v12.xx installation folder to give it a try. If you are using the 64-bit v12 version there is a new build at http://www.globalmapper.com/global_mapper12_64bit.zip .

I downloaded and extracted the latest build (b021711) into my Global Mapper 64 bit folder and tried again. Still not working. Here are two screenshots showing the problem... notice the crazy scale on the first screenshot. The second screenshot is taken after I clicked OK, opened the control center, and right-clicked on the elev.gmg layer and selected "Zoom to layer". Note that the scale is correct in the second screenshot!

I am baffled, I simply cannot get it to fail on my machine. How are you running the script? I have tried both using File->Run Script and loading the script as a workspace and it works perfectly in all cases, both in Debug and in the Release 64-bit build. Although I can't think of any settings that would mess this up, you could go to the General tab of the Configuration dialog and click the button to reset the defaults and see if that does anything.

That did the trick. I clicked the button to reset the defaults and then dragged the .GMS file into Global Mapper. It worked perfectly! I will keep an eye on the settings as I change them to find out which setting breaks the script.