[Geoserver-users] extraneous horizontal lines drawn when contouring a raster

GeoServer GeoServer User
1

I have an sld that applies the geoserver bundled wps contouring process transform to a raster (geotiff). When the GetMap request srs param differs from the tiff's native srs and the tiff's contents cross a boundary in the projection specified in the request, the returned map image still has the normal contours but also has horizontal lines that appear to be connecting points on the right of the image with points on the left side of the image. See attached picture.

I think the cause of this is that the wps doesn't have access to the request srs or the re-projected geotiff, so contouring occurs in the tiff's native srs - which is passed to the wps in the GridCoverage2D parameter. So contouring occurs in, say epsg:4326 where it might be reasonable to connect a point at, say -31,6 (lon/lat) to a point at -29,6 if they have similar userData values. But if the target projection is a whole-world cylindrical projection centered on 150 lon, then -30 is the edge of the world and those points are on opposite sides of the image. So the points should not be connected because it would require drawing around the back side of the image, if you will.

I know that geoserver can handle splitting raster data sources when necessary during re-projection. It happily splits the raster and shows part of it on the left and part of it on the right. (This is a very cool feature by the way.) But when the raster is vectorized (into lineStrings) via the contour service this splitting during re-projection doesn't appear to occur. Maybe the re-projection occurs on the vector data before it gets rasterized and the cool raster splitting code doesn't work on lines/polygons? Is there something that I'm missing, or is this a limitation of geoserver?

I'm using geoserver 2.7.2 but the contour process doesn't appear to have changed in any significant way since 2.7.2. Thanks for any info or suggestions you may have.

Tom Ruff

horizontalContourLines.png

2

Hi Ruff,
the contour process did change recently, to handle flat areas,
you might want to try out and see if that helps any but… I’m not sure it will,

it seems you’re having issues with dateline crossing, which is something “new”

for the contouring stuff.

I believe it can be fixed, but might not be trivial.

Cheers
Andrea

···

On Fri, Feb 26, 2016 at 4:56 AM, Ruff, Thomas <THOMAS.RUFF@anonymised.com> wrote:

I have an sld that applies the geoserver bundled wps contouring process transform to a raster (geotiff). When the GetMap request srs param differs from the tiff’s native srs and the tiff’s contents cross a boundary in the projection specified in the request, the returned map image still has the normal contours but also has horizontal lines that appear to be connecting points on the right of the image with points on the left side of the image. See attached picture.

I think the cause of this is that the wps doesn’t have access to the request srs or the re-projected geotiff, so contouring occurs in the tiff’s native srs - which is passed to the wps in the GridCoverage2D parameter. So contouring occurs in, say epsg:4326 where it might be reasonable to connect a point at, say -31,6 (lon/lat) to a point at -29,6 if they have similar userData values. But if the target projection is a whole-world cylindrical projection centered on 150 lon, then -30 is the edge of the world and those points are on opposite sides of the image. So the points should not be connected because it would require drawing around the back side of the image, if you will.

I know that geoserver can handle splitting raster data sources when necessary during re-projection. It happily splits the raster and shows part of it on the left and part of it on the right. (This is a very cool feature by the way.) But when the raster is vectorized (into lineStrings) via the contour service this splitting during re-projection doesn’t appear to occur. Maybe the re-projection occurs on the vector data before it gets rasterized and the cool raster splitting code doesn’t work on lines/polygons? Is there something that I’m missing, or is this a limitation of geoserver?

I’m using geoserver 2.7.2 but the contour process doesn’t appear to have changed in any significant way since 2.7.2. Thanks for any info or suggestions you may have.

Tom Ruff

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

==
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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

3

Thanks for your reply Andrea.

I was able to hack a fix by splitting the post-contoured (vector) data at the boundary of my target projection. I believe that this confirms my suspicion of the root cause described below - essentially that geoserver doesn’t split geometry in vector backed layers when the geometry crosses a boundary in the target projection of a GetMap request. I’ve noticed this same problem with postgres features in epsg:4326 that I try to render via GetMap in a pacific centered projection. Are there any plans to address this? If you have suggestions on where to start looking in the geoserver code that would be helpful.

Tom

···

On Fri, Feb 26, 2016 at 4:56 AM, Ruff, Thomas <THOMAS.RUFF@…554…> wrote:

I have an sld that applies the geoserver bundled wps contouring process transform to a raster (geotiff). When the GetMap request srs param differs from the tiff’s native srs and the tiff’s contents cross a boundary in the projection specified in the request, the returned map image still has the normal contours but also has horizontal lines that appear to be connecting points on the right of the image with points on the left side of the image. See attached picture.

I think the cause of this is that the wps doesn’t have access to the request srs or the re-projected geotiff, so contouring occurs in the tiff’s native srs - which is passed to the wps in the GridCoverage2D parameter. So contouring occurs in, say epsg:4326 where it might be reasonable to connect a point at, say -31,6 (lon/lat) to a point at -29,6 if they have similar userData values. But if the target projection is a whole-world cylindrical projection centered on 150 lon, then -30 is the edge of the world and those points are on opposite sides of the image. So the points should not be connected because it would require drawing around the back side of the image, if you will.

I know that geoserver can handle splitting raster data sources when necessary during re-projection. It happily splits the raster and shows part of it on the left and part of it on the right. (This is a very cool feature by the way.) But when the raster is vectorized (into lineStrings) via the contour service this splitting during re-projection doesn’t appear to occur. Maybe the re-projection occurs on the vector data before it gets rasterized and the cool raster splitting code doesn’t work on lines/polygons? Is there something that I’m missing, or is this a limitation of geoserver?

I’m using geoserver 2.7.2 but the contour process doesn’t appear to have changed in any significant way since 2.7.2. Thanks for any info or suggestions you may have.

Tom Ruff

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

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

–

==
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

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

4

On Fri, Mar 4, 2016 at 1:20 AM, Ruff, Thomas <THOMAS.RUFF@anonymised.com> wrote:

Thanks for your reply Andrea.

I was able to hack a fix by splitting the post-contoured (vector) data at
the boundary of my target projection. I believe that this confirms my
suspicion of the root cause described below - essentially that geoserver
doesn't split geometry in vector backed layers when the geometry crosses a
boundary in the target projection of a GetMap request. I've noticed this
same problem with postgres features in epsg:4326 that I try to render via
GetMap in a pacific centered projection. Are there any plans to address
this? If you have suggestions on where to start looking in the geoserver
code that would be helpful.

Hi,
there is already some attempt to address these in the ProjectionHandler
classes, but they are a set of heuristics
and only address certain real world cases.
So I'd first try 2.9-beta, that has the latest improvements in those
classes, and if that does not work,
check this set of classes and see if anything can be done to improve things:

https://github.com/geotools/geotools/tree/master/modules/library/render/src/main/java/org/geotools/renderer/crs

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

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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