Hi,
I've been working enthusiastically with vectortiles for a while now - huge potential compared to the RasterTileCaches !!!! For certain maps I rely on more complex line-strokes - dash patterns (and also 45-degree Hatched Filled Patterns but that's a different topic 😛 ).
When publishing line features as VectorTiles from ArcGIS Pro (2.8.1), "dash patterns" are supported - but it seems that only dashes of "Dasharrays x-y" (6,3 or 10,5 or ....) are supported. More complex dashes like 9,3,3,3 or 10 5 3 5 3 5 ( Line space dot space dot space) are not translated correctly. Not even if you edit them in the VectorTileStyleEditor... not even if you adjust the property "line-dasharray" via editor in the StyleFile of a VectorTilePackage.
Where is the origin of this problem? Is it expected that this functionality will be included?
Are there any workarounds / hacks to get a result anyway (I was thinking of "shape markers" and "dash-pattern-vectorimages")?
Any kind of input is welcome
Andi
The style editor doesn't seem to expose this setting, but there is a "line-cap": "round", property often in place which obscures smaller dashes. Here is a 1,1 dash array with rounded caps:
At an exaggerated width value, you can see the "gaps", but with smaller widths, it appears as a straight line. That said, when I attempt to use the 10,3,3,3 dash array, it renders clearly enough.
Here are the same dash arrays, but with the line cap property set to "butt".
1,1 array w/ exaggerated width
10,3,3,3
And something else, just for good measure.
1,1,3,5,5,5,3,1
I tested opening the tile service in Pro, and it did appear to load the modified dash array just fine.
Hi Josh
Thanks for your reply - I was not aware of these hidden properties.
Still, I couldn't reproduce your solution or I do not understand what I'm doing wrong that it doesn't work for me 🙂
Can you send me the "style file" from the style editor or share the tile service / style so i can take a closer look at differences?
Im still confused because if I use a simple line feature and set the "dasheffect" to e.g. "9,3,3,3", Cap=Butt, Join = Round and then push that to a VectorTilePackage via "Create Vector Tile Package" the 9,3,3,3 pattern seems to be missing.
If I extract the styles\root.json from the VectorTilePackage (vtpk) I'll find the "line-dasharray":[6,2] and "line-width":2 , although originally it was set to 9,3,3,3 and w/ 1.5.
If I edit the style file manually (line-dasharray to 9,3,3,3 and linecolor to ff00ff) and package again to vtpk, add the vtpk to ArcGIS Pro -> no "line-dasharray" change… but the color is updated.
ArcGIS Pro Line Feature | LineFeature to VectorTilePackage | Manually Edited VectorTilePackage - Style (Dasharray 9,3,3,3; Linewith 1.5, Color ff00ff) |
The same goes for the LineFeature, published as vectortile-service to ArcGIS Enterprise Portal (10.8.1):
The Dasharray is not displayed, if i open the style in the styleeditor I encounter the Dasharray 6-2, although it was published from ArcGIS Pro 2.8.1 as Dasharray: 9,3,3,3.
If I change the Dasharray in the Style Editor to 9,3,3,3 nothing seems to happen.
Even if I download the style and change the properties "line-cap" and "line-join" and update the style on the portal, nothing seems to change.
Portal 10.8.1 MapViewer | VectorTileStyleEditor Dash Array | Modified Dash Array |
What am I missing?
Kind regards
Andi
Hm. This seems like it might be Bug territory, that's very odd that it wouldn't work for you.
All I was doing was editing the style JSON of ESRI's main topo basemap, and didn't save it.
This is AGOL-only, but you can try using the Simple Vector Style Editor, too. You could share your Portal style publicly and add it to an AGOL account in order to access it there. It gives you a nice, easy way of editing the JSON directly and seeing the results.
I switched to AGOL for testing.
In AGOL-VectorTileStyleEditor, the dasharray changes to e.g. 9,3,3,3 are directly properly displayed, like you already showed. For the VectorTileStyleEditor in Enterprise Portal 10.9 that seems not to be the case.
However, on AGOL if I save the 9,3,3,3 style for the VectorTileStyleEditor and open it in a new map with "mapviewer classic", the dashpattern is incorrect displayed (not 9,3,3,3, I guess 9,3 ?!).
If I open the same style with the new mapviewer (mapviewer beta), the dashpattern 9,3,3,3 appears.
Oddly enough, if I open that TileLayer from AGOL (via .*pitemx ) in ArcGIS Pro 2.8.1, the dasharray is not rendered as 9,3,3,3 (but for you it worked?!).
So is the Mapviewer-Classic not able to handle the 9,3,3,3 dasharrays?
Andi
I ran into the same issues.
For the time being I am using the following solution to ensure my line displays as a dash-dot-dash. It's not perfect, but since we want to use the tiles in map viewer + Pro + map viewer classic this is what I will be doing for now.
Thanks for sharing your workaround.
In my case I have to display the correct lines-dashed, therefore the workaround is unfortunately not working for me.
It's been a while since the original post and much was improved regarding VectorTiles, especially with the new MapViewer 🙂 Still some things are missing... as you mentioned in interaciton with ArcGIS Pro (Correct translation into VT, ScaleBasedLabel-Options, ...). Would be nice to be able to define everything in ArcGIS Pro and not readjust/ configure the layers in VTSE.
Another thing in noticed: It seems that the linedash-array is not always correctly translated from ArcGIS Pro into the style of a hosted tile layer.
Anyway - I'm looking forward to more improvments
Just wanted to let you know that I've created an idea for this issue (https://community.esri.com/t5/arcgis-pro-ideas/complex-dash-patterns-from-vector-tiles/idi-p/1196864...)
I've also spoken to @TommyFauvell & @DanielStephen and they are are aware of the issue. I'll be making a support case as well to get this logged as an enhancement request.
@BrettFrahm Great and wonderfull news! I'm "glad" that I'm not the only one this bothers, happy that there is awareness on esri-side and I hope that the enhancement request will be heard implemented 🙂 In some specific cases (e.g. maps with "law-regulated-representations") this is the only missing piece for us to move from a resource heavy cached mapservice to the nice light vectortile cache.