Hide measurement label
Hi,
We're using a trick to hide 'total length' measurement labels. We set the color to red, and then use some custom css that hides red path and text elements in the measurements graphics layer. This works fine.
However, when we use the Export Map activity in a workflow, our custom css is not used, and the labels show up.
Does anyone know a trick to hide these labels in exported maps?
0
-
I found that labels are hidden properly if I clear "language-measurement-polyline-final-markup-label" and "language-measurement-polygon-final-markup-label" in mapping.xx-xx.json.js. It's just that this is a global viewer setting that has effect on all sites.
I'd still appreciate other options.0 -
@Berend,
If you make that change in [sitename]/viewers/[viewername]/virtualdirectory/resources/locales/mapping.xx-xx.json.js it should only affect that one single viewer - not all sites.0 -
As far as I know that is not correct, there are no language files for each viewer. 0 -
@Nico, we use custom language files for every viewer we publish. If the files aren't there you can just create your own directory and put your custom locale files in there. The location can actually be anywhere - the path is set in your desktop.json.js file under the mapping library section. { "id": "Mapping", "uri": "Resources/Compiled/Mapping.js", "locales": [ { "locale": "en-US", "uri": "{ViewerConfigUri}../../../Resources/Locales/Mapping.en-US.json.js" }, { "locale": "fr-CA", "uri": "{ViewerConfigUri}../../../Resources/Locales/Mapping.fr-CA.json.js" } ] }0 -
@Peter, How do you handle upgrades to newer versions of the viewer, where additions are made to the language files? It seems a lot of work to keep track of changes you make to individual viewers. 0 -
There is a bit of work involved for sure but there are a couple things that make this reasonable for us:
1) being a govenment organization change doesn't happen quickly so we might only upgrade viewer versions once a year or maybe every two years.
2) we have overlapping infrastructure (new and older versions of Essentials) so we can migrate applications over longer periods as they need maintenance
3) there are usually only a handful (maybe a couple dozen, depending on how many versions we're jumping) changes to be made each time. WinMerge really speeds the process of identifying and making changes between files.
4) Regardless of the time it takes (which is still reasonable) using custom locale files is:
1) the only way we can fully support both official languages, and
2) the only way we can have unique titles/subtitles/custom strings for each site.0
Please sign in to leave a comment.
Comments
6 comments