[Geoserver-devel] Status of support for Z-values in Geoserver?

What is the current status of support for Z-values in GeoServer? Specifically, support for reading and writing Z values on vertices of geometry in WFS, to datastores which support Z.

I see this has been raised as an issue in the past, and the response then was that this would be a non-trivial exercise to add to the stack. Is this still the situation?

Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Hi Martin,

Not sure there is a quick answer to this one. It depends on what backend data formats are in play, but also what type of output format / encoding is in play. Some will respect z, others don’t.

Indeed it is a non-trivial exercise to modify things to preserve z through an entire request chain. I would start with a specific format, say postgis, and then start surveying a bunch of different outputs formats. GML 3/2, GeoJSON, figuring out where along the chain z is dropped.

Take for instance the specific case of WFS 1.1/GML 3 output with a postgis backend. The postgis driver explicitly forces 2d coordinates with a Force2D call. And also last time I checked the GML3 geometry bindings also ignore the third coordinate. Obviously those things would have to be changed to carry z through.

Then of course there would be the opposite chain with wfs transactions. I am less familiar with the behaviour in that case but the exercise remains the same. Debug different scenarios and patch accordingly.

-Justin

On Tue, Mar 6, 2012 at 6:03 PM, Martin Davis <mdavis@anonymised.com> wrote:

What is the current status of support for Z-values in GeoServer? Specifically, support for reading and writing Z values on vertices of geometry in WFS, to datastores which support Z.

I see this has been raised as an issue in the past, and the response then was that this would be a non-trivial exercise to add to the stack. Is this still the situation?

Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.


Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Wed, Mar 7, 2012 at 4:47 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Martin,

Not sure there is a quick answer to this one. It depends on what backend data formats are in play, but also what type of output format / encoding is in play. Some will respect z, others don’t.

Indeed it is a non-trivial exercise to modify things to preserve z through an entire request chain. I would start with a specific format, say postgis, and then start surveying a bunch of different outputs formats. GML 3/2, GeoJSON, figuring out where along the chain z is dropped.

Take for instance the specific case of WFS 1.1/GML 3 output with a postgis backend. The postgis driver explicitly forces 2d coordinates with a Force2D call. And also last time I checked the GML3 geometry bindings also ignore the third coordinate. Obviously those things would have to be changed to carry z through.

Then of course there would be the opposite chain with wfs transactions. I am less familiar with the behaviour in that case but the exercise remains the same. Debug different scenarios and patch accordingly.

And btw, don’t patch as if anything would want the 3rd dimension, the renderer never does,
and explicitly asks to use a particular type of 2d coordinate sequences.
Here is the code setting up the hints:

// … basic one, we want fast and compact coordinate sequences and geometries optimized
// for the collection of one item case (typical in shapefiles)
LiteCoordinateSequenceFactory csFactory = new LiteCoordinateSequenceFactory();
GeometryFactory gFactory = new SimpleGeometryFactory(csFactory);
Hints hints = new Hints(Hints.JTS_COORDINATE_SEQUENCE_FACTORY, csFactory);
hints.put(Hints.JTS_GEOMETRY_FACTORY, gFactory);
hints.put(Hints.FEATURE_2D, Boolean.TRUE);

A optimized datastore should honor all of them.

For the record, the lite coordinate sequence is a special case of packed coordinate sequence
that can be manipulated and copied directly, the SimpleGeoemtryFactory uses special
subclasses of Geometry for the case of MultiGeometry with a single element inside
(avoids the overhead of arrays and the like), and FEATURE_2D asks for 2d geometries

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


On Wed, Mar 7, 2012 at 2:03 AM, Martin Davis <mdavis@anonymised.com> wrote:

What is the current status of support for Z-values in GeoServer? Specifically, support for reading and writing Z values on vertices of geometry in WFS, to datastores which support Z.

I see this has been raised as an issue in the past, and the response then was that this would be a non-trivial exercise to add to the stack. Is this still the situation?

Back at the times of GeoServer 1.7.x I opened a straight path from postgis to kml (and only this specific path, not others).
However that path could not have tests in the build, since one cannot assume PostGIS is around and we did not have
the test machinery to setup a postgis specific test back then, eventually during the various component upgrades
the path was severed.

If you open a new one this time try to open it for embedded H2 as well, of shapefiles, or the property data store, anything
that can be used in a test in the build, so that this time the path stays open for good

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Thanks for the good comments, guys.

Good to know about the 2D hint for rendering - that seems like an elegant solution.

That brings up another design question. If Z is available from the datastore, should it always automatically be provided in WFS requests? And if not, how would that be indicated? (I.e a flag on the request? Or else just a flag at the layer definition level?)

On Wed, Mar 7, 2012 at 12:14 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Mar 7, 2012 at 2:03 AM, Martin Davis <mdavis@anonymised.com> wrote:

What is the current status of support for Z-values in GeoServer? Specifically, support for reading and writing Z values on vertices of geometry in WFS, to datastores which support Z.

I see this has been raised as an issue in the past, and the response then was that this would be a non-trivial exercise to add to the stack. Is this still the situation?

