Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
I should add that it's probably not feasible to use FreeMarker templates, since we have a lot of layers defined, and in some cases we don't have the ability to modify the server configuration. Also, we also want to be able to retrieve the geometry via GetFeatureInfo in some situations. Ideally there would be some kind of query parameter that could be added to control how the geometry is returned in the response. On Wed, Jun 10, 2015 at 10:41 AM, Martin Davis mtncl...@gmail.com wrote: We're looking for ways to improve performance of Identify operations in a web map client (using OpenLayers). We are seeing poor performance due to the network latency of retrieving large GetFeatureInfo reponses. Is there any way to reduce the size of geometries returned in GetFeatureInfo responses? In order of decreasing preference, things that might work for us include: 1. simplify the geometry 2. provide only the bounding box rather than full geometry 3. eliminate the geometry entirely Does the WMS vendor parameter propertyName [1] allow removing the geometry from the response? In any case this isn't ideal for us, because we'd prefer to not have to specify the required properties explicitly. The #2 option of returning only BBOX would be ideal - is that possible? -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
On Wed, Jun 10, 2015 at 7:41 PM, Martin Davis mtncl...@gmail.com wrote: We're looking for ways to improve performance of Identify operations in a web map client (using OpenLayers). We are seeing poor performance due to the network latency of retrieving large GetFeatureInfo reponses. Is there any way to reduce the size of geometries returned in GetFeatureInfo responses? In order of decreasing preference, things that might work for us include: 1. simplify the geometry 2. provide only the bounding box rather than full geometry 3. eliminate the geometry entirely Does the WMS vendor parameter propertyName [1] allow removing the geometry from the response? In any case this isn't ideal for us, because we'd prefer to not have to specify the required properties explicitly. Yeah, you can get whatever property you want, but you have to list explicitly the ones you require The #2 option of returning only BBOX would be ideal - is that possible? Not without changing the code, I guess you could roll a new vendor option, e.g., geometry=none|bbox|standard Simplifying would require yet another param to specify how much to simplify it. 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 Poggio alle Viti 1187 55054 Massarosa (LU) Italy 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. --- -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] geoserver 2.7 publish style
I believe it is set to false. filter filter-nameRequest Logging Filter/filter-name filter-classorg.geoserver.filters.LoggingFilter/filter-class init-param !-- The 'enabled' parameter is a boolean value, true (case-insensitive) for true or any other value for false. If enabled, then the logging will be performed; otherwise the logging filter will have no effect. If not specified, this parameter defaults to false. -- param-nameenabled/param-name param-valuefalse/param-value /init-param init-param !-- The 'log-request-bodies' parameter is a boolean value, true (case-insensitive) for true or any other value for false. If enabled, then the logging will include the body of POST and PUT requests. If not specified, this parameter defaults to false. Note that this may noticeably degrade responsiveness of your geoserver since it will not begin to process requests until the entire request body has been received by the server. -- param-namelog-request-bodies/param-name param-valuefalse/param-value /init-param /filter Dominique Bessette Software Engineer General Dynamics Information Technology Office: 619-881-2748 From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of Andrea Aime Sent: Tuesday, June 09, 2015 10:15 PM To: Bessette-Halsema, Dominique E Cc: geoserver-users@lists.sourceforge.net Subject: Re: [Geoserver-users] geoserver 2.7 publish style HI Dominique, do you have by any chance request logging enabled in web.xml (it is not by default, just checking if you did enabled it)? If so, does your request work if you turn it off? Cheers Andrea On Fri, Jun 5, 2015 at 7:31 PM, Bessette-Halsema, Dominique E dominique.besse...@gdit.commailto:dominique.besse...@gdit.com wrote: I’m trying to publish a style to geoserver 2.7 via the GeoServerRESTPublisher class. If I use the publishStyle(File file) API or the publishStyle(String sldBody) I get the following error 17:19:55,192 ERROR [stderr] (http-/0.0.0.0:8080-1) [Fatal Error] :1:1: Content is not allowed in prolog. 17:19:55,193 ERROR [org.geoserver.rest] (http-/0.0.0.0:8080-1) : java.lang.RuntimeException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog. at org.geotools.styling.SLDParser.parseSLD(SLDParser.java:438) [gt-main-13.1.jar:] at org.geoserver.catalog.SLDHandler.parse10(SLDHandler.java:105) [gs-main-2.7.1-nn-1.jar:2.7.1-nn-1] at org.geoserver.catalog.SLDHandler.parse(SLDHandler.java:97) [gs-main-2.7.1-nn-1.jar:2.7.1-nn-1] at org.geoserver.catalog.rest.StyleFormat.read(StyleFormat.java:91) [gs-restconfig-2.7.1.jar:2.7.1] at org.geoserver.rest.format.StreamDataFormat.toObject(StreamDataFormat.java:34) [gs-rest-2.7.1.jar:2.7.1] at org.geoserver.rest.ReflectiveResource.handlePost(ReflectiveResource.java:118) [gs-rest-2.7.1.jar:2.7.1] … The style xml is below. I formatted it in this email but usually its one long string. I’ve tried trimming for whitespace, removing the encoding, and some other validation checks I’ve found online. I was wondering if anything stands out. ?xml version=1.0 encoding=UTF-8? sld:StyledLayerDescriptor xmlns=http://www.opengis.net/sld; xmlns:sld=http://www.opengis.net/sld; xmlns:ogc=http://www.opengis.net/ogc; xmlns:gml=http://www.opengis.net/gml; version=1.0.0 sld:NamedLayer sld:Namenrdb_threshold_132/sld:Name sld:UserStyle sld:Namesurface air temperature/sld:Name sld:FeatureTypeStyle sld:Namenrdb_threshold_132/sld:Name sld:FeatureTypeNameFeature/sld:FeatureTypeName sld:Rule sld:RasterSymbolizer sld:ColorMap type=intervals sld:ColorMapEntry color=#00 opacity=0.0 quantity=244.160893 label=244.160893/ sld:ColorMapEntry color=#008000 opacity=1.0 quantity=283.789 label=283.789/ /sld:ColorMap /sld:RasterSymbolizer /sld:Rule /sld:FeatureTypeStyle /sld:UserStyle /sld:NamedLayer /sld:StyledLayerDescriptor -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.netmailto: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 Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it AVVERTENZE AI
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
Thanks. That's pretty much what I expected to hear. The vendor option idea sounds good, particularly for the none|bbox options. Agreed that the simplify option would also require a tolerance value. On further thought I'm not sure this would provide an effect that is all that useful, since it's so tied to view map scale. We'll have to weigh the cost of a code enhancement versus the pain of other options... On Wed, Jun 10, 2015 at 10:57 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: On Wed, Jun 10, 2015 at 7:41 PM, Martin Davis mtncl...@gmail.com wrote: We're looking for ways to improve performance of Identify operations in a web map client (using OpenLayers). We are seeing poor performance due to the network latency of retrieving large GetFeatureInfo reponses. Is there any way to reduce the size of geometries returned in GetFeatureInfo responses? In order of decreasing preference, things that might work for us include: 1. simplify the geometry 2. provide only the bounding box rather than full geometry 3. eliminate the geometry entirely Does the WMS vendor parameter propertyName [1] allow removing the geometry from the response? In any case this isn't ideal for us, because we'd prefer to not have to specify the required properties explicitly. Yeah, you can get whatever property you want, but you have to list explicitly the ones you require The #2 option of returning only BBOX would be ideal - is that possible? Not without changing the code, I guess you could roll a new vendor option, e.g., geometry=none|bbox|standard Simplifying would require yet another param to specify how much to simplify it. -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] GeoServer on Java 8 VM
I'm doing testing on how GeoServer runs on Java 8 (Although compiled with Java 7). As yet I'm not seeing any issues, including when I run the unit tests for the release profile. I'll be throwing some automated stress tests at it today. There's no particular reason to expect this to be problematic but I'd like to confirm so does anyone have any experience running in Java 8, be it an interesting a failure or a boring success? Especially if it was in production or involved any attempt to do thorough testing. I know the topic of running on Java 8 has come up before I expect we won't fully lay it to rest until we can build reliably under Java 8, but I would like to get something a bit more solid than it should work or it seems to work. -- Kevin Smith Software Engineer | Boundless http://boundlessgeo.com/ ksm...@boundlessgeo.com +1-778-785-7459 @boundlessgeo http://twitter.com/boundlessgeo/ http://twitter.com/boundlessgeo/ [image: http://boundlessgeo.com/] http://boundlessgeo.com/ -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
We did consider this option as well, but we don't think it will move the needle enough on download size and processing time. Problematic datasets have features with over 10K coordinates. Even if we dropped half the coordinate digits, this would still only reduce the response size to 50%. That's better, but not down to the 5% improvement that the NONE or BBOX strategy would provide. On Wed, Jun 10, 2015 at 2:09 PM, Rahkonen Jukka (MML) jukka.rahko...@maanmittauslaitos.fi wrote: Hi, I would add one more 0. Reduce the precision of coordinates -Jukka Rahkonen- -- Martin Davis wrote: We're looking for ways to improve performance of Identify operations in a web map client (using OpenLayers). We are seeing poor performance due to the network latency of retrieving large GetFeatureInfo reponses. Is there any way to reduce the size of geometries returned in GetFeatureInfo responses? In order of decreasing preference, things that might work for us include: 1. simplify the geometry 2. provide only the bounding box rather than full geometry 3. eliminate the geometry entirely Does the WMS vendor parameter propertyName [1] allow removing the geometry from the response? In any case this isn't ideal for us, because we'd prefer to not have to specify the required properties explicitly. The #2 option of returning only BBOX would be ideal - is that possible? -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
I would say take a leaf from ESRI REST services and add ReturnGeometry=true/false to getFeatureInfo would be a good extension to the WMS format. If you dont really need to execute against multiple layers, then consider using WFS getFeature instead where you can specify propertynames. ( My maps have the concept of active layer for use in all searching, hover controls etc.) Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
I would say take a leaf from ESRI REST services and add ReturnGeometry=true/false to getFeatureInfo would be a good extension to the WMS format. If you dont really need to execute against multiple layers, then consider using WFS getFeature instead where you can specify propertynames. ( My maps have the concept of active layer for use in all searching, hover controls etc.) Actually, I see that propertynames (exclude the shape from list) is a geoserver vendor option for single layer getFeatureInfo. If using OL, you would need to make sure that is in the options parameter for the control, rather than using the propertyNames parameter of the getFeatureInfo control (which filters the fields AFTER the call). returnGeometry=true/false would be a better extension however because it would with multiple layers. -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
All good advice, but unfortunately not so easy to take advantage of in our environment. We allow all visible layers to be queried. This is why we prefer GetFeatureInfo to WFS, since it's sensitive to scale limits. The propertynames option is one way to do this, but we have hundreds of layers, so this would involve a large amount of client-side configuration. And that configuration is brittle - we don't totally control the map servers, and if a property name changes then the request will fail (I think...) A new vendor option of geometry=none|bbox would work well for us, since it offers maximum flexibility for minimum configuration. ESRI sometimes has good ideas 8^) On Wed, Jun 10, 2015 at 2:44 PM, Phil Scadden p.scad...@gns.cri.nz wrote: I would say take a leaf from ESRI REST services and add ReturnGeometry=true/false to getFeatureInfo would be a good extension to the WMS format. If you dont really need to execute against multiple layers, then consider using WFS getFeature instead where you can specify propertynames. ( My maps have the concept of active layer for use in all searching, hover controls etc.) Actually, I see that propertynames (exclude the shape from list) is a geoserver vendor option for single layer getFeatureInfo. If using OL, you would need to make sure that is in the options parameter for the control, rather than using the propertyNames parameter of the getFeatureInfo control (which filters the fields AFTER the call). returnGeometry=true/false would be a better extension however because it would with multiple layers. -- Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232 Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
