Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Layers in Legend and No Base Layer Tile Requests Sent #1401

Closed
Crispin-at-Linknode opened this issue Jul 5, 2022 · 9 comments
Closed

Comments

@Crispin-at-Linknode
Copy link

I have a map with Base Layer Groups that is not loading properly (links below).

There is NO OPERATION=GetTileImage request sent to the mapserver at all when the layout loads. And the legend is only showing a subset of the available layers. I can see more when searching, but even then, toggling the base map group does not send a server request.
I am guessing something is stopping the layers list loading, which is then not reading down to the Base Layers and hence the local layer cache of the MapDefinition will always be incomplete?

I also get a lot of "failed to Fetch" errors in the viewer -- it would be great to have some logging or setting that would allow a detailed error to be shown when this occurs.

React Layout without Tiled Layers
(click the icon in the legend to expand the groups and layers, but still not properly showing th

https://webgis.east-ayrshire.gov.uk/mapguide31/viewer/sidebar.html?resource=Library://EastAyrshire/Layouts/EACInternet_TileSet.WebLayout

You can see how it should look with the AJAX version:

https://webgis.east-ayrshire.gov.uk/mapguide31/mapviewerajax/?WEBLAYOUT=Library://EastAyrshire/Layouts/EACInternet_TileSet.WebLayout

@jumpinjackie
Copy link
Owner

What release/version of the viewer are you using?

@Crispin-at-Linknode
Copy link
Author

It was only installed a month or so ago -- it was either the current GitHub release or built from source... I don't think there were many significant commits between the release and 5 weeks ago.

@jumpinjackie
Copy link
Owner

jumpinjackie commented Jul 7, 2022

I was able to spin up a http server on my local viewer that proxies mapagent requests to your MG mapagent I can see the problem locally.

At a glance, it looks like a bug in the group node visibility check on the legend component (among other problems). I'll dig further tomorrow.

@Crispin-at-Linknode
Copy link
Author

Thanks -- if you ever do a blog about getting started debugging with VS or VS Code and the viewer I could probably get started and find a way in, but a TypeScript project just feels too alien at the moment

@jumpinjackie
Copy link
Owner

An update.

I found the likely culprit. It is currently not looking like the viewer is at fault, but rather the CREATERUNTIMEMAP operation.

The Layer collection in the response only has 11 items, but when I look at the map definition itself there is clearly way more. So for reasons currently unknown, the CREATERUNTIMEMAP operation is skipping a whole bunch of layers.

The legend constructs its tree structure based on this (incomplete) information which is why there's only 6 groups visible.

Made a ticket on the MG side for you to follow: https://trac.osgeo.org/mapguide/ticket/2846

@Crispin-at-Linknode
Copy link
Author

Interesting... but the classic AJAX viewer constructs the legend as expected - doesn't use the same CreateRuntimeMap operation I guess.

If I knew what oddity was in one of the layers or definition I could try and adapt the layer or .MapDefinition as putting a server hotfix in place will be a bit more of a PITA !

Thanks for updating.

@jumpinjackie
Copy link
Owner

jumpinjackie commented Jul 20, 2022

Another update.

I have identified the problem. The CREATERUNTIMEMAP operation is failing to XML-encode ampersand (&) characters in layer names resulting in invalid XML, which the JSON conversion proceeds to give up at the layer with the ampersand character in its name, which happens to be the 11th layer on the list of layers to process!

An immediate short-term workaround (until we have a fix in MG) would be to change & to and in affected layer names. You should get the full layer tree again like the AJAX viewer.

MG ticket updated with new description

@Crispin-at-Linknode
Copy link
Author

Yes, that's excellent news - much easier to do a layer rename than a patch and lowers the severity with a reasonable workaround. Many thanks

@jumpinjackie
Copy link
Owner

Ok, closing as the problem is now solely on the MG side via the referenced ticket

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants