Re: [Geoserver-users] DataSource not available after calling dispose() or before being set

[Ashley Mort via Geoserver-users]

Thanks Jody and Andrea.  I just saw these replies, sorry!  Here is my 
stacktrace.  I will try to work on making a bug report for this but I’ve never 
done that before.  Thanks again!


2021-04-25 20:59:48,271 INFO [geoserver.wms] -
Request: getMap
Angle = 0.0
BaseUrl = http://localhost:8080/geoserver/
Bbox = SRSEnvelope[-1.001875417E7 : 0.0, 1.001875416998E7 : 2.003750834E7]
BgColor = java.awt.Color[r=255,g=255,b=255]
Buffer = 0
Clip = null
CQLFilter = null
Crs = PROJCS["WGS84 / Google Mercator",
  GEOGCS["WGS 84",
DATUM["World Geodetic System 1984",
  SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],
  AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.017453292519943295],
AXIS["Longitude", EAST],
AXIS["Latitude", NORTH],
AUTHORITY["EPSG","4326"]],
  PROJECTION["Mercator_1SP"],
  PARAMETER["semi_minor", 6378137.0],
  PARAMETER["latitude_of_origin", 0.0],
  PARAMETER["central_meridian", 0.0],
  PARAMETER["scale_factor", 1.0],
  PARAMETER["false_easting", 0.0],
  PARAMETER["false_northing", 0.0],
  UNIT["m", 1.0],
  AXIS["x", EAST],
  AXIS["y", NORTH],
  AUTHORITY["EPSG","900913"]]
Elevation = []
Env = {}
Exceptions = SE_XML
FeatureId = null
FeatureVersion = null
Filter = null
Format = image/png8
FormatOptions = {}
Get = true
Height = 1024
Interpolations = []
Layers = [org.geoserver.wms.MapLayerInfo@fd1f8f6a, 
org.geoserver.wms.MapLayerInfo@676c50cf,
 
org.geoserver.wms.MapLayerInfo@b491b3a5,
 
org.geoserver.wms.MapLayerInfo@1c7eb5aa,
 
org.geoserver.wms.MapLayerInfo@74aa2fae,
 
org.geoserver.wms.MapLayerInfo@e0cb40b6,
 
org.geoserver.wms.MapLayerInfo@c752a7b5,
 
org.geoserver.wms.MapLayerInfo@59780bd3,
 
org.geoserver.wms.MapLayerInfo@e44c2be1,
 
org.geoserver.wms.MapLayerInfo@8cacef37,
 
org.geoserver.wms.MapLayerInfo@254a57fd,
 
org.geoserver.wms.MapLayerInfo@58f17b08,
 
org.geoserver.wms.MapLayerInfo@648a2c70,
 
org.geoserver.wms.MapLayerInfo@642eaf18,
 
org.geoserver.wms.MapLayerInfo@5e69aee9,
 
org.geoserver.wms.MapLayerInfo@8671ba5f,
 
org.geoserver.wms.MapLayerInfo@9c6b8c6c,
 
org.geoserver.wms.MapLayerInfo@13da7cf0,
 
org.geoserver.wms.MapLayerInfo@249aad59,
 
org.geoserver.wms.MapLayerInfo@9532e2ce,
 
org.geoserver.wms.MapLayerInfo@9b657911,
 
org.geoserver.wms.MapLayerInfo@36440ac1]
MaxFeatures = null
Palette = null
RawKvp = {FORMAT=image/png8, STYLES=, WIDTH=1024, HEIGHT=1024, LAYERS=osm:osm, 
EXCEPTIONS=SE_XML, GWC_SEED_INTERCEPT=true, REQUEST=GetMap, SRS=EPSG:900913, 
BBOX=-10018754.17,10018754.16998,0.0,20037508.34, VERSION=1.1.1, 
SERVICE=WMS, TRANSPARENT=true}
RemoteOwsType = null
RemoteOwsURL = null
Request = GetMap
RequestCharset = UTF-8
ScaleMethod = null
Sld = null
SldBody = null
SldVersion = null
SortBy = null
SortByArrays = null
SRS = EPSG:900913
StartIndex = null
StyleBody = null
StyleFormat = sld
Styles = [StyleImpl[ name=simplified_water], StyleImpl[ name=water], StyleImpl[ 
name=coast_poly], StyleImpl[ name=world], StyleImpl[ name=icesheet], StyleImpl[ 
name=icesheet_outlines], StyleImpl[ name=all_regions], StyleImpl[ 
name=landusages], StyleImpl[ name=waterareas], StyleImpl[ name=waterways], 
StyleImpl[ name=buildup], StyleImpl[ name=all_boundaries], StyleImpl[ 
name=boundaries], StyleImpl[ name=transport_areas], StyleImpl[ name=buildings], 
StyleImpl[ name=roads], StyleImpl[ name=states], StyleImpl[ name=addresses], 
StyleImpl[ name=admin_labels], StyleImpl[ name=places], StyleImpl[ 
name=amenities], StyleImpl[ name=transport_points]]
StyleUrl = null
StyleVersion = null
Tiled = false
TilesOrigin = null
Time = []
Transparent = true
ValidateSchema = false
Version = 1.1.1
ViewParams = null
Width = 1024
2021-04-25 20:59:48,320 ERROR [renderer.lite] - DataSource not available after 
calling dispose() or before being set.
java.lang.IllegalStateException: DataSource not available after calling 
dispose() or before being set.
at 

