Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi all,
this (https://github.com/geoserver/geoserver/pull/41) is the pull request for
the cumulative patch which implements all the requested changes to the
collection of the JSON response Handlers I have provided.
May I have to update the GSIP-79 (
http://geoserver.org/pages/viewpage.action?pageId=49938445 ) with the changes
(new examples etc...)? Documentation is already aligned.
Thank you all,
Carlo
Date: Tue, 2 Oct 2012 15:42:44 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
CC: geoserver-devel@lists.sourceforge.net
Hi,
I forgot one thing - see inline.
On Tue, Oct 2, 2012 at 3:32 PM, Andreas Hocevar ahoce...@opengeo.org wrote:
For Exceptions:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Also perfect.
And you could also add
version: 1.1.1
next to exceptions.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hey Carlo,
see answers inline.
On Mon, Oct 1, 2012 at 5:15 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
so this is what are you asking for, right?
*{layerDescriptions:
*[
*{
*layerName: cite:Lakes,
*owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
*owsType: WFS
*},
*{
*layerName: cite:Forests,
*owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
*owsType: WFS
*}
*]
*}
Yes, but the typeName is missing. typeName is the typename
attribute of the Query node, and layerName is the name attribute
of the LayerDescription.
And in addition, you could also add a version property next to
layerDescriptions, with the ServiceExceptionReport's version
attribute as value.
And what about an Exception like this?
{exceptionCode:InvalidParameterValue,exceptionLocator:typeName,exceptionText:Could
not find type name foobar})
Well, OpenLayers also has an OGC Exception format parser, and it would
be nice if we could share the format here as well. This is an example
object from the output of OpenLayers.Format.OGCExceptionReport:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Note that exceptions is an array.
Let me know if you have more questions.
Andreas.
Thank you,
Carlo
Date: Fri, 7 Sep 2012 19:24:39 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
On Fri, Sep 7, 2012 at 7:23 PM, Andreas Hocevar ahoce...@opengeo.org
wrote:
I should add though that it will probably make sense to have GeoServer
return an object with a layerDescription property
And I guess layerDescriptions would be an appropriate name - plural for
arrays.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Andreas,
And in addition, you could also add a version property next to
layerDescriptions, with the ServiceExceptionReport's version
attribute as value.
The version I could append is the same as the protocol version, I've no
information about the ExceptionHandler if no exception is returned (in this
case it is the same 1.1.1).
Yes, but the typeName is missing. typeName is the typename
attribute of the Query node, and layerName is the name attribute
of the LayerDescription.
I'm not sure about the Query node is the same as the layerName on my point of
view, right?
I'll get:{version:1.1.1layerDescriptions:
[
{
layerName: cite:Lakes,
owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
owsType: WFS typeName: cite:Lakes,
},
{
layerName: cite:Forests,
owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
owsType: WFS typeName: cite:Forests,
}
]
}
For Exceptions:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
is there a problem if i add the locator attribute?:{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobarlocator:
typeName
}
]
}
thanks for feedback,Carlo
Date: Tue, 2 Oct 2012 13:07:27 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
CC: geoserver-devel@lists.sourceforge.net
Hey Carlo,
see answers inline.
On Mon, Oct 1, 2012 at 5:15 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
so this is what are you asking for, right?
*{layerDescriptions:
*[
*{
*layerName: cite:Lakes,
*owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
*owsType: WFS
*},
*{
*layerName: cite:Forests,
*owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
*owsType: WFS
*}
*]
*}
Yes, but the typeName is missing. typeName is the typename
attribute of the Query node, and layerName is the name attribute
of the LayerDescription.
And in addition, you could also add a version property next to
layerDescriptions, with the ServiceExceptionReport's version
attribute as value.
And what about an Exception like this?
{exceptionCode:InvalidParameterValue,exceptionLocator:typeName,exceptionText:Could
not find type name foobar})
Well, OpenLayers also has an OGC Exception format parser, and it would
be nice if we could share the format here as well. This is an example
object from the output of OpenLayers.Format.OGCExceptionReport:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Note that exceptions is an array.
Let me know if you have more questions.
Andreas.
Thank you,
Carlo
Date: Fri, 7 Sep 2012 19:24:39 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
On Fri, Sep 7, 2012 at 7:23 PM, Andreas Hocevar ahoce...@opengeo.org
wrote:
I should add though that it will probably make sense to have GeoServer
return an object with a layerDescription property
And I guess layerDescriptions would be an appropriate name - plural for
arrays.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi,
On Tue, Oct 2, 2012 at 3:00 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
And in addition, you could also add a version property next to
layerDescriptions, with the ServiceExceptionReport's version
attribute as value.
The version I could append is the same as the protocol version, I've no
information about the ExceptionHandler if no exception is returned (in this
case it is the same 1.1.1).
Sorry for the confusion. The ServiceExceptionReport was a typo on my
end - 1.1.1 is fine.
Yes, but the typeName is missing. typeName is the typename
attribute of the Query node, and layerName is the name attribute
of the LayerDescription.
I'm not sure about the Query node is the same as the layerName on my point
of view, right?
In GeoServer it is the same, but the spec allows WMS layer names to be
mapped to different WFS/WCS type names.
I'll get:
{
version:1.1.1
layerDescriptions:
[
{
layerName: cite:Lakes,
owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
owsType: WFS
typeName: cite:Lakes,
},
{
layerName: cite:Forests,
owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
owsType: WFS
typeName: cite:Forests,
}
]
}
Perfect.
For Exceptions:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Also perfect.
is there a problem if i add the locator attribute?:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
locator: typeName
}
]
}
Extra attributes don't hurt - you can definitely add them.
Thanks again,
Andreas.
thanks for feedback,
Carlo
Date: Tue, 2 Oct 2012 13:07:27 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
CC: geoserver-devel@lists.sourceforge.net
Hey Carlo,
see answers inline.
On Mon, Oct 1, 2012 at 5:15 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
so this is what are you asking for, right?
* {layerDescriptions:
* [
* {
* layerName: cite:Lakes,
* owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
* owsType: WFS
* },
* {
* layerName: cite:Forests,
* owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
* owsType: WFS
* }
* ]
* }
Yes, but the typeName is missing. typeName is the typename
attribute of the Query node, and layerName is the name attribute
of the LayerDescription.
And in addition, you could also add a version property next to
layerDescriptions, with the ServiceExceptionReport's version
attribute as value.
And what about an Exception like this?
{exceptionCode:InvalidParameterValue,exceptionLocator:typeName,exceptionText:Could
not find type name foobar})
Well, OpenLayers also has an OGC Exception format parser, and it would
be nice if we could share the format here as well. This is an example
object from the output of OpenLayers.Format.OGCExceptionReport:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Note that exceptions is an array.
Let me know if you have more questions.
Andreas.
Thank you,
Carlo
Date: Fri, 7 Sep 2012 19:24:39 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
On Fri, Sep 7, 2012 at 7:23 PM, Andreas Hocevar ahoce...@opengeo.org
wrote:
I should add though that it will probably make sense to have
GeoServer
return an object with a layerDescription property
And I guess layerDescriptions would be an appropriate name - plural for
arrays.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi,
I forgot one thing - see inline.
On Tue, Oct 2, 2012 at 3:32 PM, Andreas Hocevar ahoce...@opengeo.org wrote:
For Exceptions:
{
exceptions: [
{
code: InvalidParameterValue,
text: Could not find type name foobar
}
]
}
Also perfect.
And you could also add
version: 1.1.1
next to exceptions.
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Andreas, so this is what are you asking for, right?
*{layerDescriptions: *[ *{ *
layerName: cite:Lakes, *owsURL:
http://localhost:8080/geoserver/wfs/WfsDispatcher?;, *owsType:
WFS *}, *{ *layerName: cite:Forests,
*owsURL: http://localhost:8080/geoserver/wfs/WfsDispatcher?;,
*owsType: WFS *} *] *}
And what about an Exception like this?
{exceptionCode:InvalidParameterValue,exceptionLocator:typeName,exceptionText:Could
not find type name foobar})
Thank you,Carlo
Date: Fri, 7 Sep 2012 19:24:39 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: ccancelli...@hotmail.com
On Fri, Sep 7, 2012 at 7:23 PM, Andreas Hocevar ahoce...@opengeo.org wrote:
I should add though that it will probably make sense to have GeoServer
return an object with a layerDescription property
And I guess layerDescriptions would be an appropriate name - plural for
arrays.
Andreas.
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
I was thinking to keep things more clean moving: /wfs-2.3-SNAPSHOT/src/main/java/org/geoserver/wfs/GeoJSONBuilder.java/wfs-2.3-SNAPSHOT/src/main/java/org/geoserver/wfs/GeoJSONOutputFormat.javato/wfs-2.3-SNAPSHOT/src/main/java/org/geoserver/wfs/json/GeoJSONBuilder.java /wfs-2.3-SNAPSHOT/src/main/java/org/geoserver/wfs/json/GeoJSONOutputFormat.java and /wfs-2.3-SNAPSHOT/src/test/java/org/geoserver/wfs/GeoJSONBuilderTest.java/wfs-2.3-SNAPSHOT/src/test/java/org/geoserver/wfs/GeoJSONTest.java to/wfs-2.3-SNAPSHOT/src/test/java/org/geoserver/wfs/json/GeoJSONBuilderTest.java/wfs-2.3-SNAPSHOT/src/test/java/org/geoserver/wfs/json/GeoJSONTest.java May be this is not a good Idea, do you think this may brake some extensions? Cheers,Carlo Date: Thu, 20 Sep 2012 08:20:06 -0600 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net On Thu, Sep 20, 2012 at 5:54 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: All I'm going to applying requested changes:I see Justin suggested theparseResponse as callback method name. Is it good for you? Anderas is on vacation this week and won't be back until next week. I don't have a precedent for the name aside from the fact that parseResponse makes more sense to me than paddingOutput based on the usage of it. But i of course delegate to someone else more experienced with applications that use jsonp. Carlo Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeaturesYou can specify the desired 'output_format': INFO_FORMAT=text/javascriptand also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures You'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in a jsonP format with the callback function called getLayerFeatures NOTE: 1. I don't added a specific format_option for exception callback right now, do we really need one? 2. The format_options callback parameter is NOT mandatory in that case (JSONP for response or exception) the default one is used paddingOutput (see JSONType). Same things can be obtained when you use application/json. In that case you are simply asking for a json without the callback function (which is ignored if specified). Json and JsonP http://en.wikipedia.org/wiki/JSONP Take also a look
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Andreas, I'm going to start fixing those patches, probably I'll ask you some feedback when done. PS: No changes to the jsonp callback default method name? (paddingOutput) Thank you all,Carlo Date: Fri, 7 Sep 2012 14:50:38 +0200 From: ahoce...@opengeo.org To: chol...@opengeo.org CC: geoserver-devel@lists.sourceforge.net; alessio.fabi...@geo-solutions.it Subject: Re: [Geoserver-devel]GSIP 79 - Json support and WFS and WMS ExceptionHandlers Unfortunately the structures are not well documented. We could add documentation though to help with this effort. Otherwise the best place to see the structure is the tests (https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html, https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html). For OpenLayers 3, the plan is to port the existing Format classes without making structural changes, unless there are obvious flaws in the structure we use in OpenLayers 2 (shouldn't be the case for DescribeLayer and DescribeFeatureType). Andreas. On Fri, Sep 7, 2012 at 2:40 PM, Chris Holmes chol...@opengeo.org wrote: Me too. Andreas - is there somewhere that this object structure is documented? And is that structure going to remain the same for OL 3? On Fri, Sep 7, 2012 at 5:08 AM, Alessio Fabiani alessio.fabi...@geo-solutions.it wrote: Agree with Andreas observations about Describe operations compliance w/ OL. == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 331 6233686 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justin, Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
All I'm going to applying requested changes:I see Justin suggested theparseResponse as callback method name. Is it good for you? Carlo Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeaturesYou can specify the desired 'output_format': INFO_FORMAT=text/javascriptand also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures You'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in a jsonP format with the callback function called getLayerFeatures NOTE: 1. I don't added a specific format_option for exception callback right now, do we really need one? 2. The format_options callback parameter is NOT mandatory in that case (JSONP for response or exception) the default one is used paddingOutput (see JSONType). Same things can be obtained when you use application/json. In that case you are simply asking for a json without the callback function (which is ignored if specified). Json and JsonP http://en.wikipedia.org/wiki/JSONP Take also a look to examples here: http://docs.geoserver.org/latest/en/user/services/wms/reference.html Hope that this answers your questions. Cheers, Carlo Thanks. -Justin On Wed, Sep 5, 2012 at 12:16 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi all, the GSIP 79 (about Json ExceptionHandlers) is here:http://geoserver.org/pages/viewpage.action?pageId=49938445 It is already committed on the master branch and it would be nice to discuss about its backport to the stable release 2.2.2. Cheers,Carlo Date: Mon, 3 Sep 2012 11:31:21 -0500 From: j...@codehaus.org To: ccancelli...@hotmail.com Subject: [jira] (GEOS-5247) Json[p] WFS and WMS exceptionHandler Justin Deoliveira commented on GEOS-5247 Json[p] WFS and WMS exceptionHandler Any chance we can get a short GSIP before the work is backported. Maybe at least just summarizing all the info placed
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
On Thu, Sep 20, 2012 at 5:54 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: All I'm going to applying requested changes: I see Justin suggested the parseResponse as callback method name. Is it good for you? Anderas is on vacation this week and won't be back until next week. I don't have a precedent for the name aside from the fact that parseResponse makes more sense to me than paddingOutput based on the usage of it. But i of course delegate to someone else more experienced with applications that use jsonp. Carlo -- Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: -- Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=application/vnd.ogc.se_xmlSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You can specify the desired 'output_format': INFO_FORMAT=text/javascript and also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=text/javascriptSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in a jsonP format with the callback function called getLayerFeatures NOTE: 1. I don't added a specific format_option for exception callback right now, do we really need one? 2. The format_options callback parameter is NOT mandatory in that case (JSONP for response or exception) the default one is used paddingOutput (see JSONType). Same things can be obtained when you use application/json. In that case you are simply asking for a json without the callback function (which is ignored if specified). Json and JsonP http://en.wikipedia.org/wiki/JSONP Take also a look to examples here: http
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Unfortunately the structures are not well documented. We could add documentation though to help with this effort. Otherwise the best place to see the structure is the tests (https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html, https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html). For OpenLayers 3, the plan is to port the existing Format classes without making structural changes, unless there are obvious flaws in the structure we use in OpenLayers 2 (shouldn't be the case for DescribeLayer and DescribeFeatureType). Andreas. On Fri, Sep 7, 2012 at 2:40 PM, Chris Holmes chol...@opengeo.org wrote: Me too. Andreas - is there somewhere that this object structure is documented? And is that structure going to remain the same for OL 3? On Fri, Sep 7, 2012 at 5:08 AM, Alessio Fabiani alessio.fabi...@geo-solutions.it wrote: Agree with Andreas observations about Describe operations compliance w/ OL. == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 331 6233686 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justin, Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures You can specify the desired 'output_format': INFO_FORMAT=text/javascript and also
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Dear Andreas,
Thank you very much.
I have just done a test to compare the two objects. The object returned by the
OpenLayers API contains some attributes that the actual json object returned by
the DescribeFeatureType service doesn't contain. In my opinion it is correct to
adapt the DescribeFeatureType output to the OpenLayers output.
Thanks a lot.
Best Regards
Francesca
-Original Message-
From: Andreas Hocevar [mailto:ahoce...@opengeo.org]
Sent: 07 September 2012 5:09 PM
To: Vigetti, Francesca (CIOK)
Cc: Carlo Cancellieri; chol...@opengeo.org; alessio.fabi...@geo-solutions.it;
geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
@Carlo: unfortunately there is no good documentation of the format.
For now the best source is looking at the unit tests - see
https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html
and
https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html.
@Francesca: the proper way to read a responseXML is as follows:
new OpenLayers.Format.WFSDescribeFeatureType().read(xml /*XmlDoc or string*/);
new OpenLayers.Format.WFSDescribeLayer().read(xml /*XmlDoc or string*/);
For the XML you provided, OpenLayers would expect the following:
{
elementFormDefault: qualified,
targetNamespace: http://www.fao.org/aquastat;,
featureTypes: [
{
typeName: major_hydrobasins,
properties: [
{
maxOccurs: 1,
minOccurs: 0,
name: the_geom,
nillable: true,
type: gml:MultiSurfacePropertyType,
localType: MultiSurfacePropertyType
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_BAS,
nillable: true,
type: xsd:long,
localType: long
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_NAME,
nillable: true,
type: xsd:string,
localType: string
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_AREA,
nillable: true,
type: xsd:int,
localType: int
}
]
}
],
targetPrefix: AQUASTAT
}
I hope this helps,
Andreas
On Fri, Sep 7, 2012 at 4:34 PM, Vigetti, Francesca (CIOK)
francesca.vige...@fao.org wrote:
Dear All,
Since I am involved in this task, I was trying to test the
OpenLayers.Format.XML with the output of a describeFeatureType call, but I
haven’t found a method to read the whole xml document at a time.
Looking for a solution I found the OpenLayers.Format.XML.VersionedOGC that
has a read method. I have just applied this to my situation but I receive the
following error:
1. Uncaught TypeError: Cannot call method 'replace' of null
OpenLayers.js:275
1.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.getParserOpenLayer
s.js:275
2.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.readOpenLayers.js:
276
The xml document I receive from my request is the following:
xsd:schema xmlns:AQUAMAPS=http://www.fao.org/aquamaps;
xmlns:AQUASTAT=http://www.fao.org/aquastat;
xmlns:COMMON=http://www.fao.org/common;
xmlns:COUNTRYPROFILES=http://www.fao.org/countryprofilesxmlns:FSATMI
S=http://www.fao.org/fsatmis; xmlns:GAEZ=http://www.fao.org/gaez;
xmlns:GEONETWORK=http://www.fao.org/geonetwork;
xmlns:SFS_LOCAL=http://www.fao.org/sfs_localxmlns:SFS_REMOTE=http:/
/www.fao.org/sfs_remote xmlns:SOLAW=http://www.fao.org/solaw;
xmlns:TEMP=http://www.fao.org/TEMP;
xmlns:gml=http://www.opengis.net/gmlxmlns:xsd=http://www.w3.org/200
1/XMLSchema elementFormDefault=qualified
targetNamespace=http://www.fao.org/aquastat;
xsd:import namespace=http://www.opengis.net/gml;
schemaLocation=http://hqlqatcdrgeo2.hq.un.fao.org:8081/geoserver/sche
mas/gml/3.1.1/base/gml.xsd/
xsd:complexType name=major_hydrobasinsType
xsd:complexContent
xsd:extension base=gml:AbstractFeatureType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=the_geom
nillable=true type=gml:MultiSurfacePropertyType/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_BAS
nillable=true type=xsd:long/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_NAME
nillable=true type=xsd:string/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_AREA
nillable=true type=xsd:int/
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
xsd:element name=major_hydrobasins substitutionGroup=gml:_Feature
type=AQUASTAT:major_hydrobasinsType/
/xsd:schema
If I use the jsonp format I receive the following object, that contains all
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
On 10 September 2012 17:58, Tim Schaub tsch...@opengeo.org wrote: I wanted to add a quick note to say that admins should be able to disable this feature. The security concern is minor, but it's a real hole that may raise red flags in some audits. Here's the (obviously contrived) situation where this allows secure data to leak to an evil hacker. Agent Geo is a staffer at a facility with data they hope to keep secure. Agent Geo runs a GeoServer that is available at http://localhost:8080/geoserver/, and has recently been browsing his top:secret feature type; having been prompted by GeoServer to enter his credentials, he did so. While on a lunch break, Agent Geo visits http://evilhacker.com/ a site maintained by Evil Hacker. Evil Hacker has been waiting for someone with a GeoServer on localhost and a feature type named top:secret to stumble upon his site. Wouldn't that be topp:secret? Sorry couldn't resist :-) Ian -- Ian Turton -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Agree with Andreas observations about Describe operations compliance w/ OL. == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 331 6233686 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justin, -- Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: -- Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=application/vnd.ogc.se_xmlSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You can specify the desired 'output_format': INFO_FORMAT=text/javascript and also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Me too. Andreas - is there somewhere that this object structure is documented? And is that structure going to remain the same for OL 3? On Fri, Sep 7, 2012 at 5:08 AM, Alessio Fabiani alessio.fabi...@geo-solutions.it wrote: Agree with Andreas observations about Describe operations compliance w/ OL. == Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Alessio Fabiani @alfa7691 Founder/Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 331 6233686 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.orgwrote: Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justin, -- Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: -- Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=application/vnd.ogc.se_xmlSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You can specify the desired 'output_format': INFO_FORMAT=text/javascript and also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Andreas, I know that the OL is a very common and widely used client but my intention was to map 1 to 1 the XML as a Json object.Where I can find documentation on the JSON format you are using?Carlo Date: Fri, 7 Sep 2012 08:40:00 -0400 From: chol...@opengeo.org To: alessio.fabi...@geo-solutions.it CC: geoserver-devel@lists.sourceforge.net; ahoce...@opengeo.org Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers Me too. Andreas - is there somewhere that this object structure is documented? And is that structure going to remain the same for OL 3? On Fri, Sep 7, 2012 at 5:08 AM, Alessio Fabiani alessio.fabi...@geo-solutions.it wrote: Agree with Andreas observations about Describe operations compliance w/ OL.==Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information. == Ing. Alessio Fabiani@alfa7691Founder/Technical Lead GeoSolutions S.A.S.Via Poggio alle Viti 118755054 Massarosa (LU) Italyphone: +39 0584 962313fax: +39 0584 962313 mob: +39 331 6233686 http://www.geo-solutions.it http://twitter.com/geosolutions_it --- On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justin, Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeaturesYou can specify the desired 'output_format': INFO_FORMAT=text/javascriptand also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
: {
type : string,
minimum : 0,
maxLength : 75
},
MAJ_AREA : {
type : integer,
minimum : 0,
maxLength : 9
}
}
}
}
} ])
Could you kindly provide a working example that returns the OpenLayers
converted json object? So we can compare it with the one returned from
Geoserver.
Thanks in advance.
Best Regards
Francesca Vigetti
From: Carlo Cancellieri [mailto:ccancelli...@hotmail.com]
Sent: 07 September 2012 4:18 PM
To: chol...@opengeo.org; alessio.fabi...@geo-solutions.it; Vigetti, Francesca
(CIOK)
Cc: geoserver-devel@lists.sourceforge.net; ahoce...@opengeo.org
Subject: RE: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
Andreas,
I know that the OL is a very common and widely used client but my intention
was to map 1 to 1 the XML as a Json object.
Where I can find documentation on the JSON format you are using?
Carlo
Date: Fri, 7 Sep 2012 08:40:00 -0400
From: chol...@opengeo.org
To: alessio.fabi...@geo-solutions.it
CC: geoserver-devel@lists.sourceforge.net; ahoce...@opengeo.org
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
Me too.
Andreas - is there somewhere that this object structure is documented? And is
that structure going to remain the same for OL 3?
On Fri, Sep 7, 2012 at 5:08 AM, Alessio Fabiani
alessio.fabi...@geo-solutions.it wrote:
Agree with Andreas observations about Describe operations compliance w/ OL.
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 331 6233686
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
On Thu, Sep 6, 2012 at 3:59 PM, Justin Deoliveira jdeol...@opengeo.org
wrote:
Hi Carlo,
I forward this proposal on to some of our javascript devs and here is some
feedback that Andreas, one of the core OpenLayers developers had.
quote
I like the idea of having JSONP output, but it would be nice if the
JavaScript payload would be in a structure that we can use out of the
box. For WMS GetFeatureInfo, the job is well done - it returns
GeoJSON. For the other requests (WFS DescribeFeatureType, WMS
DescribeLayer), OpenLayers has Format classes that read the XML into a
JavaScript object, but the GeoServer output is much different from
that object so applications would need heavy modifications when
switching from XML + OpenLayers.Format parsing to JSONP.
tl;dr: My suggestion would be to have GeoServer return the same object
structure that OpenLayers.Format.WMSDescribeLayer and
OpenLayers.Format.WFSDescribeFeatureType generate.
/quote
On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.com
wrote:
Hi Justin,
Date: Wed, 5 Sep 2012 20:53:32 -0400
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: jdeol...@opengeo.org
To: ccancelli...@hotmail.com
CC: geoserver-devel@lists.sourceforge.net
Thanks for laying that out Carlo.
In the wms doc noticed a small typo in the last table in the DescribeLayer
section, both formats are listed as JSONP ,i believe the first one should
be just JSON?
Oops... yes, I'll fix it.
Also a question, does the default callback function name paddingOutput
come from anywhere? Like is it a convention? The wikipedia page uses
parseResponse as an example which sort of makes sense.
Don't think there's a standard/convention, about this, it simply comes out
from padding() +output. We could define a better one commenting the GSIP.
No strong opinion here. If there was something of a convention to follow i
would say go with that but if not no worries.
Carlo
On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com
wrote:
Hi Justing,
response inline:
Date: Wed, 5 Sep 2012 12:35:46 -0400
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: jdeol...@opengeo.org
To: ccancelli...@hotmail.com
CC: geoserver-devel@lists.sourceforge.net
Thanks Carlo.
It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was
some links there and also a bit of a description in the proposal itself
rather than having to go into the issues and try to determine what the high
level changes are.
OK, i'll do
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Andreas, ok, that's good for me, I'll wait for other opinions than proceed to
changes (if needed).
What about DescribeLayer? I see that the returned by OL format is:
[{layerName:AQUASTAT:data_by_indicator,owsType:WFS,owsURL:http:/X/geoserver/wfs/WfsDispatcher?,typeName:AQUASTAT:data_by_indicator}]
Which does not include the versionThis is the current implementation:
WMS_DescribeLayerResponse: {version: 1.1.1,LayerDescription: {name:
AQUASTAT:data_by_indicator,owsURL: http://
X /geoserver/wfs/WfsDispatcher?,owsType: WFS}
Ciao,Carlo
Date: Fri, 7 Sep 2012 17:08:52 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: francesca.vige...@fao.org
CC: ccancelli...@hotmail.com; chol...@opengeo.org;
alessio.fabi...@geo-solutions.it; geoserver-devel@lists.sourceforge.net
@Carlo: unfortunately there is no good documentation of the format.
For now the best source is looking at the unit tests - see
https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html
and
https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html.
@Francesca: the proper way to read a responseXML is as follows:
new OpenLayers.Format.WFSDescribeFeatureType().read(xml /*XmlDoc or string*/);
new OpenLayers.Format.WFSDescribeLayer().read(xml /*XmlDoc or string*/);
For the XML you provided, OpenLayers would expect the following:
{
elementFormDefault: qualified,
targetNamespace: http://www.fao.org/aquastat;,
featureTypes: [
{
typeName: major_hydrobasins,
properties: [
{
maxOccurs: 1,
minOccurs: 0,
name: the_geom,
nillable: true,
type: gml:MultiSurfacePropertyType,
localType: MultiSurfacePropertyType
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_BAS,
nillable: true,
type: xsd:long,
localType: long
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_NAME,
nillable: true,
type: xsd:string,
localType: string
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_AREA,
nillable: true,
type: xsd:int,
localType: int
}
]
}
],
targetPrefix: AQUASTAT
}
I hope this helps,
Andreas
On Fri, Sep 7, 2012 at 4:34 PM, Vigetti, Francesca (CIOK)
francesca.vige...@fao.org wrote:
Dear All,
Since I am involved in this task, I was trying to test the
OpenLayers.Format.XML with the output of a describeFeatureType call, but I
haven’t found a method to read the whole xml document at a time.
Looking for a solution I found the OpenLayers.Format.XML.VersionedOGC that
has a read method. I have just applied this to my situation but I receive
the following error:
1. Uncaught TypeError: Cannot call method 'replace' of null
OpenLayers.js:275
1.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.getParserOpenLayers.js:275
2.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.readOpenLayers.js:276
The xml document I receive from my request is the following:
xsd:schema xmlns:AQUAMAPS=http://www.fao.org/aquamaps;
xmlns:AQUASTAT=http://www.fao.org/aquastat;
xmlns:COMMON=http://www.fao.org/common;
xmlns:COUNTRYPROFILES=http://www.fao.org/countryprofilesxmlns:FSATMIS=http://www.fao.org/fsatmis;
xmlns:GAEZ=http://www.fao.org/gaez;
xmlns:GEONETWORK=http://www.fao.org/geonetwork;
xmlns:SFS_LOCAL=http://www.fao.org/sfs_localxmlns:SFS_REMOTE=http://www.fao.org/sfs_remote;
xmlns:SOLAW=http://www.fao.org/solaw;
xmlns:TEMP=http://www.fao.org/TEMP;
xmlns:gml=http://www.opengis.net/gmlxmlns:xsd=http://www.w3.org/2001/XMLSchema;
elementFormDefault=qualified
targetNamespace=http://www.fao.org/aquastat;
xsd:import namespace=http://www.opengis.net/gml;
schemaLocation=http://hqlqatcdrgeo2.hq.un.fao.org:8081/geoserver/schemas/gml/3.1.1/base/gml.xsd/
xsd:complexType name=major_hydrobasinsType
xsd:complexContent
xsd:extension base=gml:AbstractFeatureType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=the_geom nillable=true
type=gml:MultiSurfacePropertyType/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_BAS nillable=true
type=xsd:long/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_NAME nillable=true
type=xsd:string/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_AREA
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hey Carlo,
the version is omitted in the result because it is only relevant to
the XML parser that provides the result.
The important thing (and missing in your current implementation) is
that the returned structure is an array, to support WMS DescribeLayer
responses for multiple layer names (e.g.
http://localhost:8080/geoserver/wms?SERVICE=WMSVERSION=1.1.1REQUEST=DescribeLayerLAYERS=usa:states,medford:zoning).
Andreas.
On Fri, Sep 7, 2012 at 6:41 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
Andreas,
ok, that's good for me, I'll wait for other opinions than proceed to
changes (if needed).
What about DescribeLayer? I see that the returned by OL format is:
[{layerName:AQUASTAT:data_by_indicator,owsType:WFS,owsURL:http:/X/geoserver/wfs/WfsDispatcher?,typeName:AQUASTAT:data_by_indicator}]
Which does not include the version
This is the current implementation:
WMS_DescribeLayerResponse: {
version: 1.1.1,
LayerDescription: {
name: AQUASTAT:data_by_indicator,
owsURL: http:// X /geoserver/wfs/WfsDispatcher?,
owsType: WFS
}
Ciao,
Carlo
Date: Fri, 7 Sep 2012 17:08:52 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: francesca.vige...@fao.org
CC: ccancelli...@hotmail.com; chol...@opengeo.org;
alessio.fabi...@geo-solutions.it; geoserver-devel@lists.sourceforge.net
@Carlo: unfortunately there is no good documentation of the format.
For now the best source is looking at the unit tests - see
https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html
and
https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html.
@Francesca: the proper way to read a responseXML is as follows:
new OpenLayers.Format.WFSDescribeFeatureType().read(xml /*XmlDoc or
string*/);
new OpenLayers.Format.WFSDescribeLayer().read(xml /*XmlDoc or string*/);
For the XML you provided, OpenLayers would expect the following:
{
elementFormDefault: qualified,
targetNamespace: http://www.fao.org/aquastat;,
featureTypes: [
{
typeName: major_hydrobasins,
properties: [
{
maxOccurs: 1,
minOccurs: 0,
name: the_geom,
nillable: true,
type: gml:MultiSurfacePropertyType,
localType: MultiSurfacePropertyType
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_BAS,
nillable: true,
type: xsd:long,
localType: long
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_NAME,
nillable: true,
type: xsd:string,
localType: string
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_AREA,
nillable: true,
type: xsd:int,
localType: int
}
]
}
],
targetPrefix: AQUASTAT
}
I hope this helps,
Andreas
On Fri, Sep 7, 2012 at 4:34 PM, Vigetti, Francesca (CIOK)
francesca.vige...@fao.org wrote:
Dear All,
Since I am involved in this task, I was trying to test the
OpenLayers.Format.XML with the output of a describeFeatureType call, but I
haven’t found a method to read the whole xml document at a time.
Looking for a solution I found the OpenLayers.Format.XML.VersionedOGC
that has a read method. I have just applied this to my situation but I
receive the following error:
1. Uncaught TypeError: Cannot call method 'replace' of null
OpenLayers.js:275
1.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.getParserOpenLayers.js:275
2.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.readOpenLayers.js:276
The xml document I receive from my request is the following:
xsd:schema xmlns:AQUAMAPS=http://www.fao.org/aquamaps;
xmlns:AQUASTAT=http://www.fao.org/aquastat;
xmlns:COMMON=http://www.fao.org/common;
xmlns:COUNTRYPROFILES=http://www.fao.org/countryprofilesxmlns:FSATMIS=http://www.fao.org/fsatmis;
xmlns:GAEZ=http://www.fao.org/gaez;
xmlns:GEONETWORK=http://www.fao.org/geonetwork;
xmlns:SFS_LOCAL=http://www.fao.org/sfs_localxmlns:SFS_REMOTE=http://www.fao.org/sfs_remote;
xmlns:SOLAW=http://www.fao.org/solaw; xmlns:TEMP=http://www.fao.org/TEMP;
xmlns:gml=http://www.opengis.net/gmlxmlns:xsd=http://www.w3.org/2001/XMLSchema;
elementFormDefault=qualified
targetNamespace=http://www.fao.org/aquastat;
xsd:import namespace=http://www.opengis.net/gml;
schemaLocation=http://hqlqatcdrgeo2.hq.un.fao.org:8081/geoserver/schemas/gml/3.1.1/base/gml.xsd/
xsd:complexType name=major_hydrobasinsType
xsd:complexContent
xsd:extension base=gml:AbstractFeatureType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name=the_geom nillable=true
type=gml:MultiSurfacePropertyType/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_BAS nillable=true
type=xsd:long/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_NAME nillable=true
type=xsd:string/
xsd:element maxOccurs=1 minOccurs=0 name=MAJ_AREA nillable=true
type=xsd:int/
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
xsd:element name=major_hydrobasins
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
I should add though that it will probably make sense to have GeoServer
return an object with a layerDescription property that holds the array
of descriptions, instead of just the array. First of all, it is quite
common in JSONP to return an object (and not an array), and it also
leaves room for future additions of elements at the root level.
Andreas.
On Fri, Sep 7, 2012 at 7:07 PM, Andreas Hocevar ahoce...@opengeo.org wrote:
Hey Carlo,
the version is omitted in the result because it is only relevant to
the XML parser that provides the result.
The important thing (and missing in your current implementation) is
that the returned structure is an array, to support WMS DescribeLayer
responses for multiple layer names (e.g.
http://localhost:8080/geoserver/wms?SERVICE=WMSVERSION=1.1.1REQUEST=DescribeLayerLAYERS=usa:states,medford:zoning).
Andreas.
On Fri, Sep 7, 2012 at 6:41 PM, Carlo Cancellieri
ccancelli...@hotmail.com wrote:
Andreas,
ok, that's good for me, I'll wait for other opinions than proceed to
changes (if needed).
What about DescribeLayer? I see that the returned by OL format is:
[{layerName:AQUASTAT:data_by_indicator,owsType:WFS,owsURL:http:/X/geoserver/wfs/WfsDispatcher?,typeName:AQUASTAT:data_by_indicator}]
Which does not include the version
This is the current implementation:
WMS_DescribeLayerResponse: {
version: 1.1.1,
LayerDescription: {
name: AQUASTAT:data_by_indicator,
owsURL: http:// X /geoserver/wfs/WfsDispatcher?,
owsType: WFS
}
Ciao,
Carlo
Date: Fri, 7 Sep 2012 17:08:52 +0200
Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
ExceptionHandlers
From: ahoce...@opengeo.org
To: francesca.vige...@fao.org
CC: ccancelli...@hotmail.com; chol...@opengeo.org;
alessio.fabi...@geo-solutions.it; geoserver-devel@lists.sourceforge.net
@Carlo: unfortunately there is no good documentation of the format.
For now the best source is looking at the unit tests - see
https://github.com/openlayers/openlayers/blob/master/tests/Format/WFSDescribeFeatureType.html
and
https://github.com/openlayers/openlayers/blob/master/tests/Format/WMSDescribeLayer.html.
@Francesca: the proper way to read a responseXML is as follows:
new OpenLayers.Format.WFSDescribeFeatureType().read(xml /*XmlDoc or
string*/);
new OpenLayers.Format.WFSDescribeLayer().read(xml /*XmlDoc or string*/);
For the XML you provided, OpenLayers would expect the following:
{
elementFormDefault: qualified,
targetNamespace: http://www.fao.org/aquastat;,
featureTypes: [
{
typeName: major_hydrobasins,
properties: [
{
maxOccurs: 1,
minOccurs: 0,
name: the_geom,
nillable: true,
type: gml:MultiSurfacePropertyType,
localType: MultiSurfacePropertyType
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_BAS,
nillable: true,
type: xsd:long,
localType: long
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_NAME,
nillable: true,
type: xsd:string,
localType: string
},
{
maxOccurs: 1,
minOccurs: 0,
name: MAJ_AREA,
nillable: true,
type: xsd:int,
localType: int
}
]
}
],
targetPrefix: AQUASTAT
}
I hope this helps,
Andreas
On Fri, Sep 7, 2012 at 4:34 PM, Vigetti, Francesca (CIOK)
francesca.vige...@fao.org wrote:
Dear All,
Since I am involved in this task, I was trying to test the
OpenLayers.Format.XML with the output of a describeFeatureType call, but I
haven’t found a method to read the whole xml document at a time.
Looking for a solution I found the OpenLayers.Format.XML.VersionedOGC
that has a read method. I have just applied this to my situation but I
receive the following error:
1. Uncaught TypeError: Cannot call method 'replace' of null
OpenLayers.js:275
1.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.getParserOpenLayers.js:275
2.
OpenLayers.Format.XML.VersionedOGC.OpenLayers.Class.readOpenLayers.js:276
The xml document I receive from my request is the following:
xsd:schema xmlns:AQUAMAPS=http://www.fao.org/aquamaps;
xmlns:AQUASTAT=http://www.fao.org/aquastat;
xmlns:COMMON=http://www.fao.org/common;
xmlns:COUNTRYPROFILES=http://www.fao.org/countryprofilesxmlns:FSATMIS=http://www.fao.org/fsatmis;
xmlns:GAEZ=http://www.fao.org/gaez;
xmlns:GEONETWORK=http://www.fao.org/geonetwork;
xmlns:SFS_LOCAL=http://www.fao.org/sfs_localxmlns:SFS_REMOTE=http://www.fao.org/sfs_remote;
xmlns:SOLAW=http://www.fao.org/solaw;
xmlns:TEMP=http://www.fao.org/TEMP;
xmlns:gml=http://www.opengis.net/gmlxmlns:xsd=http://www.w3.org/2001/XMLSchema;
elementFormDefault=qualified
targetNamespace=http://www.fao.org/aquastat;
xsd:import namespace=http://www.opengis.net/gml;
schemaLocation=http://hqlqatcdrgeo2.hq.un.fao.org:8081/geoserver/schemas/gml/3.1.1/base/gml.xsd/
xsd:complexType name=major_hydrobasinsType
xsd:complexContent
xsd:extension base=gml:AbstractFeatureType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=0 name
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi Justin, Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeaturesYou can specify the desired 'output_format': INFO_FORMAT=text/javascriptand also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures You'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in a jsonP format with the callback function called getLayerFeatures NOTE: 1. I don't added a specific format_option for exception callback right now, do we really need one? 2. The format_options callback parameter is NOT mandatory in that case (JSONP for response or exception) the default one is used paddingOutput (see JSONType). Same things can be obtained when you use application/json. In that case you are simply asking for a json without the callback function (which is ignored if specified). Json and JsonP http://en.wikipedia.org/wiki/JSONP Take also a look to examples here: http://docs.geoserver.org/latest/en/user/services/wms/reference.html Hope that this answers your questions. Cheers, Carlo Thanks. -Justin On Wed, Sep 5, 2012 at 12:16 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi all, the GSIP 79 (about Json ExceptionHandlers) is here:http://geoserver.org/pages/viewpage.action?pageId=49938445 It is already committed on the master branch and it would be nice to discuss about its backport to the stable release 2.2.2. Cheers,Carlo Date: Mon, 3 Sep 2012 11:31:21 -0500 From: j...@codehaus.org To: ccancelli...@hotmail.com Subject: [jira] (GEOS-5247) Json[p] WFS and WMS exceptionHandler Justin Deoliveira commented on GEOS-5247 Json[p] WFS and WMS exceptionHandler Any chance we can get a short GSIP before the work
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi Carlo, I forward this proposal on to some of our javascript devs and here is some feedback that Andreas, one of the core OpenLayers developers had. quote I like the idea of having JSONP output, but it would be nice if the JavaScript payload would be in a structure that we can use out of the box. For WMS GetFeatureInfo, the job is well done - it returns GeoJSON. For the other requests (WFS DescribeFeatureType, WMS DescribeLayer), OpenLayers has Format classes that read the XML into a JavaScript object, but the GeoServer output is much different from that object so applications would need heavy modifications when switching from XML + OpenLayers.Format parsing to JSONP. tl;dr: My suggestion would be to have GeoServer return the same object structure that OpenLayers.Format.WMSDescribeLayer and OpenLayers.Format.WFSDescribeFeatureType generate. /quote On Thu, Sep 6, 2012 at 6:37 AM, Carlo Cancellieri ccancelli...@hotmail.comwrote: Hi Justin, -- Date: Wed, 5 Sep 2012 20:53:32 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks for laying that out Carlo. In the wms doc noticed a small typo in the last table in the DescribeLayer section, both formats are listed as JSONP ,i believe the first one should be just JSON? Oops... yes, I'll fix it. Also a question, does the default callback function name paddingOutput come from anywhere? Like is it a convention? The wikipedia page uses parseResponse as an example which sort of makes sense. Don't think there's a standard/convention, about this, it simply comes out from padding() +output. We could define a better one commenting the GSIP. No strong opinion here. If there was something of a convention to follow i would say go with that but if not no worries. Carlo On Wed, Sep 5, 2012 at 2:25 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi Justing, response inline: -- Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=application/vnd.ogc.se_xmlSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You can specify the desired 'output_format': INFO_FORMAT=text/javascript and also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures http://localhost:8080/geoserver/wms?INFO_FORMAT=text/javascriptREQUEST=GetFeatureInfoEXCEPTIONS=text/javascriptSERVICE=WMSINFO_FORMAT=text/javascriptVERSION=1.1.1WIDTH=970HEIGHT=485X=486Y=165BBOX=-180%2c-90%2c180%2c90LAYERS=COUNTRYPROFILES:grp_administrative_mapQUERY_LAYERS=COUNTRYPROFILES:grp_administrative_mapTYPENAME=COUNTRYPROFILES:grp_administrative_mapformat_options=callback:getLayerFeatures You'll get: case
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Thanks. -Justin On Wed, Sep 5, 2012 at 12:16 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi all, the GSIP 79 (about Json ExceptionHandlers) is here: http://geoserver.org/pages/viewpage.action?pageId=49938445 It is already committed on the master branch and it would be nice to discuss about its backport to the stable release 2.2.2. Cheers, Carlo -- Date: Mon, 3 Sep 2012 11:31:21 -0500 From: j...@codehaus.org To: ccancelli...@hotmail.com Subject: [jira] (GEOS-5247) Json[p] WFS and WMS exceptionHandler Justin Deoliveirahttps://jira.codehaus.org/secure/ViewProfile.jspa?name=jdeolivecommented on [image: Improvement] GEOS-5247 https://jira.codehaus.org/browse/GEOS-5247 *Json[p] WFS and WMS exceptionHandler*https://jira.codehaus.org/browse/GEOS-5247 Any chance we can get a short GSIP before the work is backported. Maybe at least just summarizing all the info placed into the various tickets. It would be nice to get some more javascript developers eyes on this on before it's set in stone on the stable branch. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administratorshttps://jira.codehaus.org/secure/ContactAdministrators%21default.jspa . For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers
Hi Justing, response inline: Date: Wed, 5 Sep 2012 12:35:46 -0400 Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers From: jdeol...@opengeo.org To: ccancelli...@hotmail.com CC: geoserver-devel@lists.sourceforge.net Thanks Carlo. It seems thsi proposal encompasses GEOS-5246 as well, be nice is there was some links there and also a bit of a description in the proposal itself rather than having to go into the issues and try to determine what the high level changes are. OK, i'll do it. That said, i have questions about mime types used. I see both application/json and text/javascript used for both output format and exceptions. Can you provide a bit of clarity there? Is text/javascript used to suppor the jsonp callback? In conjunction with the callback format option? Let's say f.e. in a request like this: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=application/vnd.ogc.se_xml SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeaturesYou can specify the desired 'output_format': INFO_FORMAT=text/javascriptand also the desired exception format: EXCEPTIONS=application/vnd.ogc.se_xml In this case you'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in an xml format (as default) Now if you change that request in: http://localhost:8080/geoserver/wms? INFO_FORMAT=text/javascript REQUEST=GetFeatureInfo EXCEPTIONS=text/javascript SERVICE=WMS INFO_FORMAT=text/javascript VERSION=1.1.1 WIDTH=970HEIGHT=485X=486Y=165BBOX=-180,-90,180,90 LAYERS=COUNTRYPROFILES:grp_administrative_map QUERY_LAYERS=COUNTRYPROFILES:grp_administrative_map TYPENAME=COUNTRYPROFILES:grp_administrative_map format_options=callback:getLayerFeatures You'll get: case 1: - the response in a jsonP format with the callback function called getLayerFeatures case 2: - the exception in a jsonP format with the callback function called getLayerFeatures NOTE: 1. I don't added a specific format_option for exception callback right now, do we really need one? 2. The format_options callback parameter is NOT mandatory in that case (JSONP for response or exception) the default one is used paddingOutput (see JSONType). Same things can be obtained when you use application/json. In that case you are simply asking for a json without the callback function (which is ignored if specified). Json and JsonP http://en.wikipedia.org/wiki/JSONP Take also a look to examples here: http://docs.geoserver.org/latest/en/user/services/wms/reference.html Hope that this answers your questions. Cheers, Carlo Thanks. -Justin On Wed, Sep 5, 2012 at 12:16 PM, Carlo Cancellieri ccancelli...@hotmail.com wrote: Hi all, the GSIP 79 (about Json ExceptionHandlers) is here:http://geoserver.org/pages/viewpage.action?pageId=49938445 It is already committed on the master branch and it would be nice to discuss about its backport to the stable release 2.2.2. Cheers,Carlo Date: Mon, 3 Sep 2012 11:31:21 -0500 From: j...@codehaus.org To: ccancelli...@hotmail.com Subject: [jira] (GEOS-5247) Json[p] WFS and WMS exceptionHandler Justin Deoliveira commented on GEOS-5247 Json[p] WFS and WMS exceptionHandler Any chance we can get a short GSIP before the work is backported. Maybe at least just summarizing all the info placed into the various tickets. It would be nice to get some more javascript developers eyes on this on before it's set in stone on the stable branch. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include
