samknight · BMG Staff


Last Active
No Roles
Invited by
  • Best raster file format for fast display

    I prefer JP2 over the others mainly because of compatibility, almost everyone supports read of JP2 natively in display engines now due to it being an open ISO standard, and the internal referencing in JP2 is more flexible than that found in ECW, this is a benefit when using custom coordinate systems which is something we happen to do a lot of here at Blue Marble.  Many state and federally supplied collections are in JP2 already so it's becoming more familiar to everyone.  That said, MrSID and ECW are much better supported for read now than years ago.  It's not like 10 years ago when you would have to find and install plugins into software to enable a particular format in a display package.  In terms of performance and superiority, there are many factors involved that make it very difficult to give a one size fits all answer; certain qualities of the image like transparency, the specific software it will be accessed through, etc.  There are scenarios where each of those three will outperform the others but generally they are all in the same ballpark.

    Sam Knight
    Director of Product Management
    Blue Marble Geographics
  • Best raster file format for fast display

    Hi Danielek, at small sizes, you'll notice less practical difference in performance, but in general the wavelet compressed formats (JP2, ECW, MrSID) outperform all others and each of those will have similar performance at small or large sizes.  Another factor is the practical size of data they can handle.  A Tiff file with common packbit compression of about a gigabyte, will pack down to more like 2-10 megabytes depending on the chosen compression for the wavelet format, and the format itself can only handle up to about 2gb of data.  To your question about unpacking the data, the wavelet formats access the data differently than the more raw formats, so there isn't much of a hit there.  The analogy I use is a suitcase.  In formats like Tiff of JPG, it's like having a duffel bag full of clothes that were all just stuffed in there.  The wavelet formats are like a suitcase with many compartments and all the clothes are neatly folded and organized.  The stuff inside is the same, it's the efficiency of the storage itself that makes a difference.  In the duffel bag, you've got to dig through everything in the bag, even if you're only after your socks.  But in the neatly folded bag you know exactly which compartment to find your socks in, so you can get them out faster.

    Another factor, if you are working purely in Global Mapper is that you can set up a Map Catalog that will allow you to load up individual tiles into a collection of tiles.  This allows you to set up zoom levels for tilesets of various resolution and coverage, and allow the application to only load particular images when they are needed, rather than loading up images covering larger areas all the time.  To extend my previous analogy, this would be like having a whole family of efficiently packed suitcases with names labeled on the outside so now you can find a particular person's socks.  Make sense?  I hope that helps.  

    The short version of my answer is, I recommend JP2 as a go-to image format, and map catalogs of tilesets if you are working with coverages of big areas.

    Sam Knight
    Director of Product Management
    Blue Marble Geographics
  • Has Global Mapper development ceased? Any alternatives?

    I can only offer some information and hope you will continue to see the value in sticking with us.  18 months before today was March 19th, 2017.  Since then we have released Global Mapper 18.2 in April 2017, Global Mapper Mobile for Android (May 2017), Global Mapper 19.0 (September 2017), and Global Mapper 19.1 (February 2018).  Just last night we rolled out Global Mapper 20.  Each of these releases had a large list of updates which you can browse in the Knowledge Base for all releases.  Beyond that, we roll out an updated Daily Build every single day based on requests and bug reports, much like the old days, with the difference being there's a lot more included in these builds than before and they clear a testing process before going out every day.  

    Our support team supports users around the globe, spanning practically every industry.  We work to support the diaspora of users that come to us despite the simple fact that it is impossible for us to be experts in all fields.  We do have experts in a number of fields, and we strive to improve our knowledge and expertise every day.   If you have concerns about any interactions you have had with our team, I would encourage you to bring those to us at or reach out to me directly.  We can assess the response and look for ways to improve for the future.  We exist for our users, and we feel that we provide an excellent value in the GIS world.  I hope you will continue to agree.

    Best Regards,
    Sam Knight
    Director of Product Management
    Blue Marble Geographics

  • Past requests, future action?

    Hi Bill,
    I understand the desire for some insight and folks are always welcome to check in with us on feature development.  Long time users remember communicating directly with Mike and he'd crank out a fix or new widget within minutes in a hot patch.  He's still here as the lead developer on the project, and we actually still do that, we just have more of a support structure to help us scale to needs of a (rapidly) growing user base, and bigger plans in terms of development that are supported by a larger development team behind the product.  The daily build of global mapper is where those get rolled up instead of doing one-off builds the old way.  In terms of what we're working on and how we prioritize, it comes right from users.  At the last release for version 19.1 in February, we took a look at all the features we released under what we consider to be "significant" updates, and realized that everything on the list had come directly from user requests.  That wasn't by mistake, we have thousands of requests in our system, and one of the major factors in prioritizing them is based on the number of users requesting a particular feature, we actually wrote a new tool in house this year to help us isolate clusters of related functions that are high request items that have been hanging around on our wishlist.  Years ago we had to move away from the old "To Do" list on the forum simply because it was entirely unsustainable due to volume and now we manage requests in a true database.  For business reasons we've kept that offline, but we are always happy to discuss particular requests. 

    One of the easiest ways to check in on development is to use the request number if we've given you one, such as #11502 from your first item.  A quick note asking how's it going on that ticket and we can look it up and get back to you.  It's easiest for us if you email directly to the support team ( as a lot of folks like to use the forum with anonymous handles, so we aren't always able to look you up by name to find requests if you don't have a ticket number.  We actually hit 25000 last week, and there are not many in the system left that are less than 10000.  As you might assume, we don't go in consecutive order and those numbers span our entire set of products, as of this moment we have 2103 open requests for Global Mapper targeted for various future releases.  We often handle between 300-750 tasks in a given release depending how long our cycle is.  It's a balancing act for priorities, we're a very dynamic team, but we do have limits of how much we can do at once as a small company, so we do have to make hard decisions about what needs to get done first.

    So about your specific enquiries:
    1) Save Layer visibility in the Control Centre.
    Item #11502 is definitely one the older requests at this point, it's often come up for discussion.  It's remained as long as it has due to some architecture issues, as well as just not having particularly high request counts relative to other features that have made the cut.  We're looking at this again in conjunction with some other updates to the Control Center.  You don't need to make your arguments at all on this one, a lot of folks, including us, want it.  So without making promises, I'm hopeful this will be on our short term list.

    2) Name and Save 3D viewpoints
    This is item #17690 and #14185.  These had to take a back seat to some of the 3d optimizations we've been working on since the 18 cycle as we have changed out the guts underneath the 3D window.  The long and short of this is that it's a popular request that we've wanted to do for a while, it just hasn't made sense to implement from a development standpoint because of the sweeping changes to how we have been modernizing the 3D interface under the hood.  This is being reconsidered again for 20.1 since we are getting to a place where we can get it done right the first time.  This one I had already actually flagged for discussion as we begin the next cycle.

    3) Generate rectangular area / crop boundary from centre point and width/height
    This is unfortunately a prime example of something seemingly fairly simple that hasn't been a prioritized due to low requests for it.  I've just been through the whole thread again with yours and Kelly's feedback on it and I will make sure we give this a fair look.

    4) (Not) handling variables in scripts
    I believe BMGBob has patched up both of these, so feel free to give them a try and let us know how it goes.

    I hope this helps shed some light.  As always, please feel free to come to us with feedback, we really do try to put our users at the center of the process.

    Best Regards,
    Sam Knight
    Director of Product Management
    Blue Marble Geographics