GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature #369

dromagnoli · 2024-07-10T09:40:36Z

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).

Notes:

The exisiting MapML HTML Embedded Viewer for WMS will thrown an invalid SRS exception if the requested SRS is not one of the 4 supported by MapML. The same logic has been applied when building the MapML HTML Embedded viewer for WFS.

WFS 1.0.0 requires a simple format name to be reported in the capabilities document (i.e. MAPML-HTML). This will reported in 1.1.0 and 2.0.0 too, together with the text/html; subtype=mapml

dromagnoli · 2024-07-10T09:48:38Z

src/extension/mapml/src/main/java/org/geoserver/mapml/MapMLHTMLGetFeatureOutputFormat.java

+            } else if (rawKvp.containsKey("SRS")) {
+                srs = (String) rawKvp.get("SRS");
+            } else {
+                srs = "EPSG:4326";


Should we default to OSMTILE?

I gather that because OSMTILE does not include the poles, that Andrea prefers to use WGS84. I can live with that. On the other hand, "OSMTILE" is the default map projection used by the <mapml-viewer> if you don't specify the projection attribute. That shouldn't impact GeoServer though, since as Andrea points out the OSMTILE can't cover all earthly data.
WGS84 could be the default here.

Actual live mapml should be served as text/mapml. The preview application is (now, in WMS) served as text/html; subtype=mapml.

Should we default to OSMTILE?

I should be more clear: I think we should default to WGS84 to be consistent with how it's done on the WMS side.

Correct, we are defaulting to WGS84 indeed.

dromagnoli · 2024-07-10T09:50:46Z

src/extension/mapml/src/main/java/org/geoserver/mapml/MapMLConstants.java

@@ -31,6 +33,9 @@ public final class MapMLConstants {
    /** format name */
    public static final String FORMAT_NAME = "MAPML";

+    /** format name needed to have a parseable format in WFS 1.0.0 capabilities */
+    public static final String HTML_FORMAT_NAME = "MAPML-HTML";
+


WFS 1.0.0 requires a simple format name to be reported in the capabilities document.
This will reported in 1.1.0 and 2.0.0 too, together with the text/html; subtype=mapml

what about text/html; subtype=mapml? This was used in the WMS preview for example. The important thing is to serve content (when asked for mapml) as text/mapml

Correct. We are indeed using "text/html; subtype=mapml" to serve WFS as HTML (doing the same thing that WMS does).
The problem is in WFS 1.0.0 that is not supporting that as element name for the capabilities due to this check.

https://github.com/geoserver/geoserver/blob/main/src/wfs/src/main/java/org/geoserver/wfs/WFSGetFeatureOutputFormat.java#L125

So we ended up exposing it as MAPML-HTML as well as text/html; subtype=mapml (where the first one makes WFS 1.0.0 capabilities happy).

The WFS KML output format does a similar thing, using KML for WFS 1.0.0 (see above screenshot)
This will result in having variations of the same output listed in WFS 1.1.0 and 2.0.0.

Check the below 1.1.0 WFS capabilities document where KML output is listed with the 3 variations (marked in red) and MapML-HTML in 2 variations (marked in yellow)

Long story short:
When requesting WFS for MAPML, it will indeed serve content as text/mapml
When requesting WFS 1.0.0 for MAPML-HTML or text/html; subtype=mapml it will indeed serve the Mapml client as text/html; subtype=mapml.

Does it clarify?

Yes it does, thank you very much! So the MAPML value gets sent under the text/mapml Content-type: text/mapml. Curious why text/csv didn't get caught by that rule.

I guess it's just that the CSV rule is implemented but the MAPML rule not quite yet, perhaps.

Yes it does, thank you very much! So the MAPML value gets sent under the text/mapml Content-type: text/mapml. Curious why text/csv didn't get caught by that rule.

Actually it gets caught too.
WFS 1.0.0 only reports CSV whilst WFS 1.1.0 reports both csv and text/csv

OK I understand now but in no case do we see text/mapml in the list.

Indeed you don't, it's already the case in an un-modified GeoServer, e.g.:

https://gs-main.geosolutionsgroup.com/geoserver/ows?service=WFS&version=1.1.0&request=GetCapabilities

dromagnoli · 2024-07-10T09:53:17Z

src/extension/mapml/src/main/java/org/geoserver/mapml/MapMLHTMLGetFeatureOutputFormat.java

+            Map<String, Object> rawKvp = Dispatcher.REQUEST.get().getRawKvp();
+            String value = (String) rawKvp.get("SRSNAME");
+            if (value == null) value = (String) rawKvp.get("SRS");
+            throw new ServiceException(


Here, we are using the same logic that is applied by WMS when producing the HTML. Only the 4 MapML supported CRSs will be accepted.

Without having time to get into the code, I must point out that we currently can serve any WFS SRS into MapML, realizing that we can't view that content without a custom TCRS definition, but it still may be useful to serve it for completeness' sake. The technique I've used in the viewer is to disallow / throw on projection values that contain a : colon. So when serving a text/mapml document as EPSG:1234 for example, we could create a custom TCRS definition for EPSG1234 and serve that. If the projection is unknown i.e. no custom TCRS definition exists, the viewer reports a different problem. The purpose of this is to avoid having people think that EPSG:codes code be uses as TCRS names directly. i.e. you need the extra defintional stuff provided by a TCRS, it's not the same thing as an EPSG:code.

dromagnoli · 2024-07-11T08:07:20Z

Hi @prushforth , based on your feedbacks, I will create the official PR in GeoServer if no changes are required.
About the CoordinateReferenceSystems management and supported CRS, we will revisit that part once we will work on the other task related to supporting TCRS configurations.
Please, let us know.

prushforth · 2024-07-11T09:03:24Z

Please, let us know

I apologize I have been looking at Joseph's PR, I will just build this one before I give the thumb's up :-)

prushforth · 2024-07-11T09:32:24Z

About the CoordinateReferenceSystems management and supported CRS, we will revisit that part once we will work on the other task related to supporting TCRS configurations.

Sounds good. Apart from the defaulting to OSMTILE, I am quite happy with this!

edit: maybe I'm wrong about it defaulting to osmtile. Now I'm thinking it's working. I think the content negotiation based on links was fooling me.

dromagnoli · 2024-07-11T09:37:10Z

About the CoordinateReferenceSystems management and supported CRS, we will revisit that part once we will work on the other task related to supporting TCRS configurations.

Sounds good. Apart from the defaulting to OSMTILE, I am quite happy with this!

Ok. Note that we weren't proposing to default to OSMTILE. That was a question since we were defaulting to WGS84.

prushforth · 2024-07-11T09:38:22Z

Sorry its confusion on my part due to getting up at 3:30 am this week

please proceed, lgtm

aaime · 2024-07-15T12:53:06Z

Dang, merged by mistake. Will clean up the history of the geosolutions fork.

dromagnoli requested a review from aaime July 10, 2024 09:40

dromagnoli force-pushed the GEOS-11461 branch from fb43e4a to 7f52ace Compare July 10, 2024 09:46

dromagnoli commented Jul 10, 2024

View reviewed changes

dromagnoli force-pushed the GEOS-11461 branch 3 times, most recently from 52f9fed to c7c612d Compare July 10, 2024 10:38

GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature

4026352

dromagnoli force-pushed the GEOS-11461 branch from c7c612d to 4026352 Compare July 10, 2024 11:32

aaime merged commit 9c63512 into geosolutions-it:main Jul 15, 2024
11 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature #369

GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature #369

dromagnoli commented Jul 10, 2024

dromagnoli Jul 10, 2024 •

edited

Loading

prushforth Jul 10, 2024

prushforth Jul 10, 2024

prushforth Jul 11, 2024

dromagnoli Jul 11, 2024

dromagnoli Jul 10, 2024

prushforth Jul 10, 2024

dromagnoli Jul 10, 2024 •

edited

Loading

prushforth Jul 10, 2024 •

edited

Loading

prushforth Jul 10, 2024

dromagnoli Jul 10, 2024 •

edited

Loading

prushforth Jul 11, 2024

aaime Jul 11, 2024

dromagnoli Jul 10, 2024

prushforth Jul 10, 2024

dromagnoli commented Jul 11, 2024

prushforth commented Jul 11, 2024

prushforth commented Jul 11, 2024 •

edited

Loading

dromagnoli commented Jul 11, 2024

prushforth commented Jul 11, 2024

aaime commented Jul 15, 2024

GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature #369

GEOS-11461: Support MapML embedded viewer on HTML for WFS GetFeature #369

Conversation

dromagnoli commented Jul 10, 2024

Checklist

Notes:

dromagnoli Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dromagnoli Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

prushforth Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dromagnoli Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dromagnoli commented Jul 11, 2024

prushforth commented Jul 11, 2024

prushforth commented Jul 11, 2024 • edited Loading

dromagnoli commented Jul 11, 2024

prushforth commented Jul 11, 2024

aaime commented Jul 15, 2024

dromagnoli Jul 10, 2024 •

edited

Loading

dromagnoli Jul 10, 2024 •

edited

Loading

prushforth Jul 10, 2024 •

edited

Loading

dromagnoli Jul 10, 2024 •

edited

Loading

prushforth commented Jul 11, 2024 •

edited

Loading