ThinkGeo.com    |     Documentation    |     Premium Support

V12.1 - LabelDuplicateRule.OneDuplicateLabelPerQuadrant

ThinkGeo Team,

I really like the new property of OneDuplicateLabelPerQuadrant because it provides for better labeling.

What is your definition of Quadrant? How can I determine what these are?

Below is a screen-capture of one extent which shows the effect of OneDuplicateLabelPerQuadrant.

Also, there are still street segments that could use a label. In the below screen capture you’ll notice N Orchard St. The street north and west is also N Orchard St. Why would this segment not be labeled?

To see this full image you’ll have to mouse-click on it.

Thanks,
Dennis

Thanks Dennis,
Quadrant means 1/4 Map area. So for your case if you move the map upper a little. Another N Orchard St may show up.

Thanks

Frank

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.

image

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

image

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(768
768). 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
image

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