I get the same result no matter what I try. I've tried using the mapConfig.json generated by mapproxy and also by creating a storage view served by vtsd (using the remote surface from mapproxy in the VTS storage). I've tried several ways of viewing it, both using web browser (by just browsing to it like you said) and also by using Unity with the vts-browser.dll. I've included the mapConfig.json at the bottom of this comment.
I'm not using it as a free layer though, I'm using it as a surface. I only included the freelayer.json because I thought it contained enough information about the surface. Note, this is just a workaround not a fix! I made a quick workaround in vts-browser-cpp library that ignores the meta tile data and stops the traversal. I've generated the tiling index using mapproxy-tiling.įrom my debugging, I've concluded that tiles that are completely in a NODATA area seem to have meta data in them that causes the renderer to continue traversing meta tiles very deep. There are a lot of NODATA parts outside Sweden's borders. I can give you a link to the actual GeoTIFF files if required. The DEM dataset covers most of Sweden and consists of several GeoTIFF files but I have combined them in a virtual raster. I'm using a custom reference frame that covers entire Sweden. The statistics show that it traverses of millions of higher LODs nodes even when the renderer is currently displaying a very low LOD. I debugged the vts-browser-cpp and noticed that when the problem occurs, the application spends several seconds when traversing the node tree each frame. The rendering gets extremely sluggish (<1FPS).
I'm encountering an issue during rendering (both desktop and javascript) that I think is related to how mapproxy generates tiling index or how it generates meta tiles. Version: mapproxy 1.35 (built on 12:57:52 at pomerol)