Re: [Geoserver-users] Problem with SLD PointPlacement Displacement not working

[Martin Davis]

Issue created:  https://osgeo-org.atlassian.net/browse/GEOS-9056

On Mon, Dec 10, 2018 at 10:57 PM Andrea Aime 
wrote:

> On Mon, Dec 10, 2018 at 9:37 PM Martin Davis  wrote:
>
>> Are there any known issues with this?  Or is there something wrong with
>> the style?
>>
>
> No "known issue", the functionality is simply missing.
> Polygon placement is "put the label something in there", personally never
> had the need to control
> displacement on it, can't see an existing feature request for it in the
> tracker either, but settings
> are there for polygons too, so they should be honored.
>
> Usual two steps:
>
>- Feel free to open a ticket for it
>- PR welcomed (in case you're interested, have a look at
>LabelCacheImpl in gt-render)
>
> 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.*
>
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Problem with SLD PointPlacement Displacement not working

[Martin Davis]

The maxDisplacement vendor option works well for separating two labels
which are both being rendered at the centre of the image (e.g. due to the
map extent being wholly inside both polygons). Actually I needed to use
spaceAround as well, to provide some separation between the two labels.

The problem is that in our application there client-side point feature
layers, with icons being rendered client-side (by Leaflet). When the map is
zoomed to one of the client-side point features, the icon obscures the
label underneath it.  And actually a bigger concern is that the map area
around the icon is obscured by the label behind it.

We might be able to remedy this by forcing the zoom function to move the
map so the feature location is above or below the centre of the map
extent.  But it seems cleaner and more versatile to force the underlying
labels away from the map centre.

Perhaps the general requirement here is to have more control over where
labels are placed in map image space, for the case of large "regional"
polygon features (which are often rendered at a scale where the map extent
is inside the polygon).  The SLD Displacement parameter is one way to
control this.  I could imagine a more sophisticated layout control allowing
labels to be anchored relative to the map extent box, as well.



On Tue, Dec 11, 2018 at 11:05 AM Andrea Aime 
wrote:

> On Tue, Dec 11, 2018 at 7:41 PM Martin Davis  wrote:
>
>> Thanks for the assistance.
>>
>> I will look into logging an issue for this.
>>
>> For the record, the use cases for this capability are:
>> - In the case where there are two polygonal coverage layers containing
>> large jurisdiction boundary polygons, when zoomed far in (so that the map
>> extent is fully inside the polygons), the polygon labels are both at the
>> centre of the map image and one is obscured.  By offsetting the labels up
>> and down the goal is to show both
>> - On a web map where the client displays point features with clients-side
>> icons, when the map is zoomed to a point feature, the icon is displayed in
>> the centre of the map extent, and obscures the jurisdiction polygon
>> label(s) underneath it.  Goal is to make the label visible by offsetting it.
>>
>
> Why use a static displacement, the maxDisplacement vendor option should
> let GeoServer apply a suitable offset for you
> in case the target location is already busy?
>
> 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.*
>
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Problem with SLD PointPlacement Displacement not working

[Martin Davis]

I realized that I can solve the issue of two centred labels obscuring each
other by using the VendorOptions maxDisplacement and spaceAround.  This may
also help with client-side icons being obscured.  Although I suspect that
one of the labels will still be centred.  However, the other label should
be visible, which should help.

On Tue, Dec 11, 2018 at 10:40 AM Martin Davis  wrote:

> Thanks for the assistance.
>
> I will look into logging an issue for this.
>
> For the record, the use cases for this capability are:
> - In the case where there are two polygonal coverage layers containing
> large jurisdiction boundary polygons, when zoomed far in (so that the map
> extent is fully inside the polygons), the polygon labels are both at the
> centre of the map image and one is obscured.  By offsetting the labels up
> and down the goal is to show both
> - On a web map where the client displays point features with clients-side
> icons, when the map is zoomed to a point feature, the icon is displayed in
> the centre of the map extent, and obscures the jurisdiction polygon
> label(s) underneath it.  Goal is to make the label visible by offsetting it.
>
> @Ian Turton   Not sure your idea will work because
> the label needs to be place dynamically anchored at the centre of the
> rendered image (not fixed at the polygon centroid)?
>
>
> On Tue, Dec 11, 2018 at 12:42 AM Ian Turton  wrote:
>
>> Could you work round it by adding a geom tag with a centroid function to
>> get a point?
>>
>> Ian
>>
>> On Tue, 11 Dec 2018 at 07:00, Andrea Aime 
>> wrote:
>>
>>> On Mon, Dec 10, 2018 at 9:37 PM Martin Davis  wrote:
>>>
>>>> Are there any known issues with this?  Or is there something wrong with
>>>> the style?
>>>>
>>>
>>> No "known issue", the functionality is simply missing.
>>> Polygon placement is "put the label something in there", personally
>>> never had the need to control
>>> displacement on it, can't see an existing feature request for it in the
>>> tracker either, but settings
>>> are there for polygons too, so they should be honored.
>>>
>>> Usual two steps:
>>>
>>>- Feel free to open a ticket for it
>>>- PR welcomed (in case you're interested, have a look at
>>>LabelCacheImpl in gt-render)
>>>
>>> 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.*
>>> ___
>>> Geoserver-users mailing list
>>>
>>> Please make sure you read the following two resources before posting to
>>> this list:
>>> - Earning your support instead of buying it, but Ian Turton:
>>> http://www.ianturton.com/talks/foss4g.html#/
>>> - The GeoServer user list posting guidelines:
>>> http://geoserver.org/comm/userlist-guidelines.html
>>>
>>> If you want to request a feature or an improvement, also see this:
>>> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>>>
>>>

Re: [Geoserver-users] Problem with SLD PointPlacement Displacement not working

[Martin Davis]

Thanks for the assistance.

I will look into logging an issue for this.

For the record, the use cases for this capability are:
- In the case where there are two polygonal coverage layers containing
large jurisdiction boundary polygons, when zoomed far in (so that the map
extent is fully inside the polygons), the polygon labels are both at the
centre of the map image and one is obscured.  By offsetting the labels up
and down the goal is to show both
- On a web map where the client displays point features with clients-side
icons, when the map is zoomed to a point feature, the icon is displayed in
the centre of the map extent, and obscures the jurisdiction polygon
label(s) underneath it.  Goal is to make the label visible by offsetting it.

@Ian Turton   Not sure your idea will work because the
label needs to be place dynamically anchored at the centre of the rendered
image (not fixed at the polygon centroid)?


On Tue, Dec 11, 2018 at 12:42 AM Ian Turton  wrote:

> Could you work round it by adding a geom tag with a centroid function to
> get a point?
>
> Ian
>
> On Tue, 11 Dec 2018 at 07:00, Andrea Aime 
> wrote:
>
>> On Mon, Dec 10, 2018 at 9:37 PM Martin Davis  wrote:
>>
>>> Are there any known issues with this?  Or is there something wrong with
>>> the style?
>>>
>>
>> No "known issue", the functionality is simply missing.
>> Polygon placement is "put the label something in there", personally never
>> had the need to control
>> displacement on it, can't see an existing feature request for it in the
>> tracker either, but settings
>> are there for polygons too, so they should be honored.
>>
>> Usual two steps:
>>
>>- Feel free to open a ticket for it
>>- PR welcomed (in case you're interested, have a look at
>>LabelCacheImpl in gt-render)
>>
>> 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.*
>> ___
>> Geoserver-users mailing list
>>
>> Please make sure you read the following two resources before posting to
>> this list:
>> - Earning your support instead of buying it, but Ian Turton:
>> http://www.ianturton.com/talks/foss4g.html#/
>> - The GeoServer user list posting guidelines:
>> http://geoserver.org/comm/userlist-guidelines.html
>>
>> If you want to request a feature or an improvement, also see this:
>> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>>
>>
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
>
> --
> Ian Turton
>
___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

[Geoserver-users] Problem with SLD PointPlacement Displacement not working

[Martin Davis]

We are styling an SDE layer of polygons.  We want to display the polygon
labels offset from the centre of the map image when zoomed into a single
polygon, so that the label is readable when zooming to a point (which is
using a client-side icon, so obscuring the label).

We are trying to set the SLD PointPlacement Displacement values to do this,
but this does not seem to change the location of the generated labels.  SLD
is below.

Are there any known issues with this?  Or is there something wrong with the
style?

Version is Geoserver 1.12.1.

-
http://www.opengis.net/sld; xmlns:sld="http://www.opengis.net/sld;
xmlns:gml="http://www.opengis.net/gml; xmlns:ogc="http://www.opengis.net/ogc;
version="1.0.0">
  
Default Styler

  Default Styler
  
name

  

  #FF
  4

  
  

  2.75

  


  

  FIRE_CENTRE


  Arial
  18
  normal
  normal


  

  0.5
  0.0


  0
  50

  


  3
  
#FF
  


  #00

100
  

  

  

___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Good news again...  Turns out I was testing against a 2.9 version.  Testing
against 2.12 with a custom Legend image specified seems to solve the
problem - the Legend graphic is returned correctly.

On Mon, Jun 25, 2018 at 10:05 AM, Martin Davis  wrote:

