Hi,
using geoserver trunk, basic.zip configuration, and the following request:
http://localhost:8080/geoserver/wms?service=WMS&request=GetFeatureInfo&bbox=-130,24,-66,50&format=image/jpeg&layers=states&styles=&width=550&height=250&query_layers=states&x=170&y=160&info_format=text/plain
I get the following error:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?><!DOCTYPE ServiceExceptionReport SYSTEM "http://localhost:8080/geoserver/schemas//wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1"> <ServiceException>Argument "sourceCRS" should not be null.</ServiceException> </ServiceExceptionReport>
Hmm.... sourceCRS is definitely not a WMS 1.1.1 parameter... did I spot a bug, or I'm missing something obvious?
Cheers
Andrea
Brent just did a fix to try to get reprojection working right, so maybe some small thing is off with the fix.
But you should be including an EPSG code, as it's a normal part of the WMS request, and GetFeatureInfo relies on having a full WMS request embedded in it. So try with an epsg code. But regardless we should be returning a better error.
Chris
aaime@anonymised.com wrote:
Hi,
using geoserver trunk, basic.zip configuration, and the following request:
http://localhost:8080/geoserver/wms?service=WMS&request=GetFeatureInfo&bbox=-130,24,-66,50&format=image/jpeg&layers=states&styles=&width=550&height=250&query_layers=states&x=170&y=160&info_format=text/plain
I get the following error:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?><!DOCTYPE ServiceExceptionReport SYSTEM "http://localhost:8080/geoserver/schemas//wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1"> <ServiceException>Argument "sourceCRS" should not be null.</ServiceException> </ServiceExceptionReport>
Hmm.... sourceCRS is definitely not a WMS 1.1.1 parameter... did I spot a bug, or I'm missing something obvious?
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,452112a4258642223018498!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Brent just did a fix to try to get reprojection working right, so maybe some small thing is off with the fix.
But you should be including an EPSG code, as it's a normal part of the WMS request, and GetFeatureInfo relies on having a full WMS request embedded in it. So try with an epsg code. But regardless we should be returning a better error.
Hum, the WMS response code includes SRS among the non mandatory parameters, and works
fine without it specified, so by extension getFeatureInfo should work fine without it too, no?
I already committed a fix on trunk and... arg! I just re-read the WMS spec and in fact SRS is required.
So what, do I revert the change and make getMap require SRS parameter as well?
Cheers
Andrea
Yeh SRS looks like it is required.
Did you fix it so it is optional? I've seen comments floating around in code saying that "SRS is mandatory but we are making it optional here". Can't find that code right now but I have seen it before.
I personally think that if they don't specify an SRS, the default is returned. Just to make things easier for the user.
Brent Owens
(The Open Planning Project)
aaime@anonymised.com wrote:
Chris Holmes ha scritto:
Brent just did a fix to try to get reprojection working right, so maybe some small thing is off with the fix.
But you should be including an EPSG code, as it's a normal part of the WMS request, and GetFeatureInfo relies on having a full WMS request embedded in it. So try with an epsg code. But regardless we should be returning a better error.
Hum, the WMS response code includes SRS among the non mandatory parameters, and works
fine without it specified, so by extension getFeatureInfo should work fine without it too, no?
I already committed a fix on trunk and... arg! I just re-read the WMS spec and in fact SRS is required.
So what, do I revert the change and make getMap require SRS parameter as well?
Cheers
Andrea
Brent Owens ha scritto:
Yeh SRS looks like it is required.
Did you fix it so it is optional? I've seen comments floating around in code saying that "SRS is mandatory but we are making it optional here". Can't find that code right now but I have seen it before.
I personally think that if they don't specify an SRS, the default is returned. Just to make things easier for the user.
The geoserver getMap behaviour was already to be lenient, and worked even without the SRS parameter.
The getFeatureInfo was not because it assumed SRS was always there, I just added a check to avoid
the x,y parameters coordinate reprojection in case the SRS is not specified, to make getFeatureInfo consistent with
getMap.
Cheers
Andrea
aaime@anonymised.com wrote:
Brent Owens ha scritto:
Yeh SRS looks like it is required.
Did you fix it so it is optional? I've seen comments floating around in code saying that "SRS is mandatory but we are making it optional here". Can't find that code right now but I have seen it before.
I personally think that if they don't specify an SRS, the default is returned. Just to make things easier for the user.
The geoserver getMap behaviour was already to be lenient, and worked even without the SRS parameter.
The getFeatureInfo was not because it assumed SRS was always there, I just added a check to avoid
the x,y parameters coordinate reprojection in case the SRS is not specified, to make getFeatureInfo consistent with
getMap.
That sounds like the best solution. I think it's fine for us to stay lenient. Just as long as we're consistent.
Chris
Cheers
Andrea
!DSPAM:1003,4521308e289734750375898!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
aaime@anonymised.com wrote:
Brent Owens ha scritto:
Yeh SRS looks like it is required.
Did you fix it so it is optional? I've seen comments floating around in code saying that "SRS is mandatory but we are making it optional here". Can't find that code right now but I have seen it before.
I personally think that if they don't specify an SRS, the default is returned. Just to make things easier for the user.
The geoserver getMap behaviour was already to be lenient, and worked even without the SRS parameter.
The getFeatureInfo was not because it assumed SRS was always there, I just added a check to avoid
the x,y parameters coordinate reprojection in case the SRS is not specified, to make getFeatureInfo consistent with
getMap.
That sounds like the best solution. I think it's fine for us to stay lenient. Just as long as we're consistent.
For consistency sake then, issue http://jira.codehaus.org/browse/GEOS-710 should be
resolved by not checking the VERSION parameter at all, since the other requests does not seem
to do anything but setting whatever version was required, working fine even if I do require version 0.1
or version "gizmo"...
Not sure the Geoserver behaviour is correct here thought, we should throw a service exception if
we are asked for an unsupported version... WMS wise, we do support 1.1.1, by extension 1.1.0,
I suppose 1.0.0 too?
Cheers
Andrea