Re: [Geoserver-users] Small study on "Cloud optimized OGC WMS Servers"

[Rahkonen Jukka (MML)]

Hi Andreas,

See https://github.com/geoserver/geoserver/wiki/GSIP-201 “Cloud Native 
GeoServer Project Donation”.

-Jukka Rahkonen-

Lähettäjä: Andreas Neumann 
Lähetetty: perjantai 23. huhtikuuta 2021 18.36
Vastaanottaja: geoserver-users@lists.sourceforge.net
Aihe: [Geoserver-users] Small study on "Cloud optimized OGC WMS Servers"

Hi,

For a small project as part of the Swiss National Geodata Infrastructure (grant 
project) several people worked on a study document called "Cloud-optimized OGC 
WMS Server" where we analyzed problems that can arise when you install an OGC 
web server in the cloud (e.g. docker image deployed via Kubernetes, OpenShift 
or the likes). This work had a focus on QGIS Server with it's own set of 
problems - but some of the issues studied in this document also matter for 
other OGC WMS servers, like UMN Mapserver or Geoserver, such as the load 
balancing problem, how to share resources, etc.

Here is the link to the document (not in final form yet, but close to being 
final): 
https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2

I wonder if any similar work has been done specifically around problems, 
challenges and solutions when you deploy Geoserver in cloud environments? Do 
you know of any work?

We came across this project here: http://geoserver.org/geoserver-cloud/ - this 
is probably the closest system compared to what we have in mind. Can you share 
a bit of experience with this system? How well does it work in practice? What 
are the challenges/problems and what works well?

One major problem that probably all installations of an OGC WMS server have is 
how to deploy a more intelligent load balancing system? (the "Gateway" in the 
above mentioned Geoserver system architecture diagram). Often, the default load 
balancer is some kind of round robin load balancer system, but this frequently 
leads to inferior results where "cheap and short" requests (such as a simple 
GetFeatureInfo or GetLegendGraphics request) can be queued behind a 
long-running GetMap request or PDF generation task (potentially with many 
layers, many features and a high-dpi, such as 600dpi, where the request can 
take several seconds to process. Meanwhile, the GetFeatureInfo might still wait 
behind a long-running request, while parallel instances would have free 
resources, because they have just finished their own task.

As mentioned in our study document it is of course possible to separate the 
requests to dedicated instances for short requests and potentially long 
requests, to avoid the above mentioned scenario, but we are not so satisfied 
with the solution, as it is  a bit inflexible and also a bit harder to 
maintain. Ideally, we would like to have a more intelligent load balancer with 
incoming queue that holds back requests as long as all WMS server instances are 
busy. This would avoid the situation where a "less intelligent" load balancer 
would simply forward the requests to instances based on Round-Robin principle.

Do you know of any additional work in the Geoserver community regarding cloud 
deployment, cloud optimization, intelligent load balancing and resource sharing?

In our study document I'd like to also include the perspective of other WMS 
servers besides QGIS server, so any input would be welcome.

Thanks,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer

--
Andreas Neumann
QGIS.ORG board member (treasurer)
___
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] Small study on "Cloud optimized OGC WMS Servers"

[Andreas Neumann]

Hi,

For a small project as part of the Swiss National Geodata Infrastructure
(grant project) several people worked on a study document called
"Cloud-optimized OGC WMS Server" where we analyzed problems that can arise
when you install an OGC web server in the cloud (e.g. docker image deployed
via Kubernetes, OpenShift or the likes). This work had a focus on QGIS
Server with it's own set of problems - but some of the issues studied in
this document also matter for other OGC WMS servers, like UMN Mapserver or
Geoserver, such as the load balancing problem, how to share resources, etc.

Here is the link to the document (not in final form yet, but close to being
final):
https://docs.google.com/document/d/1cOUWgzalRx7CHWTFgHz6-uyScsCcoaEmYC0VBHdZShQ/edit#heading=h.c7gq4lie7ys2

I wonder if any similar work has been done specifically around problems,
challenges and solutions when you deploy Geoserver in cloud environments?
Do you know of any work?

We came across this project here: http://geoserver.org/geoserver-cloud/ -
this is probably the closest system compared to what we have in mind. Can
you share a bit of experience with this system? How well does it work in
practice? What are the challenges/problems and what works well?

One major problem that probably all installations of an OGC WMS server have
is how to deploy a more intelligent load balancing system? (the "Gateway"
in the above mentioned Geoserver system architecture diagram). Often, the
default load balancer is some kind of round robin load balancer system, but
this frequently leads to inferior results where "cheap and short" requests
(such as a simple GetFeatureInfo or GetLegendGraphics request) can be
queued behind a long-running GetMap request or PDF generation task
(potentially with many layers, many features and a high-dpi, such as
600dpi, where the request can take several seconds to process. Meanwhile,
the GetFeatureInfo might still wait behind a long-running request, while
parallel instances would have free resources, because they have just
finished their own task.

As mentioned in our study document it is of course possible to separate the
requests to dedicated instances for short requests and potentially long
requests, to avoid the above mentioned scenario, but we are not so
satisfied with the solution, as it is  a bit inflexible and also a bit
harder to maintain. Ideally, we would like to have a more intelligent load
balancer with incoming queue that holds back requests as long as all WMS
server instances are busy. This would avoid the situation where a "less
intelligent" load balancer would simply forward the requests to instances
based on Round-Robin principle.

Do you know of any additional work in the Geoserver community regarding
cloud deployment, cloud optimization, intelligent load balancing and
resource sharing?

In our study document I'd like to also include the perspective of other WMS
servers besides QGIS server, so any input would be welcome.

Thanks,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer

--
Andreas Neumann
QGIS.ORG board member (treasurer)
___
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] cql_filter WMS with high ASCIIs or spaces in attributes

[Andrea Aime]

The thread was referring to a grammar that's used for documentation, not
the actual one used to generate code.
The actual grammar rule is here:

https://github.com/geotools/geotools/blob/94377f6769f14d2225427c73c99bb714e9e5c32a/modules/library/cql/src/main/jjtree/ECQLGrammar.jjt#L298

So grammar wise, it seems that anything can be used as long as it's double
quoted (single quotes mark a string literal instead).
That however does not automatically mean one can freely use whatever
character in identifiers in a WMS request, there is also the
request parsing involved, the potential SQL encoding of the filter and so
on.
It could break at any point in the chain. If you or anyone in your group
can set up a developer environment, let us know, we can
give you some quick indications on where to set the breakpoints

Cheers
Andrea



On Sun, Apr 25, 2021 at 12:25 PM David Persson  wrote:

> Hi,
>
> Yes, the request is url-encoded. The ECQL parser (geoserver log
> level==debug) gives "..5918, VERSION=1.1.1, SERVICE=WMS, TRANSPARENT=true,
> CQL_FILTER='Datafångstmetod' = 'Karta över Hagbysjön och Borsten 1950.
> Handdig'}" and the postgresql logs "..FROM
> "public"."sokvyx_djupdata_djuppunkter_vy_2" WHERE 0 = 1" instead of "WHERE
> " when we enclose the attribute and value in single
> quotation marks. And we then receive a WMS image without features. (If use
> double quotation marks the Geoserver debug log mentions that the filter
> could not be parsed). So it looks right from Geoservers debug logs but
> evidently the right WHERE isn't sent to postgresql (or postresql doesn't
> throw an error for this but merely "WHERE 0 = 1")
>
> It's the same for attributes with a space in the name as with high ASCIIS
> like "Datafångstmetod".
>
> (These queries work well when put directly to postgresql)
>
> I saw this thread
> http://osgeo-org.1560.x6.nabble.com/ECQL-with-space-in-attribute-name-td5311652.html
> which indicates that at least spaces in attribute names are impossible for
> ecql, period, so maybe this is the case and the same for high ASCIIS?
>
> Regards
>
> On Thu, Apr 22, 2021 at 4:42 PM Ian Turton  wrote:
>
>> Did you try urlencoding the filter? in general it's a bad idea to have
>> spaces in your table or column names. Failing that, you'll need to look at
>> the log file and see if the request is failing in the ECQL parser or the
>> query sent to PostGIS.
>>
>> Ian
>>
>> On Thu, 22 Apr 2021 at 15:14, David Persson  wrote:
>>
>>> Hi,
>>>
>>> We've published layers in geoserver based on postgresql views where some
>>> columns contain spaces and å ä ö currently. Right now we are trying to
>>> employ ecql filters with getMap requests and are finding it hard/impossible
>>> to receive an expected reply when the query contains an attribute (column
>>> name in the view / property) that contains å ä ö or a space.
>>>
>>> We've tried a number of combinations with single and double quotes
>>> around the property and property + value . If the property has single
>>> quotation marks aroun, or the property and value have single quotations
>>> around them, the getmap is succesfull but the image returned contains no
>>> features even if expected to have them.
>>>
>>> If seemingly any combination of double quotation marks ( " ) are
>>> employed we get an ecql exception.
>>>
>>> (spaces and high asciis are okay as values to search for)
>>>
>>> Is there any way to filter a getMap on a property that contains spaces
>>> or high ASCIIs?
>>>
>>> Friendly regards,
>>> David.
>>> ___
>>> 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
>


-- 

Regards, Andrea Aime

== GeoServer 

[Geoserver-users] (no subject)

[Safae El ansari]

Hi Geoserver Users Group
please what is the solution for that


org.apache.wicket.WicketRuntimeException: Error attaching this container
for rendering: [WebMarkupContainer [Component id = listContainer]] at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1848)
at org.apache.wicket.Component.onBeforeRender(Component.java:3916) at
org.apache.wicket.Component.internalBeforeRender(Component.java:950) at
org.apache.wicket.Component.beforeRender(Component.java:1018) at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836)
at org.apache.wicket.Component.onBeforeRender(Component.java:3916) at
org.apache.wicket.Component.internalBeforeRender(Component.java:950) at
org.apache.wicket.Component.beforeRender(Component.java:1018) at
org.apache.wicket.MarkupContainer.onBeforeRenderChildren(MarkupContainer.java:1836)
at org.apache.wicket.Component.onBeforeRender(Component.java:3916) at
org.apache.wicket.Page.onBeforeRender(Page.java:801) at
org.apache.wicket.Component.internalBeforeRender(Component.java:950) at
org.apache.wicket.Component.beforeRender(Component.java:1018) at
org.apache.wicket.Component.internalPrepareForRender(Component.java:2236)
at org.apache.wicket.Page.internalPrepareForRender(Page.java:242) at
org.apache.wicket.Component.render(Component.java:2325) at
org.apache.wicket.Page.renderPage(Page.java:1018) at
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:124)
at
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:236)
at
org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:175)
at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:895)
at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:265)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:222)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:293)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:261)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:203)
at
org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:626) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:166)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:177)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:52)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1040)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:626) at
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:26)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:69)
at
org.geoserver.wms.animate.AnimatorFilter.doFilter(AnimatorFilter.java:70)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:66)
at
org.geoserver.filters.SpringDelegatingFilter.doFilter(SpringDelegatingFilter.java:41)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
org.geoserver.platform.AdvancedDispatchFilter.doFilter(AdvancedDispatchFilter.java:37)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at

