Re: [Geoserver-users] Problem with SLD PointPlacement Displacement not working
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
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
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
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
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)
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&entry=gmail&source=g> >>> 55054 Massarosa >>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa&entry=gmail&source=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)
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&entry=gmail&source=g> >> 55054 Massarosa >> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa&entry=gmail&source=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)
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&entry=gmail&source=g> >>> 55054 Massarosa >>> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa&entry=gmail&source=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)
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&entry=gmail&source=g> >> 55054 Massarosa >> <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa&entry=gmail&source=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)
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&entry=gmail&source=g> > 55054 Massarosa > <https://maps.google.com/?q=Via+di+Montramito+3/A+55054+%C2%A0Massarosa&entry=gmail&source=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
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
>>>
>>>
>>>
>>>
>>> xclass
>>> Undefined
>>>
>>>
[Geoserver-users] How to fix Error: Tile Layers out of synch ?
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)
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 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 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&VERSION=1.1.1&REQU >> EST=getlegendgraphic&FORMAT=image/png&layer=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.NativeMethodAccessorImpl.invoke0(Native
[Geoserver-users] Error in GelLegendGraphic against an Oracle POINT table (class [B is not supported)
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&VERSION=1.1.1&REQUEST=getlegendgraphic&FORMAT=image/png&layer=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(DelegatingMe
[Geoserver-users] Geoserver as a raster overlay engine?
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?
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 > *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 > wrote: > >> On Wed, Oct 18, 2017 at 6:09 PM, Martin Davis 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?
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 wrote: > On Wed, Oct 18, 2017 at 6:09 PM, Martin Davis 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?
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 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?
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 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 >> 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&version=2.0. >>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1& >>> startindex=0 >>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0. >>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1& >>> startindex=1 >>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0. >>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=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 >>>> wrote: >>>> >>>> Martin, >>>> >>>>> >>>>> try Settings / Global / Number of decimals. This works for GML 2
Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?
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 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&version=2.0. > 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1& > startindex=0 > http://localhost:8080/geoserver/wfs?service=WFS&version=2.0. > 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1& > startindex=1 > http://localhost:8080/geoserver/wfs?service=WFS&version=2.0. > 0&request=GetFeature&typenames=topp:states&outputformat=json&count=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 >> 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&version=2.0. >>> 0&request=GetFeature&typenames=topp:states&propertyname=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
Re: [Geoserver-users] Reduce precision of WFS output to decrease response size?
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 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&version=2.0. > 0&request=GetFeature&typenames=topp:states&propertyname=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 > 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?
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 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?
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?
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?
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 ?
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 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
[Geoserver-users] How to use REST to create a coverage from a TIF file with no explicit SRS ?
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?
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 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?
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
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
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 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 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
Re: [Geoserver-users] Legend issue - blank entries for label rules
Ok... at least this confirms this is known behaviour, not something we're missing. On Thu, Feb 23, 2017 at 10:24 AM, Andrea Aime wrote: > On Thu, Feb 23, 2017 at 7:12 PM, Martin Davis wrote: > >> 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? >> > > Yep: https://github.com/geoserver/geoserver/blob/master/CONTRIBUTING.md > > >> This behaviour actuall seems a bit useless, so perhaps it could be >> prevented in the code? >> > > Agreed it should > > 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
Re: [Geoserver-users] Legend issue - multiple symbols for cased lines
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 wrote: > On Thu, Feb 23, 2017 at 7:19 PM, Martin Davis 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
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
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?
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?
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 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?
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?
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 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 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?
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?
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 wrote: > On Thu, Dec 8, 2016 at 7:52 PM, Martin Davis 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?
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
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?
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&T Tech Expo July 15-16. Meet us at AT&T 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
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&iu=/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&iu=/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?
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 : > >> 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&iu=/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
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 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 : > >> 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&iu=/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
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&iu=/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?
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 : > >> 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&iu=/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?
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&iu=/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
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 wrote: > On Tue, Feb 16, 2016 at 6:10 PM, Martin Davis 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&iu=/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
Thanks for the advice - and for the warning. Sigh On Tue, Feb 16, 2016 at 9:35 AM, Andrea Aime wrote: > On Tue, Feb 16, 2016 at 6:10 PM, Martin Davis 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&iu=/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
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 wrote: > On Tue, Feb 16, 2016 at 12:05 AM, Martin Davis 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&iu=/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
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&iu=/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
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&iu=/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
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&iu=/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.
+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&iu=/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 ?
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 wrote: > On Tue, Nov 24, 2015 at 6:52 PM, Martin Davis 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&iu=/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 ?
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 wrote: > On Mon, Nov 23, 2015 at 11:03 PM, Martin Davis 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&iu=/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 ?
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&iu=/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
+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
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 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 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
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?
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 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 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?
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?
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
wrote:
> On Wed, Sep 2, 2015 at 1:21 AM, Martin Davis 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&iu=/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 ?
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
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&iu=/4140___
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?
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 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 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?
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 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 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 >> 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 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 >>>> 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?
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 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 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 >> 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?
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 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] Native Oracle JDBC logging in GeoServer ?
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] Schemaless WFS spatial queries in GeoServer ?
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 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 > . - 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 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
[Geoserver-users] Schemaless WFS spatial queries in GeoServer ?
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] Performance issue with large polygon
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 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?
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 wrote: > On Thu, Jul 30, 2015 at 7:56 PM, Martin Davis 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?
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
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 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?
All good advice, but unfortunately not so easy to take advantage of in our environment. We allow all visible layers to be queried. This is why we prefer GetFeatureInfo to WFS, since it's sensitive to scale limits. The propertynames option is one way to do this, but we have hundreds of layers, so this would involve a large amount of client-side configuration. And that configuration is brittle - we don't totally control the map servers, and if a property name changes then the request will fail (I think...) A new vendor option of "geometry=none|bbox" would work well for us, since it offers maximum flexibility for minimum configuration. ESRI sometimes has good ideas 8^) On Wed, Jun 10, 2015 at 2:44 PM, Phil Scadden wrote: > > > I would say take a leaf from ESRI REST services and add > > ReturnGeometry=true/false to getFeatureInfo would be a good extension to > > the WMS format. If you dont really need to execute against multiple > > layers, then consider using WFS getFeature instead where you can specify > > propertynames. ( My maps have the concept of "active layer" for use in > > all searching, hover controls etc.) > Actually, I see that propertynames (exclude the shape from list) is a > geoserver vendor option for single layer getFeatureInfo. If using OL, > you would need to make sure that is in the options parameter for the > control, rather than using the propertyNames parameter of the > getFeatureInfo control (which filters the fields AFTER the call). > returnGeometry=true/false would be a better extension however because it > would with multiple layers. > > -- > Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St, > Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 > 5232 > > Notice: This email and any attachments are confidential. > If received in error please destroy and immediately notify us. > Do not copy or disclose the contents. > > > > -- > ___ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users > -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
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?
Thanks. That's pretty much what I expected to hear. The vendor option idea sounds good, particularly for the none|bbox options. Agreed that the simplify option would also require a tolerance value. On further thought I'm not sure this would provide an effect that is all that useful, since it's so tied to view map scale. We'll have to weigh the cost of a code enhancement versus the pain of other options... On Wed, Jun 10, 2015 at 10:57 AM, Andrea Aime wrote: > On Wed, Jun 10, 2015 at 7:41 PM, Martin Davis wrote: > >> We're looking for ways to improve performance of Identify operations in a >> web map client (using OpenLayers). We are seeing poor performance due to >> the network latency of retrieving large GetFeatureInfo reponses. Is there >> any way to reduce the size of geometries returned in GetFeatureInfo >> responses? >> >> In order of decreasing preference, things that might work for us include: >> >> 1. simplify the geometry >> 2. provide only the bounding box rather than full geometry >> 3. eliminate the geometry entirely >> >> Does the WMS vendor parameter propertyName [1] allow removing the >> geometry from the response? In any case this isn't ideal for us, because >> we'd prefer to not have to specify the required properties explicitly. >> >> > Yeah, you can get whatever property you want, but you have to list > explicitly the ones you require > > >> The #2 option of returning only BBOX would be ideal - is that possible? >> > > Not without changing the code, I guess you could roll a new vendor option, > e.g., &geometry=none|bbox|standard > Simplifying would require yet another param to specify how much to > simplify it. > > > -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
I should add that it's probably not feasible to use FreeMarker templates, since we have a lot of layers defined, and in some cases we don't have the ability to modify the server configuration. Also, we also want to be able to retrieve the geometry via GetFeatureInfo in some situations. Ideally there would be some kind of query parameter that could be added to control how the geometry is returned in the response. On Wed, Jun 10, 2015 at 10:41 AM, Martin Davis wrote: > We're looking for ways to improve performance of Identify operations in a > web map client (using OpenLayers). We are seeing poor performance due to > the network latency of retrieving large GetFeatureInfo reponses. Is there > any way to reduce the size of geometries returned in GetFeatureInfo > responses? > > In order of decreasing preference, things that might work for us include: > > 1. simplify the geometry > 2. provide only the bounding box rather than full geometry > 3. eliminate the geometry entirely > > Does the WMS vendor parameter propertyName [1] allow removing the geometry > from the response? In any case this isn't ideal for us, because we'd > prefer to not have to specify the required properties explicitly. > > The #2 option of returning only BBOX would be ideal - is that possible? > > > -- ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Reduce Geometry size in GetFeatureInfo responses?
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] Oracle View Problem
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 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 > 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 : >> >> > ServiceExceptionReport SYSTEM " >> http://172.16.1.139:8084/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd";> >>> code="internalError"> >> Rendering process failed >> java.io.IOExceptionORA-13226: interface not supported without a spatial >> index >> ORA-06512: at "MDSYS.MD", line 1723 >> ORA-06512: at "MDSYS.MDERR", line 8 >> ORA-06512: at "MDSYS.SDO_3GL", line 88 >> >> >> >> 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] Oracle View Problem
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 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 : > > ServiceExceptionReport SYSTEM " > http://172.16.1.139:8084/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd";> > code="internalError"> > Rendering process failed > java.io.IOExceptionORA-13226: interface not supported without a spatial > index > ORA-06512: at "MDSYS.MD", line 1723 > ORA-06512: at "MDSYS.MDERR", line 8 > ORA-06512: at "MDSYS.SDO_3GL", line 88 > > > > 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] Questions about layer naming
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 wrote: > On Fri, Apr 24, 2015 at 9:42 PM, Martin Davis 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
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 wrote: > On Fri, Apr 24, 2015 at 7:55 PM, Martin Davis 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
Re: [Geoserver-users] Questions about layer naming
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 > 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 f
Re: [Geoserver-users] Questions about layer naming
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 wrote: > On Thu, Apr 23, 2015 at 9:47 PM, Martin Davis 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
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 wrote: > On Thu, Apr 23, 2015 at 6:59 PM, Martin Davis 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_15&utm_medium=email&utm_campaign=VA_SF___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] Questions about layer naming
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_15&utm_medium=email&utm_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?
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 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 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_15&utm_medium=email&utm_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_15&utm_medium=email&utm_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?
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_15&utm_medium=email&utm_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?
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 wrote: > On Wed, Apr 22, 2015 at 6:43 PM, Martin Davis 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_15&utm_medium=email&utm_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?
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 wrote: > On Wed, Apr 22, 2015 at 6:23 PM, Martin Davis 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_15&utm_medium=email&utm_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?
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_15&utm_medium=email&utm_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?
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 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_15&utm_medium=email&utm_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?
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 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_15&utm_medium=email&utm_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?
On Thu, Apr 2, 2015 at 11:51 PM, Andrea Aime wrote: > On Thu, Apr 2, 2015 at 7:47 PM, Martin Davis 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
Re: [Geoserver-users] Slow WFS query against SDE?
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 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
