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

<map-extent> .extent should use in-scope <map-meta> AND child <map-input>-derived bounds / zoom bounds #921

Closed prushforth closed 4 months ago

prushforth commented 4 months ago

The \ element uses child \ elements for extent and zoom to define an extent that is added to by layer content. That is, if a \ has no content, its extent bounds and zoom bounds default to that of the projection; if it has content, the content defines the bounds and zoom bounds, and the projection bounds/zoom bounds aren't taken into account. (The first, in document order) \ child \ elements for bounds and zoom bounds, if present, define bounds similar to \ and \: each is one of many contributing elements to bounds and zoom bounds.

In the \ case, the bounds and zoom bounds are calculated ONLY through the addition of all the child \ bounds. Child \ elements are not considered from the \ POV. Each (templated) child \ element calculates its own bounds and zoom bounds, based on a strategy or algorithm which currently only considers sibling and ancestor \ bounds-related elements (name=zoom or name=extent) IFF a bounds and zoom bounds can't be calculated from associated \s. I think this strategy is ok for \ extent calculation: it gives the author an 'out' from specifying axis min/max on \ elements, which can be slightly confusing. Entering the extent as <map-meta name="extent" content="..."></map-meta> might be slightly easier YMMV. It can be considered an alternative markup strategy for \ bounds to keep the templated \ as simple as possible.

Should \ directly consider the sibling and/or ancestor \?

I don't think so, but I do believe that the \ bounds strategy should be updated, to be calculated according to a similar strategy to that used by \ as described in the first paragraph above, that is, the in-scope extent-contributing \ elements should form a baseline extent for the \.

cc @AliyanH

prushforth commented 4 months ago

This will require adding a mutation observer to \. The current observer on \ only looks at childList mutations, does not include subtree type mutations, and it probably shouldn't keep track of subtree modifications, maybe it would not perform well.

AliyanH commented 4 months ago

This will require adding a mutation observer to .

Yes that seems like the best option, only other option that comes to mind (if we don't want many mutation observers slowing down our codebase) is to implement this inside of the map-meta connectedcallback which checks what it was appended to (and wait on whenReady) and invokes the parent's method to take it into account. Though I think we already tried this approach and it did not work well for us for some reason.

prushforth commented 4 months ago

I do believe that the bounds strategy should be updated, to be calculated according to a similar strategy to that used by as described in the first paragraph above, that is, the in-scope extent-contributing elements should form a baseline extent for the .

We discussed this and we defined "in-scope extent-contributing \ elements" to mean \ child \ elements. This was committed in map-extent.js here.

prushforth commented 4 months ago

Available in 0.13.0