POST
|
Found it in the docs here: In 3D, for layers that are rendered on the terrain, the order of the layers also depends on the type of layer. Tiled layers (BaseTileLayer, ImageryTileLayer, OpenStreetMapLayer, TileLayer, VectorTileLayer, WCSLayer, WebTileLayer and WMTSLayer) are always drawn first in the same order as specified in the layer collection. Dynamic layers (MapImageLayer, ImageryLayer, WMSLayer, and feature based layers with elevation mode on-the-ground) are rendered on top using the order from the layer collection.
... View more
02-13-2024
09:27 AM
|
0
|
0
|
124
|
POST
|
I am trying to load a tiled layer in an ArcGIS Maps SDK for JavaScript map so that it draws on top of a non-tiled layer but this does not work when I use a 3D SceneView. Its fine in a 2D MapView. Is there some limitation with ordering of tiled vs non-tiled layer tiles in 3D SceneViews? This codepen shows a specific case where a ImageryTileLayer will not draw on top of an ImageryLayer. I can also reproduce the same thing with a custom BaseTIleLayer instance. Is this a bug or did I miss something in the docs?
... View more
02-12-2024
04:35 PM
|
0
|
1
|
206
|
POST
|
A very late response to an old post, but the trick I recently found that, so far, has gotten around this problem well is to hold off calling .refresh until after the layer has finished loading: So the setThreshold function in the codepen becomes something like: function layerCompletelyDrawnAndVisible(layer, view) {
let [watchUtils] = await loadModules(["esri/core/reactiveUtils"]);
let layerView = await view.whenLayerView(layer);
let layerId = await new Promise((resolve) => {
if (layerView.updating) {
watchUtils.when(
() => !layerView.updating,
() => {
return resolve(layer.id);
},
{
once: true,
}
);
} else return resolve(layer.id);
});
return layerId;
}
function setThreshold() {
thresholdVal = parseInt(threshold.value);
let { colors, stops } = getRasterStopsAndColors(
5000,
thresholdVal,
seedColors
);
//lercLayer.max = 3000;
lercLayer.threshold = thresholdVal;
lercLayer.stops = stops;
lercLayer.colors = colors;
//lercLayer.refresh();
layerCompletelyDrawnAndVisible(lercLayer, view).then(v => lercLayer.refresh())
}
// @ts-ignore
threshold.addEventListener("change", setThreshold); that seems to deal with the problem nicely!
... View more
01-26-2024
04:49 PM
|
0
|
0
|
833
|
POST
|
Posted request for 512x512 3D Raster Tile layer support or 512x512 tiled basemaps here! Go give it a kudos to get this idea traction.
... View more
11-07-2023
01:13 PM
|
0
|
0
|
681
|
IDEA
|
Currently the JavaScript Maps SDK doesn't support mixed Raster tiling sizes in 3D SceneViews. Raster API tiles only work when all other layers have same tiling size. (link) Since most maps created with the JavaScript Maps SDK use ESRI Basemaps, map creators or developers are often constrained to using layers with 256x256 tiling schemes. This is unfortunate because increasingly applications are recommending 512x512 tiling schemes for better performance on large or high-resolution devices (example1, example2). Our own limited testing suggests improvements as well. We would be interested to see SceneView support mixing 256x256 and 512x512 tiling schemes since both are pretty common. Failing that, we would be interested to see ESRI consider publish their official standard basemaps in 512x512 tiling formats. That way we can use our 512x512 Raster tile layers in 3D easily. Related ESRI Community Question Post
... View more
11-07-2023
01:10 PM
|
2
|
0
|
339
|
POST
|
The testing we did was far from anything authoritative but we noted on comparison that because of browser limits of 6(?) concurrent fetches to a domain it was noticeably faster to download 512x512 tiles due to less fetches. We looked at load time of a static area on app load. Of course this was done on large hi-res screens with fast CPU. Results would probably vary based on device.
... View more
11-02-2023
05:44 PM
|
0
|
0
|
706
|
POST
|
Thanks for the clarification. We've seen performance benefits from using 512x512 tile sizes over 256x256 on high-res or large screens. Removing the basemap isn't really ideal although I confirmed that it works. If supporting mixed tile sizes (even limited to 256 and 512) in 3D is complex, perhaps another idea would be ESRI 512x512 basemaps? Something I can raise over in ideas.
... View more
11-02-2023
10:33 AM
|
0
|
2
|
713
|
POST
|
I have a custom Raster TileLayer in a map that works with a 512x512 tiling scheme. But when I try to switch from a 2D MapView to a 3D SceneView the layer fails to load. Error message is: > The tiling scheme of this layer is incompatible with the tiling scheme of the surface That's because my custom layer is drawing with 512x512 tile size I think. The docs say: Raster API tiles only work when all other layers have same tiling size. (link) My map is using, of course, an ESRI Basemap (I think ESRI ArcGIS Maps SDK for JavaScript maps require a basemap layer right?). I assume then that effectively I have to use 256x256 tiles unless I build my own custom basemap layer? Am I interpreting this right? I am hoping that others or someone at ESRI can clarify that I am reading this right. I'd like to clarify that this is the case before I post over in Ideas asking if it is possible and on any roadmap to support mixed tile sizes in 3D Scenes. I haven't tried yet a custom basemap layer. I also haven't tried maintaining a separate Map instance for each SceneView and MapView because that's a lot of rework in my app. I have tried removing and reloading the custom Raster TileLayer every time the user switches between 2D and 3D. It's really slow as the layer has to completely reload and redraw before we can even spin up the 3D view.
... View more
10-27-2023
02:01 PM
|
1
|
5
|
873
|
POST
|
The video was from Firefox. Note that it is import to return to your initial zoom extent. You want to zoom in, say 4x, then zoom back out 4x to return to the initial zoom level. I probably should have added a zoom element displayed in the codepen to show that. I wasn't able to reproduce the problem every time. If I changed the threshold and waited for a few seconds too long before zooming I did not seem to get the issue. Also note there it looks like there are tiles that aren't drawing at all now whereas my initial example where we'd see the old filtered tile data remain? At the office here I was eventually able to reproduce the issue (ff) though it too a few tries. In Chrome the only way I was able to reproduce in the office now, is if I throttle the network speed. Then the problem is really easy to reproduce in your example (missing tiles, not old cached tiles). Try setting the network to 'Fast3G' to see what I mean. Its certainly tricky though. Let me know if there's anything else I can do. Thanks for looking into.
... View more
05-24-2023
12:40 PM
|
0
|
0
|
1821
|
POST
|
I just tested your code pen but I am still able to reproduce the problem I demonstrated above. Or at least there seems to be tiles not drawing correctly. Here is a video:
... View more
05-23-2023
05:03 PM
|
0
|
0
|
1834
|
POST
|
Thanks for the update. I just tested our app with the next version of the ArcGIS JavaScript API ArcGIS Maps SDK and it works! Thank you for the fix. Look forward to the upcoming release of 4.27.
... View more
04-14-2023
04:19 PM
|
0
|
0
|
645
|
POST
|
I have been working on setting up client-side rendering for Raster-based layers. I've created a customized BaseTileLayer where I can change the filter of the data client-side. However sometimes old tiles of data persist. Example: This codepen is a rough example that demonstrates the issue. Set threshold to something like 3400. Zoom in a bit. Set threshold to 400. Zoom out. See old filter applied still for certain tiles. This is not a new issue. I initially noted this problem here in another post. I also posted about similar problems occuring when changing the colors client-side on a renderer for a ImageryTileLayer. I've raised the issue to ESRI Technical support but we were unable to resolve the issue. At that time I thought it would be sufficient for my needs to ensure that the MapView was fully drawn and stationary before letting the user adjust the styles. But that turns out not to be acceptable from a client standpoint. Does anyone know if there is something that can be done to prevent this while still allowing client-side rendering and adjustments?
... View more
04-11-2023
10:54 AM
|
0
|
5
|
1923
|
POST
|
Thanks for your prompt response. The problem is that these request for the count of features take really long-- as I've described in the linked posts. This prevents the layers from loading in a SceneView the same as it did in our MapView. In 2D, disabling "snapshot mode" allowed those layers to continue to work because these types of requests were no longer made. I would like to do the same in a SceneView. Perhaps disabling these calls to 'returnCountOnly' is not possible? I know that in a SceneView, there are parameters like maximumNumberOfFeatures that are applied to LayerViews. More Detail: When I load the sceneView, I see two different types of calls for returnCountOnly for each layer: there is first one for the total layer count (where1=1). Subsequent to that, there is calls for the count within a specific area (tile). I think it is the first that are the problematic ones. I will do some sandbox testing to check further. If you can clarify that disabling these calls for returnCountOnly are not able to be disabled for SceneView and perhaps provide a bit of guidance why that would probably answer this question. I might open different ones to explore other ways to deal with this problem as I test more. Since I can't share our own large MapService layers, I'll probably start by pursuing the question/issue further with ESRI Canada technical support.
... View more
04-06-2023
08:20 AM
|
0
|
0
|
711
|
POST
|
I just realized that I seem to be sometimes having the same problem when creating a SceneView and the above doesn't fix it there. I've created a new Post for help with this.
... View more
04-05-2023
08:43 PM
|
0
|
0
|
309
|
POST
|
I want to disable 'snapshot mode' in my SceneView. As described and discussed in this Ideas Post, "Fix 4.2x so that initial requests for large layers are faster" and in these Questions (Post 1, Post 2), the feature can really slow down the loading of large MapService layers. For a MapView (2D) the workaround posted in the links is to configure: 'featurelayer-snapshot-disabled':0 See here. But now I need to do that in a SceneView because I seem to be having the same issue there. Here's a simple CodePen of it working for a MapView. Here's a copied CodePen of same thing failing for a SceneView. To Test: Although the effects aren't that significant for this sample data above, you can see that in the sceneView you will still get requests with `returnCountTrue` param which are the snapshot feature requests if you open your browser DevTools to the network pane and watch traffic. Is there a 3D equivalent of 'featurelayer-snapshot-disabled':0? Help!
... View more
04-05-2023
08:37 PM
|
0
|
5
|
781
|
Title | Kudos | Posted |
---|---|---|
2 | 11-07-2023 01:10 PM | |
1 | 10-27-2023 02:01 PM | |
1 | 05-15-2020 04:58 PM | |
1 | 04-15-2021 09:08 AM | |
1 | 04-06-2021 10:29 AM |
Online Status |
Offline
|
Date Last Visited |
03-15-2024
06:57 PM
|