Re: [Geoserver-users] cql_filter WMS with high ASCIIs or spaces in attributes

[David Persson]

Hi,

Yes, the request is url-encoded. The ECQL parser (geoserver log
level==debug) gives "..5918, VERSION=1.1.1, SERVICE=WMS, TRANSPARENT=true,
CQL_FILTER='Datafångstmetod' = 'Karta över Hagbysjön och Borsten 1950.
Handdig'}" and the postgresql logs "..FROM
"public"."sokvyx_djupdata_djuppunkter_vy_2" WHERE 0 = 1" instead of "WHERE
" when we enclose the attribute and value in single
quotation marks. And we then receive a WMS image without features. (If use
double quotation marks the Geoserver debug log mentions that the filter
could not be parsed). So it looks right from Geoservers debug logs but
evidently the right WHERE isn't sent to postgresql (or postresql doesn't
throw an error for this but merely "WHERE 0 = 1")

It's the same for attributes with a space in the name as with high ASCIIS
like "Datafångstmetod".

(These queries work well when put directly to postgresql)

I saw this thread
http://osgeo-org.1560.x6.nabble.com/ECQL-with-space-in-attribute-name-td5311652.html
which indicates that at least spaces in attribute names are impossible for
ecql, period, so maybe this is the case and the same for high ASCIIS?

Regards

On Thu, Apr 22, 2021 at 4:42 PM Ian Turton  wrote:

> Did you try urlencoding the filter? in general it's a bad idea to have
> spaces in your table or column names. Failing that, you'll need to look at
> the log file and see if the request is failing in the ECQL parser or the
> query sent to PostGIS.
>
> Ian
>
> On Thu, 22 Apr 2021 at 15:14, David Persson  wrote:
>
>> Hi,
>>
>> We've published layers in geoserver based on postgresql views where some
>> columns contain spaces and å ä ö currently. Right now we are trying to
>> employ ecql filters with getMap requests and are finding it hard/impossible
>> to receive an expected reply when the query contains an attribute (column
>> name in the view / property) that contains å ä ö or a space.
>>
>> We've tried a number of combinations with single and double quotes around
>> the property and property + value . If the property has single quotation
>> marks aroun, or the property and value have single quotations around them,
>> the getmap is succesfull but the image returned contains no features even
>> if expected to have them.
>>
>> If seemingly any combination of double quotation marks ( " ) are employed
>> we get an ecql exception.
>>
>> (spaces and high asciis are okay as values to search for)
>>
>> Is there any way to filter a getMap on a property that contains spaces or
>> high ASCIIs?
>>
>> Friendly regards,
>> David.
>> ___
>> 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] Failed to create reader error while trying to create coverage using REST API

[Kris Johnson via Geoserver-users]

Hello,

I am trying to load a GeoTIFF into my geoserver using the REST API (via
curl). Thank you for any help you can provide.

Geoserver version 2.19.0

