Turn on\off layers and updating of the cached services,

[JamalNUMAN]

Turning on\off layers and updating of the cached services,

Sounds that there are two issues with the cached (tiled) services


1. When caching an mxd file that contains multiple layers, then these layers can???t be turned on\off on the web mapping application. Does this mean that we need to create a separate service for each single layer to be able to turn it on\off from the web mapping application?

[ATTACH=CONFIG]28635[/ATTACH]

2. How the cached services are updated as the data changes? Do we need to ???overwrite an existing service??? when the data changes (edited)? In case of dynamic service, we don???t need to ???overwrite an existing service??? as the data edited, the edits are transferred to the web application directly.


Thank you

Best

[MarcoBoeringa]

Turning on\off layers and updating of the cached services,

Sounds that there are two issues with the cached (tiled) services


1. When caching an mxd file that contains multiple layers, then these layers can�??t be turned on\off on the web mapping application. Does this mean that we need to create a separate service for each single layer to be able to turn it on\off from the web mapping application?

Jamal,

Cached map services are just "dumb" images, like a JPEG photo from your iPhone, even if the original data was vector / Feature Class data. In this respect, they do not differ from "image services". They do, however, support things like identifying based on a course back to the original vector data in the geodatase.

So yes, if you include multiple layers in a single cached map service, there is no way to turn on/off a single layer, as all layers are in that "single" image (albeit cut up in many tiles). As you deducted, you need to create a separate service for each layer if you need that turn on / off ability for each individual layer.

2. How the cached services are updated as the data changes? Do we need to �??overwrite an existing service�?� when the data changes (edited)? In case of dynamic service, we don�??t need to �??overwrite an existing service�?� as the data edited, the edits are transferred to the web application directly.

As for the "dynamic service", this is because you are always directly reading the original data, not a copy that may become "outdated" if not explicitly refreshed / renewed.

You may consider using the Create tiles on demand option, as described on this Help page, and in detail on this Help page: Map caching on demand. This overcomes the need to pre-generate your entire caches, since it creates tiles on the fly based on user demand, to be stored for later usage by other users. This allows you to gradually build up the cache instead of an entire cache in one go.

Also mind this warning in the Help about cached image services, that probably also applies to cached map services based on Feature Class data:

"If the update (edit: of the caches) cannot keep up with the changes in an acceptable amount of time or the image service has to be changed frequently with different image properties, then the image service is not appropriate for caching."

2. How the cached services are updated as the data changes? Do we need to �??overwrite an existing service�?� when the data changes (edited)?

See the Updating tiles topic on the Help page I linked before: Map caching on demand

[JamalNUMAN]

Jamal,

Cached map services are just "dumb" images, like a JPEG photo from your iPhone, even if the original data was vector / Feature Class data. In this respect, they do not differ from "image services". They do, however, support things like identifying based on a course back to the original vector data in the geodatase.

So yes, if you include multiple layers in a single cached map service, there is no way to turn on/off a single layer, as all layers are in that "single" image (albeit cut up in many tiles). As you deducted, you need to create a separate service for each layer if you need that turn on / off ability for each individual layer.



As for the "dynamic service", this is because you are always directly reading the original data, not a copy that may become "outdated" if not explicitly refreshed / renewed.

You may consider using the Create tiles on demand option, as described on this Help page, and in detail on this Help page: Map caching on demand. This overcomes the need to pre-generate your entire caches, since it creates tiles on the fly based on user demand, to be stored for later usage by other users. This allows you to gradually build up the cache instead of an entire cache in one go.

Also mind this warning in the Help about cached image services, that probably also applies to cached map services based on Feature Class data:

"If the update (edit: of the caches) cannot keep up with the changes in an acceptable amount of time or the image service has to be changed frequently with different image properties, then the image service is not appropriate for caching."



See the Updating tiles topic on the Help page I linked before: Map caching on demand

Thank you very much Marco for the very useful answer.

1. I couldn�??t figure out the effect of �??update cache automatically�?�. Doesn�??t this mean that the cashed service is updated automatically once the source data is edited?

[ATTACH=CONFIG]28697[/ATTACH], [ATTACH=CONFIG]28698[/ATTACH], [ATTACH=CONFIG]28699[/ATTACH]



2. �??The create cache on demand�?� sounds not to solve the issue of updating the tiles neither. The database is updated while the cached services are not

[ATTACH=CONFIG]28700[/ATTACH], [ATTACH=CONFIG]28701[/ATTACH]



What I�??m looking for is scenario from which cached services are automatically updated as the database is edited.

The cross-road now is performance versus updating!

[MarcoBoeringa]

1. I couldn�??t figure out the effect of �??update cache automatically�?�. Doesn�??t this mean that the cashed service is updated automatically once the source data is edited?

Jamal, that is a good catch and one I think ESRI needs to answer or at least document better, because I am now confused what the Update cache automatically option is actually supposed to do: determine the way the one time creation of the cached map service is done, or truly update your cache automatically. Beats me based on the documentation... it seems the "Update cache automatically" may actually be a very bad description of what this option does. Please see the:

Map service caching configuration

heading on this WIKI GIS page maintained by ESRI. Scroll down on that page to see the heading I meant. It seems this option has little to do with "updating" your map cache automatically when something changes, but rather refers to a choice to use an available default caching service for creating the caches, or to define manually your own running caching services (server computers you dedicated for the heavy job of creating cache tiles). Please bear with me I am entirely going by the documentation here~! I don't have a running ArcGIS Server available, neither generated caches myself.

It is going deep here into ArcGIS for Server, but you may wish to read this Help page too:

Allocation of server resources to caching

2. �??The create cache on demand�?� sounds not to solve the issue of updating the tiles neither. The database is updated while the cached services are not

