search

Maps4HTML / Web-Map-Custom-Element

A custom <mapml-viewer> and <layer-> element suite
https://maps4html.org/Web-Map-Custom-Element/
Other
54 stars 15 forks source link

Thrown errors when processing "Next Feature" / ">" in multi-extent query on CBMTILE layer #958

Closed prushforth closed 2 months ago

prushforth commented 3 months ago

Steps to reproduce

Start a local instance of GeoServer on port 8084 (or adjust port number as required) Set WMS MapML setting to serialize layers as multiple extents Load this layer Open the devTools console drawer Zoom in on the spearfish sub-layer: image Click on a bunch of features in the spearfish extent In the popup navigation footer, click "Next Feature / '>' " What happens: StackOverFlow What should happen: the next feature in the set of returned features' should be popped up.

prushforth commented 2 months ago

Have done a bit of debugging, and I think the problem lies in the fact that the first feature added to the shadow root of the \ via the "> Next Feature" button gets an incorrect fallbackCS from its _getFallbackCS(), which returns the default "gcrs" where it should be returning "pcrs" because no \ elements yet exist in the \.shadowRoot . Will investigate further as time permits. The error is not thrown when the projection is OSMTILE, but the problem still exists because the viewer thinks that the cs of the feature is gcrs, so in the above link the only expression of the bug is that the "Zoom to here" link goes off into some space uninhabited by people. ;-). Here's a link with the same layers in CBMTILE that throws the exception.

I think that two things need to be done:

1) make it so that if the query response returns \ they are guaranteed to be added to the \.shadowRoot first thing and 2) \.getFallbackCS() should be amended to look a little harder for a projection and cs before actually falling back. i.e. for a \ in a \, it should be easily possible to obtain the projection from the \ attribute, and the cs value should come from the first \ units attribute that is linked/related to the \ tref via the variable name.

prushforth commented 2 months ago

Not that this bug is due to lack of a spec for default cs value, but I noticed that the code ultimately does fall back to gcrs if there is no cs attribute on the geometry and no <map-meta name="cs"...> in the provenance of a <map-feature>, so I added it as something to specify