I imagine this was destined for geoserver-devel so moved it.
Thanks for tackling the wms cite issues. I can confirm that both wms 1.1 and wms 1.3 tests are ready to go. WHen i get some time i will parse through your feedback on the elevation stuff more closely but it doesn’t surprise me that the tests are out of wack. Welcome to months of my life wasted 
Anyways, i think its fine for now to ignore compliance levels that don’t make sense because of the tests themselves. We do this with xlink for wfs as well. The alternative is to try and work with the cite groups to update the tests. Which while they seem to open to such things is a very long process. Just getting some blatantly obvious patches in for the wfs tests is taking weeks. I can’t imagine what a major overhaul would take
-Justin
On Sat, Jun 9, 2012 at 2:51 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
just fixed the cite WMS 1.3 test suite too, it was a matter of setting
the proper srs handling
to make the KML output formats work.I also noticed the WMS 1.3 has the ability to test time and elevation
and had a look at it.
Unfortunately there are roadblocks, the cite test suite makes too many
assumptions
about optional stuff:
http://cite.opengeospatial.org/teamengine/wms-1.3.0-r1/In particular:
- the raster elevation test seems to imply one can publish a elevation
dataset and
have its values treated as elevations, so that, for example, one can
select 100/200
and thus get back only the pixels at those elevations.
The spec does not suggest anything like that, while I can prepare a
mosaic that
would work (and it would have 425 separate files…) it seems to me the
test is oddly setup- “nearest” value support is afaik optional, yet the tests for vector elevation
and vector time demand it…- multiplevalues attribute is not exposed by GeoServer, but in
practice GS always
accept multiple values, yet the test demands that one can setup time
and elevation
so that multiple values are not supported… this is a configuration
we’re missing- the time support one works off a shapefile that has the time stored as text,
which again we don’t support (we’d need to use converters to handle
a time that
way)… I guess that for this specific one we could try a convertion
to property
file (since the shapefile spec does not support timestamp, the
shapefile store can
actually use that type but it requires a special system variable to
be setup)…Some thing could be fixed/adapted, but the test requirements to expose the
optional attributes multiplevalues/nearestvalues are imho out of lineCheers
Andrea–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech leadVia Poggio alle Viti 1187
55054 Massarosa (LU)
Italyphone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
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/
GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.