Jamal, you can probably not properly test this feature with just a small dataset. If the dataset is so small so as to require only one tile, your tile will be generated on the first view. If you subsequently update some portion of your geodatabase in an area that is still within the bounds of the original dataset, as you do here, there may be no trigger to generate a new tile, as there is already a tile for that area. I don't know if the tile is supposed to update or not automatically based on an edit, that may require the other option "Update cache automatically".

Also mind this option from this Help page:

"Allow clients to cache tiles locally

When this box is checked, Esri client applications, such as ArcMap, are allowed to keep a local cache of any tiles they retrieve from the server. This can help the client view the tiles more quickly when returning to the area. Clients must manually clear their cache to get any newer tiles from the server; therefore, consider unchecking this box if you'll be updating your cache frequently."

I also still think you may be misinterpreting or mis-using the caching features. Caching is only really appropriate for complex maps, where the cache represents multiple, or complex layers, including imagery, highly detailed vector Feature Class data (e.g. scale 1:1000 - 1:25.000), or data represented using complex cartographic symbology or intelligent labelling.

I do know you use aerial imagery too, for which using map caching - especially in combination with overlayed Feature Classes for for example roads or buildings - may be entirely valid.

In all other cases (non-complex Feature Classes, basic labelling), you may be better off using a dynamic Map Service, of even a Feature Service.

As a reminder, from this Help page:

"Can I cache all my maps?

A map cache represents a snapshot of your map at one point in time. Because of this, caches work best with maps that do not change frequently. These include street maps, imagery, and terrain maps.

If your data tends to change, you might still be able to use the caching tools to periodically update the cache. You can even schedule these updates to occur automatically. To understand whether your frequently changing map can still be cached, it helps to ask these questions:

How up-to-date does my map need to be?

If the data you see on the map needs to be live, with no time delay acceptable, caching is not appropriate. However, if a short delay is acceptable and the cache updates can be performed within that time window, you can still use caching.

How big is the cache and how widespread are the changes to my data?

These two questions go together. A large cache takes more time to create. It may be practical to update your large cache only if you can isolate the changed areas and update those alone. If the cache is small, you might be able to quickly rebuild the entire cache.

If the update cannot keep up with the changes in an acceptable amount of time, the map is not appropriate for caching.

After considering the questions above, use caching whenever it's appropriate. The performance benefit that you gain is probably worth the investment it takes to create and update the cache."

[JamalNUMAN]

Jamal, that is a good catch and one I think ESRI needs to answer or at least document better, because I am now confused what the Update cache automatically option is actually supposed to do: determine the way the one time creation of the cached map service is done, or truly update your cache automatically. Beats me based on the documentation... it seems the "Update cache automatically" may actually be a very bad description of what this option does. Please see the:

Map service caching configuration

heading on this WIKI GIS page maintained by ESRI. Scroll down on that page to see the heading I meant. It seems this option has little to do with "updating" your map cache automatically when something changes, but rather refers to a choice to use an available default caching service for creating the caches, or to define manually your own running caching services (server computers you dedicated for the heavy job of creating cache tiles). Please bear with me I am entirely going by the documentation here~! I don't have a running ArcGIS Server available, neither generated caches myself.

It is going deep here into ArcGIS for Server, but you may wish to read this Help page too:

Allocation of server resources to caching



Jamal, you can probably not properly test this feature with just a small dataset. If the dataset is so small so as to require only one tile, your tile will be generated on the first view. If you subsequently update some portion of your geodatabase in an area that is still within the bounds of the original dataset, as you do here, there may be no trigger to generate a new tile, as there is already a tile for that area. I don't know if the tile is supposed to update or not automatically based on an edit, that may require the other option "Update cache automatically".

Also mind this option from this Help page:

"Allow clients to cache tiles locally

When this box is checked, Esri client applications, such as ArcMap, are allowed to keep a local cache of any tiles they retrieve from the server. This can help the client view the tiles more quickly when returning to the area. Clients must manually clear their cache to get any newer tiles from the server; therefore, consider unchecking this box if you'll be updating your cache frequently."

I also still think you may be misinterpreting or mis-using the caching features. Caching is only really appropriate for complex maps, where the cache represents multiple, or complex layers, including imagery, highly detailed vector Feature Class data (e.g. scale 1:1000 - 1:25.000), or data represented using complex cartographic symbology or intelligent labelling.

I do know you use aerial imagery too, for which using map caching - especially in combination with overlayed Feature Classes for for example roads or buildings - may be entirely valid.

In all other cases (non-complex Feature Classes, basic labelling), you may be better off using a dynamic Map Service, of even a Feature Service.

As a reminder, from this Help page:

"Can I cache all my maps?

A map cache represents a snapshot of your map at one point in time. Because of this, caches work best with maps that do not change frequently. These include street maps, imagery, and terrain maps.

If your data tends to change, you might still be able to use the caching tools to periodically update the cache. You can even schedule these updates to occur automatically. To understand whether your frequently changing map can still be cached, it helps to ask these questions:

How up-to-date does my map need to be?

If the data you see on the map needs to be live, with no time delay acceptable, caching is not appropriate. However, if a short delay is acceptable and the cache updates can be performed within that time window, you can still use caching.

How big is the cache and how widespread are the changes to my data?

These two questions go together. A large cache takes more time to create. It may be practical to update your large cache only if you can isolate the changed areas and update those alone. If the cache is small, you might be able to quickly rebuild the entire cache.

If the update cannot keep up with the changes in an acceptable amount of time, the map is not appropriate for caching.

After considering the questions above, use caching whenever it's appropriate. The performance benefit that you gain is probably worth the investment it takes to create and update the cache."

Thank you very much Marco for the valuable elaboration. This is very useful.

Best

Jamal