Back at the times of GeoServer 1.7.x I opened a straight path from postgis to kml (and only this specific path, not others).
However that path could not have tests in the build, since one cannot assume PostGIS is around and we did not have
the test machinery to setup a postgis specific test back then, eventually during the various component upgrades
the path was severed.

If you open a new one this time try to open it for embedded H2 as well, of shapefiles, or the property data store, anything
that can be used in a test in the build, so that this time the path stays open for good

Cheers

Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

On Wed, Mar 7, 2012 at 6:39 PM, Martin Davis <mdavis@anonymised.com> wrote:

Thanks for the good comments, guys.

Good to know about the 2D hint for rendering - that seems like an elegant
solution.

That brings up another design question. If Z is available from the
datastore, should it always automatically be provided in WFS requests? And
if not, how would that be indicated? (I.e a flag on the request? Or else
just a flag at the layer definition level?)

imho wfs should just return data as is it, if there is a Z it should be there.
There are no options to flatten data in WFS, we could roll a vendor extension
if someone is interested in that though

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

Ok, sounds good. That seems like the simplest option.

On Wed, Mar 7, 2012 at 9:50 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Mar 7, 2012 at 6:39 PM, Martin Davis <mdavis@anonymised.com…> wrote:

Thanks for the good comments, guys.

Good to know about the 2D hint for rendering - that seems like an elegant
solution.

That brings up another design question. If Z is available from the
datastore, should it always automatically be provided in WFS requests? And
if not, how would that be indicated? (I.e a flag on the request? Or else
just a flag at the layer definition level?)

imho wfs should just return data as is it, if there is a Z it should be there.
There are no options to flatten data in WFS, we could roll a vendor extension
if someone is interested in that though

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf


Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

+1.. If I'm allowed to vote :wink:

Some time ago I've made some modifications to a local geoserver
version to be able to preserve the Z value in the Postgresql -
GeoServer - WFS chain with EPSG:7415

It works and it wasn't difficult but I ran into some trouble with
calculation of the bbox value (from native srs to latlon bbox) when
adding a layer.
This was caused by the fact that the dimensions of the two srs'es were
different.. (two versus three).

We're also using WFS-T and at the moment we use a seperate height
column to piggyback the Z column..

It would be great if this will go into the geoserver trunk and
eventually turn into a release :slight_smile:

Best regards,
Sjoerd Brandsma
CycloMedia

On Wed, Mar 7, 2012 at 7:40 PM, Martin Davis <mdavis@anonymised.com> wrote:

Ok, sounds good. That seems like the simplest option.

On Wed, Mar 7, 2012 at 9:50 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Wed, Mar 7, 2012 at 6:39 PM, Martin Davis <mdavis@anonymised.com> wrote:
> Thanks for the good comments, guys.
>
> Good to know about the 2D hint for rendering - that seems like an
> elegant
> solution.
>
> That brings up another design question. If Z is available from the
> datastore, should it always automatically be provided in WFS requests?
> And
> if not, how would that be indicated? (I.e a flag on the request? Or
> else
> just a flag at the layer definition level?)

imho wfs should just return data as is it, if there is a Z it should be
there.
There are no options to flatten data in WFS, we could roll a vendor
extension
if someone is interested in that though

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I forgot to mention:

This is done with the 'modified' version of geoserver under the hood:

http://www.opengeospatial.org/blog/1552

Keep up the good work!

Best regards,
Sjoerd

On Wed, Mar 7, 2012 at 10:26 PM, Sjoerd Brandsma <sbrandsma@anonymised.com> wrote:

+1.. If I'm allowed to vote :wink:

Some time ago I've made some modifications to a local geoserver
version to be able to preserve the Z value in the Postgresql -
GeoServer - WFS chain with EPSG:7415

It works and it wasn't difficult but I ran into some trouble with
calculation of the bbox value (from native srs to latlon bbox) when
adding a layer.
This was caused by the fact that the dimensions of the two srs'es were
different.. (two versus three).

We're also using WFS-T and at the moment we use a seperate height
column to piggyback the Z column..

It would be great if this will go into the geoserver trunk and
eventually turn into a release :slight_smile:

Best regards,
Sjoerd Brandsma
CycloMedia

On Wed, Mar 7, 2012 at 7:40 PM, Martin Davis <mdavis@anonymised.com> wrote:

Ok, sounds good. That seems like the simplest option.

On Wed, Mar 7, 2012 at 9:50 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Wed, Mar 7, 2012 at 6:39 PM, Martin Davis <mdavis@anonymised.com> wrote:
> Thanks for the good comments, guys.
>
> Good to know about the 2D hint for rendering - that seems like an
> elegant
> solution.
>
> That brings up another design question. If Z is available from the
> datastore, should it always automatically be provided in WFS requests?
> And
> if not, how would that be indicated? (I.e a flag on the request? Or
> else
> just a flag at the layer definition level?)

imho wfs should just return data as is it, if there is a Z it should be
there.
There are no options to flatten data in WFS, we could roll a vendor
extension
if someone is interested in that though

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

--
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel