[Geoserver-devel] Measured geometries support in WFS

GeoServer GeoServer Developer
,
1

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 :slight_smile:

Cheers,

Nuno Oliveira

--
Regards,
Nuno Oliveira

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.

2

I believe it would be nice/useful to have information about the M at the GeometryDescriptor level,
like done in this commit for the dimensions:
https://github.com/geotools/geotools/commit/a9c4b52c0404ec0357d0006ce8900c209875ec9a

but during a discussion you reported that the info is not always available and/or we might have

a mix of mesured and non measured geometries, could you elaborate?

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.

This would be a new method in a GeoTools “trait” interface that only some CoordinateSequences would
implement?

  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

Have a look here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/api/src/main/java/org/geotools/geometry/jts/DefaultCoordinateSequenceTransformer.java#L61

The following issue in GeoServer as an interesting discussion about this:

https://osgeo-org.atlassian.net/browse/GEOS-8858

Yep, some output formats are allergic to M and we’d have to decide if to return it as a vendor extension (much like the way
we handle 2.5D data declaring a 2D CRS) and others allow loopholes but again not all clients might understand.

Cheers
Andrea

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

3

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 :slight_smile:

Cheers,

Nuno Oliveira

4

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

5

Jody and James,
looks like a great opportunity for collaboration, but the vague timing has me worried.
Like, if the JTS stuff and consequent GeoTools upgrade happen one day before release, that leaves no time for Nuno to react.

I guess Nuno could work off snapshot JTS versions, how stable is the current API? Can we do anything to expedite
the JTS changes?

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

6

Hi Andrea,
please see my answers bellow :slight_smile:

Yes the goal is to have the information about the available measurements in the user data of the geometry descriptor, similar to the dimension information [1], is this aligned with what you were thinking ? Data stores like PostGIS and shapefiles allow us to be explicit about the existence of a measurement, e.g. using geometry types like PointM or LineStringM, so we can infer the number of available measurements by looking at the meta-data, but that may not be the case for all the other supported data stores … For the cases where is not possible to infer the number of measurements automatically we will need to allow the user to provide it explicitly when configuring the layer. Note that this may also be needed for use cases where the user was not explicit about the geometry type. For the moment I’m focusing \ supporting only the use cases where we can infer it automatically. [1] Yes, so basically when reading the geometry from the data source (e.g. PostGIS [2]) we will store the information about the available measurements in the geometry user data, then we will use the new getMeasures() utility method in the CoordianteSequence trait to get the information when needed, e.g. when encoding the geometry to GML 3.2 [3]. [2] [3] Ah yes the re-projections, I hope this class concentrates must of the code used to re-project the coordinates sequences … Ideally that configuration should be per layer basis, i.e. if M are available select all the output formats that should output it. My main doubt is how to make that information reach the for example the GML encoder … a thread local ? Alternatives here are welcome :slight_smile:

···

On 07/31/2018 01:53 PM, Andrea Aime wrote:

I believe it would be nice/useful to have information about the M at the GeometryDescriptor level,
like done in this commit for the dimensions:
https://github.com/geotools/geotools/commit/a9c4b52c0404ec0357d0006ce8900c209875ec9a

but during a discussion you reported that the info is not always available and/or we might have

a mix of mesured and non measured geometries, could you elaborate?

https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L330

On Tue, Jul 31, 2018 at 2:11 PM Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

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.

This would be a new method in a GeoTools “trait” interface that only some CoordinateSequences would
implement?

https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L181-L211
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301

  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

Have a look here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/api/src/main/java/org/geotools/geometry/jts/DefaultCoordinateSequenceTransformer.java#L61

The following issue in GeoServer as an interesting discussion about this:

https://osgeo-org.atlassian.net/browse/GEOS-8858

Yep, some output formats are allergic to M and we’d have to decide if to return it as a vendor extension (much like the way
we handle 2.5D data declaring a 2D CRS) and others allow loopholes but again not all clients might understand.

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.
7

My thoughts, thanks Andrea :slight_smile:

···

On 07/31/2018 05:17 PM, Andrea Aime wrote:

Jody and James,
looks like a great opportunity for collaboration, but the vague timing has me worried.
Like, if the JTS stuff and consequent GeoTools upgrade happen one day before release, that leaves no time for Nuno to react.

I guess Nuno could work off snapshot JTS versions, how stable is the current API? Can we do anything to expedite
the JTS changes?

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.
8

Hi Nuno,

Quick question since it lines up with some of what Jody has been discussing…

Are you expecting to support more than one measure (i.e., multiple M’s?) or just one? (I’m biased since I’d only need one measure. Jody points to the other cases where users have a number of measures.)

Cheers,

Jim

···

On 07/31/2018 01:19 PM, Nuno Oliveira wrote:

Hi Andrea,
please see my answers bellow :slight_smile:

Yes the goal is to have the information about the available measurements in the user data of the geometry descriptor, similar to the dimension information [1], is this aligned with what you were thinking ? Data stores like PostGIS and shapefiles allow us to be explicit about the existence of a measurement, e.g. using geometry types like PointM or LineStringM, so we can infer the number of available measurements by looking at the meta-data, but that may not be the case for all the other supported data stores … For the cases where is not possible to infer the number of measurements automatically we will need to allow the user to provide it explicitly when configuring the layer. Note that this may also be needed for use cases where the user was not explicit about the geometry type. For the moment I’m focusing \ supporting only the use cases where we can infer it automatically. [1] Yes, so basically when reading the geometry from the data source (e.g. PostGIS [2]) we will store the information about the available measurements in the geometry user data, then we will use the new getMeasures() utility method in the CoordianteSequence trait to get the information when needed, e.g. when encoding the geometry to GML 3.2 [3]. [2] [3] Ah yes the re-projections, I hope this class concentrates must of the code used to re-project the coordinates sequences … Ideally that configuration should be per layer basis, i.e. if M are available select all the output formats that should output it. My main doubt is how to make that information reach the for example the GML encoder … a thread local ? Alternatives here are welcome :slight_smile:

On 07/31/2018 01:53 PM, Andrea Aime wrote:

I believe it would be nice/useful to have information about the M at the GeometryDescriptor level,
like done in this commit for the dimensions:
https://github.com/geotools/geotools/commit/a9c4b52c0404ec0357d0006ce8900c209875ec9a

but during a discussion you reported that the info is not always available and/or we might have

a mix of mesured and non measured geometries, could you elaborate?

https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L330

On Tue, Jul 31, 2018 at 2:11 PM Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

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.

This would be a new method in a GeoTools “trait” interface that only some CoordinateSequences would
implement?

https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L181-L211
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301

  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

Have a look here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/api/src/main/java/org/geotools/geometry/jts/DefaultCoordinateSequenceTransformer.java#L61

The following issue in GeoServer as an interesting discussion about this:

https://osgeo-org.atlassian.net/browse/GEOS-8858

Yep, some output formats are allergic to M and we’d have to decide if to return it as a vendor extension (much like the way
we handle 2.5D data declaring a 2D CRS) and others allow loopholes but again not all clients might understand.

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
9

Hi Jim,

Our current use case is to support one … but I’m aiming at he more general use case where we can have multiple ones whenever is possible.
The number of measures that will be supported will be limited by the input and output formats.

Cheers,

···

On 07/31/2018 06:31 PM, Jim Hughes wrote:

Hi Nuno,

Quick question since it lines up with some of what Jody has been discussing…

Are you expecting to support more than one measure (i.e., multiple M’s?) or just one? (I’m biased since I’d only need one measure. Jody points to the other cases where users have a number of measures.)

Cheers,

Jim

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

On 07/31/2018 01:19 PM, Nuno Oliveira wrote:

Hi Andrea,
please see my answers bellow :slight_smile:

Yes the goal is to have the information about the available measurements in the user data of the geometry descriptor, similar to the dimension information [1], is this aligned with what you were thinking ? Data stores like PostGIS and shapefiles allow us to be explicit about the existence of a measurement, e.g. using geometry types like PointM or LineStringM, so we can infer the number of available measurements by looking at the meta-data, but that may not be the case for all the other supported data stores … For the cases where is not possible to infer the number of measurements automatically we will need to allow the user to provide it explicitly when configuring the layer. Note that this may also be needed for use cases where the user was not explicit about the geometry type. For the moment I’m focusing \ supporting only the use cases where we can infer it automatically. [1] Yes, so basically when reading the geometry from the data source (e.g. PostGIS [2]) we will store the information about the available measurements in the geometry user data, then we will use the new getMeasures() utility method in the CoordianteSequence trait to get the information when needed, e.g. when encoding the geometry to GML 3.2 [3]. [2] [3] Ah yes the re-projections, I hope this class concentrates must of the code used to re-project the coordinates sequences … Ideally that configuration should be per layer basis, i.e. if M are available select all the output formats that should output it. My main doubt is how to make that information reach the for example the GML encoder … a thread local ? Alternatives here are welcome :slight_smile:

On 07/31/2018 01:53 PM, Andrea Aime wrote:

I believe it would be nice/useful to have information about the M at the GeometryDescriptor level,
like done in this commit for the dimensions:
https://github.com/geotools/geotools/commit/a9c4b52c0404ec0357d0006ce8900c209875ec9a

but during a discussion you reported that the info is not always available and/or we might have

a mix of mesured and non measured geometries, could you elaborate?

https://github.com/geotools/geotools/blob/master/modules/library/jdbc/src/main/java/org/geotools/jdbc/JDBCFeatureSource.java#L330

On Tue, Jul 31, 2018 at 2:11 PM Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

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.

This would be a new method in a GeoTools “trait” interface that only some CoordinateSequences would
implement?

https://github.com/geotools/geotools/blob/master/modules/plugin/jdbc/jdbc-postgis/src/main/java/org/geotools/data/postgis/WKBReader.java#L181-L211
https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml2/src/main/java/org/geotools/gml2/simple/GMLWriter.java#L287-L301

  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

Have a look here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/api/src/main/java/org/geotools/geometry/jts/DefaultCoordinateSequenceTransformer.java#L61

The following issue in GeoServer as an interesting discussion about this:

https://osgeo-org.atlassian.net/browse/GEOS-8858

Yep, some output formats are allergic to M and we’d have to decide if to return it as a vendor extension (much like the way
we handle 2.5D data declaring a 2D CRS) and others allow loopholes but again not all clients might understand.

Cheers
Andrea

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](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](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
10

Hi Nuno, Andrea,

Good questions. From my side, if we all agree on Jody’s PR(1), then that should be most of the API changes. I’d like to see the WK(B|K) readers and writers updated to handle Z and M.

In terms of time frame, are you trying to get this into GeoTools 20/GeoServer 2.14? (And when is that scheduled/expected? September or later? If so, we can identify a JTS release date that’d work.)

For expediting the JTS work, I’m looking for consensus and validation of the changes around Z and M. In some sense, if Nuno’s work builds off a JTS snapshot, I feel like that’d validate the JTS changes very well. For the WKB Reader/Writers, would that need to be in GeoTools to cover non-linear cases? I’d love to see fewer classes called WKBReader, but I know that might not be possible;).

Cheers,

Jim

  1. https://github.com/locationtech/jts/pull/293
···

On 07/31/2018 01:21 PM, Nuno Oliveira wrote:

My thoughts, thanks Andrea :slight_smile:

On 07/31/2018 05:17 PM, Andrea Aime wrote:

Jody and James,
looks like a great opportunity for collaboration, but the vague timing has me worried.
Like, if the JTS stuff and consequent GeoTools upgrade happen one day before release, that leaves no time for Nuno to react.

I guess Nuno could work off snapshot JTS versions, how stable is the current API? Can we do anything to expedite
the JTS changes?

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [http://sdm.link/slashdot](http://sdm.link/slashdot)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
11

Hi Nuno, Andrea,

Good questions. From my side, if we all agree on Jody’s PR(1), then that should be most of the API changes. I’d like to see the WK(B|K) readers and writers updated to handle Z and M.

In terms of time frame, are you trying to get this into GeoTools 20/GeoServer 2.14?

Yes

(And when is that scheduled/expected? September or later? If so, we can identify a JTS release date that’d work.)

The changes must be developed, reviewed and merged before August 18th (2.14-RC, with the cut of the new stable branch),
any change landing after that date will be locked in GeoServer 2.15/GeoTools 21 with no immediate option to backport them
(we can discuss it of course, the PSC can override the default behavior, but normally we don’t do feature backports in the first bugfix release).
What needs to be stable is the API, in an ideal world Nuno should be able to kick the tires of the current JTS implementation and
provide feedback, and then have a coordinated commit/release when everything is working (otherwise we risk discovering problems
past release and be in indeed of a newer one right away).

For expediting the JTS work, I’m looking for consensus and validation of the changes around Z and M. In some sense, if Nuno’s work builds off a JTS snapshot, I feel like that’d validate the JTS changes very well. For the WKB Reader/Writers, would that need to be in GeoTools to cover non-linear cases? I’d love to see fewer classes called WKBReader, but I know that might not be possible;).

Yes, must be in GeoTools to cover the non linear case. That’s not “WKB” either, it’s extended WKB, a PostGIS specific extension to
the official WKB.
If you want, you could look at the JTS WKB reader vs GeoTools WKB reader and figure out how to change the JTS one to allow subclassing,
so that the GeoTools one can just extend the JTS one.

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

12

Okay my PR is now tested and ready to go, with PackedCoordinateSequence providing an implementation of the API.
Once that is merged and we have a release commitment I hope Nuno can make use of a 1.16-SNAPSHOT.

···

–
Jody Garnett

13

Mind, GeoTools and GeoServer use extensively LiteCoordinateSequence to have maximum performance in WMS (but found
it’s used also in WFS) , as it gives direct access to its internal array
(bad for JTS API wise, but fundamental to avoid reallocations in the rendering chain [1]).
And oh, that’s a PackedCoordinateSequence subclass!

Hum… well I guess that LiteCoordinateSequence will just inherit the new functionality from its base class
(as long as it’s in PackedCoordinateSequence and not in its non abstract subclasses) :slight_smile:

Jody, any reason not to have that method in all coordinate sequences, with a default implementation?
Or at least have it in the most common one, CoordinateArraySequence?

Cheers
Andrea

[1]: One thing Laurent Bourges suggested is to replace that coordinate sequence with a different one that
would pool the ordinate arrays. That’s how Marlin got its main performance boost, by avoiding allocating
and throwing away lots of arrays. I did not find the time to look into it yet, and I’m not sure it will provide
a measurable benefit, most of the time now seems to be spent in IO and encoding results.

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

14

Can you tell me more above it the direct access to the coordinate array?

I did fix up the remaining coordinate sequence implementations last night, but if you have any API requests now is the time.

If LiteCoordinateSequence is useful perhaps it is an approach to be taken for JTS.

One idea that came up during implementation was CoordinateSequence.createCoordinate( double … ordinates ) to prevent client code having to sort out what is required and allow sequences to define new implementations.

···

–
Jody Garnett

15

Ok. Basically we have bits of code that love to work against arrays of ordinates, direct access to the ordinate array avoids
having to build a new copy of the internal array in the consumer code (e.g., reprojection is significantly faster when working directly
against an array of ordinates, than when reprojecting point by point).
Check the getXYArray and getOrdinateArray(dimension) here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/main/src/main/java/org/geotools/geometry/jts/LiteCoordinateSequence.java#L278

and their usage in these two places:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/main/src/main/java/org/geotools/geometry/jts/Decimator.java#L463

https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/main/src/main/java/org/geotools/geometry/jts/LineIterator2.java#L76

and then also direct access on the write side here:
https://github.com/geotools/geotools/blob/9fbd02a320fa19d563972808d226a0a0445a5b13/modules/library/main/src/main/java/org/geotools/geometry/jts/Decimator.java#L540

Now, ideally on the last bit of code it would be nice to avoid having that second array allocation for the packed, final size version of the array,
and instead just tell the sequence to keep its array, but consider only the first N elements. Back when this was coded (over 10 years ago) we did not have yet
PNGJ and Marlin, so I’m guessing doing that did not give much benefit, but today it might, given the different weight of the various map serving steps.
Something to try out on a rainy day, or if/when we participate again in a performance contest [1], along with Laurent’s suggestion to
pool the arrays instead of re-allocating them over and over for each new geometry read (that would require a StreamingRenderer specific
coordinate sequence factory that has a “dispose” method which will give back the ordinate arrays to the pool).

Cheers
Andrea

[1] Reminder, while we haven’t had a FOSS4G performance shootout in a long while, the performance is still being checked regularly,
e.g.http://www.agrotic.org/blog/wp-content/uploads/2016/12/02_performance_qgis_server.pdf
and
https://github.com/camptocamp/ms_perfs
https://github.com/camptocamp/docker-geoserver/

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

16

Okay so it looks like access to a double array is what is important here, and dimension and measures can be used as a guide to the contents. The size can even be used if you end up in the case you describe where the array is longer then the data contained within it.

I assume you only want this array if it is readily available. Easy enough to add that method to PackedCoordinateSequence.DOUBLE. But for CoordianteArraySequence or PackedCoordinateSequence.FLOAT there is no advantage to be had.

···

–
Jody Garnett

17

Wrong assumption, check the code, if it’s not readily available the version with the desired dimensions is built on the fly.
Doing otherwise would have littered the code with even more ifs (there are enough checking if the sequence is a Lite one already).
I suggest you check call points method by method, I gave you examples, but if you want to get rid of LiteCoordinateSequence in GeoTools, you’ll have to cover it all.

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

18

Restarting this thread, although perhaps you saw the update in the meeting notes.

The XYZM support has been merged to jts master branch, so you should be in position to start your work (using 1.16.0-SNAPSHOT). Expect to issue a 1.16.0-RC when you are ready to merge your work.

James is starting the release cycle for JTS on gitter, takes about three weeks, putting us in position to make an official 1.16.0 release in September.

···

–
Jody Garnett

19

Hi Jody,
yes I saw the notes, thanks for the heads up :slight_smile:

I have made two PRs one in GeoServer and another one GeoTools:

The GeoServer PR basically allow us to configure per feature type if coordinates measures should be encoded or not (is a check-box in the publishing tab under WFS section).

The GeoTools pull request makes:

  • PostGIS correctly read coordinates with measures
  • GML3 and GML32 correctly encode coordinates with measurements or not if it was configured that way (GS checkbox)

Looking forward to read you feedback on this.

Thanks,

Nuno Oliveira

···

On 08/09/2018 04:31 AM, Jody Garnett wrote:

Restarting this thread, although perhaps you saw the update in the meeting notes.

The XYZM support has been merged to jts master branch, so you should be in position to start your work (using 1.16.0-SNAPSHOT). Expect to issue a 1.16.0-RC when you are ready to merge your work.

James is starting the release cycle for JTS on gitter, takes about three weeks, putting us in position to make an official 1.16.0 release in September.

–
Jody Garnett

On Tue, 31 Jul 2018 at 05:09, Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

Hi all,

I’m working on bringing support for M measurements in WFS. Some parallel work
related with this is happening on JTS:

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 :slight_smile:

Cheers,

Nuno Oliveira

–
Regards,
Nuno Oliveira

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.
20

I spend some time today investigating a few tests \ compilations failures:

First comment, the current API breaks backward compatibility by requiring that a measure should always be provided when building a coordinate sequence, IMHO it should have a fallback method that assumes zero measures if none if provided … otherwise changes in jaitools will also be required.

When investigating a failing test I step on a visibility change [1] that doesn’t allow us to change LiteCoordinateSequence coordinates\dimension in place anymore.
Long story short, we cannot set again the dimension anymore when changing the coordinates array [2], hence we cannot also change geometries in place anymore …
Is there any good reason for the visibility change ? could it be reverted ?

Another issues, the following test [3] is failing when invoking the normalize function [4] on polygon:

