Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?

[Martin Davis]

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

Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?

[Phil Scadden]

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

[Phil Scadden]

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?

[Martin Davis]

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?

[Rahkonen Jukka (MML)]

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

Re: [Geoserver-users] geoserver 2.7 publish style

[Bessette-Halsema, Dominique E]

I believe it is set to false.





 Request Logging Filter

 org.geoserver.filters.LoggingFilter

 

 

 enabled

 false

 

 

 

 log-request-bodies

 false

 

   



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 
mailto: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.





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

  

nrdb_threshold_132



  surface air temperature

  

nrdb_threshold_132

Feature



  



  

  



  



  



  






--

___
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 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 c

[Geoserver-users] GeoServer on Java 8 VM

[Kevin Smith]

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 

ksm...@boundlessgeo.com

+1-778-785-7459

@boundlessgeo 




[image: 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?

[Martin Davis]

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

> On Wed, Jun 10, 2015 at 7:41 PM, 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.
>>
>>
> 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

Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?

[Andrea Aime]

On Wed, Jun 10, 2015 at 7:41 PM, 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.
>
>
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] Reduce Geometry size in GetFeatureInfo responses?

[Martin Davis]

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  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] Reduce Geometry size in GetFeatureInfo responses?

[Martin Davis]

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