question about planar view performance when using elevation layer

[rollastre]

Hello.

I am trying to set up a WMTS based planar view with two layers, one for the imaginery and the other for the elevation.

I have tested that when using only the imaginery (here https://gis.iconiqlabs.com/wmts_test/view_wmts.html) the system works as expected.

But when I include the elevation layer (here https://gis.iconiqlabs.com/wmts_test/view_wmts_with_elevation.html) the performance drops and it becomes unresponsive. I am setting this up myself so I suppose I am doing something really wrong. But I don't know what.

The two links are actually the exact same thing but with the addLayer(elevation) line disabled or enabled accordingly

Can somebody help me, please?

[zarov]

Hi,

From what I understand, you are loading the elevation from a single file ?

var elevationUrl = serverUrl + '/wmtsproxy/elevation/Oslo_test_terrain_EPSG_3785.obj'

This is where you are making a mistake: for a single file, you need to use FileSource, instead of a WMTSSource. Note that I'm not aware of a sample with an elevation tile described in a single file, so I'm not sure of how it will render. Please share your result with us when you got improvements !

[rollastre]

Hello, thanks for the reply.

Sorry, I should have explained the whole context before. I am actually writing a web server that interfaces with clients using WMTS protocol (i.e., a WMTS server).

Behind the scenes it can do several things.

• One of them is to just act as a proxy of other WMTS server, This is what it does for the color layer.
• Another is to produce tiles for elevation, and the source of the elevation can be several things. In this case it is an .OBJ file. But it is still a WMTS server. When a tile is requested, if it is the first time, it is generated in the server from the source then saved there for subsequent requests, and sent as a JPEG file. I.e. each tile is a different file. This is a Work In Progress thing and today, all the tiles are completely black. The world is flat. I was about to implement the elevation when I tested it and saw that iTowns wasn't able to cope with it. So, before I spend more time on it, I wanted to confirm my approach had sense (hence this question).
• It will also be able to produce tiles from orthophoto files (this is not yet implemented).
• ... to be a proxy of another WMS server (this is not yet implemented)

In summary, in the current setting, iTowns only speaks to a WMTS server in both cases. And in both layers the tiles are 256x256 JPEG files.

I am actually implementing this because I understood that is what iTowns expects. And I took iTowns into consideration because the size of my datasets, I need a solution that handles multiresolution. iTowns seemed to be a good choice.

Maybe I was wrong? From my ignorance, if I use FileSource, I wouldn't have multiresolution right? Since I can have terrains in TINs with milions of points easily, shouldn't I expect then for the system to not work at all?

Best.

[rollastre]

Hello @gchoqueux

Please notice that everything is a raster. The blahblah.obj in the url is just an address. Not the OBJ file itself (I see I should have used another less confusing url naming :-) ). That is what my WMTS server will use to know what tiles (rasters) it will send.

You can also check it is a WMTS here https://gis.iconiqlabs.com//wmtsproxy/elevation/Oslo_test_terrain_EPSG_3785.obj?Service=WMTS&Request=GetCapabilities

The problem I have is that everything becomes so slow that at some point it just dies. The closer I get to the ground, the worse the situation becomes.

Maybe the elevation tiles are too detailed (256x256)?

Regards.

[gchoqueux]

could you add updateStrategyin your source :

const source = new itowns.WMTSSource({
// ...
updateStrategy: {
                type: 1,
                options: {
                    groups: [0, 4, 8, 12, 16, 19],
                },
// ...
});

This strategy only fetches the zoom levels written in the groups option. It's not necessary to fetch all zoom/level because there isn't enough vertex on terrain mesh.

[gchoqueux]

I fix your example : https://github.com/gchoqueux/itowns/blob/ISSUE_1346/index.html

There's a problem with original viewer extent is too small to represent the world extent. So the elevations are exaggerated and generate too much subdivision of the terrain and slow itowns.

// too small extent isn't representative of the world
var bbox = [ 1200978.58991277, 8382390.26904445, 1203424.57481807, 8384836.25394975]
var extent = new itowns.Extent(
    epsgStr,
    bbox[0], bbox[2], bbox[1], bbox[3]
);

The second problem is time response server is slow ~350ms by tile.

Warning, the EPSG:3785 is deprecated.

You're on the right way, now you need to get data in the elevation tiles.

[rollastre]

Ok! Thank you so much @gchoqueux . The extent was it! It now works like a charm. I don't really understand why it made the elevation to work so bad before. But I now know what to look at. I used that extent because is the area where the elevation data is and I thought that would take the viewer to there directly when loading the page. I guess it is used for something else.

About the response time. Well, 350ms is slow? Wow. Well, it is my own implementation, the server is in the US, etc.. I wasn't expecting to have the most performant code in the first round, but I thought 350ms was kind of ok. :-). A 4K screens gets populated in a couple of seconds. Let's see what the customer says. He's the one who is always right.

About EPSG:3785 being deprecated, thanks. I saw it. But the intersection of the CRSs I use (Norway), the CRSs of the data sets I had, and the CRSs supported by iTowns, gave me this one.. I tried others, but always getting proj's problems (btw, where can I find the list of supported CRSs in iTowns?). Anyway, this won't be a problem as I am planning to add support to the server to reproject, transform the data between formats, and to restructure it (WMTS allows the tile sets to be irregular -not quadtrees- and this is a problem for products expecting quadtree structures). All this will come if I manage to get the elevation working as I expected. It was a showstopper and it looks like I can continue.

Again, thanks for your help. I will let you know when the elevation is working at the server side (and probably come back with more questions :-) ).

Best Regards.

[gchoqueux]

Extent is geographical bounding rectangle defined by 4 limits: west, east, south and north. (visiting doc)

that extent because is the area where the elevation data is

So define extent to elevation source

where can I find the list of supported CRSs in iTowns?

itowns supports all projections supported by proj4js. If you use a new projection, add it with itowns.proj4.defs('EPSG:3785', /* ... */);