ZoomIn From Large Scale to Small Scale

[Dennis]

MapSuite Team,



I’m encountering issues when a ZoomIn is performed, for example, from ZoomLevel14 (Scale 18023) to ZoomLevel17 (Scale 1900).



From nearly the same CenterMap when this ZoomIn is performed the Transition displays the existing lines/icons extremely large.  In fact the larger the difference in scale the larger the lines/icons.  So big that a single icon nearly fills a 22" widescreen monitor top to bottom.



This is actually pretty frightening to my users.  And in sometimes causes the MapSuite SDK to encounter an exception, hence crashing my application.



This blow-up in size of lines/icons only occurs when the CenterMap remains the same at time of ZoomIn.  If the ZoomIn is issued to CenterMap on a different extent this blow-up does not happen.  The farther ‘off-center’ the new CenterMap less blow-up occurs.



The LayerOverlay is set with TileType=MultipleTile, TileTransitionEffect=Stretch, TileWidth=1024, TileHeight=1024.



What can be done to prevent this blow-up and the crash from occurring?



I have downloaded several mp4’s to my ThinkGeo account (home/videos/ZoomIn20151116) so that you can see what I’m talking about.



Thanks,

Dennis





ViewOfChicago->CurrentDomain_UnhandledException:

Unhandled Exception–>Outer

Source=WpfDesktopEdition

TargetSite=Void DrawException(ThinkGeo.MapSuite.Core.GeoCanvas, System.Exception)

StackTrace=   at ThinkGeo.MapSuite.WpfDesktopEdition.Tile.DrawException(GeoCanvas geoCanvas, Exception exception)

   at ThinkGeo.MapSuite.WpfDesktopEdition.Tile.Draw(GeoCanvas geoCanvas)

   at ThinkGeo.MapSuite.WpfDesktopEdition.Tile.phc=(Object status)

   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Message=Object reference not set to an instance of an object.

[Troy]

Hi Dennis,



Thanks for the videos, we saw the behaviors. What I am guessing is your application is using the point style to represent the images, if that, then I am afraid it is hard to avoid it as this layer is actually treated as a tiled image layer. Zooming to fast/many will make the image stretch a lot during the new rendering is finished. 



A solution is using markerOverlay rather than a FeatureLayer, the marker which is a control won’t be stretched like image layer. However, we would recommend do not add too many markers like thousands in an extant as it may results to a potential performance issue. Here are some test codes:

ShapeFileFeatureSource featureSource = new ShapeFileFeatureSource(@"…\SampleData\Data\MajorCities.shp");
            featureSource.Open();
            Collection<Feature> allFeatures = featureSource.GetAllFeatures(ReturningColumnsType.AllColumns);
 
            foreach (var item in allFeatures)
            {
                Marker marker = new Marker(item.GetShape() as PointShape);
                marker.ImageSource = new BitmapImage(new Uri("/Resources/AQUABLANK.png", UriKind.RelativeOrAbsolute));
                marker.Width = 20;
                marker.Height = 34;
                marker.YOffset = -17;
 
                TextBlock content = new TextBlock();
                content.Text = item.ColumnValues[“AREANAME”];
                content.FontSize = 14;
                content.FontWeight = FontWeights.Bold;
                content.Foreground = new SolidColorBrush(Colors.White);
                content.Margin = new Thickness(0, -10, 0, 0);
                marker.Content = content;
                markerOverlay.Markers.Add(marker);
            }

As for the exception, I am guessing is if the zoom in is too fast, then the rendering may results to some unexpected issue like out of memory or resource lock issue etc…But it is just my guess.

 

Thanks,



Troy

[Dennis]

Troy,



You are correct, I am using PointStyle.  My application supports 65 layers with 21 that are points so switching to a marker would not be advisable as I cannot even consider taking any kind of performance hit.



It is not as evident in the video, but line layers are also blown-up like the icons.



The LayerOverlays set TileTransitionEffect to Stretch.  When this property is set to None it seems as though a transition still occurs when scale is changed.  However, during the change of scale the screen goes blank right before it draws.  What is the purpose behind this property?



The exception being encountered is ‘object reference not set…’.  It’s not a matter of zooming too fast in this case.  The application programmatically changes the scale on behalf of the user from ZoomLevel14 to ZoomLevel17.  It’s just a ZoomIn from one scale to another so I don’t understand why it should encounter this exception.



Your thoughts please?



Thanks,

Dennis

[Troy]

Hi Dennis,



I can imagine the line layer also have the same behavior but I think for these kind of layers, this behavior should not be an issue but on the contrast, keeping the previous tile will make the zoom looks smooth before the new tiles show. Actually, most of the maps like Bing Map also takes the same strategy during the zooming. Please check my test video from Bing map: screencast.com/t/3j0anBl9fK8f



As you can see the difference on TransitionEffect, the “Stretch” mode will keep the old tiles for a while till the new tile generated to replace the old one. 



For the exception, I am not sure if I recreated your exception, but when I test 50 large size jp2000 files layers, each file size is about 1G, I did encounter some Memory exceptions, if I change the layer count as 20 or less, I won’t encounter the exception. Besides, if I change the tile size as 256, the exception also won’t happen. So, would you please let us know your layers detail and try to change the tile size as 256?



Thanks,



Troy