Repository navigation
Allow nested <map-extent> content model #1035
Description
Activity
This may be slightly off topic of the current issue, tbd. If so, I will make it its own issue depending on comments received.
Currently, a
<map-extent>is used to load templated content for one or more child<map-link rel="image">,<map-link rel="features">and<map-link rel="tile">.Now, the
imageandfeaturesvalues are the same "shape", in the sense that the map is supposed to load a viewport's-worth of content for rendering in one request. Fortile, it is implied that the map will load all the tiles it needs to cover the viewport, replenishing as required.Recently, I've thought that this may complicate the
<map-input type="location">attributes and usage.Consider a nested child
<map-tile-extent>that is a template / form for the extent of a single tile request such that it could be re-processed for as many tiles as required to cover the viewport implicit in its parent<map-extent>. Would its child<map-input type="location">attributes markup be simpler to understand because of the narrower context ?For example, here's a current working map extent that uses a WMS backend to obtain tiles:
<map-extent units="CBMTILE" checked="checked" hidden="hidden"> <map-input name="z" type="zoom" min="0" max="25"></map-input> <map-input name="txmin" type="location" rel="tile" position="top-left" axis="easting" units="tilematrix" min="-4313954.351966471" max="4003122.4215241135"></map-input> <map-input name="tymin" type="location" rel="tile" position="bottom-right" axis="northing" units="tilematrix" min="-3418178.4063371555" max="1196662.9066845388"></map-input> <map-input name="txmax" type="location" rel="tile" position="bottom-right" axis="easting" units="tilematrix" min="-4313954.351966471" max="4003122.4215241135"></map-input> <map-input name="tymax" type="location" rel="tile" position="top-left" axis="northing" units="tilematrix" min="-3418178.4063371555" max="1196662.9066845388"></map-input> <map-link tref="http://localhost:8080/geoserver/nurc/wms?request=GetMap&crs=MapML:CBMTILE&service=WMS&bbox={txmin},{tymin},{txmax},{tymax}&layers=Img_Sample&format=image/jpeg&width=256&language=en&styles=raster&version=1.3.0&transparent=true&height=256" rel="tile"></map-link> <map-input name="i" type="location" axis="i" units="tile"></map-input> <map-input name="j" type="location" axis="j" units="tile"></map-input> <map-link tref="http://localhost:8080/geoserver/nurc/wms?request=GetFeatureInfo&query_layers=Img_Sample&crs=MapML:CBMTILE&bbox={txmin},{tymin},{txmax},{tymax}&language=en&version=1.3.0&transparent=true&service=WMS&layers=Img_Sample&width=256&x={i}&feature_count=50&y={j}&styles=raster&info_format=text/mapml&height=256" rel="query"></map-link> </map-extent>
Above, the
units="tilematrix" rel="tile"attributes convey that the thing being serialized is a tile, meaning that the developer requires the tile corner location (identified byposition="top-left") in projected units identified by theaxis="easting"attribute.Would the following markup make
<map-input>attributes significantly simpler to understand / explain? At what cost?<map-extent units="CBMTILE" checked="checked" hidden="hidden"> <map-tile-extent> <map-input name="z" type="zoom" min="0" max="25"></map-input> <map-input name="xmin" type="location" position="top-left" axis="easting" min="-4313954.351966471" max="4003122.4215241135"></map-input> <map-input name="ymin" type="location" position="bottom-right" axis="northing" min="-3418178.4063371555" max="1196662.9066845388"></map-input> <map-input name="xmax" type="location" position="bottom-right" axis="easting" min="-4313954.351966471" max="4003122.4215241135"></map-input> <map-input name="ymax" type="location" position="top-left" axis="northing" min="-3418178.4063371555" max="1196662.9066845388"></map-input> <map-link rel="tile" tref="http://localhost:8080/geoserver/nurc/wms?request=GetMap&crs=MapML:CBMTILE&service=WMS&bbox={xmin},{ymin},{xmax},{ymax}&layers=Img_Sample&format=image/jpeg&width=256&language=en&styles=raster&version=1.3.0&transparent=true&height=256"></map-link> <map-input name="i" type="location" axis="i"></map-input> <map-input name="j" type="location" axis="j"></map-input> <map-link rel="query" tref="http://localhost:8080/geoserver/nurc/wms?request=GetFeatureInfo&query_layers=Img_Sample&crs=MapML:CBMTILE&bbox={xmin},{ymin},{xmax},{ymax}&language=en&version=1.3.0&transparent=true&service=WMS&layers=Img_Sample&width=256&x={i}&feature_count=50&y={j}&styles=raster&info_format=text/mapml&height=256" ></map-link> </map-tile-extent> </map-extent>
Presumably in addition to a child
<map-tile-extent>, the same parent<map-extent>could have other location inputs and link templates that would render in painter's model order. Would this impact the map viewer user interface? A single<map-tile-extent>could contain multiple templated<map-link>elements just as the<map-extent>can currently, but these aren't directly accessible in the UI - you can always put them in another<map-extent>or even<map-layer>.
The
<map-layer>can contain sequences of<map-extent>,<map-feature>and<map-tile>content. This allows the user to turn on/off the layer, and it allows them to turn on/off the<map-extent>as sub-layer elements in the layer control. However, this means that the<map-feature>and<map-tile>elements can't be independently accessed i.e. they're not accessible as sub-layers, and that is an a11y failure I believe.Should we allow the
<map-extent>to have an alternate content model that allows<map-feature>,<map-tile>and maybe<map-extent>? That brings up how deep might it be allowed to nest?Currently, when a
<map-link>element loads a map document, it only supports<map-feature>and<map-tile>and I don't think it would be smart to load and process<map-extent>, due to potentially infinite nesting. Maybe we could make the same injunction wrt<map-extent>i.e. it can't contain another<map-extent>. That would solve the problem of content not being under control of the layer control.On the other hand, if the nesting is "manual" i.e. not processed blindly by loading a link, maybe allowing some nesting of
<map-extent>would be ok? How many levels of nesting is reasonable: 0, 1, 2, 3, n? Maybe we could start off with 0 and see how it works out and prototype our way from there.wdyt?