Martin, Thanks for all your thoughts in this matter. I'm not trying to be a stubborn thorn in the side of reason, more a devil's advocate. So, acknowledging the risk of beating this near dead horse further...
On Tue, Jul 17, 2012 at 10:45 AM, Andrea Aime <[email protected]> wrote: > On Tue, Jul 17, 2012 at 6:18 PM, Martin Davis <[email protected]> wrote: >> >> Two more thoughts in favour of "reduced precision = interval": >> >> 1. Expressiveness - If reduced-precision time strings are taken to mean a >> precise instant, then there is no simple way of expressing a standard >> interval. Whereas if reduced-precision is interpreted as an interval, it's >> still possible to express an instant via a full-precision string. Agreed. My counterpoint would be that by being explicit, both are supported. Since software is going to be making the request, the 'expressiveness' argument seems less convincing - the client can support being expressive whilst still adhering to the protocol. While making manual WMS requests is a nice option when debugging, how many folks beyond developers are manually editing WMS parameters to achieve success in their endeavors? To address the concern about February being a leap month, most clients would have access to calendar math and could formulate the appropriate request. >> 2. Common Usage: When someone says "2012" they typically mean the entire >> year 2012, not the instant at the start of the year. Likewise for other >> reduced-precision expressions of time. (I realize that standards often >> don't let reality intrude, but it might be taken into consideration in >> absence of other clear direction) Totally and completely agree. The problem as I see it is that to achieve both 'Common Usage' _and_ adhere to the spec, we introduce a difference in behavior - if 2012 means all of 2012 excluding 2013-01-01T00:00:00Z but 2012/2013 means _including_ that first day of the new year (as per the spec), then this would bad™. I again submit the evidence that in many domains, single increments on a precision element (e.g. 1 year, 1 month, etc.) are _not_ standard or common usage (think census data, seasonal weather deviations from norm, stream gauge-data, weather forecasts, etc.). hair-splitting standards wonkery(© mdavis), indeed... Cheers®, -Ian > > > Agreed this is a sensible approach. Hopefully Justin will be able to find > some more guidance about this > with OGC. > > The CITE tests are a bit funky, but as far as I remember one has to be able > to configure precise and non precise > handling on a per layer basis to pass them, so hopefully there is some test > checking both ways. > > Cheers > Andrea > > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for more > information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Ian Schneider 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
