nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Map Cache Tiles - labels cut off

LeonScott

I have a tiled map service with addresses labeled on it. Sometimes a label gets partially cut off (see attached). Is there a way to prevent this from happening. I'm guessing this is occurring at the edge of a tile.

Leon

[ATTACH=CONFIG]29912[/ATTACH]

Capture.PNG

mpboyle_4-1779802967821.png

Finde mehr Beiträge mit dem Tag

Accepted answers

DennisJarrard

Something else you might look into is to use the Map Server Cache Tiling Scheme to Polygons tool in conjunction with the Tiled Labels to Annotation tool. This method essentially subdivides a data frame extent using the same scales as an existing map service cache tiling scheme and creates tiles over a large area, or "supertiles". Since the supertile extent is larger than the actual tiles defined in the scheme, tiles used as input into the Tiled Labels to Annotation tool can convert labels to annotation over a larger area at a time. This process minimizes annotation duplication across tiles. It also allows you to see how the map will label based on the zoom level you are at, so if you are using standard labels, you'll know if they will get cut off and be able to adjust accordingly before waiting for a cache to be created to see the result.

All comments

WilliamCraft

I have a tiled map service with addresses labeled on it. Sometimes a label gets partially cut off (see attached). Is there a way to prevent this from happening. I'm guessing this is occurring at the edge of a tile.[ATTACH=CONFIG]29912[/ATTACH]

Which version of ArcGIS Desktop and ArcGIS Server are you using? In terms of your building layers' label properties, are the labels being generated directly from the buildings polygon layer or from a point layer in the map document? The behavior you're seeing probably IS due to there being two adjacent tiles, as you've suspected. When the cache tiles are created, the caching process re-renders the layers in the map document at a particular scale and extent for each tile. You should probably check your lebeling Placement Properties; my guess is that the labels are drawing in different places around your features depending on the extent of your map document. If the label is drawn on in the middle of the feature for one tile, and then the map document centers on a new extent and therefore shifts for the next tile to be created, the label might be drawn to the right, left, top, or bottom of the feature instead.. or it simply might not draw at all depending on your label weights compared to what other features are nearby. Later when rendering those tiles next to one another, it looks like the label is cut off. That's my theory anyways. What you might need to do is "force" your labels to stay in the same place no matter where the map document pans for a particular scale. I find this easier to do with a point layer; that is, generate building centroids and symbolize them to nothing and force the label to always draw on top of the point location giving them a high weight in the pecking order.

LeonScott

I'm running 10.1 SP1 for both desktop and server. I am labeling the addresses numbers from address points and placing the label "Centered on point". I do have the "May shift label upon fixed postion" option checked. I'm not sure how much of an impact that has, but will try it without.

Leon

DennisJarrard

LeonScott

Thank you for the suggestion, Dennis. I will take a closer look at those tools to automate address annotation for my basemap. Forcing the label to center on the point is not solving the problem.

Leon

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.