curl command:
curl -v -u $GEOSERVER_ADMIN_USER:$GEOSERVER_ADMIN_PASSWORD \
-XPOST -H "Content-type: text/xml" \
-d "\
$rastname\
EPSG:26915EPSG:26915
\
\
423031.0\
636179.0\
5112559.0\
5320715.0\
EPSG:26915\
" \

http://geoserver:8080/geoserver/rest/workspaces/foropt/coveragestores/$rastname/coverages

error output:
java.io.IOException: Failed to create reader from
/tmp/data/mammal_in/WHNGS_for_subset_2070.tif and hints Hints:
  REPOSITORY   =
org.geoserver.catalog.CatalogRepository@4f2770aa

  FILTER_FACTORY   = FilterFactoryImpl


  GRID_COVERAGE_FACTORY= GridCoverageFactory


TILE_ENCODING  = null


  FEATURE_FACTORY  =
org.geotools.feature.LenientFeatureFactoryImpl@3a4ed5cd

  FORCE_LONGITUDE_FIRST_AXIS_ORDER = true


  STYLE_FACTORY= StyleFactoryImpl


  FORCE_AXIS_ORDER_HONORING= http


  EXECUTOR_SERVICE =
java.util.concurrent.ThreadPoolExecutor@6b360f59[Running, pool size = 0,
active threads = 0, queued tasks = 0, completed tasks = 0]
  LENIENT_DATUM_SHIFT  = true


  COMPARISON_TOLERANCE = 1.0E-8



at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1574)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1491)
at
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1486)
at
org.geoserver.catalog.CatalogBuilder.initCoverage(CatalogBuilder.java:855)
at
org.geoserver.rest.catalog.CoverageController.handleObjectPost(CoverageController.java:319)
at
org.geoserver.rest.catalog.CoverageController.coveragePost(CoverageController.java:193)
at jdk.internal.reflect.GeneratedMethodAccessor266.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
at
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
at
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:105)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892)
at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797)
at
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1040)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:652)
at
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:352)
at org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:171)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:26)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:69)
at
org.geoserver.flow.controller.IpBlacklistFilter.doFilter(IpBlacklistFilter.java:89)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:66)
at org.geoserver.monitor.MonitorFilter.doFilter(MonitorFilter.java:142)
at

[Geoserver-users] New maintenance releases

[Ian Turton]

The team is pleased to announce that the latest round of maintenance
releases have been made:

GeoTools 24.3

GeoServer 2.18.3
GeoWebCache 1.18.3


Thanks to Jody Garnet (GeoCat) for helping out with this release.
-- 
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] wrong scale printing on mapfish

[Miroslav Hrćan]

Hello everyone,

Not sure if this is the right place for this topic, but I did not found any
Mapfish mailing list or similar.

I have a problem with printing layers on concrete scale. For example, I
send request as below:

{

   "layout":"A4 portrait",

   "outputFormat":"pdf",

   "outputFilename":"test",

   "attributes":{

  "label":"",

  "description":"",

  "madeBy":"",

  "notes":"",

  "copyright":"  © OpenStreetMap
Contributors; ",

  "madeIn":"",

  "mmVersion":"",

  "datasource":[

 {

"table":{

   "data":[



   ],

   "columns":[



   ]

},

"displayName1":"",

"displayName2":"",

"displayName3":"",

"isParcel":0,

"isMap":1,

"map":{

   "dpi":"96",

   "rotation":0,

   "center":[

  1960176.3323157998,

  6168869.43851

   ],

   "scale":7000,

   "layers":[

  {

 "type":"osm",

 "baseURL":"
http://tile.openstreetmap.org/{z}/{x}/{y}.png;,

 "opacity":1,

 "maxExtent":[

-20037508.342789244,

-20037508.342789244,

20037508.342789244,

20037508.342789244

 ],

 "tileSize":[

256,

256

 ],

 "resolutions":[

156543.03390625,

78271.516953125,

39135.7584765625,

19567.87923828125,

9783.939619140625,

4891.9698095703125,

2445.9849047851562,

1222.9924523925781,

611.4962261962891,

305.74811309814453,

152.87405654907226,

76.43702827453613,

38.218514137268066,

19.109257068634033,

9.554628534317017,

4.777314267158508,

2.388657133579254,

1.194328566789627,

0.5971642833948135,

0.29858214169740677,

0.14929107084870338,

0.07464553542435169,

0.037322767712175846,

0.018661383856087923,

0.009330691928043961,

0.004665345964021981,

0.0023326729820109904,

0.0011663364910054952,

0.0005831682455027476,

0.0002915841227513738

 ],

 "imageExtension":"png"

  }

   ]

}

 }

  ],

  "legendOnPage":0,

  "printParcelInfo":0,

  "iconLeft":"images/logo.png",

  "iconRight":""

   }

}



