Runtime labels for streets from vector tile package too few, not matching same data in Pro

[PaulCone2]

I am generating data in vector tile package format (.vtpk) for use in the onboard map on our city fire rigs, which uses the ArcGIS Runtime as implemented by our 911 dispatch software vendor.  We were nearing rollout citywide but then a driver from Station 1 notice that not enough of the streets are labeling.  Here is what they see...

Notice how almost all the east/west streets are not labeling.

Contrast with how it looks in Pro -- on the left is the source map for the vector tile package, and on the right that package added to map with other vector tile packages...

MDT MapViewer vector tile labels in Pro

Why are so many street labels missing in the Runtime map?  There are so many absent that the customer is telling me they can't deploy this, and have to stick with the older version that uses raster tiles.

I've tried adjusting many labeling settings but most of them seem geared toward raster tiles.  The palette of settings is basically tranferred over from ArcMap, so which of them can really be applied to vector tiles, especially when they are used by the Runtime?  I've also tried generating an index layer as far down as it will go but I still don't have enough street labels.

I'm using ArcGIS Pro 2.9.2 and the client software uses Runtime 100.11.

Paul Cone

City of Portland, Oregon

[NathanCastle1]

I'm sorry to hear you're having problems with labeling for Vector Tiles in Runtime.

For authoring, I've found documentation on what is supported for labels in vector tiles: https://pro.arcgis.com/en/pro-app/latest/help/mapping/map-authoring/labeling-in-vector-tiles.htm

The text-allow-overlap and possibly icon-allow-overlap properties may be of interest. I did some light tinkering starting with Esri's published reference style, and was able to get better (although not perfect) behavior. Using the Vector Tile Style Editor, I was also able to change the "spacing" property in the symbol position group, which fixed an issue with labeling gaps.

I hope that information can be a useful starting point while I inquire about options for solving the problem.

To better understand and diagnose the issue, it would be helpful to know the resolution and screen size of the device that is being used.

[PaulCone2]

Hi Nathan,

Thank you for the reply.  I did look at that page about vector tile labeling but nothing there seemed to apply because I don't see where in the ArcGIS Pro interface I can set those properties.  And I don't think the Vector Tile Style Editor works with vector tile packages, does it?

The screen in the photo above is 1024x768, so the map is about 80% of that, given the large buttons on the perimeter (it's a touchscreen).

Paul

[Nicholas-Furness]

Hi @PaulCone2,

I sent you a DM. Could you dig that out and get back to me please? Would like to take a look at the VTPK if possible.

Thanks.

[PaulCone2]

Hi Nicholas,

I sent you a reply on Friday within about 30 minutes of your orignal message, but I just hit reply to the automated email from Esri Community and maybe that doesn't work.  I uploaded my .vtpk on Friday as well.

Paul

[Nicholas-Furness]

---

I did look at that page about vector tile labeling but nothing there seemed to apply because I don't see where in the ArcGIS Pro interface I can set those properties.

---

This documentation seems to refer to the Pro setting that translates to "text-allow-overlap" in vector tiles in the link @NathanCastle1 provided.

And this doc seems to cover the setting that translates to "symbol-spacing".

Hope that helps, but would still like to see your VTPKs that are used in the map (see the DM I sent you).

To confirm, you are deploying multiple VTPKs to your Runtime app and combining them in a map, and not using them to generate a single VTPK in Pro, correct?

[PaulCone2]

VTPKs already sent on Friday.  Yes, they are combined on the client side.  In Pro it's just to preview.  Will look at the documentation now.

[PaulCone2]

I looked at the documentation you pointed to.  I'm aware of all of those options as those are the ones ported over from ArcMap.  I have spent hours and hours over several years trying to get the labels right for the raster tile packages.  Unfortunately they don't translate well into what the Runtime does with a vector tile package.  Specifically I've tried Never Remove and Repeat Minimum Interval, with no effect.  I just uploaded my project document and file geodatabase so if you want to try for a better result, that would be great!

[Nicholas-Furness]

Thanks for sharing your VTPKs. When I display them in an iPad Pro (with Runtime 100.11 and Runtime 100.13.1), then they appear good:

It also looks the same in Pro and a Windows Runtime test app:

Also note the size of the red point symbols in my iPad test vs your screenshot, which makes me wonder: What is the DPI of the deployment device? That could help us repro what you're seeing.

But… considering the use case, a more fundamental point is that Vector Tiles are static and labels are positioned when the tiles are cooked. Set aside for the moment that they look wrong on the deployment device and pretty good in our tests, I wonder whether longer term for this use case it might be more appropriate to use the Runtime labeling engine with a feature class of street polylines (perhaps in a mobile geodatabase) and suitable label definitions. You could still rely on the VTPK to render the streets themselves, but use transparent line features to place street labels dynamically.

[PaulCone2]

Well that is odd that you're seeing more labels at what appear to be the same scale (1:4514).

The MDT device is this.  I didn't find a specsheet on the vendor's site but hopefully there is enough information there to answer the DPI question.

Rugged PC Review.com - Rugged Notebooks: GETAC B300X

As far as using Runtime labels from a geodatabase -- that is what we did with the last version of the software, laying them down on raster tiles.  The vendor removed that support in the new version but I'm inquiring if it could be put back.