[GEOS-11294] map ml wms vector representation

[turingtestfail]

Checklist

• I have read the contribution guidelines.
• I have sent a Contribution Licence Agreement (not required for small changes, e.g., fixing typos in documentation).
• First PR targets the main branch (backports managed later; ignore for branch specific issues).
• All the build checks are green (see automated QA checks).

For core and extension modules:

• New unit tests have been added covering the changes.
• Documentation has been updated (if change is visible to end users).
• The REST API docs have been updated (when changing configuration objects or the REST controllers).
• There is an issue in the GeoServer Jira (except for changes that do not affect administrators or end users in any way).
• Commit message(s) must be in the form [GEOS-XYZWV] Title of the Jira ticket.
• Bug fixes and small new features are presented as a single commit.
• Each commit has a single objective (if there are multiple commits, each has a separate JIRA ticket describing its goal).

[aaime]

Can we use MapMLConstants here and in the rest of this form?

[turingtestfail]

Fixed

[aaime]

Whoops, wholesale reformat here?

[aaime]

This method seems to be used solely to feed into featureCollectionToMapML... I'd rather pass the requestCRS into that method, and call this one internally, rather than having one more public method?

[turingtestfail]

Fixed

[aaime]

I'm thinking that the MapMLFeatureUtil could also be folded into MapMLFeaturesBuilder, does it have any usage other than setting up the builder and have it run?

[aaime]

Copyright header missing

[turingtestfail]

Fixed

[aaime]

Does not support.. yet?

[turingtestfail]

Fixed

[aaime]

Wondering what should happen if there are multiple layers, and some are raster?

[turingtestfail]

Raster check implemented

[aaime]

Do we actually need a pair of these in the test? Would be useful if we have to make assertions involving both, but if we assert only the response, why not just return it directly, as it's done in the rest of GeoServer?

[turingtestfail]

Removed

[aaime]

Would not hurt to have a utility method called "getAsMapML" that internally runs the request, check the response mime type (or types, maybe two methods then?), parses the MapML and returns it. Similar to "getAsDom" and "getAsJSON".

[turingtestfail]

Created

[prushforth]

