Hide measurement label

Berend Veldkamp

17 Oktober 2018 15:03

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

• 

  Berend Veldkamp

  17 Oktober 2018 15:16

  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
• 

  Permanently deleted user

  18 Oktober 2018 13:25

  @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
• 

  Nico Burgerhart

  18 Oktober 2018 13:37

  As far as I know that is not correct, there are no language files for each viewer.

  0
• 

  Permanently deleted user

  18 Oktober 2018 13:46

  @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
• 

  Berend Veldkamp

  18 Oktober 2018 13:50

  @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
• 

  Permanently deleted user

  18 Oktober 2018 14:00

  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

Du måste logga in om du vill lämna en kommentar.