Global Mapper v25.0

Global Mapper v10.00 Beta 2 Now Available

global_mapper
global_mapper Administrator
edited September 2008 in Announcement and News
Global Mapper Software LLC is pleased to announce the availability
of the 2nd beta of Global Mapper v10.00 at
http://www.globalmapper.com/global_mapper_setup_v1000_beta.exe . Just
download that file and run it to install v10.00. It will install alongside any existing Global Mapper version, so you don't have to worry about losing what you're currently working on.

Among the numerous significant changes in this second v10.00 beta are the following:

- (NEW FOR BETA 2) Added KML/KMZ Super Overlay Support! This allows working with huge data sets in Google Earth. The option to automatically grid the data on the KML/KMZ export dialog enables this behavior.
- (NEW FOR BETA 2) Added support for creating new feature coordinates based on distance/bearing and/or COGO values from a start location using the Digitizer Tool.
- (NEW FOR BETA 2) Added option on the Gridding tab for exports to grid to the currently selected area features. This will create a separate export file for each selected area feature. Naming can be done using the display labels or an attribute of the selected area feature(s).
- (NEW FOR BETA 2) Added options when editing multiple features to rename attributes and also to copy the values of one attribute to a different attribute.
- Added new Coordinate Convertor option under the Tools menu to allow easily converting a coordinate between any two supported projections/datums/units.
- Added ability to Search Vector Data dialog to limit your search to the existing search results. This effectively allows you to query on multiple attributes/values.
- Added a large collection of new available line styles to use when rendering line features or area feature borders.
- Added option to crop a loaded raster layer to the currently selected area feature to the Cropping tab of the Raster Options dialog accessible from the Overlay Control Center.
- Added support for exporting loaded vector data to the MapInfo TAB/MAP format.
- Added support for exporting loaded 3D line and point data to the SEGP1 format.
- Made automatic collar cropping work for BSB marine charts.

All of the other numerous changes are listed in the What's New document that is displayed during installation.

Prior to the v10.00 release we also plan on adding a couple other major features, including support for ESRI Personal Geodatabase format files and possibly BigTIFF support.

Here is a temporary registration key so that you can try everything
out in the beta for the next week:

RegName: DEMO_08182008
RegCode: 1097052748

While we plan on officially releasing v10.00 in 2-3 weeks, for those
of you that just can't wait to purchase new licenses and upgrades to
existing licenses, you can purchase those now from
Global Mapper - Download/Purchase . Pricing for upgrades from v9 is $99 US per license and pricing for new licenses are $299
US for a single license with price breaks for multi-license
purchases.

Let me know if you any problems or questions.

Thanks,

Mike
Global Mapper Software LLC
support@globalmapper.com

