I have a few general observations about different web maps, tile cache and such in beta 13 that I’d like to share with your development & support team as my role in my current project is coming to an end.
Some of them are just annoyances that one just needs to know and some I’d categorize as actual bugs.
That being said, first time I ever used ThinkGeo offering was back in 2012, with MapSuite Desktop 6.0. Now I have been working with beta 13 about a year. It’s good to see how far you have come with your products and in general I’m more than happy with them. There’s more features I would ever need and current beta has solved 99% of my problems. Not to mention your fast & excellent support here on the forums and with tickets. Same applies to sales, hassle free and fast.
But enough with the sweet talk! Here’s The List
You’ll create overlay’s TileCache using
new FileRasterTileCache(string path, string id) so e.g.
new FileRasterTileCache(@"c:\temp", "layer")
If you want to get the path to cache afterwards you need to combine
CacheIdyourself. It would be great to have a new get property that provides this information directly, say
Also, because TileCache works little differently across overlay implementation, getting cache path would be great. Now if you apply mentioned TileCache to
OpenStreetMapOverlayyou’ll get the exact same path and id you provided in the constructor. But if you apply it to
ThinkGeoCloudRasterMapsOverlaythen id is changed to e.g.
layer\Light_3857behind the scenes (because of cloud based styles) when you actually wanted it to be just
If internet connectivity is lost, then using
LayerOverlaystores error tiles into the tile cache, effectively preventing you from ever getting the actual tile from the service again when connectivity is restored.
WmsOverlayworks as it’s supposed to in this regard.
You can add
WmsOverlaybut those credentials are never applied to outgoing web requests. One needs to catch every request and apply request header by hand.
If you add “custom” parameters to
WmsOverlay, implementation breaks. One would expect that anything you add there would be then applied to outgoing request.
If your base server uri contains any extra parameters, those are dropped or implementation break. Say, end point needs some parameter to work correctly then you need to jump hoops to make that happen (e.g. http://www.someservice.com?parameter=123). This relates to bullet above in a sense that a) query parameters could be added to Parameters array from the WmsOverlay constructor or b) one could add these extra parameters to Parameters array by hand
You can’t change VERSION of outgoing request w/o catching individual request and modifying it on the fly. Now version is always fixed as 1.0.0 and some services do not like that. I know services don’t always provide response using the version they advertise they do, but this could maybe be a new property on
WmsOverlay does not obey max width and -height provided in service capabilities. This can lead to situations where no response is received since requested size exceeds the limits.
- Things mentioned above apply here for the most part
- One would expect that WMTS outperforms it’s WMS counterpart from the same service. In reality WMTS is really, really slow. It is usable but one can’t really say it’s a smooth experience. I find this odd.
One would expect to find
WfsOverlay, similar to
WmtsTiledOverlaybut no such class exists. This makes implementation of multiple web based services a little quirky as they don’t follow the same pattern.
Credentials property does not exist on
Feature caching is hidden pretty deep and I’m sure many developers can miss it easily (e.g.
layer.FeatureSource.GeoCache.IsActive). It’s also unclear how one should properly work with feature cache in combination with tile cache set for the overlay.
Sometimes when projection converter is applied to WFS layer nothing is shown on the map if layer was opened right after creation, before applying the projection converter. Sadly I couldn’t reproduce this easily in a simple application but it gave me few new gray hairs.
- Sometimes due to not-any-specific-condition creation of UnmanagedProjectionConverter fails when using SRIDs in the constructor, e.g.
new UnmanagedProjectionConverter(4326, 3857). Using projection strings never fail, e.g.
new UnmanagedProjectionConverter("+proj=longlat +datum=WGS84 +no_defs", "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs")
Layer file path
- For consistency property pointing to the “main file” of any given layer could be the same across implementations. Now we have e.g.
PathNamein some vector based layers but in TAB it’s
TabPathFilenameand for rasters we have
PathNamewould work nicely for each.