One quick comment (I'm still looking, will get back with more as and when appropriate).

When “Use Features” is checked/ true, the tref attribute of the map-link for the layer contains the “format_options=mapmlfeatures:true” -- this is good!

E.g. http://localhost:8080/geoserver/tiger/wms?format_options=mapmlfeatures:true&request=GetMap&crs=MapML:OSMTILE&bbox={xmin},{ymin},{xmax},{ymax}&format=text/mapml&language=en&version=1.3.0&transparent=true&service=WMS&layers=poi&width={w}&styles=&height={h}

The default number of decimal places for a layer in WFS settings is 0, which leads to unusable gcrs coordinates. This is perhaps a documentation issue more than a functional problem. I note that you can control the number of decimal places with this setting, so that’s good.

The dynamic content that is fetched by the above map-link tref contains content like that below. Note that there is a discrepancy between the coordinates encoded in the <map-coordinates> elements and the coordinate system declared via <map-meta> below. The declaration says ‘pcrs’, whereas the coordinates are encoded as gcrs. Generally, the coordinates should be encoded in the same coordinate system that was requested via the URL, in this case that should be pcrs/ meters.

Also, note that the response below contains several <map-link rel=”alternate” projection=”...”> links. These are strictly not necessary in the templated responses, as they are ignored and just clutter things up. We don’t want recursively requested requests to happen, and I think the client is going to have to actively guard against that in the future, but up to now no special code is in place to prevent it IIRC.

    <map-meta name="projection" content="OSMTILE"></map-meta>
    <map-meta name="extent"
        content="top-left-easting=-8238959.40,top-left-northing=4971112.17,bottom-right-easting=-8237812.69,bottom-right-northing=4969300.12"></map-meta>
    <map-meta name="cs" content="pcrs"></map-meta>    <!-- this is the correct declaration -->

<map-link href="http://localhost:8080/geoserver/tiger/wms?LANGUAGE=en&amp;CRS=MapML:OSMTILE&amp;FORMAT=text/mapml&amp;STYLES=&amp;WIDTH=588&amp;HEIGHT=911&amp;LAYERS=poi&amp;REQUEST=GetMap&amp;FORMAT_OPTIONS=mapmlfeatures:true&amp;BBOX=-8239245.213801639,4968578.821850099,-8237840.683406899,4970754.888499092&amp;SRSNAME=MapML:OSMTILE&amp;VERSION=1.3.0&amp;SERVICE=WMS&amp;TRANSPARENT=true&amp;Language=en" rel="alternate" projection="OSMTILE"></map-link>


    <map-feature id="poi.1" class="poi">
        <map-geometry>
            <map-point>
                <map-coordinates>-74.010461 40.707588</map-coordinates>  <!-- this encoding is gcrs, which doesn't follow the declaration above. Should be in projected / meters. -->
            </map-point>
        </map-geometry>
        <map-properties>
            <table xmlns="http://www.w3.org/1999/xhtml">
...
            </table>
        </map-properties>
    </map-feature>

[turingtestfail]

One quick comment (I'm still looking, will get back with more as and when appropriate).

When “Use Features” is checked/ true, the tref attribute of the map-link for the layer contains the “format_options=mapmlfeatures:true” -- this is good!

E.g. http://localhost:8080/geoserver/tiger/wms?format_options=mapmlfeatures:true&request=GetMap&crs=MapML:OSMTILE&bbox={xmin},{ymin},{xmax},{ymax}&format=text/mapml&language=en&version=1.3.0&transparent=true&service=WMS&layers=poi&width={w}&styles=&height={h}

The default number of decimal places for a layer in WFS settings is 0, which leads to unusable gcrs coordinates. This is perhaps a documentation issue more than a functional problem. I note that you can control the number of decimal places with this setting, so that’s good.

The dynamic content that is fetched by the above map-link tref contains content like that below. Note that there is a discrepancy between the coordinates encoded in the <map-coordinates> elements and the coordinate system declared via <map-meta> below. The declaration says ‘pcrs’, whereas the coordinates are encoded as gcrs. Generally, the coordinates should be encoded in the same coordinate system that was requested via the URL, in this case that should be pcrs/ meters.

Also, note that the response below contains several <map-link rel=”alternate” projection=”...”> links. These are strictly not necessary in the templated responses, as they are ignored and just clutter things up. We don’t want recursively requested requests to happen, and I think the client is going to have to actively guard against that in the future, but up to now no special code is in place to prevent it IIRC.

    <map-meta name="projection" content="OSMTILE"></map-meta>
    <map-meta name="extent"
        content="top-left-easting=-8238959.40,top-left-northing=4971112.17,bottom-right-easting=-8237812.69,bottom-right-northing=4969300.12"></map-meta>
    <map-meta name="cs" content="pcrs"></map-meta>    <!-- this is the correct declaration -->

<map-link href="http://localhost:8080/geoserver/tiger/wms?LANGUAGE=en&amp;CRS=MapML:OSMTILE&amp;FORMAT=text/mapml&amp;STYLES=&amp;WIDTH=588&amp;HEIGHT=911&amp;LAYERS=poi&amp;REQUEST=GetMap&amp;FORMAT_OPTIONS=mapmlfeatures:true&amp;BBOX=-8239245.213801639,4968578.821850099,-8237840.683406899,4970754.888499092&amp;SRSNAME=MapML:OSMTILE&amp;VERSION=1.3.0&amp;SERVICE=WMS&amp;TRANSPARENT=true&amp;Language=en" rel="alternate" projection="OSMTILE"></map-link>


    <map-feature id="poi.1" class="poi">
        <map-geometry>
            <map-point>
                <map-coordinates>-74.010461 40.707588</map-coordinates>  <!-- this encoding is gcrs, which doesn't follow the declaration above. Should be in projected / meters. -->
            </map-point>
        </map-geometry>
        <map-properties>
            <table xmlns="http://www.w3.org/1999/xhtml">
...
            </table>
        </map-properties>
    </map-feature>

Both of these issues should now be addressed in the most recent push.

[turingtestfail]

One quick comment (I'm still looking, will get back with more as and when appropriate).

When “Use Features” is checked/ true, the tref attribute of the map-link for the layer contains the “format_options=mapmlfeatures:true” -- this is good!

E.g. http://localhost:8080/geoserver/tiger/wms?format_options=mapmlfeatures:true&request=GetMap&crs=MapML:OSMTILE&bbox={xmin},{ymin},{xmax},{ymax}&format=text/mapml&language=en&version=1.3.0&transparent=true&service=WMS&layers=poi&width={w}&styles=&height={h}

The default number of decimal places for a layer in WFS settings is 0, which leads to unusable gcrs coordinates. This is perhaps a documentation issue more than a functional problem. I note that you can control the number of decimal places with this setting, so that’s good.

The dynamic content that is fetched by the above map-link tref contains content like that below. Note that there is a discrepancy between the coordinates encoded in the <map-coordinates> elements and the coordinate system declared via <map-meta> below. The declaration says ‘pcrs’, whereas the coordinates are encoded as gcrs. Generally, the coordinates should be encoded in the same coordinate system that was requested via the URL, in this case that should be pcrs/ meters.

Also, note that the response below contains several <map-link rel=”alternate” projection=”...”> links. These are strictly not necessary in the templated responses, as they are ignored and just clutter things up. We don’t want recursively requested requests to happen, and I think the client is going to have to actively guard against that in the future, but up to now no special code is in place to prevent it IIRC.

    <map-meta name="projection" content="OSMTILE"></map-meta>
    <map-meta name="extent"
        content="top-left-easting=-8238959.40,top-left-northing=4971112.17,bottom-right-easting=-8237812.69,bottom-right-northing=4969300.12"></map-meta>
    <map-meta name="cs" content="pcrs"></map-meta>    <!-- this is the correct declaration -->

<map-link href="http://localhost:8080/geoserver/tiger/wms?LANGUAGE=en&amp;CRS=MapML:OSMTILE&amp;FORMAT=text/mapml&amp;STYLES=&amp;WIDTH=588&amp;HEIGHT=911&amp;LAYERS=poi&amp;REQUEST=GetMap&amp;FORMAT_OPTIONS=mapmlfeatures:true&amp;BBOX=-8239245.213801639,4968578.821850099,-8237840.683406899,4970754.888499092&amp;SRSNAME=MapML:OSMTILE&amp;VERSION=1.3.0&amp;SERVICE=WMS&amp;TRANSPARENT=true&amp;Language=en" rel="alternate" projection="OSMTILE"></map-link>


    <map-feature id="poi.1" class="poi">
        <map-geometry>
            <map-point>
                <map-coordinates>-74.010461 40.707588</map-coordinates>  <!-- this encoding is gcrs, which doesn't follow the declaration above. Should be in projected / meters. -->
            </map-point>
        </map-geometry>
        <map-properties>
            <table xmlns="http://www.w3.org/1999/xhtml">
...
            </table>
        </map-properties>
    </map-feature>

Heads up that I just pushed a fix to the number of decimals issue. It was defaulting to zero but now it should default to the global setting (which in turn defaults to 8). This matches how GML2 handles the same issue in WFS.

[prushforth]

I'm unable to get (for example) the states layer to serve up vectors in pcrs coordinates for MapML:OSMTILE. Works well, including the bugfix for default decimals, for MapML:WGS84. Getting non-WGS84 projections working is essential, but am I missing something? Thanks

Edit: wait a second I seem to have missed something

[turingtestfail]

Peter, It looks like in some cases the ReprojectingFeatureCollection I introduced for this conversion is not able to detect the CRS from the geometry, leading it to return the coordinates in the stored CRS. I just pushed a fix that establishes a fallback CRS based on the stored layer configuration that should address the issue. Can you do a pull and test again? Joe

…

On Mon, Feb 26, 2024 at 5:03 PM Peter Rushforth ***@***.***> wrote: I'm unable to get (for example) the states layer to serve up vectors in pcrs coordinates for MapML:OSMTILE. Works well, including the bugfix for default decimals, for MapML:WGS84. Getting non-WGS84 projections working is essential, but am I missing something? Thanks — Reply to this email directly, view it on GitHub <#358 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHRJZ4WXUBCRWFJ5NPPZ5FDYVUBD5AVCNFSM6AAAAABDFD7D72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVGM3TQMRYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[prushforth]

Can you do a pull and test again?

ok that seems to make a big difference for me. I will proceed to look more!

Thanks!

[prushforth]

I think that when the "Use Features" MapML option is selected, that we should leave out the <map-link rel="query" ...> link. It seems redundant and may mess somebody up. I can take care of that, once I take a look at and understand your code.

Looking pretty good! I note that no clipping to the bbox is happening yet, correct? i.e. the whole layer is requested at each map movement.

I also note that the popup for large (many attributes) attribute tables is really not great. We'll raise an issue on the client for that.

Edit: also I note that the <map-meta name="cs" content="gcrs"> is still used for MapML:WGS84, probably because of a bug / not quite baked client implementation of WGS84 pcrs coordinates. It's working, so good.

[aaime]

@prushforth yes, handling clipping is going to be my first task once this PR is merged, while @turingtestfail dives into style translation.

[turingtestfail]

Peter, Once the <map-link rel="query" ...> link is removed are you OK with us moving forward with a PR against the main repository? Thanks, Joe

…

On Tue, Feb 27, 2024 at 2:11 AM Andrea Aime ***@***.***> wrote: @prushforth <https://github.com/prushforth> yes, handling clipping is going to be my first task once this PR is merged, while @turingtestfail <https://github.com/turingtestfail> dives into style translation. — Reply to this email directly, view it on GitHub <#358 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHRJZ4WPN55CZBGZZPDEWWLYVWBK3AVCNFSM6AAAAABDFD7D72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHEYTQMJRGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[prushforth]

Once the <map-link rel="query" ...> link is removed are you OK with us
moving forward with a PR against the main repository?

Yes!