Comments

  • PaulTocknell
    PaulTocknell Forum Administrator Unconfirmed
    edited August 2008
    Thanks Mike. And don't forget that you can get the upgrade for $89 and a full copy for only $254!

    Upgrade to Global Mapper Version 10: http://www.globalmapperforum.com/upgrade10

    Purchase Global Mapper Version 10: Product Information
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    Thanks for adding SuperOverlay support. A few suggestions if you have time.

    1) Your using an old method of creating KML files where you are creating one KML file for each tile. This is no longer necessary. Only 1 KML file is needed. See This File for an example.
    . It is much better to have just one KML files for several reasons (less overhead, fewer files, easier to edit, etc.).

    2) I don't think you are calculating draw order correctly. Shouldn't each level have a unique draw order. Looks like you are giving each tile a unique draw order. Would be great if we could assign the initial draw order in case we want to layer separate maps a certain way.

    3) You might want to change where it says Compressed KMZ. Compressed KMZ probably should only be recommended for small SuperOverlays that are on local machine. Should not be recommended if tiles will be served online or if the resulting KMZ file is huge.

    4) The tile resolutions and grid sizes are odd. For example, one file I ran created Level 2 tiles with following resolutions:

    L2 0 0 - 512x512
    L2 0 1 - 286x366
    L2 1 0 - 512x512
    L2 1 1 - 286x366
    L2 2 0 - 512x655
    L2 2 2 - 283x366

    The last 2 displayed in GE as a thin strip at the bottom of the map. Are you breaking the image up into square chunks, then creating a separate tile pyramid for each chunk? I guess I'm just used to tiles all having the same resolution.

    5) Will SuperOverlay be supported in Batch mode? I did not see an option to create SuperOverlay on the Export to KML/KMZ Batch screen.

    6) Will SuperOverlay work with vector data, other than by converting to raster? This is one of the remaining shortcomings of Google Earth. Not really a good way of displaying huge vector data sets. I can see this being difficult to implement since would need to adjust the detail of the vector data for each level.
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt wrote: »
    Thanks for adding SuperOverlay support. A few suggestions if you have time.

    1) Your using an old method of creating KML files where you are creating one KML file for each tile. This is no longer necessary. Only 1 KML file is needed. See This File for an example.
    . It is much better to have just one KML files for several reasons (less overhead, fewer files, easier to edit, etc.).

    Thanks for the information. I had looked for some approach that didn't require as many separate KML files, but the KML documentation for Super Overlays didn't seem to document an approach like that. Is there some documentation on the approach in the KML file that you provided (nested folders?) that indicates that it offers the benefits of the super overlay approach?
    2) I don't think you are calculating draw order correctly. Shouldn't each level have a unique draw order. Looks like you are giving each tile a unique draw order. Would be great if we could assign the initial draw order in case we want to layer separate maps a certain way.

    There is currently just a sequential draw order assigned for each export tile. I will change it to just use a different one for each zoom level.
    3) You might want to change where it says Compressed KMZ. Compressed KMZ probably should only be recommended for small SuperOverlays that are on local machine. Should not be recommended if tiles will be served online or if the resulting KMZ file is huge.

    I will add something to this effect.
    4) The tile resolutions and grid sizes are odd. For example, one file I ran created Level 2 tiles with following resolutions:

    L2 0 0 - 512x512
    L2 0 1 - 286x366
    L2 1 0 - 512x512
    L2 1 1 - 286x366
    L2 2 0 - 512x655
    L2 2 2 - 283x366

    The last 2 displayed in GE as a thin strip at the bottom of the map. Are you breaking the image up into square chunks, then creating a separate tile pyramid for each chunk? I guess I'm just used to tiles all having the same resolution.

    Global Mapper will obey your sample spacing first and foremost, so for tiles on the right and bottom of the export the width and/or height of the tiles (which is normally 512x512) may be reduced to keep the data from going beyond the specified export bounds and still maintain the specified sample spacing on the most detailed zoom layer.
    5) Will SuperOverlay be supported in Batch mode? I did not see an option to create SuperOverlay on the Export to KML/KMZ Batch screen.

    I'll add an option for batch conversion as well.
    6) Will SuperOverlay work with vector data, other than by converting to raster? This is one of the remaining shortcomings of Google Earth. Not really a good way of displaying huge vector data sets. I can see this being difficult to implement since would need to adjust the detail of the vector data for each level.

    There are not any plans to add similar support for vector data, although it could be added at a later date.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    Thanks for the information. I had looked for some approach that didn't require as many separate KML files, but the KML documentation for Super Overlays didn't seem to document an approach like that. Is there some documentation on the approach in the KML file that you provided (nested folders?) that indicates that it offers the benefits of the super overlay approach?

    I don't know of any documentation other than what's on the Google KML page, which I'm sure you've already seen. The single KML file method for SuperOverlays was implemented by Google somewhere around version 4.2 so maybe they never bothered to document it. The single KML file does the exact same thing as multiple KML files in that it turns tiles on/off depending on the location of the camera view relative to each tile. They even have very similar format. The only difference is all the code is contained in a single KML file instead of 100's or 1,000's.

    I think the problem with multiple KML files was that GE can overload servers with too many file requests. This can cause timeouts and slow load times. Google Earth itself also starts to have problems processing all the KML files when you get up over 5 levels of tiles.

    The single KML format also works just fine with the GE Browser plugin. Here is example Aero-Charts.

    Matt
  • PaulTocknell
    PaulTocknell Forum Administrator Unconfirmed
    edited August 2008
    Love your application by the way, that's great.
  • global_mapper
    global_mapper Administrator
    edited August 2008
    I've converted the KML super overlay output to the new method and made several of the other changes that you mentioned (including batch conversion support for super overlays). I have placed a new build of Global Mapper 10 with the change at http://www.globalmapper.com/global_mapper10.zip . Simply download that file and extract the contents over your existing v10.xx installation to give it a try. Note that you might want to wait about 20 minutes before downloading this as I'm on the road and my internet uplink is very slow right now for some reason.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    I've converted the KML super overlay output to the new method and made several of the other changes that you mentioned (including batch conversion support for super overlays). I have placed a new build of Global Mapper 10 with the change at http://www.globalmapper.com/global_mapper10.zip . Simply download that file and extract the contents over your existing v10.xx installation to give it a try. Note that you might want to wait about 20 minutes before downloading this as I'm on the road and my internet uplink is very slow right now for some reason.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com


    Thanks for the changes. Having only one KML file is big improvement.

    Did notice one issue with the the odd tile resolutions. Since the tiles are different resolutions and they all use the same LOD (Display when File is XXX Pixels In Size) the levels pop in at different altitudes.

    For example, the 512x512 Level 3 tile might become visible at 10 km alt. But the Level 3 tile adjacent to it which is 250x120 won't become visible until the user zooms in to 5 km. See screenshot attached for example. The right side of the map hasn't yet loaded the next tile level. I can see two ways of fixing this.

    1) Figure out a way to make all the tiles the same resolution and scale.

    2) Automatically adjust the LOD values so that each one is proportional to the width of the tile. But make sure we are able to manually set the 512x512 LOD value.

    Also, the default value of 64 for the LOD is a bit low, although it does tend to hide the bug above. 256 would probably be good value for off-line use. 512 if they plan on posting online. If that value is too low, people with low end video cards could have problems and it takes much longer to download the tiles if they are put online.

    Matt
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    Forgot to ask, will SuperOverlay be supported in the scripting language so we can run batches that manually assign the LOD value and KMZ/KML flag for each file? Looks like that would be the only way to set those values for batch processing.

    I just tried a 12,000x8,000 map with the Batch Processor and it creates an KMZ file that is unusable in GE (locks it up) because LOD value of 64 overloads video memory. Change it to 512 or even 768 works much much better.

    Matt
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    One more, then I'll stop bugging you :)

    If you allow batch mode and KML instead of KMZ, need to change the name of the KML file from doc.kml to FILENAME.kml. I don't think there is any reason that it must be named doc.kml. I think that used to be required way back when, but not anymore.

    Matt
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt,

    I have updated the LOD values to be automatically adjusted for tiles that aren't the full tile size (I use the larger of the tile width or height to adjust it). It wouldn't be possible to keep all of the tiles at 512x512 and still maintain both the specified spatial resolution and export bounds. What would be a possibility if this became an issue is to change the tile size so that it would be close to an even multiple of that to cover the entire data set, but that would make specification of the LOD difficult.

    I also updated the default LOD to 128 pixels from 64. I don't like to make it too high because then you have to zoom in so far to see the data. I like the feel of the smaller values better since you can see your data sooner, but understand that could cause issues on lower end video cards.

    I hope to add raster KML/KMZ export to the scripting language prior to the v10 release.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    Matt,

    I also updated the default LOD to 128 pixels from 64. I don't like to make it too high because then you have to zoom in so far to see the data. I like the feel of the smaller values better since you can see your data sooner, but understand that could cause issues on lower end video cards.

    Mike
    Global Mapper Support
    support@globalmapper.com

    Good point. What I typically do is set the LOD for the first level at 64 so that it shows up at a greater altitude, essentially a visual placeholder. Then set the remaining levels at 512 so the video card can keep up and bandwidth requirements are minimized if the tiles are online.

    Typically not a big deal to do this manually with text editor using search/replace. But will be difficult if the LOD values vary depending on the tile size.

    Matt
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt,

    I did some thinking about this last night and I think what is best for super overlays is that the specified LOD value just applies to the topmost tile covering everything as that really controls when the entire data set becomes visible. Then for all tiles below that I will now use a value of 256 for the LOD as that would be when the screen to tile pixel ratio is about 1:2 (i.e. each tile pixel is 1/2 a pixel on the screen). I have placed a new build of Global Mapper 10 with the change at http://www.globalmapper.com/global_mapper10.zip . Simply download that file and extract the contents over your existing v10.xx installation to give it a try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    Getting close. It looks like your method of adjusting LOD for the smaller textures works great for the sides of the map, but doesn't work for the textures along the bottom.

    Here is how GE calculated LOD according to the KML documentation.

    <minLodPixels> (required)
    Measurement in screen pixels that represents the minimum limit of the visibility range for a given Region. Google Earth calculates the size of the Region when projected onto screen space. Then it computes the square root of the Region's area (if, for example, the Region is square and the viewpoint is directly above the Region, and the Region is not tilted, this measurement is equal to the width of the projected Region). If this measurement falls within the limits defined by <minLodPixels> and <maxLodPixels> (and if the <LatLonAltBox> is in view), the Region is active. If this limit is not reached, the associated geometry is considered to be too far from the user's viewpoint to be drawn.

    Matt
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt,

    Thanks for the additional info. I have updated the LOD calculation to use the square root of the area to hopefully much what Google Earth is doing. I have placed a new build at http://www.globalmapper.com/global_mapper10.zip with the change for you to try. Simply download that file and extract the contents into your existing v10.xx installation folder to give it a try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited August 2008
    The LOD issue looks to be fixed. One other bug I noticed today. See screenshot.

    The whole row of JPGs at the bottom of image are missing, but the KML file is looking for them. This area is outside the boundaries of the JPG, but were added by GM.

    Also, something weird happens to me. When I finish export of a map using KMZ option, the map becomes invisible in GM. Almost like it's hidden, but it's not set to be hidden. Clicking Hide and then Unhide brings it back. Doesn't happen when exporting to TIFF.
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt,

    Can you send me your source file that you used to generate the problem of the missing files so that I can give it a try? You can email it to support@globalmapper.com.

    I will look at the redraw issue today, that should be easy to fix.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • global_mapper
    global_mapper Administrator
    edited August 2008
    Matt,

    I was able to reproduce and fix the problem with the missing tiles so that the KML file will no longer reference un-exported tiles.

    I also found and fixed a minor problem with the minLodPixels value for edge tiles.

    I have placed a new build at http://www.globalmapper.com/global_mapper10.zip with the change for you to try. Simply download that file and extract the contents into your existing v10.xx installation folder to give it a try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • global_mapper
    global_mapper Administrator
    edited September 2008
    Matt,

    I was just doing some more KML super overlay work and discovered what seems like a major problem in the nested folder approach for super overlays. Apparently with this approach as you zoom in and have new layers draw, the other lower resolution layers still draw as well! Normally this would not be an issue as the higher detail layers would cover up the lower resolution ones, but if you have layers with transparency (such as if you rendered vector data to PNG files in your KML), then you can see through the transparency to the lower resolution layers, resulting in a big mess!

    Do you know of any way to make the nested folder approach behave like a true super overlay and only draw the layers that are the appropriate resolution and not the entire heirarchy of layers?

    I'm thinking I may have to go back to the documented super overlay approach with the swarm of KML files if I can get this problem fixed more elegantly.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • global_mapper
    global_mapper Administrator
    edited September 2008
    Matt,

    I have attached a sample .kmz file that demonstrates this issue.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited September 2008
    Matt,

    I was just doing some more KML super overlay work and discovered what seems like a major problem in the nested folder approach for super overlays. Apparently with this approach as you zoom in and have new layers draw, the other lower resolution layers still draw as well! Normally this would not be an issue as the higher detail layers would cover up the lower resolution ones, but if you have layers with transparency (such as if you rendered vector data to PNG files in your KML), then you can see through the transparency to the lower resolution layers, resulting in a big mess!

    Do you know of any way to make the nested folder approach behave like a true super overlay and only draw the layers that are the appropriate resolution and not the entire heirarchy of layers?

    I'm thinking I may have to go back to the documented super overlay approach with the swarm of KML files if I can get this problem fixed more elegantly.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com

    What you are seeing is a result of setting maxLodPixels to -1. The -1 tells GE to always display that tile no matter what the view elevation is. The draw order keeps the higher detailed tiles on top of the lower detailed tiles. It would behave the exact same way if you changed back to the other method of generating KML code.

    You can change this value from -1 to something like 1/2 the minLodPixels setting for all levels except the most detailed, which you'd still want to be -1. But the tradeoff is you'll often get visible breaks and tiles flashing on and off when the higher resolution tiles are loading instead of a smooth transition as you get now.

    Typically, transparency shouldn't be an issue. See the Alaska portion of this overlay I did a couple days ago with GM that uses transparency.

    http://www.gelib.com/maps/Sectionals/Aero_Charts_nl.kml

    But there may be some circumstances where it is. There probably isn't much you can do other than accept it as a limitation of GE. Or add a switch that allows the user to set maxLodPixels to a value other than -1.

    Matt
  • Matt
    Matt Global Mapper User Trusted User
    edited September 2008
    Matt,

    I have attached a sample .kmz file that demonstrates this issue.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com

    As far as I know, right now there is no real good way of displaying complex sets of vector data such as this example in GE without some kind of Server-Side scripting that dynamically generates the KML upon view refresh. Short of that, the best thing to do would be to leave it as Vector format and break it into manageable regions/layers so that you're not trying to load more than 3 or 4 megabytes of data at a time. If you must rasterize, then don't use SuperOverlay.

    One of GE's biggest limitations right now is there is no good way to have a static KML file with complex vector data. I think some day someone will figure out a way of doing something like SuperOverlay with Vector data. For example, the complexity of the vector automatically increases as the user zooms in closer to the earth. This should be possible, but I don't think anyone has attempted it yet. Although there are some ArcGIS KML addon tools that might do this somehow, but I don't have ArcGIS, so never tried them.

    Matt
  • global_mapper
    global_mapper Administrator
    edited September 2008
    Matt,

    Thanks for the further feedback. I think I agree that there is not a good solution to this problem. For now I will just disable transparency in the exported files when vector data is being saved. The remaining problems should not be too significant.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • Matt
    Matt Global Mapper User Trusted User
    edited September 2008
    Matt,

    Thanks for the further feedback. I think I agree that there is not a good solution to this problem. For now I will just disable transparency in the exported files when vector data is being saved. The remaining problems should not be too significant.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com

    I just had one other thought. There is also an option to set tiles to Fade in and out based on LOD. You might be able to set that up so that the less detailed tiles fade out as the user zooms in. Then they would become transparent as the higher detail level tiles load. I've never tried this, but might work.

    Matt
  • global_mapper
    global_mapper Administrator
    edited September 2008
    I took a look at the fade stuff and it had promise if I could make use of the <maxLodPixels> tag. The problem is that it seems like when I use a <maxLodPixels> value it seems to affect a particular tile AND every sub folder under that tile. So if I set for example a <maxLodPixels> value for the topmost folder to say 256, as soon as that lowest resolution tile is larger than 256 pixels, the entire data set disappears and the higher res stuff doesn't show up. So unless I'm missing something here I'm not sure that I can do anything about this.

    I have gone ahead and disabled transparency for super overlay KML exports involving vector data, which should eliminate the problem there, but of course eliminate the ability to see any underlying data in this situation.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com