The scale is set to "scale":7000.

However, after printing pdf on paper, distance is as it was set to scale.
1:5000. I have measured lines on paper and figured out that the scale is
not good at all.

I have tried to solve the problem with attribute “geodetic”: true, as is
recommended on these two pages:

https://gis.stackexchange.com/questions/218015/geoserver-mapfish-print-wrong-scale-and-scalebar-on-my-printed-map

https://gis.stackexchange.com/questions/173678/geoserver-with-printing-plugin-scale-too-low

but, unfortunately with no luck.

In configuration file, my set up for a4 is:

templates:


#===

  A4 portrait: !template


#===

reportTemplate: A4Portrait.jrxml

tableData: jrDataSource

outputFilename: ${outputFilename}

attributes:

  iconLeft: !string {}

  iconRight: !string {}

  madeBy: !string {}

  madeIn: !string {}

  mmVersion: !string {}

  label: !string {}

  description: !string {}

  notes: !string {}

  copyright: !string {}

  legendCols: !integer

default: 3

  datasource: !datasource

attributes:

  table: !table {}

  isParcel: !integer {}

  isMap: !integer {}

  displayName1: !string {}

  displayName2: !string {}

  displayName3: !string {}

  map: !map

maxDpi: 450

dpiSuggestions: [90,96,150,300]

width: 570

height: 696

  scalebar: !scalebar

width: 240

height: 30

createSubReport: false

  

[Geoserver-users] Inconsistent axis order in app-schema WFS json output [SEC=OFFICIAL]

[Sedgmen Aaron]

Hi GeoServer Users,

I have an app-schema WFS with a feature type containing a 3D LineString 
geometry.  I'm finding that the axis order of the x,y coordinates is 
inconsistent in the json output, i.e. some features are returned with latitude 
first and longitude second and others the reverse.

Following are two example features from our test server to illustrate the 
issue.  The "shape" property contains the LineString geometry:

Correct axis order - 
https://boreholes.gs.cloud.ga.gov.au/wfs?service=WFS=1.1.0=GetFeature=gsmlbh:Borehole=json=ga.borehole.466607

Incorrect axis order - 
https://boreholes.gs.cloud.ga.gov.au/wfs?service=WFS=1.1.0=GetFeature=gsmlbh:Borehole=json=ga.borehole.10093

gml32 output is ok, i.e. x,y axis order is the same for all features.

The examples are from a GeoServer 2.18.1 and postgres/postgis installation.  
I've also tested with GeoServer 2.19.0 and an Oracle database, with the same 
results.  There are no differences in geometry type, srid and ordering of the 
coordinates in the database geometries (both postgis and Oracle) where axis 
order differs in the WFS json output.

Any suggestions or advice on what may be causing the inconsistent axis order 
would be much appreciated.

Regards,

Aaron Sedgmen.


Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is 
intended only for the person or entity to which it is addressed. If you are not 
the intended recipient, then you have received this e-mail by mistake and any 
use, dissemination, forwarding, printing or copying of this e-mail and its file 
attachments is prohibited. The security of emails transmitted cannot be 
guaranteed; by forwarding or replying to this email, you acknowledge and accept 
these risks.
___
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] Fwd: GeoServer printing module fails

