|     Documentation    |     Premium Support

Confusion regarding different cache types


I’m a little confused about how to correctly, or most effectively, use different caching options you are offering.


I think the basic use case for WMS/WMTS services is to have a WmsOverlay or WmtsOverlay. These both offer TileCache property and I have been using those for caching. But then again WmtsOverlay has also ProjectedTileCache property, that is not present on WmsOverlay. What’s the difference and what’s the recommended use?

  1. WFS

I expected to find WfsOverlay for WFS services but that wasn’t the case. Instead I need to create a LayerOverlay and then add WfsFeatureLayer into that overlay.

I think with this approach overlay might cache invalid tiles in case of network/service error? This happens with both Wms- and Wmts layers when attached to LayerOverlay.

Anyway, LayerOverlay has the TileCache property but then again WfsFeatureLayer has GeoCache property in it’s FeatureSource. Can I use these both at the same time? What’s the recommended use? Is there any another cache type for vector sources (vector cache)?

  1. ThinkGeo Cloud offering

Both ThinkGeoCloudRasterMapsOverlay and ThinkGeoCloudVectorMapsOverlay have TileCache property. But on top of that ThinkGeoCloudVectorMapsOverlay has also VectorTileCache. I have been using only VectorTileCache but why there’s two caching properties? What’s the recommended use?

  1. Bonus :smiley:

When using any web map service based overlay it seems impossible to get the correct bounding box when calling GetBoundingBox() method. Now I need to fetch the service capabilities and parse bounding box for each layer service is offering as it seems that overlay, connected to given service, is unable to provide the BB. Feature or bug? Any workarounds or recommendations?

  1. Megabonus :star2:

WMS/WMTS/WFS services might offer content in multiple different coordinate systems. Is there any reasonable way to determine correct MapUnit for WPF MapView (meter, decimal degree) other than trying to figure it out from given EPSG/SRID’s projection string?

Thanks a bunch!

Hey @Mikko_Viitala,

  1. Only use ProjectedTileCache if you are using a ProjectionConverter and want to cache the tiles in the projected format. Otherwise, using the TileCache is always going to be the best option.
  2. The GeoCache is only an in-memory cache that stores features for a given bounding box while the app is running. I’m not sure if that would meet your requirements. And the reason why there is no WfsOverlay is because it is feature based. And the LayerOverlay cache would be for all layers regardless of whether or not one of those layers were unsuccessful. What you could do is subclass the LayerOverlay specifically for WFS that checks the network connection before caching the features.
  3. The VectorTileCache stores tiles in the .pbf format while the TileCache stores the rasterized image resulted from drawing the vector information. If you only care about the images and not the vector info, the the normal TileCache is probably sufficient and possibly takes less disk space and processing.
  4. As of now, the best way to get the BoundingBox is to parse the service’s capabilities and use the bounding box property for the layer that you want. Essentially, because GetBoundingBox doesn’t know which layer to get the bounding box of, it makes it subjective on what the bounding box actually is.
  5. Best way to determine the MapUnit would be to use the Projection class:
    mapView.MapUnit = new Projection("EPSG:900913").GetUnit();


1 Like

Thanks, I can move forward with this.

Example for my question 5. does not work since it seems Projection expects projection string if constructor argument is string. But this works when plain integer is provided, e.g. 4326 or 3857.

But still projection returns Unknown for 900913 even though Projection.ConvertEpsgToProjString(900913) returns a valid projection string?


new Projection(900913).GetUnit()

new Projection(Projection.ConvertEpsgToProjString(900913)).GetUnit()


I see there’s extensive projstring information included in gdal\share\epsg and other similar files but not nearly all of those are returned by Projection.ConvertEpsgToProjString(srid) method.

Hey @Mikko_Viitala,

You’re right, that doesn’t work. I’ve made a fix for it that should be available in the next beta package later today.


1 Like