Caused by: java.lang.IllegalArgumentException: Invalid ordinate index: 2
at org.locationtech.jts.geom.CoordinateXY.getOrdinate(CoordinateXY.java:77)
at org.locationtech.jts.geom.impl.CoordinateArraySequence.getOrdinate(CoordinateArraySequence.java:260)
at org.locationtech.jts.geom.CoordinateSequences.swap(CoordinateSequences.java:47)
at org.locationtech.jts.geom.CoordinateSequences.reverse(CoordinateSequences.java:32)
at org.locationtech.jts.geom.Polygon.normalize(Polygon.java:429)
at org.locationtech.jts.geom.Polygon.normalized(Polygon.java:416)
at org.locationtech.jts.geom.Polygon.normalize(Polygon.java:374)
at it.geosolutions.jaiext.vectorbin.ROIGeometry.(ROIGeometry.java:269)
at it.geosolutions.jaiext.vectorbin.ROIGeometry.(ROIGeometry.java:195)
at it.geosolutions.jaiext.vectorbin.ROIGeometry.(ROIGeometry.java:150)
at org.geotools.coverage.grid.io.footprint.MultiLevelROIGeometry$FastClipROIGeometry.(MultiLevelROIGeometry.java:162)
at org.geotools.coverage.grid.io.footprint.MultiLevelROIGeometry.getTransformedROI(MultiLevelROIGeometry.java:128)
at org.geotools.coverage.grid.io.footprint.MultiLevelROIGeometry.getTransformedROI(MultiLevelROIGeometry.java:45)
at org.geotools.gce.imagemosaic.GranuleDescriptor.loadRaster(GranuleDescriptor.java:1348)
at org.geotools.gce.imagemosaic.GranuleLoader.call(GranuleLoader.java:108)
… 44 more

I’m not familiar with JTS code, so I’m clueless in find out what may be causing this :frowning:

Last finding, the previous coordinate object, even if only a dimension of 2 was provided, was always allowing to access or set a Z value, this is not the case anymore in the new API [5].
I agree that the behavior of the new API is the correct behavior, but unfortunately it breaks existing expectations. The issue here is that again this will prevent us to change geometries in place, which means that some not so trivial re-factor will need to be done in a few places.

This are the issues I found when using the new JTS API, all of the found issues (at exception the polygon normalize) are the consequence of the new JTS API breaking backward compatibility.

[1] https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/geom/impl/PackedCoordinateSequence.java#L48
[2] https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/geometry/jts/LiteCoordinateSequence.java#L81-L88
[3] https://github.com/geotools/geotools/blob/master/modules/plugin/imagemosaic/src/test/java/org/geotools/gce/imagemosaic/ImageMosaicFootprintsTest.java#L1053-L1080
[4] https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/geom/Polygon.java#L373-L379
[5] https://github.com/locationtech/jts/blob/master/modules/core/src/main/java/org/locationtech/jts/geom/CoordinateXY.java#L80-L92

···

On 08/14/2018 03:27 AM, Nuno Oliveira wrote:

Hi Jody,
yes I saw the notes, thanks for the heads up :slight_smile:

I have made two PRs one in GeoServer and another one GeoTools:

The GeoServer PR basically allow us to configure per feature type if coordinates measures should be encoded or not (is a check-box in the publishing tab under WFS section).

The GeoTools pull request makes:

  • PostGIS correctly read coordinates with measures
  • GML3 and GML32 correctly encode coordinates with measurements or not if it was configured that way (GS checkbox)

Looking forward to read you feedback on this.

Thanks,

Nuno Oliveira

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

On 08/09/2018 04:31 AM, Jody Garnett wrote:

Restarting this thread, although perhaps you saw the update in the meeting notes.

The XYZM support has been merged to jts master branch, so you should be in position to start your work (using 1.16.0-SNAPSHOT). Expect to issue a 1.16.0-RC when you are ready to merge your work.

James is starting the release cycle for JTS on gitter, takes about three weeks, putting us in position to make an official 1.16.0 release in September.

–
Jody Garnett

On Tue, 31 Jul 2018 at 05:09, Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

Hi all,

I’m working on bringing support for M measurements in WFS. Some parallel work
related with this is happening on JTS:

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 :slight_smile:

Cheers,

Nuno Oliveira

–
Regards,
Nuno Oliveira

GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Con riferimento alla normativa sul trattamento dei dati
personali (Reg. UE 2016/679 - Regolamento generale sulla
protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto,
gli eventuali allegati, etc.) è un dato la cui conoscenza
è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è
tenuta/o a cancellarlo, ogni altra operazione è illecita.
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to
which it is addressed and may contain information that
is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European
Regulation 2016/679 “GDPR” - copying, dissemination or
use of this e-mail or the information herein by anyone
other than the intended recipient is prohibited. If you
have received this email by mistake, please notify
us immediately by telephone or e-mail.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.