> Well, apparently setting a custom legend image is NOT a workaround.  Even
> when a legend image is specified, the error still occurs on the
> GetLegendGraphic request:
>
> java.lang.IllegalArgumentException: class [B is not supported by this
> method
>
> Other ideas welcome...
>
> On Mon, Jun 25, 2018 at 9:38 AM, Martin Davis  wrote:
>
>> Revisting this issue...
>>
>> One workaround for this would be to provide a custom legend image that
>> overrides the generated one.  Is this possible in Geoserver?  Is there
>> documentation on this?
>>
>> Martin
>>
>> On Thu, Apr 26, 2018 at 10:27 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Thu, Apr 26, 2018 at 7:25 PM, Martin Davis 
>>> wrote:
>>>
>>>> Yes, agreed, that looks like a byte array.  I don't know why it's
>>>> occurring at that point, however.  I'd probably have to trace into a debug
>>>> instance to find out.  I will try and do that.
>>>>
>>>> @Andrea: any idea why a byte array is showing up there?  Is this an
>>>> Oracle extension issue, caused by the type of SDO_GEOMETRY?
>>>>
>>>
>>> Sorry, nothing comes to mind.
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Andrea Aime
>>>
>>> ==
>>> 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
>>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>>> 55054  Massarosa
>>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>>> (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.
>>>
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Well, apparently setting a custom legend image is NOT a workaround.  Even
when a legend image is specified, the error still occurs on the
GetLegendGraphic request:

java.lang.IllegalArgumentException: class [B is not supported by this method

Other ideas welcome...

On Mon, Jun 25, 2018 at 9:38 AM, Martin Davis  wrote:

> Revisting this issue...
>
> One workaround for this would be to provide a custom legend image that
> overrides the generated one.  Is this possible in Geoserver?  Is there
> documentation on this?
>
> Martin
>
> On Thu, Apr 26, 2018 at 10:27 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> On Thu, Apr 26, 2018 at 7:25 PM, Martin Davis  wrote:
>>
>>> Yes, agreed, that looks like a byte array.  I don't know why it's
>>> occurring at that point, however.  I'd probably have to trace into a debug
>>> instance to find out.  I will try and do that.
>>>
>>> @Andrea: any idea why a byte array is showing up there?  Is this an
>>> Oracle extension issue, caused by the type of SDO_GEOMETRY?
>>>
>>
>> Sorry, nothing comes to mind.
>>
>> Cheers
>> Andrea
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
>>
>> ==
>> 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
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>> 55054  Massarosa
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>> (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.
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Next question: is it possible to configure this via the REST API?

On Mon, Jun 25, 2018 at 9:47 AM, Martin Davis  wrote:

> Ok, I see this now in the docs for Geoserver 2.12  [1].Custom legend
> images can be set on the Style Editor page under the Legend area.
>
>
> [1] http://docs.geoserver.org/maintain/en/user/styling/
> webadmin/index.html#style-editor-data-tab
>
> On Mon, Jun 25, 2018 at 9:38 AM, Martin Davis  wrote:
>
>> Revisting this issue...
>>
>> One workaround for this would be to provide a custom legend image that
>> overrides the generated one.  Is this possible in Geoserver?  Is there
>> documentation on this?
>>
>> Martin
>>
>> On Thu, Apr 26, 2018 at 10:27 AM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Thu, Apr 26, 2018 at 7:25 PM, Martin Davis 
>>> wrote:
>>>
>>>> Yes, agreed, that looks like a byte array.  I don't know why it's
>>>> occurring at that point, however.  I'd probably have to trace into a debug
>>>> instance to find out.  I will try and do that.
>>>>
>>>> @Andrea: any idea why a byte array is showing up there?  Is this an
>>>> Oracle extension issue, caused by the type of SDO_GEOMETRY?
>>>>
>>>
>>> Sorry, nothing comes to mind.
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Andrea Aime
>>>
>>> ==
>>> 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
>>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>>> 55054  Massarosa
>>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>>> (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.
>>>
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Ok, I see this now in the docs for Geoserver 2.12  [1].Custom legend
images can be set on the Style Editor page under the Legend area.


[1]
http://docs.geoserver.org/maintain/en/user/styling/webadmin/index.html#style-editor-data-tab

On Mon, Jun 25, 2018 at 9:38 AM, Martin Davis  wrote:

> Revisting this issue...
>
> One workaround for this would be to provide a custom legend image that
> overrides the generated one.  Is this possible in Geoserver?  Is there
> documentation on this?
>
> Martin
>
> On Thu, Apr 26, 2018 at 10:27 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> On Thu, Apr 26, 2018 at 7:25 PM, Martin Davis  wrote:
>>
>>> Yes, agreed, that looks like a byte array.  I don't know why it's
>>> occurring at that point, however.  I'd probably have to trace into a debug
>>> instance to find out.  I will try and do that.
>>>
>>> @Andrea: any idea why a byte array is showing up there?  Is this an
>>> Oracle extension issue, caused by the type of SDO_GEOMETRY?
>>>
>>
>> Sorry, nothing comes to mind.
>>
>> Cheers
>> Andrea
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
>>
>> ==
>> 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
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>> 55054  Massarosa
>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
>> (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.
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Revisting this issue...

One workaround for this would be to provide a custom legend image that
overrides the generated one.  Is this possible in Geoserver?  Is there
documentation on this?

Martin

On Thu, Apr 26, 2018 at 10:27 AM, Andrea Aime 
wrote:

> On Thu, Apr 26, 2018 at 7:25 PM, Martin Davis  wrote:
>
>> Yes, agreed, that looks like a byte array.  I don't know why it's
>> occurring at that point, however.  I'd probably have to trace into a debug
>> instance to find out.  I will try and do that.
>>
>> @Andrea: any idea why a byte array is showing up there?  Is this an
>> Oracle extension issue, caused by the type of SDO_GEOMETRY?
>>
>
> Sorry, nothing comes to mind.
>
> Cheers
> Andrea
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> 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
> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
> 55054  Massarosa
> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa=gmail=g>
> (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.
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Trouble with dynamically generated SLD

[Martin Davis]

You can also read the Geoserver SLD Reference docs, which describe the
element ordering specified by the standard (and might be a bit easier to
read).

On Mon, May 14, 2018 at 7:17 AM, Kris Johnson  wrote:

> Hi Ian,
>
> Thanks for the response.
> Your answer is what I was afraid of.
> It's a bit frustrating because I couldn't find any mention of this order
> enforcement for rules in the official OGC specification.
> But, more to the point, the python library I'm using (
> https://github.com/azavea/python-sld) doesn't seem capable of enforcing
> this.
>
> Do you have any suggestions for dynamically creating SLDs (for ingestion
> into Geoserver via REST calls) using python?
>
>
> On Fri, May 11, 2018 at 1:46 PM, Ian Turton  wrote:
>
>> As the error message suggests your filter is in the wrong place. It
>> should be at the top of the rule.
>>
>> Ian
>>
>> On Fri, 11 May 2018, 18:48 Kris Johnson,  wrote:
>>
>>> Hello,
>>>
>>> I'm attempting to generate an SLD file in python.
>>> And while the output appears valid to me when I load it in as a new
>>> style in Geoserver and click "Validate" I get an error:
>>>
 line 17: cvc-complex-type.2.4.a: Invalid content was found starting
 with element 'ogc:Filter'. One of 
 '{"http://www.opengis.net/sld":Symbolizer}'
 is expected.
>>>
>>>
>>> ​I'm assuming this occurs 18 times--once for each filter.
>>> The filter tag is correctly nested within the rule tag alongside a
>>> symbolizer, so I don't see what the issue is here.
>>> Here's the full SLD:
>>> ​
>>>
>>> http://www.opengis.net/ogc; 
>>> xmlns:sld="http://www.opengis.net/sld; 
>>> xmlns:xlink="http://www.w3.org/1999/xlink; 
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; version="1.0.0">
>>>   
>>> my style
>>> 
>>>   
>>> 
>>>   White Pine Rule
>>>   
>>> 
>>>   #f490bd
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   White Pine
>>> 
>>>   
>>> 
>>> 
>>>   Aspen-Oak Land Rule
>>>   
>>> 
>>>   #dfb1f9
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Aspen-Oak Land
>>> 
>>>   
>>> 
>>> 
>>>   Mixed White Pine and Red Pine Rule
>>>   
>>> 
>>>   #7a40bc
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Mixed White Pine and Red Pine
>>> 
>>>   
>>> 
>>> 
>>>   River Bottom Forest Rule
>>>   
>>> 
>>>   #6ef46e
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   River Bottom Forest
>>> 
>>>   
>>> 
>>> 
>>>   Lakes (open water) Rule
>>>   
>>> 
>>>   #65d14d
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Lakes (open water)
>>> 
>>>   
>>> 
>>> 
>>>   Big Woods - Hardwoods (oak, maple, basswood, hickory) 
>>> Rule
>>>   
>>> 
>>>   #5ff47f
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Big Woods - Hardwoods (oak, maple, basswood, 
>>> hickory)
>>> 
>>>   
>>> 
>>> 
>>>   Wet Prairie Rule
>>>   
>>> 
>>>   #c746f2
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Wet Prairie
>>> 
>>>   
>>> 
>>> 
>>>   Prairie Rule
>>>   
>>> 
>>>   #e552cd
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   xclass
>>>   Prairie
>>> 
>>>   
>>> 
>>> 
>>>   Undefined Rule
>>>   
>>> 
>>>   #c933f7
>>> 
>>> 
>>>   #000
>>>   1
>>> 
>>>   
>>>   
>>> 
>>>   

[Geoserver-users] How to fix Error: Tile Layers out of synch ?

[Martin Davis]

We get the following error message when invoking the Tile Caching / Tile
Layers panel in the web UI:

Caused by: java.lang.IllegalStateException: Could not locate a layer or
layer group with id LayerInfoImpl--2c3fc31e:159ff9b77e2:-7f6a within
GeoServer configuration, the GWC configuration seems to be out of synch

Is there any way to fix this?  Perhaps by deleting objects from the data
directory?  Even better would be a way to fix it from the Web UI itself,
since we don't have easy access to the server.

There are previous reports of the same issue [1][2].  Seems like a
candidate for some more gracefully failure handling..


[1] https://osgeo-org.atlassian.net/browse/GEOS-7202
[2] https://sourceforge.net/p/geoserver/mailman/message/34484893/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

Yes, agreed, that looks like a byte array.  I don't know why it's occurring
at that point, however.  I'd probably have to trace into a debug instance
to find out.  I will try and do that.

@Andrea: any idea why a byte array is showing up there?  Is this an Oracle
extension issue, caused by the type of SDO_GEOMETRY?

On Thu, Apr 26, 2018 at 12:34 AM, Ian Turton <ijtur...@gmail.com> wrote:

> I'm fairly sure that class [B is a byte array, can you add the featuretype
> info?
>
> Ian
>
> On 25 April 2018 at 19:16, Martin Davis <mtncl...@gmail.com> wrote:
>
>> We are seeing an error when issuing GetLegendGraphic against an Oracle
>> view containing POINT geometries.
>>
>> The error trace is below.
>>
>> The styling is straightforward - uses a PNG as the icon for the point.
>> The layer displays the point feature icons correctly - it's just the legend
>> that doesn't work.  SLD is attached.
>>
>> Is this a known issue with Oracle?  (Is this possibly an issue with
>> trying to synthesize a layer feature in order to render the legend graphic?)
>>
>> Any idea why or what "class [B" refers to?
>> Is there a workaround?
>>
>> GeoServer version 2.9.2 - yes I know this is old, but perhaps someone
>> knows if this is an issue that has been fixed in a newer release?
>>
>>
>> 2018-04-25 11:07:41,463 DEBUG 
>> [security.IncludeQueryStringAntPathRequestMatcher]
>> - Matched Path: /wms, QueryString: SERVICE=WMS=1.1.1
>> EST=getlegendgraphic=image/png=CAMP_COMPLEX_POINT_SVW with
>> /**
>> 2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler
>> mapping found for [/wms]
>> 2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler
>> mapping found for [/wms]
>> 2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler
>> mapping found for [/wms]
>> 2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler
>> mapping found for [/wms]
>> 2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler
>> mapping found for [/wms]
>> 2018-04-25 11:07:41,463 DEBUG [ows.OWSHandlerMapping] - Mapping [/wms] to
>> HandlerExecutionChain with handler [org.geoserver.ows.Dispatcher@6cb1726a]
>> and 1 interceptor
>> 2018-04-25 11:07:41,463 INFO [geoserver.wms] -
>> Request: getServiceInfo
>> 2018-04-25 11:07:41,463 TRACE [sqlserver.jtds] - No JTDS jar on classpath
>> 2018-04-25 11:07:41,463 DEBUG [geotools.util] - CRSConverterFactory can
>> be applied from Strings to CRS  only.
>> 2018-04-25 11:07:41,463 DEBUG [sqlserver.jtds] - Failed to find JTDS jar
>> 2018-04-25 11:07:41,463 DEBUG [geotools.util] -
>> InterpolationConverterFactory can be applied from Strings to Interpolation
>> only.
>> 2018-04-25 11:07:41,463 DEBUG [wms.legendgraphic] - looking for styles
>> 2018-04-25 11:07:41,463 ERROR [geoserver.ows] -
>> java.lang.IllegalArgumentException: class [B is not supported by this
>> method
>> at org.geotools.data.DataUtilities.defaultValue(DataUtilities.java:1016)
>> at org.geotools.feature.simple.SimpleFeatureBuilder.convert(Sim
>> pleFeatureBuilder.java:323)
>> at org.geotools.feature.simple.SimpleFeatureBuilder.set(SimpleF
>> eatureBuilder.java:310)
>> at org.geotools.feature.simple.SimpleFeatureBuilder.add(SimpleF
>> eatureBuilder.java:233)
>> at org.geotools.feature.simple.SimpleFeatureBuilder.template(Si
>> mpleFeatureBuilder.java:482)
>> at org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBu
>> ilder.createSampleFeature(BufferedImageLegendGraphicBuilder.java:1020)
>> at org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBu
>> ilder.createSampleFeature(BufferedImageLegendGraphicBuilder.java:942)
>> at org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBu
>> ilder.getSampleFeatureForRule(BufferedImageLegendGraphicBuilder.java:569)
>> at org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBu
>> ilder.calcSymbolScale(BufferedImageLegendGraphicBuilder.java:488)
>> at org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBu
>> ilder.buildLegendGraphic(BufferedImageLegendGraphicBuilder.java:356)
>> at org.geoserver.wms.legendgraphic.PNGLegendOutputFormat.produc
>> eLegendGraphic(PNGLegendOutputFormat.java:41)
>> at org.geoserver.wms.legendgraphic.PNGLegendOutputFormat.produc
>> eLegendGraphic(PNGLegendOutputFormat.java:22)
>> at org.geoserver.wms.GetLegendGraphic.run(GetLegendGraphic.java:49)
>> at org.geoserver.wms.DefaultWebMapService.getLegendGraphic(Defa
>> ultWebMapService.java:349)
>> at sun.reflect.Nativ

[Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)

[Martin Davis]

We are seeing an error when issuing GetLegendGraphic against an Oracle view
containing POINT geometries.

The error trace is below.

The styling is straightforward - uses a PNG as the icon for the point.  The
layer displays the point feature icons correctly - it's just the legend
that doesn't work.  SLD is attached.

Is this a known issue with Oracle?  (Is this possibly an issue with trying
to synthesize a layer feature in order to render the legend graphic?)

Any idea why or what "class [B" refers to?
Is there a workaround?

GeoServer version 2.9.2 - yes I know this is old, but perhaps someone knows
if this is an issue that has been fixed in a newer release?


2018-04-25 11:07:41,463 DEBUG
[security.IncludeQueryStringAntPathRequestMatcher] - Matched Path: /wms,
QueryString:
SERVICE=WMS=1.1.1=getlegendgraphic=image/png=CAMP_COMPLEX_POINT_SVW
with /**
2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler mapping
found for [/wms]
2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler mapping
found for [/wms]
2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler mapping
found for [/wms]
2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler mapping
found for [/wms]
2018-04-25 11:07:41,463 TRACE [ows.OWSHandlerMapping] - No handler mapping
found for [/wms]
2018-04-25 11:07:41,463 DEBUG [ows.OWSHandlerMapping] - Mapping [/wms] to
HandlerExecutionChain with handler [org.geoserver.ows.Dispatcher@6cb1726a]
and 1 interceptor
2018-04-25 11:07:41,463 INFO [geoserver.wms] -
Request: getServiceInfo
2018-04-25 11:07:41,463 TRACE [sqlserver.jtds] - No JTDS jar on classpath
2018-04-25 11:07:41,463 DEBUG [geotools.util] - CRSConverterFactory can be
applied from Strings to CRS  only.
2018-04-25 11:07:41,463 DEBUG [sqlserver.jtds] - Failed to find JTDS jar
2018-04-25 11:07:41,463 DEBUG [geotools.util] -
InterpolationConverterFactory can be applied from Strings to Interpolation
only.
2018-04-25 11:07:41,463 DEBUG [wms.legendgraphic] - looking for styles
2018-04-25 11:07:41,463 ERROR [geoserver.ows] -
java.lang.IllegalArgumentException: class [B is not supported by this method
at org.geotools.data.DataUtilities.defaultValue(DataUtilities.java:1016)
at
org.geotools.feature.simple.SimpleFeatureBuilder.convert(SimpleFeatureBuilder.java:323)
at
org.geotools.feature.simple.SimpleFeatureBuilder.set(SimpleFeatureBuilder.java:310)
at
org.geotools.feature.simple.SimpleFeatureBuilder.add(SimpleFeatureBuilder.java:233)
at
org.geotools.feature.simple.SimpleFeatureBuilder.template(SimpleFeatureBuilder.java:482)
at
org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBuilder.createSampleFeature(BufferedImageLegendGraphicBuilder.java:1020)
at
org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBuilder.createSampleFeature(BufferedImageLegendGraphicBuilder.java:942)
at
org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBuilder.getSampleFeatureForRule(BufferedImageLegendGraphicBuilder.java:569)
at
org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBuilder.calcSymbolScale(BufferedImageLegendGraphicBuilder.java:488)
at
org.geoserver.wms.legendgraphic.BufferedImageLegendGraphicBuilder.buildLegendGraphic(BufferedImageLegendGraphicBuilder.java:356)
at
org.geoserver.wms.legendgraphic.PNGLegendOutputFormat.produceLegendGraphic(PNGLegendOutputFormat.java:41)
at
org.geoserver.wms.legendgraphic.PNGLegendOutputFormat.produceLegendGraphic(PNGLegendOutputFormat.java:22)
at org.geoserver.wms.GetLegendGraphic.run(GetLegendGraphic.java:49)
at
org.geoserver.wms.DefaultWebMapService.getLegendGraphic(DefaultWebMapService.java:349)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.geoserver.kml.WebMapServiceKmlInterceptor.invoke(WebMapServiceKmlInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.geoserver.ows.util.RequestObjectLogger.invoke(RequestObjectLogger.java:55)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy63.getLegendGraphic(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 

[Geoserver-users] Geoserver as a raster overlay engine?

[Martin Davis]

Has anyone experimented with using Geoserver as a raster overlay engine?

I can think of two ways this might work:

1. Use the SLD compositing capabiity
2. Render layers as two or multi-valued images, and then use client-side
image processing code to combine the rasters

An ability to support even the most basic binary-valued raster overlay
could be useful for simple overlay queries.  Adding in tile
pyramiding/caching might allow supporting very large raster overlays.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

Good point.  Reduced precision should only be used for data which is being
used in a read-only way.  I guess Geoserver could try to enforce this, or
else leave it up to the caller to make sure they are doing the right thing.

On Wed, Oct 18, 2017 at 10:13 AM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
> Reducing precision could lead to corrupted data with WFS-T. Perhaps server
> should accept the parameter, if it comes true, only when it is
> not configured to support transactions.
>
>
> -Jukka Rahkonen-
> ------
> *Lähettäjä:* Martin Davis <mtncl...@gmail.com>
> *Lähetetty:* 18. lokakuuta 2017 19:53
> *Vastaanottaja:* Andrea Aime
> *Kopio:* geoserver-users@lists.sourceforge.net
> *Aihe:* Re: [Geoserver-users] Reduce precision of WFS output to decrease
> response size?
>
> Well, isn't this the Discussion phase of the feature request?
>
> And as I mentioned, although it would be great to see this done,
> unfortunately we may not be able to make a good case to fund it.
>
> On Wed, Oct 18, 2017 at 9:43 AM, Andrea Aime <andrea.a...@geo-solutions.it
> > wrote:
>
>> On Wed, Oct 18, 2017 at 6:09 PM, Martin Davis <mtncl...@gmail.com> wrote:
>>
>>> Here's another reason why reducing precision of responses on-the-fly
>>> would be useful.  It turn out the data as stored in EPGS:3005 essentially
>>> has 1 m precision.  However, we are requesting it reprojected to
>>> EPSG:3857.  The reprojection creates values using full double precision,
>>> which is output by GeoServer.  So in this case it is perfectly safe to
>>> round back to 1 m precision.
>>>
>>> We will explore requesting the data in the native CRS, since we can
>>> project on the client-side.  But it would be nice to be able to do this
>>> fully in GeoServer.
>>>
>>
>> By now you should know that just being right about the usefulness of a
>> feature request achieves exactly nothing ;-)
>> See: https://github.com/geoserver/geoserver/wiki/Successfull
>> y-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>>
>>
>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

Well, isn't this the Discussion phase of the feature request?

And as I mentioned, although it would be great to see this done,
unfortunately we may not be able to make a good case to fund it.

On Wed, Oct 18, 2017 at 9:43 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Wed, Oct 18, 2017 at 6:09 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Here's another reason why reducing precision of responses on-the-fly
>> would be useful.  It turn out the data as stored in EPGS:3005 essentially
>> has 1 m precision.  However, we are requesting it reprojected to
>> EPSG:3857.  The reprojection creates values using full double precision,
>> which is output by GeoServer.  So in this case it is perfectly safe to
>> round back to 1 m precision.
>>
>> We will explore requesting the data in the native CRS, since we can
>> project on the client-side.  But it would be nice to be able to do this
>> fully in GeoServer.
>>
>
> By now you should know that just being right about the usefulness of a
> feature request achieves exactly nothing ;-)
> See: https://github.com/geoserver/geoserver/wiki/
> Successfully-requesting-and-integrating-new-features-and-
> improvements-in-GeoServer
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

Here's another reason why reducing precision of responses on-the-fly would
be useful.  It turn out the data as stored in EPGS:3005 essentially has 1 m
precision.  However, we are requesting it reprojected to EPSG:3857.  The
reprojection creates values using full double precision, which is output by
GeoServer.  So in this case it is perfectly safe to round back to 1 m
precision.

We will explore requesting the data in the native CRS, since we can project
on the client-side.  But it would be nice to be able to do this fully in
GeoServer.

On Tue, Oct 17, 2017 at 3:55 PM, Martin Davis <mtncl...@gmail.com> wrote:

> Is there any way in GeoServer to request that the precision of WFS output
> be reduced?  (I.e. remove decimal places from the ordinates?).
>
> We have a large dataset which has far too much precision on the data.
> Removing unecessary decimal digits seems like it could significantly reduce
> WFS response size.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

I was thinking that the paging would be exposed to the user - but of course
as you point out it could just be used internally to lower the per-request
response size.  I'm not sure we'd want to flood the server that heavily,
but improving performance via concurrent queries is an interesting option,
for sure.  We'll give this some thought.  We're also exploring reducing the
precision of the data itself, which is the ultimate best solution.

Agreed that using WMS to visualize the data might be better, atlhough the
query filter is fairly large (essentially a giant IN expression), so I
wonder how that would perform in practice.  The real impediment is that the
mapping framework we are using doesn't support this explicitly (it uses
OpenLayers at its core, but heavily encapsulated for purposes of client
code longevity).  But we might explore this approach if we have to.

Thanks for all your helpful suggestions.

Martin

On Tue, Oct 17, 2017 at 5:29 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:

> Why an awkward user experience? Can you not assemble the features on the
> client side? You could even make the requests in parallel if you do not
> mind the risk of saturating the server.
>
> If you are visualising all the features on a map, WMS might be a better
> solution. Why do you need the geometries? Interaction? Could this be
> implemented with a WMS GetFeatureInfo and then a WFS GetFeature to get only
> the geometries you need?
>
> Kind regards,
> Ben.
>
>
> On 18/10/17 13:20, Martin Davis wrote:
>
>> There are many geometries in a reponse (for example, one response has 2240
>> geometries, and has an uncompressed size of 123 MB!).
>>
>> We're aware of WFS paging, but in this particular use case it would result
>> an awkward user experience.   The use case is that they want to visualize
>> *all* the features on a map, to help decide where to locate a particular
>> biological sampling station. (The query features are biogeoclimatic zones
>> in BC, which is why they are so huuuge).
>>
>> Yes, GZIP is happening on the wire, but we could still realize a 50%
>> savings if the decimals were dropped.
>>
>> On Tue, Oct 17, 2017 at 5:08 PM, Ben Caradoc-Davies <b...@transient.nz>
>> wrote:
>>
>> Martin,
>>>
>>> do you have one giant geometry or many features? If you have multiple
>>> features, you can use WFS 2.0.0 paging to select a subset so that
>>> individual requests do not time out. This example requests one at a time
>>> but you can try larger increments:
>>> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
>>> 0=GetFeature=topp:states=json=1&
>>> startindex=0
>>> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
>>> 0=GetFeature=topp:states=json=1&
>>> startindex=1
>>> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
>>> 0=GetFeature=topp:states=json=1&
>>> startindex=2
>>> [...]
>>>
>>> Note that paging enables sorting to make requests stable; this imposes a
>>> small server overhead.
>>>
>>> GeoServer also supports paging for WFS 1.1.0 if you need it (extension,
>>> not part of the spec); just use maxfeatures instead of count and you
>>> should
>>> be good to go.
>>>
>>> GZIP compression should already be used on the wire.
>>>
>>> Kind regards,
>>> Ben.
>>>
>>>
>>> On 18/10/17 12:41, Martin Davis wrote:
>>>
>>> Thanks, Ben.  Unfortunately that setting won't work for us, because (a)
>>>> we
>>>> don't have access to the server to set it, (b) we want to use GeoJSON,
>>>> and
>>>> (c) we wouldn't want this setting to impact other layers (and in fact we
>>>> would like it to apply only to specific requests).
>>>>
>>>> And yes, am aware we can request responses with no geometry, but in this
>>>> case we need to display the geometry.  That's actually the key problem -
>>>> we
>>>> are requesting a large amount of geometry for display, and the requests
>>>> are
>>>> very slow or failing completely because the response size is so large.
>>>>
>>>> On Tue, Oct 17, 2017 at 4:29 PM, Ben Caradoc-Davies <b...@transient.nz>
>>>> wrote:
>>>>
>>>> Martin,
>>>>
>>>>>
>>>>> try Settings / Global / Number of decimals. This works for GML 2 and
>>>>> GML
>>>>> 3.1 but does not seem to work for GML 3.2 output.
>&g

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

There are many geometries in a reponse (for example, one response has 2240
geometries, and has an uncompressed size of 123 MB!).

We're aware of WFS paging, but in this particular use case it would result
an awkward user experience.   The use case is that they want to visualize
*all* the features on a map, to help decide where to locate a particular
biological sampling station. (The query features are biogeoclimatic zones
in BC, which is why they are so huuuge).

Yes, GZIP is happening on the wire, but we could still realize a 50%
savings if the decimals were dropped.

On Tue, Oct 17, 2017 at 5:08 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:

> Martin,
>
> do you have one giant geometry or many features? If you have multiple
> features, you can use WFS 2.0.0 paging to select a subset so that
> individual requests do not time out. This example requests one at a time
> but you can try larger increments:
> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
> 0=GetFeature=topp:states=json=1&
> startindex=0
> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
> 0=GetFeature=topp:states=json=1&
> startindex=1
> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
> 0=GetFeature=topp:states=json=1&
> startindex=2
> [...]
>
> Note that paging enables sorting to make requests stable; this imposes a
> small server overhead.
>
> GeoServer also supports paging for WFS 1.1.0 if you need it (extension,
> not part of the spec); just use maxfeatures instead of count and you should
> be good to go.
>
> GZIP compression should already be used on the wire.
>
> Kind regards,
> Ben.
>
>
> On 18/10/17 12:41, Martin Davis wrote:
>
>> Thanks, Ben.  Unfortunately that setting won't work for us, because (a) we
>> don't have access to the server to set it, (b) we want to use GeoJSON, and
>> (c) we wouldn't want this setting to impact other layers (and in fact we
>> would like it to apply only to specific requests).
>>
>> And yes, am aware we can request responses with no geometry, but in this
>> case we need to display the geometry.  That's actually the key problem -
>> we
>> are requesting a large amount of geometry for display, and the requests
>> are
>> very slow or failing completely because the response size is so large.
>>
>> On Tue, Oct 17, 2017 at 4:29 PM, Ben Caradoc-Davies <b...@transient.nz>
>> wrote:
>>
>> Martin,
>>>
>>> try Settings / Global / Number of decimals. This works for GML 2 and GML
>>> 3.1 but does not seem to work for GML 3.2 output.
>>>
>>> Do you need the geometries? If not, you can use the propertyname
>>> parameter
>>> to request only the properties you need for even smaller responses:
>>> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
>>> 0=GetFeature=topp:states=topp:PERSONS,
>>> topp:WORKERS
>>>
>>> Kind regards,
>>> Ben.
>>>
>>>
>>> On 18/10/17 11:55, Martin Davis wrote:
>>>
>>> Is there any way in GeoServer to request that the precision of WFS output
>>>> be reduced?  (I.e. remove decimal places from the ordinates?).
>>>>
>>>> We have a large dataset which has far too much precision on the data.
>>>> Removing unecessary decimal digits seems like it could significantly
>>>> reduce
>>>> WFS response size.
>>>>
>>>>
>>>>
>>>> 
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>>
>>>> ___
>>>> Geoserver-users mailing list
>>>>
>>>> Please make sure you read the following two resources before posting to
>>>> this list:
>>>> - Earning your support instead of buying it, but Ian Turton:
>>>> http://www.ianturton.com/talks/foss4g.html#/
>>>> - The GeoServer user list posting guidelines:
>>>> http://geoserver.org/comm/userlist-guidelines.html
>>>>
>>>> Geoserver-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>>
>>>> --
>>> Ben Caradoc-Davies <b...@transient.nz>
>>> Director
>>> Transient Software Limited <http://transient.nz/>
>>> New Zealand
>>>
>>>
>>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

Thanks, Ben.  Unfortunately that setting won't work for us, because (a) we
don't have access to the server to set it, (b) we want to use GeoJSON, and
(c) we wouldn't want this setting to impact other layers (and in fact we
would like it to apply only to specific requests).

And yes, am aware we can request responses with no geometry, but in this
case we need to display the geometry.  That's actually the key problem - we
are requesting a large amount of geometry for display, and the requests are
very slow or failing completely because the response size is so large.

On Tue, Oct 17, 2017 at 4:29 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:

> Martin,
>
> try Settings / Global / Number of decimals. This works for GML 2 and GML
> 3.1 but does not seem to work for GML 3.2 output.
>
> Do you need the geometries? If not, you can use the propertyname parameter
> to request only the properties you need for even smaller responses:
> http://localhost:8080/geoserver/wfs?service=WFS=2.0.
> 0=GetFeature=topp:states=topp:PERSONS,
> topp:WORKERS
>
> Kind regards,
> Ben.
>
>
> On 18/10/17 11:55, Martin Davis wrote:
>
>> Is there any way in GeoServer to request that the precision of WFS output
>> be reduced?  (I.e. remove decimal places from the ordinates?).
>>
>> We have a large dataset which has far too much precision on the data.
>> Removing unecessary decimal digits seems like it could significantly
>> reduce
>> WFS response size.
>>
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> ___
>> Geoserver-users mailing list
>>
>> Please make sure you read the following two resources before posting to
>> this list:
>> - Earning your support instead of buying it, but Ian Turton:
>> http://www.ianturton.com/talks/foss4g.html#/
>> - The GeoServer user list posting guidelines:
>> http://geoserver.org/comm/userlist-guidelines.html
>>
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

I guess this is my answer:

https://gis.stackexchange.com/questions/228454/reduce-wfs-response-size-by-reducing-feature-detail

Too bad.  WPS is so much harder to use than WFS (at least my impression -
happy to shown otherwise).  The WFS Global setting is too broad to use in
this case.  The per-layer one would be fine, but apparently does not work
for GeoJSON (which kind of defeats the purpose, since GML is much fluffier
to begin with).  And in this case we don't have access to the server.

So it would be nice to see this added as a WFS vendor parameter
"maxDecimals" [1]

[1] http://docs.geoserver.org/stable/en/user/services/wfs/vendor.html

On Tue, Oct 17, 2017 at 3:55 PM, Martin Davis <mtncl...@gmail.com> wrote:

> Is there any way in GeoServer to request that the precision of WFS output
> be reduced?  (I.e. remove decimal places from the ordinates?).
>
> We have a large dataset which has far too much precision on the data.
> Removing unecessary decimal digits seems like it could significantly reduce
> WFS response size.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

[Geoserver-users] Reduce precision of WFS output to decrease response size?

[Martin Davis]

Is there any way in GeoServer to request that the precision of WFS output
be reduced?  (I.e. remove decimal places from the ordinates?).

We have a large dataset which has far too much precision on the data.
Removing unecessary decimal digits seems like it could significantly reduce
WFS response size.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] feature frenzy - any requests?

[Martin Davis]

Provide a Layer Preview utility that allows displaying multiple layers, and
using a user-defined base map.

On Sun, Aug 6, 2017 at 5:07 PM, Jody Garnett  wrote:

> For me I got a see first hand out some nifty features that I had only ever
> read about before:
>
> 1) Starting from an empty directory
>
> 2) Sending a get map request with no layers - only an SLD file
>
>
>
>
> --
> Jody Garnett
>
> On 6 August 2017 at 17:03, Jody Garnett  wrote:
>
>> We have a "geoserver feature frenzy" presentation coming up at foss4g.
>> Last time we asked the user list what features they found the most valuable
>> (and had some surprises like the number of people who found the oracle
>> database support vital).
>>
>> This year I would like to cast a wider net - please help out by sharing
>> any "wow I did not know geoserver could do that" experiences!
>> --
>> Jody Garnett
>>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines: http://geoserver.org/comm/
> userlist-guidelines.html
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] feature frenzy - any requests?

[Martin Davis]

Here's one: Add links to REST resources on GUI pages (such as Edit Layer,
Edit Datastore, etc).

On Sun, Aug 6, 2017 at 5:07 PM, Jody Garnett  wrote:

> For me I got a see first hand out some nifty features that I had only ever
> read about before:
>
> 1) Starting from an empty directory
>
> 2) Sending a get map request with no layers - only an SLD file
>
>
>
>
> --
> Jody Garnett
>
> On 6 August 2017 at 17:03, Jody Garnett  wrote:
>
>> We have a "geoserver feature frenzy" presentation coming up at foss4g.
>> Last time we asked the user list what features they found the most valuable
>> (and had some surprises like the number of people who found the oracle
>> database support vital).
>>
>> This year I would like to cast a wider net - please help out by sharing
>> any "wow I did not know geoserver could do that" experiences!
>> --
>> Jody Garnett
>>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Geoserver-users mailing list
>
> Please make sure you read the following two resources before posting to
> this list:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines: http://geoserver.org/comm/
> userlist-guidelines.html
>
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] How to use REST to create a coverage from a TIF file with no explicit SRS ?

[Martin Davis]

Figured this out...  by some tweaks to the REST magic words needed.

In case it helps someone else, here's how it finally worked:

1.  Delete the existing coverage (if any)

curl -s -o /dev/null -k -u %CRED% -XDELETE
%HOST%/rest/workspaces/%WS%/coveragestores/%COV%?recurse=true

2. Create the coverage store from the server-resident file (which
automatically creates a coverage as well)

curl -f -k -u %CRED% -XPUT -H "Content-type: text/plain" -d "file://%FILE%"
%HOST%/rest/workspaces/%WS%/coveragestores/%COV%/external.geotiff

3. Set the SRS and enable the coverage:

curl -s -k -u %CRED% -XPUT -H "Content-type: text/xml" -d
"EPSG:3005true"
%HOST%/rest/workspaces/%WS%/coveragestores/%COV%/coverages/%COV%

(Of course this was done in a cmd script with oodles of baroque error
checking - exercise left for the student)

On a side note, once again I needed to puzzle out the differences between
the GeoServer internal information model (as revealed by the REST API) and
the GUI terminology (which hides some of the internal concepts such as
FeatureTypes and Coverages).  I always feel that a Logical Domain Model
diagram would help with understanding this, and perhaps also some mention
in the UI docs about what is going on under the hood.


On Tue, Aug 1, 2017 at 2:43 PM, Martin Davis <mtncl...@gmail.com> wrote:

> I am trying to create a CoverageStore and Coverage layer from a TIF file
> staged on the Geoserver server, using the REST API.  As per this suggestion
> [1] I'm using an adaption of the technique in:
>
> http://docs.geoserver.org/latest/en/user/rest/workspaces.html#adding-an-
> existing-shapefile
>
> This works - almost.  The resulting coverage is created, but it has no
> Declared SRS, probably because the backing raster file does not have SRS
> information stored in it (i.e. it's a TIF, not a GeoTIFF).
>
> Is there a way I can set the Declared SRS via the REST API?
>
> I've tried the obvious route of POSTing the following partial resource:
>
> %COV%EPSG:3005
>
> to
>
> %HOST%/rest/workspaces/%WS%/coveragestores/%COV%/coverages
>
> but this had no effect.
>
> [1] https://gis.stackexchange.com/questions/37779/adding-a-
> new-coveragestore-in-a-certain-workspace-by-rest
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

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

Re: [Geoserver-users] MIssing REST datastores Swagger doc?

[Martin Davis]

Good to know that works.

The doc is still a bit unhelpful, due to the wide variability in datastore
parameters.  In an ideal world there would be doc available for each kind
of datastore... but absent that, the easiest thing to do is to GET the
definition for an existing datastore of the desired type.

On Wed, May 24, 2017 at 1:50 PM, Jim Hughes <jn...@ccri.com> wrote:

> Hi Martin,
>
> Looks like there is link missing for this yaml:
> http://docs.geoserver.org/api/#/1.0.0/datastores.yaml.
>
> Cheers,
>
> Jim
>
>
> On 05/24/2017 04:22 PM, Martin Davis wrote:
>
> Is the documentation for the REST datastores resource missing in the new
> REST API Swagger doc?
>
> It's not listed here:  http://docs.geoserver.org/
> latest/en/user/rest/index.html#rest
>
> But is here:  http://docs.geoserver.org/latest/en/user/rest/api/
> datastores.html
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] MIssing REST datastores Swagger doc?

[Martin Davis]

Is the documentation for the REST datastores resource missing in the new
REST API Swagger doc?

It's not listed here:
http://docs.geoserver.org/latest/en/user/rest/index.html#rest

But is here:
http://docs.geoserver.org/latest/en/user/rest/api/datastores.html
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Default Style via REST

[Martin Davis]

We use the request below, and it works for us.

URL:  %HOST%/rest/layers/%LYR%

Body:  %STYLE%

On Mon, Feb 27, 2017 at 1:24 AM, David Alda Fernandez de Lezea <
da...@hazi.eus> wrote:

> Hi,
>
> I'm developing a small program to automatically populate some satellite
> images via REST. I successfully populate them , but now I'm trying to set a
> specific style for one type of layer I'm populating but I'm getting some
> errors 405 and nothing else. I want that style to be the default style.
> Here is my code:
>
> WebRequest newrequest = WebRequest.Create("http://
> mydomain.com/rest/layers/TELEDETEKZIOA:" + imagen.layerName);
> newrequest.ContentType = "text/xml";
> newrequest.Method = "POST";
> newrequest.Credentials = new NetworkCredential(userName,
> password);
> xml = "
> ImagenesSateliteNDVItrue enabled>";
>
> buffer = Encoding.GetEncoding("UTF-8").GetBytes(xml);
> Stream newrequestStream = newrequest.GetRequestStream();
> newrequestStream.Write(buffer, 0, buffer.Length);
> newrequestStream.Close();
>
> response = newrequest.GetResponse();
> Console.Write("Response from GeoServer: " + response);
>
> Any Ideas??
>
> Thanks in advance.
>
> Regards,
>
> Agur bero bat,
>
>
> David Alda Fernández de Lezea
> Área de Sistemas de Información Geográfica, Planificación Territorial y
> Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren
> Arloa.
> da...@hazi.eus | www.hazi.eus
> T 945 003 240 - M 627 923 170 - F 945 003 290
> Hazi | Granja Modelo de Arkaute s/n | 01192 Arkaute - Araba
>
> *  LEGE OHARRA   ***   AVISOLEGAL
> ***   DISCLAIMER   *
> Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera
> debekatua dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta
> kontserbatu gabe.
> Este mensaje es personal y confidencial y su uso no autorizado está
> prohibido legalmente. Si usted no es el destinatario, proceda a borrarlo,
> sin reenviarlo ni conservarlo.
> This message is personal and confidential, unauthorised use is legally
> prohibited. If you are not the intended recipient, delete it without
> resending or backing it.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Legend issue - multiple symbols for cased lines

[Martin Davis]

Actually it turns out that for our particular case (cased polygon outlines)
the visual quality of simply having two LIneSymbolizers in the same rule is
acceptable (although obviously not ideal where polygons meet).  And this of
course produces a correct Legend. So we'll go with this for now.

On Thu, Feb 23, 2017 at 10:59 AM, Martin Davis <mtncl...@gmail.com> wrote:

> Makes sense, Andrea.
>
> In this particular case the rules are as simple as can be - no filters or
> scale dependency.  So that should be the easiest case to handle.
>
> I can see how this could be hard to do for complex rules.  But then again,
> if the rules are different, the Legend should probably show separate
> entries for them.
>
> Not sure I'll be able to rustle up funding to work on this, but I'll give
> it a try.
>
> On Thu, Feb 23, 2017 at 10:36 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis <mtncl...@gmail.com> wrote:
>>
>>> As I understand it, the recommended approach for producing "cased" lines
>>> (e.g. for roads or polygon outlines) is to specify each different line
>>> style in a separate FeatureTypeStyle.
>>>
>>> However, this seems to produce Legend graphics with the different line
>>> styles on separate lines.  (See attached map tile and legend).
>>>
>>> Is this a known issue?  Any workaround or fix?
>>>
>>
>> Well know issue. Fix is not trivial (not at all), but I have something in
>> mind.
>>
>> So, the two feature type styles are painted separately, and might be
>> completely unrelated... like, for example, two feature type styles
>> could be used to z order features that should appear in the back and in
>> the front.
>>
>> So one would have to compare rules in higher FTS with the lower ones, and
>> if they are a match, merge the
>> symbolizer from the higher FTS with the lower rules, making the higher
>> fts rule disappear.
>> Basically, restructure the SLD so that you end up with a single FTS.
>>
>> The tricky part is defining what a "match" is. In general, it's taking
>> the filters of the two rules, combining them,
>> and determining that they are not "logically empty". The
>> SimplifyingFilterVisitor has some symbolic evaluation
>> capabilities, but they are limited and sometimes expensive.
>>
>> I think you can imagine how this can easily spiral out of control with
>> very complex styles (having many FTS layers).
>> Still, I'd give it a try, maybe trying to constrain the application of
>> this logic to some "sane-ish" simpler case.
>>
>> 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 <+39%200584%20962313>
>> fax: +39 0584 1660272 <+39%200584%20166%200272>
>> mob: +39  339 8844549 <+39%20339%20884%204549>
>>
>> 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
>> a

Re: [Geoserver-users] Legend issue - multiple symbols for cased lines

[Martin Davis]

Makes sense, Andrea.

In this particular case the rules are as simple as can be - no filters or
scale dependency.  So that should be the easiest case to handle.

I can see how this could be hard to do for complex rules.  But then again,
if the rules are different, the Legend should probably show separate
entries for them.

Not sure I'll be able to rustle up funding to work on this, but I'll give
it a try.

On Thu, Feb 23, 2017 at 10:36 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> As I understand it, the recommended approach for producing "cased" lines
>> (e.g. for roads or polygon outlines) is to specify each different line
>> style in a separate FeatureTypeStyle.
>>
>> However, this seems to produce Legend graphics with the different line
>> styles on separate lines.  (See attached map tile and legend).
>>
>> Is this a known issue?  Any workaround or fix?
>>
>
> Well know issue. Fix is not trivial (not at all), but I have something in
> mind.
>
> So, the two feature type styles are painted separately, and might be
> completely unrelated... like, for example, two feature type styles
> could be used to z order features that should appear in the back and in
> the front.
>
> So one would have to compare rules in higher FTS with the lower ones, and
> if they are a match, merge the
> symbolizer from the higher FTS with the lower rules, making the higher fts
> rule disappear.
> Basically, restructure the SLD so that you end up with a single FTS.
>
> The tricky part is defining what a "match" is. In general, it's taking the
> filters of the two rules, combining them,
> and determining that they are not "logically empty". The
> SimplifyingFilterVisitor has some symbolic evaluation
> capabilities, but they are limited and sometimes expensive.
>
> I think you can imagine how this can easily spiral out of control with
> very complex styles (having many FTS layers).
> Still, I'd give it a try, maybe trying to constrain the application of
> this logic to some "sane-ish" simpler case.
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Legend issue - multiple symbols for cased lines

[Martin Davis]

As I understand it, the recommended approach for producing "cased" lines
(e.g. for roads or polygon outlines) is to specify each different line
style in a separate FeatureTypeStyle.

However, this seems to produce Legend graphics with the different line
styles on separate lines.  (See attached map tile and legend).

Is this a known issue?  Any workaround or fix?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Legend issue - blank entries for label rules

[Martin Davis]

It looks like GeoServer produces a "blank line" in Legends if a
TextSymbolizer is specified in a separate rule (as is often done for
scale-dependent labelling).  Is there any way to turn this off?

This behaviour actuall seems a bit useless, so perhaps it could be
prevented in the code?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Bug in SLD WKT Graphic Mark Legend generation?

[Martin Davis]

We have defined a style using a Graphic Mark defined using a WKT symbol.
The symbol looks fine on the map, but in the Legend graphic it appears to
be displaced to the upper right, resulting in a useless display.

Is there a bug in the Legend code for this? Or should the WKT extent be
different (perhaps in [0,1] ?

See attached images of map display and Legend graphic. SLD is:


http://www.opengis.net/sld;
xmlns:ogc="http://www.opengis.net/ogc; xmlns:xlink="
http://www.w3.org/1999/xlink; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://www.opengis.net/sld StyledLayerDescriptor.xsd">

XXX

  


  

  wkt://POLYGON((15 25, 25 15, 50 40, 75 15, 85 25, 60 50,
75 65, 79 52, 94 66, 82 74, 84 76, 75 85, 71 83, 65 89, 52 90, 44 88, 57
83, 65 75, 50 60, 40 70, 40 75, 36 85, 30 90, 20 90, 30 80, 20 70, 10 79,
10 70, 15 64, 24 60, 30 60, 40 50, 15 25))
  
#00
  

#88


16
  



  



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Creating a spatial view from an XY table in MS SQL Server?

[Martin Davis]

Ok, figured it out.  The view as orginally defined used
"geography::STGeomFromText".  GeoServer only recognizes the "geometry"
MS-SQL datatype (which is reasonable).  Changing the view to use
"geometry::STGeomFromText" fixed the problem. GeoServer recognizes the
geometry column and renders it.

Furthermore, the GEOMETRY_COLUMNS metatable is not required, which is a
nice simplification.

Probably we should define a spatial functional index as well, but since
this is a Point layer with only a 100 or so records, performance is fine
even without it.

Another user reported that this even works with defining the view as a
GeoServer SQL View, which is a very handy capability.  It would be nice if
this worked for Oracle as well!

On Mon, Feb 6, 2017 at 10:01 AM, Martin Davis <mtncl...@gmail.com> wrote:

> Has anyone tried creating a spatial view on an XY table in MS SQL Server,
> so it can be exposed via GeoServer?
>
> We are not having any luck with this.  What we have done is:
>
> 1) Define a spatial view:
>
> CREATE VIEW UDO_Fuel_Cache_SVW AS
>
> SELECT
>
> ID,
>
>Latitude,
>
>Longitude,
>
>Geographic,
>
>Fuel_Type,
>
>Updated,
>
>Full_Barrels,
>
>Partial_Barrels,
>
>Empty_Barrels,
>
>Owner,
>
>ContactPhone,
>
>Comments,
>
>FireCentre,
>
>FireZone,
>
>geography::STGeomFromText('POINT('+convert(varchar(20),Longitude)+' '+
> convert(varchar(20),Latitude)+')',4326) AS Geom
>
> FROM Incident.dbo.UDO_Fuel_Cache
>
>
> 2) Define a geometry metadata table:
>
> CREATE TABLE GEOMETRY_COLUMNS(
>
>F_TABLE_SCHEMA VARCHAR(30) NOT NULL,
>
>F_TABLE_NAME VARCHAR(30) NOT NULL,
>
>F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL,
>
>COORD_DIMENSION INTEGER,
>
>SRID INTEGER NOT NULL,
>
>TYPE VARCHAR(30) NOT NULL,
>
>UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),
>
>CHECK(TYPE IN ('POINT','LINE', 'POLYGON', 'COLLECTION', 'MULTIPOINT',
> 'MULTILINE', 'MULTIPOLYGON', 'GEOMETRY') ));
>
> go
>
> INSERT INTO GEOMETRY_COLUMNS
>
> ( F_TABLE_SCHEMA, F_TABLE_NAME,   F_GEOMETRY_COLUMN, COORD_DIMENSION, SRID
> ,   TYPE )
>
> VALUES ('', 'UDO_Fuel_Cache_SVW', 'Geom', 2, 4326, 'POINT');
>
>
> 3) Configure the SQL Server Store to refer to GEOMETRY_COLUMNS
> 4) Configure the layer (I hope correctly).  The layer featuretype listing
> shows a column  Geom of type byte[] - which doesn't seem promising.
>
> When trying to view the layer, we get the error:
>
> 2017-02-06 09:44:47,833 ERROR [org.geotools.jdbc] - Failed to execute
> statement SELECT FROM "UDO_Fuel_Cache_SVW"
> Caused by: java.sql.SQLException: 
> com.microsoft.sqlserver.jdbc.SQLServerException:
> Incorrect syntax near the keyword 'FROM'.
>
>
>
>
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Creating a spatial view from an XY table in MS SQL Server?

[Martin Davis]

Has anyone tried creating a spatial view on an XY table in MS SQL Server,
so it can be exposed via GeoServer?

We are not having any luck with this.  What we have done is:

1) Define a spatial view:

CREATE VIEW UDO_Fuel_Cache_SVW AS

SELECT

ID,

   Latitude,

   Longitude,

   Geographic,

   Fuel_Type,

   Updated,

   Full_Barrels,

   Partial_Barrels,

   Empty_Barrels,

   Owner,

   ContactPhone,

   Comments,

   FireCentre,

   FireZone,

   geography::STGeomFromText('POINT('+convert(varchar(20),Longitude)+' '+
convert(varchar(20),Latitude)+')',4326) AS Geom

FROM Incident.dbo.UDO_Fuel_Cache


2) Define a geometry metadata table:

CREATE TABLE GEOMETRY_COLUMNS(

   F_TABLE_SCHEMA VARCHAR(30) NOT NULL,

   F_TABLE_NAME VARCHAR(30) NOT NULL,

   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL,

   COORD_DIMENSION INTEGER,

   SRID INTEGER NOT NULL,

   TYPE VARCHAR(30) NOT NULL,

   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),

   CHECK(TYPE IN ('POINT','LINE', 'POLYGON', 'COLLECTION', 'MULTIPOINT',
'MULTILINE', 'MULTIPOLYGON', 'GEOMETRY') ));

go

INSERT INTO GEOMETRY_COLUMNS

( F_TABLE_SCHEMA, F_TABLE_NAME,   F_GEOMETRY_COLUMN, COORD_DIMENSION, SRID,
TYPE )

VALUES ('', 'UDO_Fuel_Cache_SVW', 'Geom', 2, 4326, 'POINT');


3) Configure the SQL Server Store to refer to GEOMETRY_COLUMNS
4) Configure the layer (I hope correctly).  The layer featuretype listing
shows a column  Geom of type byte[] - which doesn't seem promising.

When trying to view the layer, we get the error:

2017-02-06 09:44:47,833 ERROR [org.geotools.jdbc] - Failed to execute
statement SELECT FROM "UDO_Fuel_Cache_SVW"
Caused by: java.sql.SQLException:
com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near the
keyword 'FROM'.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Uploading SLD ExternalGraphic images via REST API?

[Martin Davis]

Thanks, Jody.

So to be clear, the "path/to/resource" in [1] is relative to the GeoServer
data directory?

[1] http://docs.geoserver.org/stable/en/user/rest/api/resources.html

On Thu, Jan 12, 2017 at 10:15 AM, Jody Garnett <jody.garn...@gmail.com>
wrote:

> The resources api was specificly created to upload and manage images and
> icons (and the occasional config file). You have the correct
> documentation link; I was able to produce a couple of GET examples for the 
> geoserver
> 2.9 release announcement
> <http://blog.geoserver.org/2016/05/30/geoserver-2-9-0-released/>.
>
>
> --
> Jody Garnett
>
> On 11 January 2017 at 13:41, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Can the REST API resources request [1] be used to upload image files for
>> use in SLDs as external graphics?
>>
>> Are there any examples of how to do this?  In particular, it's not clear
>> to me from the docs how to specify the location the files should be stored
>> to.
>>
>> [1] http://docs.geoserver.org/stable/en/user/rest/api/resources.html
>>
>> 
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Uploading SLD ExternalGraphic images via REST API?

[Martin Davis]

Can the REST API resources request [1] be used to upload image files for
use in SLDs as external graphics?

Are there any examples of how to do this?  In particular, it's not clear to
me from the docs how to specify the location the files should be stored to.

[1] http://docs.geoserver.org/stable/en/user/rest/api/resources.html
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer 2.9 deleting SLD Stroke elements?

[Martin Davis]

Yes, I tried this.  It ate the s though, so not ideal (possibly because
using it from Windows/curl).  If that is the solution then I will try
harder to see if formatting can be preserved.

Anyway, the same thing happens when using the web editor.

Seems to me a better behaviour would be to inject missing default elements,
rather than eliding them.  But if this is the new convention it would be
nice to have the defaults documented in the GeoServer docs.

On Thu, Dec 8, 2016 at 11:34 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Thu, Dec 8, 2016 at 7:52 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> It looks like GeoServer is deleting parameter elements with "default"
>> values (although I'm not aware that there is any such thing as default
>> values for SLD entries).
>>
>
> See the "raw" parameter description in the REST API reference here:
>
> http://docs.geoserver.org/stable/en/user/rest/api/styles.html#raw
>
> 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 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39  339 8844549 <+39%20339%20884%204549>
>
> 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.
>
> ---
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] GeoServer 2.9 deleting SLD Stroke elements?

[Martin Davis]

I noticed some odd behaviour in GS 2.9.1.  I load a style via the REST API
which has the following in a PolygonSymbolizer:



#00
1
1.0




When I view the style in the Style Editor panel the following is displayed:

  

  

This is also what is stored in the data directory for the style.

The same behaviour occurs when the style is entered via the Style Editor -
reloading the page shows the altered document.

It looks like GeoServer is deleting parameter elements with "default"
values (although I'm not aware that there is any such thing as default
values for SLD entries).

The SLD is attached.


ADM_NR_DISTRICTS_SVW.sld
Description: Binary data
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Hexagon Binning

[Martin Davis]

You might be able to use Rendering Transformations to do this:

http://docs.geoserver.org/latest/en/user/styling/sld/extensions/rendering-transform.html

But it will take a bit of code...

On Wed, Oct 12, 2016 at 6:07 AM, Volkan Gümüs  wrote:

> Hello everybody!
>
> I'm looking for a way to overlay my WMS layer with a layer that is
> binned through hexagons. I'd like to set an edge length (let's say
> 300meters) and receive hexagons for the whole map.
>
> Is there a way to get this kind of hexagon layer without the need to
> create previously all hexagons as postgis objects?
>
> I'd like to achieve this without geometry creation or at least only
> using lazy geometry creation (on demand).
>
> Thank you!
>
> Volkan Gümüs
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Strategy for GetCaps layer scale range for multiple styles?

[Martin Davis]

What strategy does GeoServer use for computing the GetCaps layer scale
range if a layer has multiple available styles with different scale ranges?

Is it the union (really the "envelope") of the scale ranges?
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Styling when points symbols are overlapping

[Martin Davis]

Perhaps the PointStacker rendering transformation could help?

http://docs.geoserver.org/latest/en/user/styling/sld-extensions/rendering-transform.html
https://wiki.state.ma.us/confluence/display/massgis/GeoServer+-+WMS+and+WPS+-+Rendering+Transformations+-+Point+Clustering


On Tue, Mar 29, 2016 at 7:04 AM, Stephanos Charalambous <
stephanos...@yahoo.gr> wrote:

> Hello,
>
> I would like to ask if is there a way to handle the points styling when
> points symbol (not labels) are overlapping.
> Is there a way to display only one point of the group or ever none of the
> group?
> Or is there a way to display the point with the higher priority even if
> the points of the group lets say belong to the same category?
>
> Any help appreciated.
>
> Stephanos
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Possible to obtain groups from HTTP Headers?

[Martin Davis]

Thanks for the suggestion.  We did briefly consider looking at a
UserGroupService implementation.

It turned out that the client wants to be able to use the Geoserver
security subsystem to maintain and enforce the layer-role policies (i.e. in
the layers.properties file).  So that ruled out the use of a
ResourceAccessManager extension.

In the end we're going with a custom servlet Filter which will use the
enterprise directory service to determine the roles for the user provided
in the request header.  The roles will be injected into a request header
for use by the HTTP Header Authentication module [1][2] with a Role Source
"Request Header".

If you see any issues with this concept please advise!


[1]
http://docs.geoserver.org/stable/en/user/security/tutorials/httpheaderproxy/index.html#configure-the-http-header-filter
[2]
http://docs.geoserver.org/stable/en/user/security/usergrouprole/rolesource.html#using-an-http-header-attribute

PS it wasn't totally clear to me from the docs above how to set the header
attribute name for roles.  It would be good to mention in [1] that the role
header name is entered by choosing "Request Header" under Role source, and
also be a bit more explicit about the configuration UI in [2].   (I know, I
know - make a PR for this!)

On Thu, Feb 25, 2016 at 12:51 AM, Mauro Bartolomeoli <
mauro.bartolome...@geo-solutions.it> wrote:

> Hi Martin,
>
> 2016-02-24 18:22 GMT+01:00 Martin Davis <mtncl...@gmail.com>:
>
>> Thanks, Mauro.  We are aware of the ability to pass roles as well as the
>> user.  That's certainly a nice facility to have.  Unfortunately in the
>> context we are in it is non-trivial to map the supplied group to roles (for
>> various reasons, one of which is that the filter would essentially need to
>> implement its own Role Service to access the roles defined in the GeoServer
>> environment).
>>
>
> Unfortunately you need a UserGroupService to assign groups to users. You
> could implement a custom one, that gets groups from an header (the
> UserGroupService should be able to access current request headers through
> the Dispatcher.REQUEST ThreadLocal).
>
> Regards,
> Mauro Bartolomeoli
>
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Dott. Mauro Bartolomeoli
> @mauro_bart
> Senior 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
>
> ---
>
> *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.
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] SLD problem with attribute filtering

[Martin Davis]

Just a guess, but this is probably caused by a pre-scan that GeoServer does
to validate that all the attributes referred to in the SLD are available in
the underlying layer.  (One reason for this I think is that GeoServer only
requests the attributes needed to compute the SLD filters).

I'm not sure this can be called a bug, it's more of a design limitation.
And as such you may have to adjust your requirements to match the tool you
are using...

On Wed, Feb 24, 2016 at 5:10 PM, Geoffrey Balme <bal...@gmail.com> wrote:

> ​I need to have everything in 1 SLD., it's a part of the requirements of
> the work I have to do.
>
> Isn't this behavior a bug of geoserver ?  It shouldn't behave this way
> when you don't have the exact same attribute for your point and your
> polygon.
>
> 2016-02-25 2:06 GMT+01:00 Martin Davis <mtncl...@gmail.com>:
>
>> Why not create two different SLDs?
>>
>> On Wed, Feb 24, 2016 at 3:41 PM, Geoffrey <bal...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have a SLD file styling 2 different shapefiles, one containing point
>>> and
>>> the other containing polygons. The polygons have an attribute that the
>>> point
>>> doesn't.
>>>
>>> The problem is, that when I filter the Polygon in SLD on their attribute,
>>> the point can't render because it doesn't have this attribute. Even if it
>>> not under the same rule.
>>>
>>> I hope I'm explaining well enough.
>>>
>>> Please see the SLD and shapefiles attached as example.
>>>
>>> Assign the SLD file to style the shapefiles, and see that the Area
>>> shapefile
>>> is rendered correctly, but the Point shapefile can't render. If you
>>> remove
>>> the filter for the attribute in the Polygon rule, then the point can
>>> render.
>>>
>>> Thank you
>>>
>>>
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] SLD problem with attribute filtering

[Martin Davis]

Why not create two different SLDs?

On Wed, Feb 24, 2016 at 3:41 PM, Geoffrey  wrote:

> Hello,
>
> I have a SLD file styling 2 different shapefiles, one containing point and
> the other containing polygons. The polygons have an attribute that the
> point
> doesn't.
>
> The problem is, that when I filter the Polygon in SLD on their attribute,
> the point can't render because it doesn't have this attribute. Even if it
> not under the same rule.
>
> I hope I'm explaining well enough.
>
> Please see the SLD and shapefiles attached as example.
>
> Assign the SLD file to style the shapefiles, and see that the Area
> shapefile
> is rendered correctly, but the Point shapefile can't render. If you remove
> the filter for the attribute in the Polygon rule, then the point can
> render.
>
> Thank you
>
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Possible to obtain groups from HTTP Headers?

[Martin Davis]

Thanks, Mauro.  We are aware of the ability to pass roles as well as the
user.  That's certainly a nice facility to have.  Unfortunately in the
context we are in it is non-trivial to map the supplied group to roles (for
various reasons, one of which is that the filter would essentially need to
implement its own Role Service to access the roles defined in the GeoServer
environment).

We were hoping that if there was a way to pass groups as well as the user
to the Security Subsystem, we could leave the work of computing the
group-role-layer query to it.

Instead, we may look at implementing a ResourceAccessManager plugin that
can access the Authorization mechanism that is already in place.

Martin




On Wed, Feb 24, 2016 at 12:19 AM, Mauro Bartolomeoli <
maurobartolome...@gmail.com> wrote:

> Hi Martin,
>
> 2016-02-24 2:03 GMT+01:00 Martin Davis <mtncl...@gmail.com>:
>
>> We are running GeoServer behind a HTTP security proxy which provides both
>> user authentication and user group membership information (via HTTP
>> Headers).
>>
>> Is it possible to somehow pass the user groups into GeoServer for use by
>> Security subsystem, against a suitably configured Role Service?
>>
>
> What you can currently do is use the HTTP Header Authentication Filter to
> extract both the username and a list of roles (not groups) from two
> distinct HTTP headers.
> To accomplish that you need to choose Request Header as the Role Source in
> the filter configuration.
>
> From related help: If the *role source* is *Request header*, the name of
> the HTTP header attribute has to be specified.The content of this attribute
> are the roles of the principal. The default role delimiter is the semicolon
> *;*.GeoServer accepts the sent roles without verification.
>
> Since roles are used for authorization purposes, probably it's not an
> issue mapping your groups to GeoServer roles.
>
> If you need something more flexible, some customization of this filter is
> needed.
>
>
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Possible to obtain groups from HTTP Headers?

[Martin Davis]

We are running GeoServer behind a HTTP security proxy which provides both
user authentication and user group membership information (via HTTP
Headers).

Is it possible to somehow pass the user groups into GeoServer for use by
Security subsystem, against a suitably configured Role Service?

We are happy to write a custom filter to extract the HTTP headers - it's
just not clear if there's a place to put the group information so that it
can be utilized by the Security subsystem.
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

Good news on this.   Further experimentation revealed that it is possible
to get reasonably good agreement between scales in OpenLayers and GeoServer
using the following approach:

- use OpenLayers NON-geodesic (nominal) scale calculation
- set OpenLayers DOTS_PER_INCH to match the GeoServer value of 90

This produced OL scales that were in good agreement with the GeoServer
values (close enough for government work, anyway  8^).  For example, at a
map nominal scale of 541,679 GeoServer computed the scale of 545,979

This was greatly assisted by Andrea's suggestion of using WMS Decorations,
in conjunction with some enhancements to my WMS Viewer (
http://dr-jts.github.io/maptest/maptest.html ).

For those interested, the following was used to display the GeoServer scale
on each map image:

GetMap parameter

format_options=layout:scaleratio

WMS Decoration Layout file scaleratio.xml:

layout>





On Tue, Feb 16, 2016 at 9:35 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Tue, Feb 16, 2016 at 6:10 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Thanks, Andrea.  I suspected this might be the cause of the issue.
>>
>> Is there a way to view the scale computed for a map request?  That might
>> let us correlate the client (geodetic) scale to "OGC scale", so we can
>> translate between the two.
>>
>
> You can use the decorations:
> http://docs.geoserver.org/stable/en/user/advanced/wmsdecoration.html
>
> A "correlation" might be possible in a very specific local area, but just
> so that we are on the same
> page, the math is wildly different, so you could have a rough linear
> correlation in a town,
> not sure you can have that in a larger area (something spanning degrees,
> especially
> at that latitude where the mercator scale factor starts to diverge)
>
> 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.
>
> ---
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

Thanks for the advice - and for the warning. Sigh

On Tue, Feb 16, 2016 at 9:35 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Tue, Feb 16, 2016 at 6:10 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Thanks, Andrea.  I suspected this might be the cause of the issue.
>>
>> Is there a way to view the scale computed for a map request?  That might
>> let us correlate the client (geodetic) scale to "OGC scale", so we can
>> translate between the two.
>>
>
> You can use the decorations:
> http://docs.geoserver.org/stable/en/user/advanced/wmsdecoration.html
>
> A "correlation" might be possible in a very specific local area, but just
> so that we are on the same
> page, the math is wildly different, so you could have a rough linear
> correlation in a town,
> not sure you can have that in a larger area (something spanning degrees,
> especially
> at that latitude where the mercator scale factor starts to diverge)
>
> 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.
>
> ---
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

Thanks, Andrea.  I suspected this might be the cause of the issue.

Is there a way to view the scale computed for a map request?  That might
let us correlate the client (geodetic) scale to "OGC scale", so we can
translate between the two.

On Tue, Feb 16, 2016 at 12:40 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Tue, Feb 16, 2016 at 12:05 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Are you suggesting that GeoServer computes the scale at a single known
>> point for all map request extents, no matter where on the globe they are
>> located?Does the OGC standard specify this?
>>
>
> The OGC standard basically defines (brace yourself) an "cylindrical earth"
> model in the SLD specification, that's what GeoServer implements, at least
> for
> geographic coordinate systems.
> For projected ones it's the "flat map" scale one, measured in the
> projected coordinates, which is also very far away from a true scale
> (measured along a geodetic distance) especially at those latitudes
> and using that projection.
>
> If you really want to break the standards GeoServer gives you a hand by
> offering a vendor param to compute the scale
> in the accurate (geodetic) way:
>
> http://docs.geoserver.org/latest/en/user/services/wms/vendor.html#scalemethod
>
> We normally use that for printouts :-)
>
> 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.
>
> ---
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

Are you suggesting that GeoServer computes the scale at a single known
point for all map request extents, no matter where on the globe they are
located?Does the OGC standard specify this?

If so, I guess that might explain the discrepancy between SLD scale and
true image scale, at our latitudes (49 to 60) ?




On Mon, Feb 15, 2016 at 2:35 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I am not sure if I understood the problem but I wonder how the true scale
> suits together with Web Mercator. I guess that you do not expect that the
> tiles of the same zoom level would use different styles at equator than in
> Canada or Finland even the true scale differs a lot.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Martin Davis wrote:
>
>
>
> We are displaying map images in Web Mercator, from a GeoServer with native
> CRS as BC-Albers (EPGS:3005).
>
>
>
> We are using an OpenLayers client to display the map images.  We have
> confirmed that the geodetic scale displayed by OpenLayers is approximately
> the true scale of the map images (modulo the fact that OL uses a fixed
> resolution of 72 DPI).
>
>
>
> Based on the zoom levels at which layers become visible, it appears that
> GeoServer's internal computed scale is from 2 to 4 times larger than the
> client scale.
>
>
>
> Is this expected?
>
>
>
> Is there any way to determine a way to map between client scale and
> Geoserver scale, so that we can configure the client to track GeoServer
> visibility faithfully?
>
>
>
> Is there any way to display the internal GeoServer scale to make it
> possible to confirm if this analysis is correct?
>
>
>
>
>
> GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

Yes, we realize that's an issue. In our case we're only concerned with a
relatively small area (the province of BC), so the variation in true scale
across the area is not that large (around 20%).  We realize that we won't
get 100% correlation, but we'd like to at least get it looking right better
than 50% of the time!

The issue is that it's very hard to determine what a scale limit in a SLD
corresponds to in terms of client (true, screen) scale.   It seems odd that
the GeoServer scale would be a factor of 2 or more different to the true
(image) scale.

There does appear to be a rough correlation, which may even be a linear
factor.  But it's hard to tell without seeing the exact scale that
GeoServer is using in its SLD algorithm.

As examples, here's some scale limits from SLDs, with the corresponding
largest client scale (approximate)  at which the layer is visible

SLD Client Zoom Level
 10,000,000 4,399,000 6
 6,000,000 2,297,000 7

 2,000,000 565,000 9
 1,000,000 282,000 10
 500,000 143,000 11
 20,000 8,957  15


On Mon, Feb 15, 2016 at 2:35 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I am not sure if I understood the problem but I wonder how the true scale
> suits together with Web Mercator. I guess that you do not expect that the
> tiles of the same zoom level would use different styles at equator than in
> Canada or Finland even the true scale differs a lot.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Martin Davis wrote:
>
>
>
> We are displaying map images in Web Mercator, from a GeoServer with native
> CRS as BC-Albers (EPGS:3005).
>
>
>
> We are using an OpenLayers client to display the map images.  We have
> confirmed that the geodetic scale displayed by OpenLayers is approximately
> the true scale of the map images (modulo the fact that OL uses a fixed
> resolution of 72 DPI).
>
>
>
> Based on the zoom levels at which layers become visible, it appears that
> GeoServer's internal computed scale is from 2 to 4 times larger than the
> client scale.
>
>
>
> Is this expected?
>
>
>
> Is there any way to determine a way to map between client scale and
> Geoserver scale, so that we can configure the client to track GeoServer
> visibility faithfully?
>
>
>
> Is there any way to display the internal GeoServer scale to make it
> possible to confirm if this analysis is correct?
>
>
>
>
>
> GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
>
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

[Martin Davis]

We are displaying map images in Web Mercator, from a GeoServer with native
CRS as BC-Albers (EPGS:3005).

We are using an OpenLayers client to display the map images.  We have
confirmed that the geodetic scale displayed by OpenLayers is approximately
the true scale of the map images (modulo the fact that OL uses a fixed
resolution of 72 DPI).

Based on the zoom levels at which layers become visible, it appears that
GeoServer's internal computed scale is from 2 to 4 times larger than the
client scale.

Is this expected?

Is there any way to determine a way to map between client scale and
Geoserver scale, so that we can configure the client to track GeoServer
visibility faithfully?

Is there any way to display the internal GeoServer scale to make it
possible to confirm if this analysis is correct?


GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
--
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=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Odd behaviour with WFS GetFeature in Geoserver 2.7.1.1 - property names (and geometry) returned that are not requested.

[Martin Davis]

+1 for a nogeometry switch.  We need some way to support GetFeatureInfo but
not return geometry, for security reasons.  Actually it would be great to
support returning a BBOX rather than the actual geometry, since this
supports zooming.  This improves both security and performance.

On Sun, Jan 17, 2016 at 1:19 PM, Phil Scadden  wrote:

>
>
> The constraint of requiring not null properties to be returned regardless
> of whether in property list, is only useful within the context of WFS-T.
> That should be the flagging criteria. If not in a WFS-T context, then only
> send properties requested. I suspect that editing is rare but querying is
> common. I think OGC should consider a nogeometry switch like arcGIS server.
>
>
--
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=267308311=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Remap raster band values to strings for GetFeatureInfo ?

[Martin Davis]

Thanks, Andrea.

Being a bit of a raster newb, I realized after i posted that as you suggest
an SLD is needed to provide a legend.  This will help with map
comprehension, but we'd really like a point identify capability as well.

It's not clear how to "add the label in the output feature".  Will the SLD
do this?

As you say, with custom code anything is possible, but we need to have a
supported solution for this.

On Tue, Nov 24, 2015 at 6:08 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Mon, Nov 23, 2015 at 11:03 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> We have a GeoTiff with a single paletted band.   By default
>> GetFeatureInfo returns results containing (for example) PALETTE_INDEX =
>> 2.0.  We'd like to return more business-meaningful titles, such as "C‐2
>> Boreal Spruce".
>>
>> It seems like FreeMarker templates are one way to do this (as per
>> https://sourceforge.net/p/geoserver/mailman/message/29891718/).
>> However, we'd like to do this so that it works with ALL GetFeatureInfo
>> response formats, not just HTML.  In other words, the mapping needs to be
>> done at the FeatureType level, not just at the GetFeatureInfo response
>> level.
>>
>> Is this possible?  Perhaps by adding information to the GeoTiff itself?
>>
>
> By changing the code, lots of things are possible. I'd say you want to do
> your re-mapping here:
>
> https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/featureinfo/RasterLayerIdentifier.java#L180
>
> As an idea, why don't you use the labels that might be already available
> in the SLD colormap?
>
> http://docs.geoserver.org/latest/en/user/styling/sld-reference/rastersymbolizer.html#colormap
>
> This way you can make the pair between the GetLegendGraphic output and the
> GetFeatureInfo one.
> Mapping wise I'd keep the raw value, and add the label as an extra
> attribute in the output feature,
> depending on the raster usage both can make a lot of sense
>
>
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Remap raster band values to strings for GetFeatureInfo ?

[Martin Davis]

Ok, so was referring to custom code solution.

Not an option for us now, so will have to look at a client-side solution,
unless there's another server-side option.

Perhaps this could be an future enhancement to Coverage Views (if that's
the right place for it).

On Tue, Nov 24, 2015 at 9:59 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Tue, Nov 24, 2015 at 6:52 PM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Thanks, Andrea.
>>
>> Being a bit of a raster newb, I realized after i posted that as you
>> suggest an SLD is needed to provide a legend.  This will help with map
>> comprehension, but we'd really like a point identify capability as well.
>>
>> It's not clear how to "add the label in the output feature".  Will the
>> SLD do this?
>>
>
> No, but you have the the Style object in params.getStyle(), from there
> getting the color map is not difficult (assuming
> there is only one) and then you just have to check which rules applies to
> the extracted value, get its label, and add it to the
> feature being built.
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Remap raster band values to strings for GetFeatureInfo ?

[Martin Davis]

We have a GeoTiff with a single paletted band.   By default GetFeatureInfo
returns results containing (for example) PALETTE_INDEX = 2.0.  We'd like to
return more business-meaningful titles, such as "C‐2 Boreal Spruce".

It seems like FreeMarker templates are one way to do this (as per
https://sourceforge.net/p/geoserver/mailman/message/29891718/).  However,
we'd like to do this so that it works with ALL GetFeatureInfo response
formats, not just HTML.  In other words, the mapping needs to be done at
the FeatureType level, not just at the GetFeatureInfo response level.

Is this possible?  Perhaps by adding information to the GeoTiff itself?
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer's spatial filter preventing SQL view layer from working

[Martin Davis]

+1 - agreed that this seems like the "simplest" way forward.



On Thu, Nov 19, 2015 at 10:08 AM, cheesybiscuits 
wrote:

> Wow, that is a long thread!
>
> I read / skimmed through the full conversation and what I take from it is
> there are numerous ways this could be done that would increase complexity,
> deviate from GeoServer's UI philosophy, and consume lots of developer time,
> but that Andrea's original suggestion - to not append an SDO_FILTER clause
> if a spatial index doesn't exist for the geometry column - is the most
> suitable. It can simply be the Oracle function / procedure writer's
> responsibility to ensure their code filters output features to the queried
> bbox.
>
> Ideally GeoServer would make minx, miny, maxx, and maxy of the query
> available by default (e.g. accessible in your SQL View via %%minx%%) so
> that
> these would not have to be provided by viewparams.
>
> There is a lot of documentation on starting GeoServer development but I
> have
> previously been confused about how to get involved in extension
> development.
> Any pointers for the best way to get started in this?
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/GeoServer-s-spatial-filter-preventing-SQL-view-layer-from-working-tp5237269p5237488.html
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
>
> --
> ___
> 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] GeoServer's spatial filter preventing SQL view layer from working

[Martin Davis]

Actually after some more thought I think this situation is slightly
different (although the technical solution might end up being the same).
Here's the two cases as I understand them:

1) In my original case the need was to run a query against an Oracle
spatial table and return a geometry value computed from the base geometry.
So the SDO_FILTER clause for the query bounding box was still required, it
just needed to be run against the base geometry, not the geometry returned
by the query.

2) In the cluster case (if I understand it) no SDO_FILTER clause is
required, but instead the bounding box values need to be passed to a custom
Oracle function.

It seems like #1 might be simpler to implement than #2.  For instance, in
#1 GeoServer can still run an "empty query" to determine the geometry
column(s), whereas that doesn't seem feasible in #2.


On Wed, Nov 18, 2015 at 11:22 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi Martin,
> it certainly looks similar, most likely same.
>
> No new development, still not possible, people still welcome to chip in
> with resources/funds:
>
> https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
>
> Cheers
> Andrea
>
> On Thu, Nov 19, 2015 at 6:32 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> I think this is the same issue discussed in this (lengthy) thread:
>>
>>
>> http://osgeo-org.1560.x6.nabble.com/Reducing-query-data-size-in-Oracle-td5192620.html
>>
>> TLDR: not possible right now, apparently requires clever development to
>> make it work.
>>
>> If there has been improvement on this front it would be great to know
>> about it.  Or would be great to have someone implement a workaround!
>>
>> On Wed, Nov 18, 2015 at 12:08 PM, cheesybiscuits <
>> thomaschrist...@gmail.com> wrote:
>>
>>> I've created a function within Oracle for on-the-fly clustering that I
>>> hoped
>>> to query via GeoServer using an SQL view layer.
>>>
>>> The function takes as its arguments the bounding box and the number of
>>> grid
>>> cells to use in a basic gridded clustering process (i.e. find the centre
>>> of
>>> mass for points within each grid cell). Please note I've tried the Point
>>> Stacker extension and it isn't adequate for my needs. Executing the
>>> following query within Oracle gives the list of sdo_geometry objects
>>> that I
>>> expect:
>>>
>>> select * from table(package_name.function_name(-180, -90, 180, 90, 3);
>>>
>>> My intention is to make WMS requests to GeoServer with the viewparams
>>> parameter included that provides all required arguments. Because of the
>>> way
>>> the function works the returned sdo_geometry objects will only ever be
>>> within the provided bounding box.
>>>
>>> I can successfully create an SQL view layer within GeoServer using this
>>> syntax and everything seems OK while publishing. However when I access
>>> the
>>> layer everything falls apart. GeoServer takes my query and wraps it as
>>> follows:
>>>
>>> SELECT GEOMETRY as GEOMETRY FROM (select * from
>>> table(package_name.function_name(-180, -90, 180, 90, 3))) VTABLE WHERE
>>> SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>>>
>>> Oracle then errors because the function's table return type doesn't have
>>> a
>>> spatial index to use with SDO_FILTER. Although I did find a  somewhat
>>> similar problem on GIS.SE
>>> <
>>> http://gis.stackexchange.com/questions/92554/can-i-create-an-oracle-spatial-view-from-a-non-spatial-table
>>> >
>>> the same solution does not apply as my function returns a table, not a
>>> single object, and Oracle doesn't permit indexes on named table types.
>>>
>>> As things currently stand I don't think I can make this work, and the
>>> only
>>> thing that could potentially help is to prevent GeoServer from appending
>>> its
>>> SDO_FILTER mask. However I'm guessing this just isn't possible without
>>> digging into the source and creating a custom build (totally not an
>>> option).
>>>
>>> Can anyone tell me if there's something I've missed here, or suggest a
>>> different approach for solving the same problem? Any thoughts would be
>>> very
>>> much appreciated.
>>>
>>>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer's spatial filter preventing SQL view layer from working

[Martin Davis]

I think this is the same issue discussed in this (lengthy) thread:

http://osgeo-org.1560.x6.nabble.com/Reducing-query-data-size-in-Oracle-td5192620.html

TLDR: not possible right now, apparently requires clever development to
make it work.

If there has been improvement on this front it would be great to know about
it.  Or would be great to have someone implement a workaround!

On Wed, Nov 18, 2015 at 12:08 PM, cheesybiscuits 
wrote:

> I've created a function within Oracle for on-the-fly clustering that I
> hoped
> to query via GeoServer using an SQL view layer.
>
> The function takes as its arguments the bounding box and the number of grid
> cells to use in a basic gridded clustering process (i.e. find the centre of
> mass for points within each grid cell). Please note I've tried the Point
> Stacker extension and it isn't adequate for my needs. Executing the
> following query within Oracle gives the list of sdo_geometry objects that I
> expect:
>
> select * from table(package_name.function_name(-180, -90, 180, 90, 3);
>
> My intention is to make WMS requests to GeoServer with the viewparams
> parameter included that provides all required arguments. Because of the way
> the function works the returned sdo_geometry objects will only ever be
> within the provided bounding box.
>
> I can successfully create an SQL view layer within GeoServer using this
> syntax and everything seems OK while publishing. However when I access the
> layer everything falls apart. GeoServer takes my query and wraps it as
> follows:
>
> SELECT GEOMETRY as GEOMETRY FROM (select * from
> table(package_name.function_name(-180, -90, 180, 90, 3))) VTABLE WHERE
> SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>
> Oracle then errors because the function's table return type doesn't have a
> spatial index to use with SDO_FILTER. Although I did find a  somewhat
> similar problem on GIS.SE
> <
> http://gis.stackexchange.com/questions/92554/can-i-create-an-oracle-spatial-view-from-a-non-spatial-table
> >
> the same solution does not apply as my function returns a table, not a
> single object, and Oracle doesn't permit indexes on named table types.
>
> As things currently stand I don't think I can make this work, and the only
> thing that could potentially help is to prevent GeoServer from appending
> its
> SDO_FILTER mask. However I'm guessing this just isn't possible without
> digging into the source and creating a custom build (totally not an
> option).
>
> Can anyone tell me if there's something I've missed here, or suggest a
> different approach for solving the same problem? Any thoughts would be very
> much appreciated.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/GeoServer-s-spatial-filter-preventing-SQL-view-layer-from-working-tp5237269.html
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
>
> --
> ___
> 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] Multiple Layers in GetLegendGraphic?

[Martin Davis]

Thanks, Jody.  Good to know that it's a relatively simple extension.  Not
sure if/when we'll have time to do development on this thiough.

And the idea of a map/scale-aware GetLegendGraphic is a good one.  Legends
for our maps can get very long, so any way of cutting them down to size is
useful.



On Sun, Sep 27, 2015 at 2:17 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:

> Hey Martin:
>
> I am sure we could do that, we already have a bunch of options to try and
> pass in current scale/dpi to try and get a visual that matches what is on
> the screen.
>
> The code is here:
>
>
> https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/GetLegendGraphicRequest.java
>
> The important part is:
>
>  *  LAYER Required Layer for which to produce
> legend graphic. A layergroup can be specified, too. In this case, STYLE and
> RULE parameters can have multiple values (separated by commas), one for
> each of the group layers.
>
> So if style and rule are already setup it should be fairly easy to allow
> layer to have multiple values separated by commas.
>
> Indeed internally the code already has:
>
> /** The featuretype(s) of the requested LAYER(s) */
> private List layers=new ArrayList();
>
> So no change to the data structure and logic should be required, just
> parser and test case.
>
> Aside: As long as we are dreaming here I would love to have one that
> operates like GetFeatureInfo - and includes a reference GetMap complete
> with BBox (and thus could only show the layers / rules that end up having
> something on the screen.
>
> --
> Jody Garnett
>
> On 25 September 2015 at 09:48, Martin Davis <mtncl...@gmail.com> wrote:
>
>> It looks like GetLegendGraphic only supports requesting a legend for a
>> single layer. Could this be generalized to allow multiple layers being
>> requested?
>>
>> The use case is that in some simple clients it's difficult to display an
>> arbitrary-length list of images (e.g. Jasper Reports).
>>
>>
>> --
>>
>> ___
>> 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

[Geoserver-users] Multiple Layers in GetLegendGraphic?

[Martin Davis]

It looks like GetLegendGraphic only supports requesting a legend for a
single layer. Could this be generalized to allow multiple layers being
requested?

The use case is that in some simple clients it's difficult to display an
arbitrary-length list of images (e.g. Jasper Reports).
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

Thanks, Andrea, that sounds like the cause.  We'll upgrade and see if the
problem goes away.

On Tue, Sep 1, 2015 at 11:25 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> On Wed, Sep 2, 2015 at 1:21 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> We've run some DB logging on the map requests.
>>
>> One of the causes of the slowdown for no schema is this query:
>>
>> SELECT NULL AS table_cat,
>>o.owner AS table_schem,
>>o.object_name AS table_name,
>>o.object_type AS table_type,
>>NULL AS remarks
>>   FROM all_objects o
>>   WHERE o.owner LIKE :1 ESCAPE '/'
>> AND o.object_name LIKE :2 ESCAPE '/'
>> AND o.object_type IN ('xxx', 'TABLE', 'VIEW', 'SYNONYM')
>>   ORDER BY table_type, table_schem, table_name
>>
>> If no owner is specified this returns 38K rows, as opposed to about 240
>> when owner is given.
>>
>> I'm not totally sure what this is doing, but I suspect checking for
>> Primary Key info?
>>
>> And why is this being run on each MapRequest ?
>>
>> Funnily, we have 2.6.3 running in a different setup, and it doesn't seem
>> to be issuing any of these queries - just the data query. I can't see any
>> config difference that would cause this.
>>
>
> Maybe not so funny, I remember of a major performance regression in JDBC
> stores in 2.6.0,
> indeed it was very slow against spatial databases, see the 2.6.1 release
> notes:
> http://blog.geoserver.org/2014/11/18/geoserver-2-6-1-released/
>
> Discussion here:
>
> http://osgeo-org.1560.x6.nabble.com/Severe-slowdown-in-ContentDataStore-in-12-x-and-trunk-td5167030.html
>
> To avoid this kind of issue, besides more review, which never hurts but
> requires more staff, we'd need
> continuous performance testing and comparison against production sized
> databases, something
> I've been proposing on and off for several years, but that never got the
> resourcing it needs to make it happen.
>
>
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Native Oracle JDBC logging in GeoServer ?

[Martin Davis]

Thanks for the suggestions, Jonathan.

- We did try cranking up the logging level, but I think the problematic
queries are not logged.  We didn't see them, anyway
- The SQL history tip looks very useful...
- Did think about a wire sniffer, but we don't have that level of access.
And it seems like it might be hard to interpret the raw wire data...

In the end we were able to enable DB session tracing and that gave us what
we needed to identify the problem.  For reference, here's what we did:

* Put this into the datastore Session Startup SQL:

BEGIN; DBMS_SESSION.SET_IDENTIFIER('GEOSERVER'); END;

This puts “GEOSERVER” in the user session variable CLIENT_IDENTIFIER.

* In the database, a DBA needs to do this to start tracing:

EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(client_id => 'GEOSERVER');

* Run the GeoServer query.
* Stop tracing:

EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE(client_id => 'GEOSERVER');

On Wed, Sep 2, 2015 at 3:57 AM, Jonathan Moules <jonat...@lightpear.com>
wrote:

> Hi Martin,
>  I'll leave the driver level suggestions to those more knowledgeable, but
> have you tried:
>
> - Setting the GeoServer /Geotools logging level to GeoTools developer
> logging? In my experience this seems to log most things, including some of
> the metadata queries
> - Ask Oracle what it has been up to recently:
> http://stackoverflow.com/questions/14830875/find-out-the-history-of-sql-queries
> - Failing that, maybe try using some packet sniffer intermediate to watch
> the requests as they go by; not sure if fiddler2 can handle this type of
> packet.
>
> Cheers,
> Jonathan
>
>
> On 01/09/2015 20:11, Martin Davis wrote:
>
> In order to diagnose a performance problem [1] we would like to capture
> ALL SQL statements emitted by GeoServer to Oracle.  It appears that many of
> the metadata queries are not logged.
>
> Oracle JDBC drivers support logging internally [2].  Has anyone tried
> this, and is it possible to enable this by simply creating a new logging
> properties file in GeoServer?  Or is it necessary to follow the more
> complicated configuration documented by Oracle?
>
>
> [1]
> http://osgeo-org.1560.x6.nabble.com/Issue-with-internal-connection-pooling-for-Oracle-datastore-with-no-schema-name-td5217844.html
>
> [2] http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm
>
>
> --
>
>
>
> ___
> Geoserver-users mailing 
> listGeoserver-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Native Oracle JDBC logging in GeoServer ?

[Martin Davis]

In order to diagnose a performance problem [1] we would like to capture ALL
SQL statements emitted by GeoServer to Oracle.  It appears that many of the
metadata queries are not logged.

Oracle JDBC drivers support logging internally [2].  Has anyone tried this,
and is it possible to enable this by simply creating a new logging
properties file in GeoServer?  Or is it necessary to follow the more
complicated configuration documented by Oracle?


[1]
http://osgeo-org.1560.x6.nabble.com/Issue-with-internal-connection-pooling-for-Oracle-datastore-with-no-schema-name-td5217844.html

[2] http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

An update on this issue.

As Andrea predicted, using a JNDI connection made no difference to the
performance issue (no schema still substantially slower than using a
schema).

We're now attempting to do Oracle logging to try and see what's getting run
that might slow a map request down.  (We have only limited access to the
box where the problem shows up).  Results are not conclusive so far, but we
think we are seeing several queries being run over as many as 5 different
"Geoserver sessions" during a single map request.  Cannot tell what these
are yet, but seems likely they are metadata queries.  This is odd, since we
are not seeing this happen in another similar environment.  One difference
is that we are connecting via an Oracle Service rather than a SID in the
slow environment.  Would be odd if this was the cause, though.


On Fri, Jul 31, 2015 at 10:02 AM, Martin Davis <mtncl...@gmail.com> wrote:

> Thanks, Andrea.
>
> We're using GeoServer 2.6.0
>
> The performance issue occurs for map requests - so wouldn't this be
> something different to the issue with slow metadata loading (The metadata
> retrieval is an issue we've seen as well, but it only hurts the admin, not
> the users, so we're less caring about that  8^).
>
> We'll probably try using a JNDI pool and see whether that helps at all.
> If so, we may just use that approach.  If not, we'll be looking for a code
> fix - which we can likely get funded and contribute back.
>
>
>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

We've run some DB logging on the map requests.

One of the causes of the slowdown for no schema is this query:

SELECT NULL AS table_cat,
   o.owner AS table_schem,
   o.object_name AS table_name,
   o.object_type AS table_type,
   NULL AS remarks
  FROM all_objects o
  WHERE o.owner LIKE :1 ESCAPE '/'
AND o.object_name LIKE :2 ESCAPE '/'
AND o.object_type IN ('xxx', 'TABLE', 'VIEW', 'SYNONYM')
  ORDER BY table_type, table_schem, table_name

If no owner is specified this returns 38K rows, as opposed to about 240
when owner is given.

I'm not totally sure what this is doing, but I suspect checking for Primary
Key info?

And why is this being run on each MapRequest ?

Funnily, we have 2.6.3 running in a different setup, and it doesn't seem to
be issuing any of these queries - just the data query. I can't see any
config difference that would cause this.


Any ideas?



On Tue, Sep 1, 2015 at 12:46 PM, Martin Davis <mtncl...@gmail.com> wrote:

> An update on this issue.
>
> As Andrea predicted, using a JNDI connection made no difference to the
> performance issue (no schema still substantially slower than using a
> schema).
>
> On Fri, Jul 31, 2015 at 10:02 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Thanks, Andrea.
>>
>> We're using GeoServer 2.6.0
>>
>> The performance issue occurs for map requests - so wouldn't this be
>> something different to the issue with slow metadata loading (The metadata
>> retrieval is an issue we've seen as well, but it only hurts the admin, not
>> the users, so we're less caring about that  8^).
>>
>> We'll probably try using a JNDI pool and see whether that helps at all.
>> If so, we may just use that approach.  If not, we'll be looking for a code
>> fix - which we can likely get funded and contribute back.
>>
>>
>>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

We're working on profiling from the DB side.  It's difficult to get a debug
GeoServer setup against the environment showing the problem.

On Tue, Sep 1, 2015 at 2:47 PM, Jody Garnett <jody.garn...@gmail.com> wrote:

> So are you in position to profile the code? We recently enabled the
> database online tests again, but they test conformance, not performance.
>
> --
> Jody Garnett
>
> On 1 September 2015 at 14:38, Martin Davis <mtncl...@gmail.com> wrote:
>
>> Yes, we are suspicious that the metadata queries are returning a lot of
>> rows when no schema is specified.  But can't confirm this is happening,
>> until we can get DB-level tracing enabled.
>>
>> And as you say, why would this be happening on every GetMap ?  And why
>> happening in one environment and not in a similar different one?
>>
>> On Tue, Sep 1, 2015 at 2:13 PM, Jody Garnett <jody.garn...@gmail.com>
>> wrote:
>>
>>> I have a silly suggestion, when not using a schema is the data store
>>> getting back an amazingly large number of oracle tables .. checking each
>>> one for a spatial index and so on?
>>>
>>> I would expect that to take a bit longer on startup ... but you are
>>> indicating that every GetMap request is consistently slow.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 1 September 2015 at 12:46, Martin Davis <mtncl...@gmail.com> wrote:
>>>
>>>> An update on this issue.
>>>>
>>>> As Andrea predicted, using a JNDI connection made no difference to the
>>>> performance issue (no schema still substantially slower than using a
>>>> schema).
>>>>
>>>> We're now attempting to do Oracle logging to try and see what's getting
>>>> run that might slow a map request down.  (We have only limited access to
>>>> the box where the problem shows up).  Results are not conclusive so far,
>>>> but we think we are seeing several queries being run over as many as 5
>>>> different "Geoserver sessions" during a single map request.  Cannot tell
>>>> what these are yet, but seems likely they are metadata queries.  This is
>>>> odd, since we are not seeing this happen in another similar environment.
>>>> One difference is that we are connecting via an Oracle Service rather than
>>>> a SID in the slow environment.  Would be odd if this was the cause, though.
>>>>
>>>>
>>>> On Fri, Jul 31, 2015 at 10:02 AM, Martin Davis <mtncl...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks, Andrea.
>>>>>
>>>>> We're using GeoServer 2.6.0
>>>>>
>>>>> The performance issue occurs for map requests - so wouldn't this be
>>>>> something different to the issue with slow metadata loading (The metadata
>>>>> retrieval is an issue we've seen as well, but it only hurts the admin, not
>>>>> the users, so we're less caring about that  8^).
>>>>>
>>>>> We'll probably try using a JNDI pool and see whether that helps at
>>>>> all.  If so, we may just use that approach.  If not, we'll be looking for 
>>>>> a
>>>>> code fix - which we can likely get funded and contribute back.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> ___
>>>> 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] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

Yes, we are suspicious that the metadata queries are returning a lot of
rows when no schema is specified.  But can't confirm this is happening,
until we can get DB-level tracing enabled.

And as you say, why would this be happening on every GetMap ?  And why
happening in one environment and not in a similar different one?

On Tue, Sep 1, 2015 at 2:13 PM, Jody Garnett <jody.garn...@gmail.com> wrote:

> I have a silly suggestion, when not using a schema is the data store
> getting back an amazingly large number of oracle tables .. checking each
> one for a spatial index and so on?
>
> I would expect that to take a bit longer on startup ... but you are
> indicating that every GetMap request is consistently slow.
>
> --
> Jody Garnett
>
> On 1 September 2015 at 12:46, Martin Davis <mtncl...@gmail.com> wrote:
>
>> An update on this issue.
>>
>> As Andrea predicted, using a JNDI connection made no difference to the
>> performance issue (no schema still substantially slower than using a
>> schema).
>>
>> We're now attempting to do Oracle logging to try and see what's getting
>> run that might slow a map request down.  (We have only limited access to
>> the box where the problem shows up).  Results are not conclusive so far,
>> but we think we are seeing several queries being run over as many as 5
>> different "Geoserver sessions" during a single map request.  Cannot tell
>> what these are yet, but seems likely they are metadata queries.  This is
>> odd, since we are not seeing this happen in another similar environment.
>> One difference is that we are connecting via an Oracle Service rather than
>> a SID in the slow environment.  Would be odd if this was the cause, though.
>>
>>
>> On Fri, Jul 31, 2015 at 10:02 AM, Martin Davis <mtncl...@gmail.com>
>> wrote:
>>
>>> Thanks, Andrea.
>>>
>>> We're using GeoServer 2.6.0
>>>
>>> The performance issue occurs for map requests - so wouldn't this be
>>> something different to the issue with slow metadata loading (The metadata
>>> retrieval is an issue we've seen as well, but it only hurts the admin, not
>>> the users, so we're less caring about that  8^).
>>>
>>> We'll probably try using a JNDI pool and see whether that helps at all.
>>> If so, we may just use that approach.  If not, we'll be looking for a code
>>> fix - which we can likely get funded and contribute back.
>>>
>>>
>>>
>>
>> --
>>
>> ___
>> 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

[Geoserver-users] Schemaless WFS spatial queries in GeoServer ?

[Martin Davis]

The WFS spec supports schemaless (or perhaps anonymous spatial queries
against featuretypes via the BBOX parameter.  But if a more complex query
geometry is required (e.g. polygon), it's necessary to create a Filter,
which then needs to have the spatial propertyname provided.

This means that clients need more metadata about featuretype schemas to do
polygon queries. This seems a bit inconsistent, since presumably the server
mechanism can handle schemaless queries (since it can support BBOX).

I suspect I know the answer to this, but I'll ask it anyway...  Is there
any extension in GeoServer that supports WFS queries with a polygonal query
geometry WITHOUT requiring a property name?
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Schemaless WFS spatial queries in GeoServer ?

[Martin Davis]

Not sure I understand...  I think I want to do something that is outside
the spec, and am wondering if GS has a way to do it. So not sure how the
CITE test will help?

GetFeatureInfo is not an option, since we need to query by a polygon.

On Wed, Aug 19, 2015 at 9:21 PM, Jody Garnett jody.garn...@gmail.com
wrote:

 This is the kind of thing the CITE tests hit, so you can try enabling CITE
 mode on your WFS and and using something like
 PropertyName./PropertyName - which should check against all geometry
 attributes in a feature.

 Other than that I would recommend using GetFeatureInfo and asking it to
 return GML.

 --
 Jody Garnett

 On 19 August 2015 at 13:04, Martin Davis mtncl...@gmail.com wrote:

 The WFS spec supports schemaless (or perhaps anonymous spatial
 queries against featuretypes via the BBOX parameter.  But if a more complex
 query geometry is required (e.g. polygon), it's necessary to create a
 Filter, which then needs to have the spatial propertyname provided.

 This means that clients need more metadata about featuretype schemas to
 do polygon queries. This seems a bit inconsistent, since presumably the
 server mechanism can handle schemaless queries (since it can support BBOX).

 I suspect I know the answer to this, but I'll ask it anyway...  Is there
 any extension in GeoServer that supports WFS queries with a polygonal query
 geometry WITHOUT requiring a property name?


 --

 ___
 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] Performance issue with large polygon

[Martin Davis]

AFAIK there is no way to cache a layer in memory.  This would be a useful
feature to add to GeoServer.

Perhaps you could cache the geometry as a shapefile - which should provide
fastest performance off disk?  It would be interesting to see what the
performance boost is at any rate.  I also wonder if clipping small parts
out of a very large geometry is causing a performance hit.

On Fri, Aug 7, 2015 at 1:28 AM, Kirk, Victor victor.k...@cubic.com wrote:

 Hi,

 We have a polygon layer used as a backdrop for a WMS based layer group.
 The layer contains the outlines of the UK, one of which is the mainland and
 is obviously quite large.  I have generalised versions of the geometries to
 use when zoomed out, however when zoomed in, encoding the whole mainland
 for every tile introduces a bottleneck and requests quickly build up and
 time out as every request.  The layer group contains around 20 different
 layers, without the polygon layer the group renders very quickly add the
 layer back in and it becomes very unsresposive.

 The layer is used to provide the coast and a background colour for land.
 I'm looking at chopping up the polygons on a grid to create smaller
 geometries that can be used to provide the background colour and extract
 the coast into a number of smaller lines.

 But before I do this I was wondering if there was some way I could get
 geoserver to cache the features for this layer in memory rather than having
 to hit the database for every request.

 Regards, Vic
 --



 

 This document is intended for, and should only be read by, those persons
 to whom it is addressed. Its contents are confidential and if you have
 received this message in error, please delete it. Any form of reproduction,
 dissemination, copying, disclosure, modification, distribution and / or
 publication of this message without our prior written consent is strictly
 prohibited.

 Any views expressed in this message are those of the individual sender,
 and do not necessarily represent the position of Cubic Transportation
 Systems (ITMS) Limited (‘CTS’). Furthermore CTS does not authorise or use
 e-mail for official contractual correspondence. Nothing received in e-mail
 has any contractual validity.

 CTSL and each legal entity in Cubic Corporation reserve the right to
 monitor all e-mail communications through its networks.

 Registered Office:
 Cubic Transportation Systems Ltd
 AFC House
 Honeycrock Lane
 Salfords
 Surrey
 RH1 5LA
 United Kingdom

 Registered in England under number 8498086

 

 --
 ___
 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] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

Thanks, Andrea.

We're using GeoServer 2.6.0

The performance issue occurs for map requests - so wouldn't this be
something different to the issue with slow metadata loading (The metadata
retrieval is an issue we've seen as well, but it only hurts the admin, not
the users, so we're less caring about that  8^).

But I guess anything might be happening in there. We're attempting to get
tracing on the DB side to see what's going on, but so far haven't found a
friendly-enough DBA.  8^)

We'll probably try using a JNDI pool and see whether that helps at all.  If
so, we may just use that approach.  If not, we'll be looking for a code fix
- which we can likely get funded and contribute back.

Will communicate any findings we have, to help improve the support for
Oracle.

(Postgres does tend to scare people at this particular client,
unfortunately.   We did float the idea of using a local data cache built
on top of a special technology ideally suited for this purpose whose
initials just happen to be PG... but so far no bites.  However, if we can
show a major improvement in map image request performance, we might still
be able to make this fly...)

On Thu, Jul 30, 2015 at 1:42 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Thu, Jul 30, 2015 at 7:56 PM, Martin Davis mtncl...@gmail.com wrote:

 We have the following GeoServer setup:

 Datastore to an Oracle 12c Exadata instance
 Internal connection pooling
 No schema specified


 What GEoServer version?



 We noticed a serious performance anomaly, where each layer was taking
 about 4 s to render, even when the data was very small.

 When we switched to specifying an explicit schema in the Datastore
 config, the performance got significantly faster, and the time to render
 individual layers became more proportional to the query result size.

 So the questions are:
 1. does omitting a schema name in the Oracle Datastore config cause
 connection pooling to be disabled or defeated?


 While I cannot ensure I won't be hit by an asteroid in the next hour,
 that's unlikely. So is the idea that not setting
 up the catalog can break connection pooling.

 It will likely slow down things for other reasons unrelated to connection
 pooling instead.
 Oracle is a database from hell, if you don't setup the catalog the jdbc
 driver returns a huge number of tables (50k on some installations?) when
 you get the
 database metadata.
 We had issues with caching metadata at the content data store level, with
 the Oracle dialect not using prepared statements
 for metadata (pull request still open, I'm unable to find the time to
 review it, see here:
 https://github.com/geotools/geotools/pull/905), and likely something else
 that I don't remember.

 I would suggest to try trunk, with the above pull request applied, and see
 if it gets any better.


 2. Will this issue be avoided when using a JNDI connection pool?


 Not directly, but with JNDI you can setup a single connection pool and
 then setup N datastores, one for each
 of the catalogs you need to access.

 Investigations and patches welcomed too, we have a large disconnect
 between people using and complaining
 about Oracle and people actually doing something about it. The common
 wisdom is to just drop
 Oracle in favor of PostGIS, when one can (yes, I'm well aware that's often
 not an option).



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

[Geoserver-users] Issue with internal connection pooling for Oracle datastore with no schema name?

[Martin Davis]

We have the following GeoServer setup:

Datastore to an Oracle 12c Exadata instance
Internal connection pooling
No schema specified

We noticed a serious performance anomaly, where each layer was taking about
4 s to render, even when the data was very small.

When we switched to specifying an explicit schema in the Datastore config,
the performance got significantly faster, and the time to render individual
layers became more proportional to the query result size.

So the questions are:
1. does omitting a schema name in the Oracle Datastore config cause
connection pooling to be disabled or defeated?
2. Will this issue be avoided when using a JNDI connection pool?

If the answer to # 1 is yes, this should probably be highlighted in the
docs...
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Remove geometry from gml output WMS

[Martin Davis]

You might find this recent thread applicable:
http://osgeo-org.1560.x6.nabble.com/Reduce-Geometry-size-in-GetFeatureInfo-responses-td5210228.html

On Wed, Jun 17, 2015 at 3:23 PM, Leonardo Dobles hablecon...@gmail.com
wrote:

 HI

 Is there a way to remove geometry field from the gml output in the WMS
 getfeatureinfo method?


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

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

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?

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

Re: [Geoserver-users] Oracle View Problem

[Martin Davis]

Have you tried creating a spatial function-based index on the table?

http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_exten.htm#SPATL799

See the example 9.2.1 - it creates a function creating the geometry out of
the X,Y values, and then uses that for indexing and querying.  Hopefully
it's possible to define a view hiding the existence of the function, but
still using the spatial index.  In this case, GeoServer might be able to
query the view (using SDO_FILTER as per normal) and Oracle will support the
query since it can use the index.

Ironically, in my experience when working with tables containing XY data,
it's at least as fast to simply use normal B-tree indexes and range
queries.  However, it doesn't sound like this can be made to work in
GeoServer (yet...)



On Wed, May 13, 2015 at 7:10 AM, Alper Dinçer alperd@gmail.com wrote:

 Hi,

 We have a table that includes X and Y columns for latitude and longitudes.
 We created a view with geom column from this table as follows :

 (SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE (ST.Y, ST.X, NULL), NULL, NULL))

 Then we published this view from GeoServer and try to get the WMS request.

 The WMS request has following error :

 ?xml version=1.0 encoding=UTF-8 standalone=no?!DOCTYPE
 ServiceExceptionReport SYSTEM 
 http://172.16.1.139:8084/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd;
 ServiceExceptionReport version=1.1.1ServiceException
 code=internalError
   Rendering process failed
 java.io.IOExceptionORA-13226: interface not supported without a spatial
 index
 ORA-06512: at quot;MDSYS.MDquot;, line 1723
 ORA-06512: at quot;MDSYS.MDERRquot;, line 8
 ORA-06512: at quot;MDSYS.SDO_3GLquot;, line 88

 /ServiceException/ServiceExceptionReport

 As far as I searched, this was a problem in Oracle 9, but we are working
 on 11g.

 How can we get rid of this error? There was no luck with creating spatial
 index on views.

 Best.

 A.



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Geoserver-users mailing list
 Geoserver-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Oracle View Problem

[Martin Davis]

Also see this page, which gives a good example of using the function-based
index technique:

http://gis.stackexchange.com/questions/92554/can-i-create-an-oracle-spatial-view-from-a-non-spatial-table

That page also mentions the possiblity of defining a *materialized view* on
the underlying table, which should be able to support a spatial index
directly.


On Wed, May 13, 2015 at 9:27 AM, Martin Davis mtncl...@gmail.com wrote:

 Have you tried creating a spatial function-based index on the table?


 http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_exten.htm#SPATL799

 See the example 9.2.1 - it creates a function creating the geometry out of
 the X,Y values, and then uses that for indexing and querying.  Hopefully
 it's possible to define a view hiding the existence of the function, but
 still using the spatial index.  In this case, GeoServer might be able to
 query the view (using SDO_FILTER as per normal) and Oracle will support the
 query since it can use the index.

 Ironically, in my experience when working with tables containing XY data,
 it's at least as fast to simply use normal B-tree indexes and range
 queries.  However, it doesn't sound like this can be made to work in
 GeoServer (yet...)



 On Wed, May 13, 2015 at 7:10 AM, Alper Dinçer alperd@gmail.com
 wrote:

 Hi,

 We have a table that includes X and Y columns for latitude and
 longitudes. We created a view with geom column from this table as follows :

 (SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE (ST.Y, ST.X, NULL), NULL, NULL))

 Then we published this view from GeoServer and try to get the WMS
 request.

 The WMS request has following error :

 ?xml version=1.0 encoding=UTF-8 standalone=no?!DOCTYPE
 ServiceExceptionReport SYSTEM 
 http://172.16.1.139:8084/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd;
 ServiceExceptionReport version=1.1.1ServiceException
 code=internalError
   Rendering process failed
 java.io.IOExceptionORA-13226: interface not supported without a spatial
 index
 ORA-06512: at quot;MDSYS.MDquot;, line 1723
 ORA-06512: at quot;MDSYS.MDERRquot;, line 8
 ORA-06512: at quot;MDSYS.SDO_3GLquot;, line 88

 /ServiceException/ServiceExceptionReport

 As far as I searched, this was a problem in Oracle 9, but we are working
 on 11g.

 How can we get rid of this error? There was no luck with creating spatial
 index on views.



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Questions about layer naming

[Martin Davis]

Great, that's very complete.

This could be added as a note in the section

http://docs.geoserver.org/stable/en/user/webadmin/data/layers.html#basic-info

...  as soon as this is merged:

https://github.com/geoserver/geoserver/pull/1025

On Sat, Apr 25, 2015 at 2:08 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Fri, Apr 24, 2015 at 9:42 PM, Martin Davis mtncl...@gmail.com wrote:

 Ok, how about:

 Names must be compatible with their use in OWS service requests and
 response documents.  For general use, consider using only the
 characters: upper and lowercase letters, numbers, dash, underscore and
 period.  Spaces can be present, but will need to be escaped in URLs.

 The wording consider using is meant to indicate this is only a
 suggestion to avoid possible pain, not a validation rule.


 Let me try a (longer) variation, removing spaces from the general rule as
 they are not valid for WFS/WCS 2.0


 
 Different OGC protocol have different requirements on layer names.
 If you want a single rule that will make layer names across protocols, use
 only upper and lowercase letters, numbers, dash, underscore and period,
 and make sure the name starts with a letter.

 If instead you're interested in using only a subset of the protocols, here
 is a summary:
 * WCS 1.0, 1.1 and WMS pose no limit whatsoever on the layer names, which
 can contain pretty much any character
 * WFS (all versions) and WCS 2.0 require the layer name you give to
 GeoServer to be an NCName, that is, a non colonized name. A NCName cannot
 contain several symbol characters like colon, @, $, %, , /, +, comma,
 semicolon, whitespace characters or different parenthesis. Furthermore an
 NCName cannot begin with a number, dot or minus character although they can
 appear later in an NCName.

 

 Cheers
 Andrea


 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Questions about layer naming

[Martin Davis]

Roger that.  How about:

Names must be compatible with their use in OWS service requests and
response documents. In particular, they must not contain spaces.  For
general use, it is best if they use only the following characters: upper
and lowercase letters, numbers, dash, underscore and period.

(I realized that semicolons probably cause issues in some situations - for
instance, when workspaces are used)

On Thu, Apr 23, 2015 at 11:14 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Thu, Apr 23, 2015 at 9:47 PM, Martin Davis mtncl...@gmail.com wrote:

 Thanks.  I found this discussion:
 http://osgeo-org.1560.x6.nabble.com/Layer-and-store-names-td5167890.html

 TL;DR - spaces should not be used, and preferably names should be valid
 XML tag names (defined here: http://www.w3.org/TR/xml/#NT-Name)

 I thought I might add this to the user guide...


 Please do so, but make sure to note that certain protocols (wms for
 example) have no restrictions whatsoever, and that what you're suggesting
 is just a way to ensure the name works across all protocols (which might
 not be a requirement, some people only use wms for example).

 People having externally mandated naming conventions might get really mad,
 or stop using GeoServer at all, if we start telling them to play within
 the confines of XML naming conventions, so let's be clear that the naming
 convention is just a suggestion.

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Questions about layer naming

[Martin Davis]

Great, all good advice. I was curious about the provenance of the
featuretype naming standard, so spelunked through the standards docs to get
the final word...  The WFS spec [1] says that a typename must be a XML
Qname, and the XML spec [2] says that a QName Name part must start with a
letter or underscore.

So now it could say:

Names must be compatible with their use in OWS service requests and
response documents.  Names must start with a letter or underscore. Spaces
can be present, but will need to be escaped in URLs. For general use,
consider using only the following characters: upper and lowercase letters,
numbers, dash, underscore and period.

[1] https://portal.opengeospatial.org/files/?artifact_id=8339
[2] http://www.w3.org/TR/REC-xml/#NT-NameStartChar

(Wouldn't it be great if the OGC specs were HTML...)

On Fri, Apr 24, 2015 at 10:36 AM, Rahkonen Jukka (MML) 
jukka.rahko...@maanmittauslaitos.fi wrote:

  Hi,


  Yes, spaces are allowed and they are very common in WMS services made
 with ESRI servers.

 I think that Geoserver users have had trouble with periods but I am not
 sure. Absolutely comma in a layer name has caused troubles, think about
 GetMap: layers=fine_idea,of_my_own.


  WFS is so common service and folks are publishing layers with both WMS
 and WFS that it might be good to especially mention that name of a
 featuretype must not (according to standard) begin with a number or
 underscore.


  Good test for ourselves would be to test sometimes what Geoserver
 accepts and what kind of escaping is needed

 - What we can cascade with WMS?

 - What we can cascade with WFS?


  Before you accuse me, have a look at yourself.


  -Jukka Rahkonen-




  --
 Andrea Aime wrote:

   On Fri, Apr 24, 2015 at 4:49 PM, Martin Davis mtncl...@gmail.com
 wrote:

 Roger that.  How about:

  Names must be compatible with their use in OWS service requests and
 response documents. In particular, they must not contain spaces.  For
 general use, it is best if they use only the following characters: upper
 and lowercase letters, numbers, dash, underscore and period.


  As far as I know, spaces are also valid (in WMS), you just have to
 url-encode them when making requests

  Cheers
 Andrea


  --
 ==
  GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

  ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo

Re: [Geoserver-users] Questions about layer naming

[Martin Davis]

Ok, how about:

Names must be compatible with their use in OWS service requests and
response documents.  For general use, consider using only the characters:
upper and lowercase letters, numbers, dash, underscore and period.  Spaces
can be present, but will need to be escaped in URLs.

The wording consider using is meant to indicate this is only a suggestion
to avoid possible pain, not a validation rule.


On Fri, Apr 24, 2015 at 12:32 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Fri, Apr 24, 2015 at 7:55 PM, Martin Davis mtncl...@gmail.com wrote:

 Great, all good advice. I was curious about the provenance of the
 featuretype naming standard, so spelunked through the standards docs to get
 the final word...  The WFS spec [1] says that a typename must be a XML
 Qname, and the XML spec [2] says that a QName Name part must start with a
 letter or underscore.

 So now it could say:

 Names must be compatible with their use in OWS service requests and
 response documents.  Names must start with a letter or underscore. Spaces
 can be present, but will need to be escaped in URLs. For general use,
 consider using only the following characters: upper and lowercase letters,
 numbers, dash, underscore and period.


 Without qualifying that the above sentence is valid for WFS only, that
 sentence cannot be accepted in the user guide.
 A better approach is to list the limits imposed by all standards and
 version (WCS versions different greatly between one and the next for
 example), and then you can provide a guidance for naming that would be
 valid for all standards.

 I hate repeating myself, but just a few mails ago I wrote:
 People having externally mandated naming conventions might get really
 mad, or stop using GeoServer at all, if we start telling them to play within
 the confines of XML naming conventions, so let's be clear that the naming
 convention is just a suggestion.

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Questions about layer naming

[Martin Davis]

Is there any standard or best practice for the valid charset used for layer
names?  E.g. it seems like using URL-significant chars is not a good idea
(comma, semicolon, amp, etc).

If a layer is renamed from the default name (ie. the store resource name),
is there any way in the UI to know what the name of the underlying resource
is?
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Questions about layer naming

[Martin Davis]

Thanks.  I found this discussion:
http://osgeo-org.1560.x6.nabble.com/Layer-and-store-names-td5167890.html

TL;DR - spaces should not be used, and preferably names should be valid XML
tag names (defined here: http://www.w3.org/TR/xml/#NT-Name)

I thought I might add this to the user guide...

On Thu, Apr 23, 2015 at 10:13 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Thu, Apr 23, 2015 at 6:59 PM, Martin Davis mtncl...@gmail.com wrote:

 Is there any standard or best practice for the valid charset used for
 layer names?  E.g. it seems like using URL-significant chars is not a good
 idea (comma, semicolon, amp, etc).

 If a layer is renamed from the default name (ie. the store resource
 name), is there any way in the UI to know what the name of the underlying
 resource is?


 Check the geoserver-devel archives, we had multiple discussons on the
 topic, what's valid for one standard is not valid for the other and so on.
 GeoServer poses no limitation, you're free to hang yourself (but also to
 respect naming standards that would be forbidden if we picked the
 minimum common denominator).

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Publish a table as two separate layers?

[Martin Davis]

What is the best way to publish a single table as two separate layers?
Does this required defining a SQL View for one of the layers?  It seems
like the UI only allows publishing a table as a single layer via the
Publish mechanism.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Publish a table as two separate layers?

[Martin Davis]

Thanks - I just discovered this thread giving the same advice:

http://osgeo-org.1560.x6.nabble.com/Using-two-different-FreeMarker-templates-with-the-same-PostGIS-layer-td4914758.html

This wasn't obvious to me from the UI... is it documented in the User Guide?

On Wed, Apr 22, 2015 at 9:36 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Wed, Apr 22, 2015 at 6:23 PM, Martin Davis mtncl...@gmail.com wrote:

 What is the best way to publish a single table as two separate layers?
 Does this required defining a SQL View for one of the layers?  It seems
 like the UI only allows publishing a table as a single layer via the
 Publish mechanism.


 You can re-publish the same table with a different layer name, there is a
 publish again link the second time around.
 SQL views are useful if you want the two layers to have different contents
 (different filters in the sql view)

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Layer Data Name VS Layer Publishing Name?

[Martin Davis]

Another perhaps obvious question...  in the Edit Layer screen what is the
difference between the Name field on the Data tab and the Name field on the
Publishing tab?  Are these the same data item, just exposed in two
different places for convenience?
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Publish a table as two separate layers?

[Martin Davis]

No problem with the workflow knowing that it's possible to change the layer
name. It just would be nice to see a bit of advice about this on the screen
(a tooltip maybe - but I don't think any UI controls have tooltips?).

Agreed, that is the place in the docs for it.  I'll work on adding some doc
for this feature there.

On Wed, Apr 22, 2015 at 9:47 AM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Wed, Apr 22, 2015 at 6:43 PM, Martin Davis mtncl...@gmail.com wrote:

 Thanks - I just discovered this thread giving the same advice:


 http://osgeo-org.1560.x6.nabble.com/Using-two-different-FreeMarker-templates-with-the-same-PostGIS-layer-td4914758.html

 This wasn't obvious to me from the UI... is it documented in the User
 Guide?


 Probably not but you want to publish two times the same table,
 you try to do add layer two times...what would have you expected to see
 instead? :-)

 The doc page where I would have expected to find this would have been this
 one:

 http://docs.geoserver.org/2.6.x/en/user/webadmin/data/layers.html#add-or-delete-a-layer
 Want to make a pull request and add this bit?

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Layer Data Name VS Layer Publishing Name?

[Martin Davis]

Ah, and I notice that in 2.6 the Name field no longer appears on the
Publishing tab - so question is moot!  (Serves me right for not keeping
up...)

On Wed, Apr 22, 2015 at 10:50 AM, Jody Garnett jody.garn...@gmail.com
wrote:

 Internally we have a split between resources (the data tab) and layers
 (the publish tab). In practice the two data structures have always been
 linked in the UI.

 I believe if you edit one it will update in both data structures.

 --
 Jody Garnett

 On 22 April 2015 at 10:03, Martin Davis mtncl...@gmail.com wrote:

 Another perhaps obvious question...  in the Edit Layer screen what is the
 difference between the Name field on the Data tab and the Name field on the
 Publishing tab?  Are these the same data item, just exposed in two
 different places for convenience?


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Geoserver-users mailing list
 Geoserver-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-users



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

In it's useful for anyone, attached is a small test program that
demonstrates the performance issue with computing statistics for SDE layers
with spatial filters.



On Thu, Apr 2, 2015 at 10:47 AM, Martin Davis mtncl...@gmail.com wrote:

 I've now identified the problem causing the slow WFS performance.  As
 Andrea suspected, it is in the ArcSDEQuery.calculateResultCount() method,
 called before the WFS query queries the data.  The issue is that (on our
 Oracle SDE instance at least) the SeQuery.calculateTableStatistics() call
 is extremely slow (likely it is doing a full table scan rather than using
 the spatial index).

 This shows up very obviously in our case, since we have a layer with 11M
 features in it. But it's impacting performance for every WFS query (even
 scans of small tables seem to be much slower than the actual data
 retrieval).  (This actually makes me wonder if the SDE API is pulling the
 data over the wire to count it!).

 Here's the actual stats from a test mockup:

 Testing layer MTA_SPATIAL.MTA_MINERAL_PLACER_GRID_POLY
 Fetching table stats...
 Row count = 1560    955.04 s
 Querying data...
 Row count = 1560    2.052 s

 We're going to open a ticket with ESRI about this, but I don't have much
 optimism they'll do anything for us (given that the SDE API is sunsetting).

 So what are the options on the GeoServer side?  It might be always faster
 to simply run the query twice, once to count and once for the data.  In
 fact, there is already code in the calculateResultCount to do this, for
 Oracle versioned layers. Perhaps this should be extended for *all* Oracle
 layers? (Note that I still think there may be a bug in this code to do with
 the order of API calls, but that can be fixed at the same time).

 Thoughts?

 In the meantime I am going to work on modifying the driver to test out
 this idea (and we may just use that in production if it works out anyway).

 On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime 
 andrea.a...@geo-solutions.it wrote




 So the question is: does the WMS path through the SDE driver result in a
 different statement order than the WFS path?  And if so, how can this be
 fixed?


 Hum... it may be, but a store is just a store, and
 featureSource.getFeatures(Query) is the same method.
 Maybe the contents of Query are different and this triggers a different
 code path in the store?
 One likely difference is that WFS (depending on your config and WFS
 version used) needs to perform a count before getting
 the actual data (part of the response headers), WMS does not.





TableStatsTest.java
Description: Binary data
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

I have implemented a workaround for the performance issue with computing
request size in SDE on Oracle.  It's here:

https://github.com/dr-jts/geotools/commit/eef7056e899660f34447f38e5b83c1c38666ff19

This has been tested in several environments and seems to work correctly in
all of them.

(Note: the workaround is currently active for Oracle only, since that's the
only SDE environment I can test.  The issue might exist on other DBs as
well).

Will try and create issues for this when I can (Issue tracker seems to be
in flux right now?).  I can make a pull request as well if that's
acceptable now.

On Thu, Apr 2, 2015 at 10:47 AM, Martin Davis mtncl...@gmail.com wrote:

 I've now identified the problem causing the slow WFS performance.  As
 Andrea suspected, it is in the ArcSDEQuery.calculateResultCount() method,
 called before the WFS query queries the data.  The issue is that (on our
 Oracle SDE instance at least) the SeQuery.calculateTableStatistics() call
 is extremely slow (likely it is doing a full table scan rather than using
 the spatial index).

 This shows up very obviously in our case, since we have a layer with 11M
 features in it. But it's impacting performance for every WFS query (even
 scans of small tables seem to be much slower than the actual data
 retrieval).  (This actually makes me wonder if the SDE API is pulling the
 data over the wire to count it!).

 Here's the actual stats from a test mockup:

 Testing layer MTA_SPATIAL.MTA_MINERAL_PLACER_GRID_POLY
 Fetching table stats...
 Row count = 1560    955.04 s
 Querying data...
 Row count = 1560    2.052 s

 We're going to open a ticket with ESRI about this, but I don't have much
 optimism they'll do anything for us (given that the SDE API is sunsetting).

 So what are the options on the GeoServer side?  It might be always faster
 to simply run the query twice, once to count and once for the data.  In
 fact, there is already code in the calculateResultCount to do this, for
 Oracle versioned layers. Perhaps this should be extended for *all* Oracle
 layers? (Note that I still think there may be a bug in this code to do with
 the order of API calls, but that can be fixed at the same time).

 Thoughts?

 In the meantime I am going to work on modifying the driver to test out
 this idea (and we may just use that in production if it works out anyway).

 On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime 
 andrea.a...@geo-solutions.it wrote




 So the question is: does the WMS path through the SDE driver result in a
 different statement order than the WFS path?  And if so, how can this be
 fixed?


 Hum... it may be, but a store is just a store, and
 featureSource.getFeatures(Query) is the same method.
 Maybe the contents of Query are different and this triggers a different
 code path in the store?
 One likely difference is that WFS (depending on your config and WFS
 version used) needs to perform a count before getting
 the actual data (part of the response headers), WMS does not.



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

On Thu, Apr 2, 2015 at 11:51 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Thu, Apr 2, 2015 at 7:47 PM, Martin Davis mtncl...@gmail.com wrote:

 I've now identified the problem causing the slow WFS performance.  As
 Andrea suspected, it is in the ArcSDEQuery.calculateResultCount() method,
 called before the WFS query queries the data.  The issue is that (on our
 Oracle SDE instance at least) the SeQuery.calculateTableStatistics() call
 is extremely slow (likely it is doing a full table scan rather than using
 the spatial index).

 This shows up very obviously in our case, since we have a layer with 11M
 features in it. But it's impacting performance for every WFS query (even
 scans of small tables seem to be much slower than the actual data
 retrieval).  (This actually makes me wonder if the SDE API is pulling the
 data over the wire to count it!).

 Here's the actual stats from a test mockup:

 Testing layer MTA_SPATIAL.MTA_MINERAL_PLACER_GRID_POLY
 Fetching table stats...
 Row count = 1560    955.04 s
 Querying data...
 Row count = 1560    2.052 s


 Wow... gross :-)
 At that point you can indeed fetch all the data, maybe telling SDE that
 you only want one small column (to reduce data transfer)


Nope, have to include the geometry column, in order to be able to run the
spatial query (the SDE API requires the geometry column to be specified).




 We're going to open a ticket with ESRI about this, but I don't have much
 optimism they'll do anything for us (given that the SDE API is sunsetting).

 So what are the options on the GeoServer side?  It might be always faster
 to simply run the query twice, once to count and once for the data.  In
 fact, there is already code in the calculateResultCount to do this, for
 Oracle versioned layers. Perhaps this should be extended for *all* Oracle
 layers? (Note that I still think there may be a bug in this code to do with
 the order of API calls, but that can be fixed at the same time).


 Could be but.. I'm honestly blown away that this would be the way to go...
 if it is, maybe we should add some flag to control it?
 Or is it just going to always be slower to try get the stats?


If the API is indeed doing a client-side evaluation of the spatial filter,
then the stats are always going to be no faster than the query (and a LOT
slower for a highly selective query).  I tested against three tables with
very different datasets (with 10s, 1000s and Ms of records), and the stats
call was always slower than the actual query.

If this IS the case, then it doesn't seem like there's much point to a
flag, since every query with a spatial filter should use the query twice
strategy for best performance?

I don't know if this is the case on non-Oracle databases, so it might be
worth limiting this code path to only Oracle (for now - easy to extend to
other DBs if their drivers are found to have the same behaviour).

Also, we were orginally testing using the 9.3 JARs, against a 10.2 SDE.
Today have verified that the 10.1 JARs have the same issue.



 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

I've now identified the problem causing the slow WFS performance.  As
Andrea suspected, it is in the ArcSDEQuery.calculateResultCount() method,
called before the WFS query queries the data.  The issue is that (on our
Oracle SDE instance at least) the SeQuery.calculateTableStatistics() call
is extremely slow (likely it is doing a full table scan rather than using
the spatial index).

This shows up very obviously in our case, since we have a layer with 11M
features in it. But it's impacting performance for every WFS query (even
scans of small tables seem to be much slower than the actual data
retrieval).  (This actually makes me wonder if the SDE API is pulling the
data over the wire to count it!).

Here's the actual stats from a test mockup:

Testing layer MTA_SPATIAL.MTA_MINERAL_PLACER_GRID_POLY
Fetching table stats...
Row count = 1560    955.04 s
Querying data...
Row count = 1560    2.052 s

We're going to open a ticket with ESRI about this, but I don't have much
optimism they'll do anything for us (given that the SDE API is sunsetting).

So what are the options on the GeoServer side?  It might be always faster
to simply run the query twice, once to count and once for the data.  In
fact, there is already code in the calculateResultCount to do this, for
Oracle versioned layers. Perhaps this should be extended for *all* Oracle
layers? (Note that I still think there may be a bug in this code to do with
the order of API calls, but that can be fixed at the same time).

Thoughts?

In the meantime I am going to work on modifying the driver to test out this
idea (and we may just use that in production if it works out anyway).

On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote




 So the question is: does the WMS path through the SDE driver result in a
 different statement order than the WFS path?  And if so, how can this be
 fixed?


 Hum... it may be, but a store is just a store, and
 featureSource.getFeatures(Query) is the same method.
 Maybe the contents of Query are different and this triggers a different
 code path in the store?
 One likely difference is that WFS (depending on your config and WFS
 version used) needs to perform a count before getting
 the actual data (part of the response headers), WMS does not.



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

Argh...  that code snippet for the CORRECT use of spatial constraints
should read:

  query = new SeQuery(conn, columns, construct);
  query.prepareQuery();
  query.setSpatialConstraints(...);

And agreed, it seems like it's unlikely that WFS alone uses a different
call order.  As you say, it may be that the query is being formulated in a
different way (e.g. perhaps the WFS BBOX filter is not correctly converted
to an ArcSDE spatial constraint - although it seems likely that WMS also
uses a BBOX filter).

If a count is needed (yuck!) then I would hope that the same query is used
as to retrieve the actual data - and then they should be be fast if the
query uses the spatial constraint correctly.  But there is a bunch of logic
in the ArcSDE code around counts, so perhaps something else is going on.

Gabriel, if you have ideas it would be great to hear them.  Also, I'm very
close to having a debug GeoServer environment up and running, so I will be
able to see what's going on.




On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:

 On Tue, Mar 31, 2015 at 10:48 PM, Martin Davis mtncl...@gmail.com wrote:

 An update on this issue, which I think identifies the source of the
 problem with the slow WFS query.

 After experimenting with using the SDE Java API against the troublesome
 table, I found that the order of API calls is very important.   You might
 expect that the API calls should look like this:

   query = new SeQuery(conn, columns, construct);
   query.setSpatialConstraints(...)
   query.prepareQuery();

 There's nothing in the API docs to suggest otherwise.  However, this
 results in the very slow query performance (I suspect the prepareQuery
 wipes out the spatial filter, resulting in a full table scan being
 performed).

 If the statement order is the following, then the query completes very
 fast (indicating the spatial index is now being used):

   query = new SeQuery(conn, columns, construct);
   query.setSpatialConstraints(...)
   query.prepareQuery();


 Confused, where is the difference? :-)



 So the question is: does the WMS path through the SDE driver result in a
 different statement order than the WFS path?  And if so, how can this be
 fixed?


 Hum... it may be, but a store is just a store, and
 featureSource.getFeatures(Query) is the same method.
 Maybe the contents of Query are different and this triggers a different
 code path in the store?
 One likely difference is that WFS (depending on your config and WFS
 version used) needs to perform a count before getting
 the actual data (part of the response headers), WMS does not.

 CC'ing Gabriel, he's the last one to have worked on the SDE store.


 Cheers
 Andrea


 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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.

 ---

--
Dive into the World of Parallel Programming The Go

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

Hmmm...  in ArcSDEQuery.calculateResultCount() start at line 615 I see:

[1] 615:  query.setSpatialConstraints(searchOrder, calcMasks,
spatialFilters);

and then a few lines later in a code path that is executed only if the SDE
instance is versioned and backed by Oracle:

[2] 631: query.prepareQueryInfo(queryInfo);

So that looks to me like the resultCount logic may be using the incorrect
order of calls to the SDE API.  Our setup definitely uses Oracle, and the
SDE layer may be versioned, so perhaps we're triggering this path.  The
good news is that the fix should be easy - just copy the call to
setSpatialConstraints inside the path and put it after the
prepareQueryInfo.  I will try and verify this.


[1]
https://github.com/geotools/geotools/blob/master/modules/plugin/arcsde/datastore/src/main/java/org/geotools/arcsde/data/ArcSDEQuery.java#L615
[2]
https://github.com/geotools/geotools/blob/master/modules/plugin/arcsde/datastore/src/main/java/org/geotools/arcsde/data/ArcSDEQuery.java#L631

On Wed, Apr 1, 2015 at 8:47 AM, Martin Davis mtncl...@gmail.com wrote:

 Argh...  that code snippet for the CORRECT use of spatial constraints
 should read:

   query = new SeQuery(conn, columns, construct);
   query.prepareQuery();
   query.setSpatialConstraints(...);

 And agreed, it seems like it's unlikely that WFS alone uses a different
 call order.  As you say, it may be that the query is being formulated in a
 different way (e.g. perhaps the WFS BBOX filter is not correctly converted
 to an ArcSDE spatial constraint - although it seems likely that WMS also
 uses a BBOX filter).

 If a count is needed (yuck!) then I would hope that the same query is used
 as to retrieve the actual data - and then they should be be fast if the
 query uses the spatial constraint correctly.  But there is a bunch of logic
 in the ArcSDE code around counts, so perhaps something else is going on.

 Gabriel, if you have ideas it would be great to hear them.  Also, I'm very
 close to having a debug GeoServer environment up and running, so I will be
 able to see what's going on.




 On Tue, Mar 31, 2015 at 11:12 PM, Andrea Aime 
 andrea.a...@geo-solutions.it wrote:

 On Tue, Mar 31, 2015 at 10:48 PM, Martin Davis mtncl...@gmail.com
 wrote:

 An update on this issue, which I think identifies the source of the
 problem with the slow WFS query.

 After experimenting with using the SDE Java API against the troublesome
 table, I found that the order of API calls is very important.   You might
 expect that the API calls should look like this:

   query = new SeQuery(conn, columns, construct);
   query.setSpatialConstraints(...)
   query.prepareQuery();

 There's nothing in the API docs to suggest otherwise.  However, this
 results in the very slow query performance (I suspect the prepareQuery
 wipes out the spatial filter, resulting in a full table scan being
 performed).

 If the statement order is the following, then the query completes very
 fast (indicating the spatial index is now being used):

   query = new SeQuery(conn, columns, construct);
   query.setSpatialConstraints(...)
   query.prepareQuery();


 Confused, where is the difference? :-)



 So the question is: does the WMS path through the SDE driver result in a
 different statement order than the WFS path?  And if so, how can this be
 fixed?


 Hum... it may be, but a store is just a store, and
 featureSource.getFeatures(Query) is the same method.
 Maybe the contents of Query are different and this triggers a different
 code path in the store?
 One likely difference is that WFS (depending on your config and WFS
 version used) needs to perform a count before getting
 the actual data (part of the response headers), WMS does not.

 CC'ing Gabriel, he's the last one to have worked on the SDE store.


 Cheers
 Andrea


 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/NWWaa2 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

Re: [Geoserver-users] Slow WFS query against SDE?

[Martin Davis]

An update on this issue, which I think identifies the source of the problem
with the slow WFS query.

After experimenting with using the SDE Java API against the troublesome
table, I found that the order of API calls is very important.   You might
expect that the API calls should look like this:

  query = new SeQuery(conn, columns, construct);
  query.setSpatialConstraints(...)
  query.prepareQuery();

There's nothing in the API docs to suggest otherwise.  However, this
results in the very slow query performance (I suspect the prepareQuery
wipes out the spatial filter, resulting in a full table scan being
performed).

If the statement order is the following, then the query completes very fast
(indicating the spatial index is now being used):

  query = new SeQuery(conn, columns, construct);
  query.setSpatialConstraints(...)
  query.prepareQuery();

So the question is: does the WMS path through the SDE driver result in a
different statement order than the WFS path?  And if so, how can this be
fixed?


On Tue, Mar 17, 2015 at 9:50 AM, Martin Davis mtncl...@gmail.com wrote:

 We have a GeoServer 2.6.0 connected to an SDE 10.2 backed by Oracle 11g.
 One layer is a grid layer with about 10M rectangles in it.  WMS peformance
 against this layer is fine (a few seconds to draw about 100 features).
 However, WFS queries against the layer are VERY slow (many minutes to
 return even just 1 feature).  This is for both queries using a BBOX and for
 raw queries using only a MAXFEATURES parameter (even with a very low
 setting - e.g MAXFEATURES=1)

 WFS queries against other SDE layers in the same instance are somewhat
 faster, but the layers have much less data, so it's possible that they are
 also impacted by the issue.

 Are there any known issues that might cause GeoServer SDE WFS queries to
 be very slow?

 (As an aside, the log shows the SDE driver reloading the type name cache
 every 60 secs.  This seems a bit aggressive...  and the value is hard-coded
 in the driver.  Is this part of the issue?)

 A log snippet showing the problem ( I think the final Axis length
 mismatch indicates the query finally completing):

 2015-03-17 09:20:10,077 INFO [org.geoserver.wfs] -
 Request: getServiceInfo
 2015-03-17 09:20:10,087 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Creating new ArcSDEQuery
 2015-03-17 09:20:10,087 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] - SQL
 portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:10,087 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Spatial-Filter portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:10,087 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Unsupported (and therefore ignored) portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:16,091 INFO [org.geoserver.wfs] -
 Request: getFeature
 service = WFS
 version = 1.1.0
 baseUrl = https://i1geo.nrs.bcgov:443/geoserver/
 query[0]:
 srsName = EPSG:3857
 typeName[0] = {http://gov.bc.ca/nrs}MTA_MINERAL_PLACER_GRID_POLY
 maxFeatures = 5
 outputFormat = application/json
 resultType = results
 2015-03-17 09:20:16,094 INFO [org.geoserver.wfs.json] - about to encode
 JSON
 2015-03-17 09:20:16,096 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Creating new ArcSDEQuery
 2015-03-17 09:20:16,096 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] - SQL
 portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:16,096 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Spatial-Filter portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:16,096 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Unsupported (and therefore ignored) portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:20,547 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Creating new ArcSDEQuery
 2015-03-17 09:20:20,547 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] - SQL
 portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:20,547 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Spatial-Filter portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:20,548 DEBUG [org.geotools.arcsde.data.ArcSDEQuery] -
 Unsupported (and therefore ignored) portion of SDE Query: 'Filter.INCLUDE'
 2015-03-17 09:20:28,467 DEBUG [org.geotools.arcsde.data] -
 FeatureTypeCache background process running...
 2015-03-17 09:20:34,038 DEBUG [org.geotools.arcsde.data] - Ignoring ArcSDE
 registered table SDE.GDB_TABLES_LAST_MODIFIED as it has no row id column
 2015-03-17 09:20:34,040 DEBUG [org.geotools.arcsde.data] - Finished
 updated type name cache
 2015-03-17 09:21:34,040 DEBUG [org.geotools.arcsde.data] -
 FeatureTypeCache background process running...
 2015-03-17 09:21:39,816 DEBUG [org.geotools.arcsde.data] - Ignoring ArcSDE
 registered table SDE.GDB_TABLES_LAST_MODIFIED as it has no row id column
 2015-03-17 09:21:39,818 DEBUG [org.geotools.arcsde.data] - Finished
 updated type name cache
 2015-03-17 09:22:39,819 DEBUG [org.geotools.arcsde.data] -
 FeatureTypeCache background process running...
 2015-03-17 09:22:45,405 DEBUG