I recently noted a problem with the display of shape files. I’ve distilled down a VERY simple map application that displays a single shape file in the simplest way I could devise. I had trouble getting it (the zip file) small enough to upload, but managed to upload a runnable build so that you can (hopefully) see exactly what I see without worry about build numbers and such.
So, just run the exe provided. It should come up with the shape file loaded, and you will see a number of light orange points with associated labels. The problem is, they are not all showing up. If you drag the right border left/right you should see points and/or labels coming and going seemingly at random based on whatever extent you happen to have. You can also pan to see the same behavior.
I’m assuming this is a bug? If so, it’s pretty severe and I’m surprised it’s gone unnoted. On the other hand, it could be my fault, but as simple as this is, I fail to see how. I’m looking forward to hearing what you find, and more importantly, how to fix this…
Problem (bug?) displaying shape files
I’ve posted this repeatedly, and keep getting errors. I finally got the text to post. After loosing it once and retyping it, I started it in a text editor for repeat attempts. But the only way I could get it to post was without the zip attachment.
ShapesDisplay.zip (1.96 MB)
Looks like it went in ok for my reply, but for some reason wouldn’t go along with my initial post…
Hi Russ,
I think it’s not a bug but by design of TextStyle, which
will determine which labels will be displayed or drawn to the map based on some
settings, such as “Grid Size”, “Duplicate Rule”, Clipping”, “Fitting Factor”
etc. I guess you can have a complete try of all these configurations with “Map
Suite GIS Editor” shown at thinkgeo.com/gis-editor/
. For the sample you provided, when we drag the map from left to the right, the
drawing viewport is changed and the position of each feature is changed as
well, thus Map Suite need to recalculate the label position or visibility again.
Maybe it will be hidden this time. I guess that’s why you got what you described.
Hope it helped, Thanks,
Johnny
I’m pretty sure our users (and product managers) won’t see that as anything but a bug. It would be bad enough if things you were looking for just happened not to be where they should be. But when zoom didn’t change, content didn’t change, map didn’t even move, but things come and go unexpectedly when the right boundary moves. I’m not sure what to say on this, except I’ve got to find a way to make it show things consistently, regardless of non-apparent constraints. Overlapping may be necessary, and may not be avoidable depending on user selection for zoom visibility thresholds, location, font point size, etc. But if its’ there, it needs to show without exception.
I’ve tried the editor, but had very little luck with getting anything useful out of it. Maybe I’ll take another poke at it when I can. But for now, if this is not considered a “bug”, I would just like to know what settings are necessary to make that sample show every item consistently regardless of resizing the view port.
For another perspective, our application has a very dynamic UI around the perimeter of our map (based on yours). For instance, the “legend” that was part of your older product but is now gone, I’ve had to re-implement on my own. It and other interactive UI elements (including a message panel, a control tool box, etc.) “slide out” from the side as needed and based on user need/context. There is no way that having elements just wink in and out when the map details didn’t otherwise change (no pan, no zoom, nothing intentionally hidden/show) is not going to be acceptable.
Again, even if it overlaps or is partly obscured, it absolutely must show what the user has configured all the time every time. If there is something that just doesn’t draw, perhaps something that is signaling an error that the user is now not going to see because it just happens to not be visible due to the client window being 1 pixel narrower than it was earlier, and bad things happen that cost them money and resources, I don’t want to be the one trying to explain to them about some obscure gridding details in the map component we chose to use, and how “that’s just by design”.
If the user chose thresholds or layer ordering and things are obscured because it’s too busy or showing when zoomed out too far (improper threshold), then that’s user error. But when things are showing just fine, and then the right border several inches across the screen moves, changing nothing around the element in question, and perhaps due to UI elements that have nothing to do with the map other than taking up a few pixels on the edge, and that important element just disappears from view, that’s something else entirely.
Any suggestions on what I need to do to get a consistent display of all specified points/labels at all times regardless of any other considerations, particularly those that won’t be obvious to the user. Overlapped or obscured is unfortunate, but as long as it shows what the user specified, it is FAR superior to “I can see where it is supposed to be, and there is nothing else there to block it, but it’s missing and I don’t know why”.
Still looking for a solution to this problem. None of the stuff I tried corrected the seemingly random flicker in and out of visibility. I fail to see why simply moving the right form boundary a few pixels causes things to wink in and out with no other visible change to the map content.
Hi Russ,
Sorry for the delay as we are busy with an updates of the Map Suite Product Center and related products release these days. To get a consistent display of the specified point/ labels at all times regardless of any other considerations, please try the following 2 configurations for TextStyle, I guess it should be much better, if still runs into problem, please let me know:
mapLayer.ZoomLevelSet.ZoomLevel15.DefaultTextStyle.BestPlacement = false;
mapLayer.ZoomLevelSet.ZoomLevel15.DefaultTextStyle.DuplicateRule = LabelDuplicateRule.UnlimitedDuplicateLabels;
For Legend, I guess you can try the LegendAdormentLayer or LegendAdormentOverlay to get what you want, please check the sample at wiki.thinkgeo.com/wiki/Map_Suite_Wpf_Desktop_Edition_All_Samples#Show_A_Legend, if it doesn’t fit your requirement, please feel free to let us know.
Thanks,
Johnny
I’ve tried both of those, and others, they seem to make no difference. I pasted in your code just now to make sure there was not some confusion about what I had or had not tried, perhaps with specific combinations, and as before, it made little or no difference. Did you actually try it in the sample I sent?
And forget about the Legend. The legend adornment layer sample falls unbelievably far short of the legend from pre-3.0. As such, because our customers expect the functionality, I’ve already implemented a full replacement for it.
The only reason I mention it at all is that my legend (and other UI features) dynamically slide out from the sides as needed (and based on context) causing the map client area to be reduced, much like what I described about resizing the form border on the right side using the mouse to demonstrate the problem. Again, nothing about the map shapes change. No zoom, no pan, no change at all other than the right border moves a few pixels. This is not acceptable and may well be an absolute deal breaker if it cannot be resolved. If that is the case, I need to know ASAP so I can report the problem and we can decide whether to continue work using the ThinkGeo product or not. I really very strongly suspect we’ll have to abandon the entire project and find another map component if this proves insurmountable.
Russ,
I tried what Johnny said and it works, after adding the following code,
txtStyle.DuplicateRule = LabelDuplicateRule.UnlimitedDuplicateLabels;
Then I added this line of code, it would be like following:
txtStyle.OverlappingRule = LabelOverlappingRule.AllowOverlapping;
No labels will be “flashing” during panning.
Label is a complex topic and we have whole bunch of properties just for that. Please check the following link which would help you understand TextLineSegmentRatio and GridSize property as well.
thinkgeo.com/forums/MapSuite…fault.aspx
Ben
Please accept my sincere apology. I had tried his suggestion previously on my own, and also tried again with his suggestion directly copy-n-paste to “make a mistake” and get a false result. I went back and looked again after reading your post, and I spotted the problem with my adopting Johnny’s suggestion (and likely my own attempts).
mapLayer.ZoomLevelSet.ZoomLevel15.DefaultTextStyle = txtStyle;
Basically the zoom ZoomLevel15 Default Text Style properties were being set before an overlooked subsequent complete replacement of the Text Style that lacked the configuration. So my inability to make it display consistently was (as is now obvious) completely my fault. Thank you for your assistance.
But I must say I remain rather surprised that the default behavior is to, from the users perspective, unpredictably show/hide various labels. Particularly when they show/hide when seeming irrelevant properties are changed (like resizing the right border where there is not so much as a pan of the map). I could certainly understand a property to prevent inter-label interference being made available, but the choice of default is surprising, particularly given the rather dramatic visible “twinkling” effect. I’ve noticed that your “how do I” application along with many of the samples don’t support resizing, and perhaps that is the reason? The lack of resize in “how do I” is particularly noticeable when trying to examine the provided sample code (having to constantly scroll horizontal).
Another thought, but I think in spite of my oversight yielding unexpected results, if I had found your referenced detailed description in my (many) searches, I might well have sorted it out for myself. Something like that would be great to have in an article, unless such a thing already exists and I simply haven’t found that either…
Thank you very much for your comments, Russ. It’s great that it works for you. I think you are right that we need to have more discussion on the default value, I have entered your requirements to our internal issue tracking system and submitted to development guys. Just as mentioned by Ben, the TextStyle is a really complicated style, which has lots of properties used under different circumstances. Here is a description on kinds of styles, maybe something is missed, but we have created a team who are working on the documentation stuffs now, hope it can give a good guide on our APIs in near future:
Map Suite Style Guide: wiki.thinkgeo.com/wiki/Map_Suite_Style_Guide.
Some overview of TextStyle in GisEditor (just show some built-in settings):
Map Suite GIS Editor: Simple Text Style: Duplication and Clipping Tab: youtube.com/watch?v=HwhR9GoBT2c
Map Suite GIS Editor: Simple Text Style: Icon Tab: youtube.com/watch?v=gf9chNbLgx0.
Map Suite GIS Editor: Simple Text Style: Placement and Formatting Tab: youtube.com/watch?v=_KYj9m89u18
Thanks,
Johnny
Thank you, I’ll have a look.
Welcome, Russ. Any questions please feel free to let us know.
Regards,
Johnny