[Vera Green]

Thanks for sharing this. Very helpful!

On Sat., Apr. 10, 2021, 8:02 p.m. Stephen V. Mather via Geoserver-users, <
geoserver-users@lists.sourceforge.net> wrote:

> And, for anyone following along at home who knows as little as me about
> the ecosystem as I do, you can download that jar here:
> https://mvnrepository.com/artifact/org.json/json/20080701
>
> Shutdown your container/geoserver, delete the existing
> jar json-20180813.jar, and move that jar into your geoserver/WEB-INF/lib/
> directory. In my case, that location is inside the tomcat webapps directory:
> /opt/tomcat/webapps/geoserver/WEB-INF/lib/
>
> And restart your container.
>
> Like a gif of a cat at a keyboard, I attempted to patch the fix in here
> that builds with Maven:
>
> https://github.com/smathermather/geoserver/blob/smathermather-json-patch/src/extension/printing/pom.xml
>
> If it's worthy of a pull request, I will fill out the contributor
> covenant, tag it to the JIRA, and do a pull request. It's a modified copy
> from the Mapfish patch. If it is no better than a cat at a keyboard, then
> just consider it a little noise from a non-Java developer, and I'll see my
> way out.
>
> Thanks All,
> Nice to see the GeoServer community is still amazing and amazingly quick
> and supportive,
> Best,
> Steve
>
>
>
> [image: http://sig.cmparks.net/cmp-ms-90x122.png] *Stephen V. Mather*
> GIS Manager
> (216) 635-3243 (Work)
> clevelandmetroparks.com 
>
>
>
>
> --
> *From:* Stephen V. Mather via Geoserver-users <
> geoserver-users@lists.sourceforge.net>
> *Sent:* Saturday, April 10, 2021 2:29 PM
> *To:* Mauro Bartolomeoli ; GeoServer
> Mailing List List 
> *Subject:* Re: [Geoserver-users] Fwd: GeoServer printing module fails
>
>
> *WARNING: This email originated outside of Cleveland Metroparks. DO NOT
> CLICK links or attachments unless you recognize the sender and know the
> content is safe.*
> Awesome, thanks for the confirmation. I was just about to ask about
> whether I could just swap jars and it looks like Ian already answered in
> the JIRA:
> > I can confirm that replacing json-20180813.jar with json-20080701.jar
> fixes the issue in a 2.19.0 install
>
> I'll do that for now.
>
> Thanks!
> Best,
> Steve
>
> [image: http://sig.cmparks.net/cmp-ms-90x122.png] *Stephen V. Mather*
> GIS Manager
> (216) 635-3243 (Work)
> clevelandmetroparks.com 
>
>
>
>
> --
> *From:* Mauro Bartolomeoli 
> *Sent:* Friday, April 9, 2021 5:19 AM
> *To:* GeoServer Mailing List List 
> *Subject:* [Geoserver-users] Fwd: GeoServer printing module fails
>
>
> *WARNING: This email originated outside of Cleveland Metroparks. DO NOT
> CLICK links or attachments unless you recognize the sender and know the
> content is safe.*
> Good morning Stephen,
>
> Still an avid GeoServer user over here in Cleveland. It's been a long time
> since I've had a question. I've been lurking again for a few weeks, but
> know so little now that I haven't been able to be helpful again yet.
>
>
> Glad to hear that!
>
> I can confirm the issue with 2.19.0 and I have opened a jira ticket for
> it: https://osgeo-org.atlassian.net/browse/GEOS-10015
>
> It should be related to a breaking change in json-20180813.jar. We used to
> depend on an older version.
>
> --
>
> Regards,
>
> Mauro Bartolomeoli
>
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Dott. Mauro Bartolomeoli
> @mauro_bart
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> Italy
>
> mobile: +39 393 904 1756
> phone: +39 0584 962313
> fax:  +39 0584 1660272
>
> 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