hi Frank,
You’ll notice that N Orchard St turns east and ends. Below are a few screen-captures.
Dennis
The below screen-capture shows that the section of N Orchard St in question is labeled upon a ZoomOut from ZoomLevel17 to ZoomLevel16.
This is the center of the map extent, a ZoomTo was used to center the map at this point.
Frank,
Below shows N Pine Grove Av properly labeled at ZoomLevel17, but at ZoomLevel16 it is not properly labeled. This is the opposite of what is happening with N Orchard St.
Dennis
Thanks Dennis,
Here are my answer base on the screenshot. The first one do you mean the “N Orchard St” not show up in the zoomlevel17? This probably because the road not include in the zoomlevel17.
It is difficult to get the road labeling perfect. Sometimes we have to zoom in or zoom out a little to see the road name.
Thanks
Frank
Frank,
N Orchard St is rendered for ZoomLevel15-ZoomLevel20. It is there. Both segments are labeled at ZoomLevel16, but not ZoomLevel17.
For N Pine Grove Av when I make those red buildings invisible then the label of N Pine Grove Av does appear as shown below. However, there is plenty of room to render the label when those building labels are present.
My application is used in a 91-1- call center. The users do not have free time to casually zoom in/out to see if a street label is rendered.
Dennis
hi Frank,
I do want to acknowledge that I agree that labeling is a very complex process and any changes would have to be thoroughly thought-out. Shortcomings on street labeling is about the only concern my users have with my application.
More on my last few postings…for kicks I changed LabelOverlappingRule from NoOverlapping to AllowOverlapping for both the Transportation and BuildingsHighRise (red polygons) layers, but it had no effect.
There’s another obscure labeling issue that would be nice to have refined. That is the labeling of ‘joined’ versus ‘disjointed’ line segments. In the screen-capture below we have W Schubert Ave that consists of six segments as noted by the scope icon. There are two sets of segments. Each set has three ‘joined’ segments. The two sets are ‘disjoined’. Note that the joined segments on the right are labeled twice, but that the set on the left is not labeled at all. My recommendation is that before labeling joined segments twice it should first look for a disjoined segment and label that instead.
Regards,
Dennis
Here’s another example of the same thing with W Deming Pl.
Thanks Dennis,
The mapsuite render the map by drawing tiles. Each tile is 256256. If the road is in the edge of the tile we may not draw the label no matter NoOverlapping or AllowOverlapping. Because the label will get cut. That mean only half of the label may drawn. There is one thing we could do for this. We could use
shapeFileFeatureLayer.DrawingMarginInPixel = 256;
This will draw some extra area(768768). Then cut it to 256256. and put all these 256256 together. This way even the label on the edge of 256*256 tile. It will also draw correct.
You can find some more detail here When Label spans tile border, cuts off
Thanks
Frank
Frank,
Yes, I’ve encountered labels being cut-off as you describe. However, that is not the issue here.
Has any progress been made on my original issue with the labeling of N Orchard St?
Thanks,
Dennis
hi Frank,
I’ve got another very odd labeling issue for you folks.
A polygon layer named Buildings which makes use of ValueStyles for the following ZoomLevel’s…
ZoomLevel15 apply to ZoomLevel16 labels are not used
ZoomLevel17 apply to ZoomLevel18 Label FontSize=8
ZoomLevel19 apply to ZoomLevel20 Label FontSize=14
I’ve only noticed this oddity on one building so far.
The Building is rendered from ZoomLevel15 to ZoomLevel16, but its label is not used.
The label is rendered at ZoomLevels’s 17, 18, and 20, but not rendered at 19.
This all works under V10.6, it is the same code and same area and label styles.
The building in question is the small diagonally positioned one with a label of 413-415.
Screen-captures below.
Dennis
ZoomLevel17
ZoomLevel18
ZoomLevel19
ZoomLevel20
Thanks Dennis,
It would be difficult to dig into the detail base on snapshot. since there are few label issue in this post. And the label placement is import for your application. We’d better extract the related code to a simple project. and we could debug it with our core code.
Thanks
Frank
Frank,
I’ll attempt to reproduce this behavior in a test application.
This takes time because my application is data-driven from an SQL database. Nothing having to do with layers, styles, overlays, etc is hard-coded.
Dennis
Hey Dennis,
For the label placement we fixed a bug. For some reason some tile will miss some label it should draw. Could you try with the latest V12 beta version?
Thanks
Frank
hi Frank,
The label in the screen-capture below is now rendered properly at all ZoomLevel’s. However, there are other building labels that continue to have the same issue.
Labels in regards to streets are the same as before so none of those have been fixed.
Dennis
Thanks Dennis,
If you could extract the code to isolate the issue. I understand your project may very complicate. That will be very helpful for us to add the demo project to our source code to debug the issue.
Thanks
Frank
Frank,
I will attempt to re-create this in another application for you.
Dennis
Thanks Dennis
We will look into it once we get the sample.
Frank
Frank,
In regards to the labels being missing on the Buildings Layer…I have discovered that I was applying the OneDuplicateLabelPerQuadrant by mistake, which caused the labels to not be rendered. I have changed to UnlimitedDuplicateLabels, which results in these labels being rendered as expected.
I would like to get back to my original issue, which is the labeling streets layers (or any line feature for that matter).
My conclusion at this point is a variation of my September 18th proposal. “My recommendation is that before labeling joined segments twice (within the same quadrant) it should first look for a disjoined segment (within the same quadrant) and label that instead.”
This was shown in the screen-capture in a previous post.
In my mind it is illogical that W DEMING PL is labeled twice east of N CLARK ST and not labeled at all west of N CLARK ST.
Another of my original issues is the labeling of N ORCHARD ST. The segment north of W DIVERSEY PKWY is not labeled at ZoomLevel17, but is labeled at ZoomLevel16. It should also be labeled at ZoomLevel17.
Dennis
Dennis,
Do you have any progress to re-create this in another application.
Thanks
Frank
hi Frank,
I’ve almost completed an application that allows the specification of many of the TextStyle properties so that I can see the effect of changing them in real-time.
I hope to have the application complete next week. When I do I’ll send an email with a DropBox link.
Dennis
Thanks Dennis,
That will be very helpful.
Thanks
Frank
hi Frank,
I’ve completed the application and just sent an email to support@thinkgeo.com with a DropBox share link.
Thanks,
Dennis
