I am using your new 9.0.0.66 build, and I have a problem with one map out of many. We have confirmed that this is a problem that did not exist using 8.0 before updating to 9.0.
Most of our maps have stack of shape layers providing a sort of background. These are domain specific shapes generated with geographic precision using autocad and exported to shape files. Above these layers are additional domain specific layers representing various things using InMemoryFeatureLayers. These are organized based on relationships using a variety of "overlays". These IMFL objects are the objects which the users actually interact with in our application.
But the starting point for most of our maps (including the one in question) is the AutoCAD export shape files. These include markers that are then used for placing the IMFL objects precisely. The net effect is that you see small "dots" on your shape files. You know what these dots represent, so you use our application to place the correct interactive object "dot" on top of the shape file dots, and you have things precisely located that you can work with, as opposed to shape features that you cannot. This is the point where we now have a functional map in our application. I explain all this because it is important to understand what we are seeing, and why it is a problem, and providing a repro represents a problem since it only manifests on one specific map.
What we are seeing is that for this one map in particular, when we zoom in close to the maximum level (taking max extent and dividing evenly into 20 levels using you default set of zoom levels), things become misaligned. So we may be on Level 16 and the original placement shape dots are aligned with IMFL dots. Zoom one more level to 17, and suddenly all the dots are misaligned. Not by a lot, but enough that you can see a gap between them clearly showing a misalignment. Zoom in again to 18, and the misalignment persists. But zoom one more time to 19 and suddenly everything lines up again. If it were not for that last step, I would have just assumed that there was something imprecise about the placement of the IMFL dots, and that some the discrepancy was being amplified by the zooming. But when it snapped back to the right place as I zoomed closer, that no longer makes sense.
We also have a legend that I implemented similar to the legend you provided with the 2.0 version of the map. When displayed, it dynamically resizes the map to make room. And the map is in a sub-panel of a splitter that can resize, as well as resizing the main window. I also notice the jump to miss-aligned when resizing the application main frame, the splitter, or displaying the legend. And, when it manifests, is sometimes aligns at some zoom levels, jumps out at the next, then back in on the following zoom level.
Looks to me like there is some sort of rounding issue within your zoom transform that is causing variation between different levels and/or overlays.
Relative movement between layers when zooming
I have begun to suspect that this is somehow related to the use of separate cache objects for the static shape overlay and for the IMFLs overlay (for the interactive objects). After removal of the InMemoryBitmapTileCache cache instance from the IMFLs overlay, I have not been able to reproduce the problem. When I began to suspect the cache, I removed it from both overlays, but in subsequent testing with using the cache on the static shape overlay, and it seems to be working so far. Hopefully that helps identify the problem.
Hi Russ,
Thanks for your so detail description, we hadn’t met the relative movement before.
It looks the issue you watched should be related with cache because you cannot reproduce it after remove cache.
We will try to reproduce that, if you have any update please let us know.
Regards,
Don
Removing the cache from the IMFL overlay stopped all of my relative drift repro scenarios regarding the map resizing. So I was counting this a win. Since the loss of caching on the IMFL overlay didn’t seem to noticeably impact performance, I checked in the change and reported it fixed, awaiting potential updates from you guys. I was ready to move on.
Then while testing my change, our guy who has a particular talent for breaking things, hit on another scenario that causes the relative offset 100% of the time, and once jacked up, it remains that way through all zoom levels. All he had to do was use our “auto zoom” feature to pick an object in our application (external to the map) and have the map pan/zoom to bring that object (or objects) to the forefront. This worked without problem in v8.0, so I still think it’s some internal rounding error from your view window transforms when dealing with multiple overlays, or possibly IMFL vs Shape. The logic causing this repro is basically this:
1) Get the target IMFL containing features for the type of the object(s) being selected,
2) Get each target feature and use feature.GetBoundingBox to get the bound of each feature to bring into view
3) Use ExtentHelper.GetBoundingBoxOfItems to basically union the rects to find the bounding rect.
4) Use ExtentHelper.ZoomOut to zoom out a bit, thus providing a margin so that desired objects are well “inside” the bounding rect and don’t wind up partially obscured on the edge.
5) If any side of the bounding rect is smaller than our min-rect (for instance, when only one object was targeted it will be), adjust that dimension to be at the minimum. Often this is one “point”, so the bound is too small, and you get a square bounding box with height and width equal to minDim.
6) Finally, just set the map CurrentExtent using
ThinkGeoMap.CurrentExtent = ExtentHelper.GetDrawingExtent( bound, ThinkGeoMap.Width, ThinkGeoMap.Height );
This is the same code that worked without issue in the previous v8.0 version. Now it causes a relative offset between the IMFL overlay and the static shape file overlay. The end result is that “dots” in shape file and IMFL that normally stack perfectly on top of each other now have a very visible offset with a gap between them. In my scenario, the dots (on both levels) are roughly 1/8" diameter, and you can see this stacked perfectly like looking down on a Towers of Hanoi toy. After running the auto-display (zoom/pan) repro, there will be over 3/16" clear gap between them. It is also worth noting that the distance remains almost (but not quite) exactly the same as you zoom. So it’s not a coordinate issue, which would cause the gap to change with the map zoom. It may also be relevant that styles for both the shape dot and the IMFL feature dot do not alter size with the zoom; their size is consistent at any zoom level.
This is a blocker for us, please advise.
I’m marking this thread resolved. Not because the problem is fixed, but rather because I have realized that I totally misunderstood the problem, and a lot of the information presented here is not actually relevant, but rather just a small piece of the repro picture. Turns out, this actually has something to do with points rendered as Fonts, and affects Point-Font presentation in both IMFL and Static Layers.
Hi Russ,
Thanks for your update, we are glad to get any response from user about the new version.
Regards,
Don