It is my hope to release 1.16 when this XYZM stuff is sorted, that can
certainly be done this month prior to the geotools release cycle.
--
Jody Garnett
On Tue, 31 Jul 2018 at 07:24, Jim Hughes <[email protected]> wrote:
> 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
>
------------------------------------------------------------------------------
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
