This is an interesting one, data was loaded into PostGIS via FME or similar workflow, it is perfectly valid WKB.
WMS works fine as it makes use of ST_Force2D when accessing.
WFS does not work out quite so well, data of the form:
Comes out in GeoJSON, GML2, GML3 as:
The fix should be to pay attention to the geometry dimension and compare / contrast with srs dimension to detect if measures are used.
do we need to sort out the JTS WKTReader with support for M to address this?
Observations for GML:
This probably needs to be handled like Z, we declare a 2D CRS but advertise coordinate dimensions as 3, here we should do 4
In case it's a XYM I believe we should force XYZM in output, otherwise there is no way to know if the third is a M or a Z (this is also the approach suggested by classic GeoJSON)
There are 3 code paths for encoding GML, classic and fast GML2 encoder, "fast" encoding path for GML3+ (used only for simple features), and classic and dreadfully slow GML3+ encoding path (used by complex features)... they all need to be updated
Observations for GeoJSON:
In the "classic GeoJSON" output that we have in WFS core we should probably force a XYZM interpretation whenever there is an M
In the "RFC compliant GeoJSON" output format available in the wfs3 community module I guess one should do only XYZ, the spec if memory serves me well states the M is to be ignored, unless there is an agreement between client and server about it... which could be represented by a vendor option to enable M output.
As an observation, there should be a way to recognize that the ordinate is an M somewhere (e.g., in the GeometryDescriptor user data for example, or by using a particular coordinate sequence), care should be used not to break performance optimizations for the M-less cases (pretty please, lots of work went into them... I believe they are in the WMS code paths only, but cannot be sure)