Scripting regression after 11.02 official release
tjhb
Global Mapper UserTrusted User
Mike,
There seems to be a major regression in builds after the official 11.02 release (dated 1 March 2010).
It arises when rasterizing vector data (loaded from shapefile) to GeoTIFF (and possibly other formats) by script.
The result is a pure blank output (pure background colour). I've tried setting the transparent background option on or off, exporting to RGB or to greyscale, using a cropping area or not, using a custom area style or a built-in style, processing areas or lines—all permutations yield the same blank result.
But reverting to the original 11.02 build dated 1 March immediately resolves the problem, with no change to script or data.
Installing the build dated 12 March (the current full installer build I think, though I haven't checked for a little while), or any later build I've tried, reproduces the issue (blank output).
The issue does not arise if the equivalent operation is performed through the GUI. (With all builds I've tried, including the very latest.) Only scripting is affected.
I'll attach a sample script so you can see what I'm trying to do. [I had to rename it to ~.txt to get it to stick.]
I can provide sample data as well, if necessary.
There seems to be a major regression in builds after the official 11.02 release (dated 1 March 2010).
It arises when rasterizing vector data (loaded from shapefile) to GeoTIFF (and possibly other formats) by script.
The result is a pure blank output (pure background colour). I've tried setting the transparent background option on or off, exporting to RGB or to greyscale, using a cropping area or not, using a custom area style or a built-in style, processing areas or lines—all permutations yield the same blank result.
But reverting to the original 11.02 build dated 1 March immediately resolves the problem, with no change to script or data.
Installing the build dated 12 March (the current full installer build I think, though I haven't checked for a little while), or any later build I've tried, reproduces the issue (blank output).
The issue does not arise if the equivalent operation is performed through the GUI. (With all builds I've tried, including the very latest.) Only scripting is affected.
I'll attach a sample script so you can see what I'm trying to do. [I had to rename it to ~.txt to get it to stick.]
I can provide sample data as well, if necessary.
Comments
-
Can you provide a sample file that fails in your script so I can test this and reproduce the error?
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Thank you Mike.
I've simplified the script a little bit (and given two variants, one to produce greyscale output, the second to produce RGB output with a transparent background). After editing I verified once more that they produce good output in the official 11.02 release, blank output in later builds.
Tim -
This not part of the bug report but by the way.
I wonder whether there's a way to avoid having to confirm the projection of a POLYGON_CROP_FILE during script execution. I know shapefiles are primitive when it comes to projections, and perhaps I should use, say, a .mif, which might not raise the prompt. But there might be a way to specify the projection of a cropping/tiling file within a script, which I am missing. -
Ah I think I see the issue. There was actually a bug in the v11.02 release where the ASSIGN_TYPE command would run even after issuing an error about a missing COMPARE_STR attribute. So even with that error you'd still get the "White" type assigned to all areas in the layer.
After the initial v11.02 release this was fixed to abort the ASSIGN_TYPE command when that was missing, so no type assignment would be done, so your areas were staying as Unknown Area Feature types which by default render as black borders, which of course wouldn't show up on a black background.
However, I decided that the initial unintentional behavior of ASSIGN_TYPE when the COMPARE_STR was missing was probably desirable to allow type assignment for an entire layer after the initial load of that layer, so I restored that behavior. I have placed a new build at http://www.globalmapper.com/global_mapper11.zip with the change for you to try. Simply download that file and extract the contents into your existing v11.xx installation folder to give it a try. If you are using the 64-bit version, there is a new build available at http://www.globalmapper.com/global_mapper11_64bit.zip .
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
For the POLYGON_CROP_FILE, just create a .prj file for the SHP file with the projection of the SHP file, then that will automatically be used without prompting you for the projection to use.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Mike,
I think I understand your diagnosis now, as I read it, but I know I won't in ten minutes time!
So I'll just nod and say thank you and bless you. We are lucky to have you here.
The new build does fix the problem.
You also have a simple solution to my very small ancilliary issue. That's what I'll do.
Have a good Easter break.
Tim -
I do still understand the explanation, after all.
What I had failed to appreciate—this may explain why no one else had reported the same "bug" (which it wasn't)—is that the COMPARE_STR argument was obligatory.
I had previously got away without specifying a string, only because of a small bug, which you somehow managed to identify and explain.
Now, in the latest build, a COMPARE_STR argument is optional. I am pleased about that. Thanks.
Nonetheless I've tried adapting my scripts to the former assumption that a COMPARE_STR argument will always be present. (Sensible when I pass scripts to other users, who may not have the most recent build.)
I usually want to assign one style to all features.
These two specifications can be used to include all features:
COMPARE_STR="<Feature Name>=*"
COMPARE_STR="<Feature Desc>=*"
But this specification includes none:
COMPARE_STR="<Feature Type>=*"
Perhaps that is how it should be, on the basis that we are assigning a type-specific style. -
Yeah the <Feature Type> string really was supposed to match an exact type name. Since '*' doesn't match anything, nothing matches on that. Wildcards aren't supported in the type name search.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Thanks Mike.
But the other two wildcard searches are a valid, sanctioned means to specify all features?
COMPARE_STR="<Feature Name>=*"
COMPARE_STR="<Feature Desc>=*" -
Yes, either of those will work, or you can just leave out the COMPARE_STR now since that is ok.
Let me know if I can be of further assistance.
Thanks,
Mike
Global Mapper Support
support@globalmapper.com -
Perfect. Thanks again.
Categories
- 12.8K All Categories
- 5.7K Features Discussion
- 345 Downloading Imagery
- 1.3K Elevation Data
- 385 Georeferencing Imagery Discussion
- 636 GM Script Language
- 54 User Scripts
- 114 GPS Features
- 417 Projection Questions
- 826 Raster Data
- 1.3K Vector Data
- 6.6K Support
- 178 Announcement and News
- 913 Bug Report
- 558 SDK
- 1.2K Suggestion Box
- 3.7K Technical Support
- 569 Other Discussion
- 131 GIS Data Sources
- 27 Global Mapper Showcase
- 238 How I use Global Mapper
- 107 Global Mapper Forum Website