Hi Nuno,
First, I'm excited to see M measurements in WFS; I believe that's gonna
be widely beneficial.
Second, for JTS, I can speak to the release schedule. The library has
traditionally been rather conservative/slow-to-release. Over the
summer, I visited Martin and Jody to sort out GeoTools/GeoServer
upgrading to JTS 1.15.1.
Generally, my objective is that geometry storage and processing needs in
GeoTools/GeoServer (and well, GeoMesa;)) could be handled in JTS and
benefit everyone. During our week, Jody, Martin, and I talked about
support Z and M. Jody started PR#293 out of that discussion, and I've
separately have a branch to support TWKB (which doesn't work properly
with Z and M yet).
For my part, if we can 'all agree' on the right changes to JTS, we can
cut a JTS 1.16.0 as we like. My opinion is that supporting Z and M with
the CoordinateSequences and IO bits is the outstanding work to do for a
1.16 release.
Cheers,
Jim
1. https://github.com/locationtech/jts/tree/twkb
On 07/31/2018 08:09 AM, Nuno Oliveira wrote:
Hi all,
I'm working on bringing support for M measurements in WFS. Some
parallel work related with this is happening on JTS:
* https://github.com/locationtech/jts/pull/293
* https://github.com/locationtech/jts/pull/291
If I understood the JTS situation correctly, currently is already
possible to store the M measurements values in
JTS geometries (XYZM or XYM), but is up to the client code to identify
them and handle them. The main goal of the
changes above is to create a cleaner \ explicit JTS API, i.e. make it
easier for client code to understand what
type of coordinates are available and make it easier to access the
relevant ordinates.
I'm not aware of JTS release schedule, but I guess these changes will
land on the next major release ? Which means
that they will not be available for us to use in GT\GS anytime soon. I
would like to have the M support for WFS to
land on master before the next GeoServe 2.14.x release, i.e. it need
to land on master next week at most.
Not using the new JTS API means that we will need to store the number
of measures in the geometry user data.
This would be aligned with the new JTS API approach, quoting Jody
comment on one of the pull request above:
I ended up having CoordianteSequence.getDimension() as described in
the conversation above, and
CoordianteSequence.getMeasures() being the number of measures (so if
we have XYZM dimension is 4 and measures is 1.
... so when the new JTS API becomes available we just need to switch
to get the measures value from the JTS API
instead of the user data.
That said, supporting M measurements in WFS will require:
1. correctly read geometries with measurements from data sources
2. correctly encode the measurements in the output formats
3. correctly handling measurements when doing certain operations,
e.g. re-projections
The following issue in GeoServer as an interesting discussion about this:
https://osgeo-org.atlassian.net/browse/GEOS-8858
Using PostGIS and GML 3.2. as an example:
1. we will need to take into account the possibility of a
measurement value when decoding geometries from postgis:
https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L194-L197
2. the correct geometry type (LINESTRINGM, LINESTRINGZM, etc ...)
can be obtained from the database metadata
3. vouch for the M measurement when encoding coordinates, e.g.
linestring encoding for GML 3.2
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301
In point 1 or 2 we will store in the user data the measurements number
and use it in point 3.
Comments on this are welcome :)
Cheers,
Nuno Oliveira
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
