Hi Jody, Thanks for looking at this. Short story is that I want to be able to parse TIME dimensions and extents, but I do understand the need to make this more generic and/or a better API than in this patch.
Long story is that the main purpose of the patch is to at all be able to parse the Dimension and Extent tags in WMS capabilities. The use case is that GWC is using this part of GeoTools to configure itself from WMS capabilities and that I want to be able to take this information into consideration. At the moment this would require a very ugly hack in GWC since the information isn't accessable from the current GeoTools API. Specifically I'm trying to support TIME dimensions but, at least initially, I do not need full ISO8601+extensions parsing. I can't say I know much about it but I do not on first glance understand how CRSEnvelope could be used support generic dimensions? PS. I tried to find anything about the work done in openlayers to support rotation but no luck as of yet (even tried searching the developer in questions sandbox). 2010/3/7 Jody Garnett <jody.garn...@gmail.com>: > I am going to go over your test cases and see if we can come up with a > different way of accomplishing the same goal. > My best through is to take the CRSEnvelope implementation (which already > represents Dimensions as recorded by a CoordinateReferenceSystem object > along with an extent along each dimension) and see if can drag out helper > methods so the information you are seeking is a bit more obvious. > When done I will upload the patch back to GEOT-2305 for your review. > A couple of questions (or things you can think about when reviewing): > - are you intending to handle straight dimensions from the > CoordinateReferenceSystem? > - do you want to handle other ranges such as "time", "elevation" or angle? > Jody > On 07/03/2010, at 1:50 AM, Jody Garnett wrote: > > So I have gone over this patch ... and it really looks like a data structure > rather then an object. > As an example we have units and unitSymbol as a string; were possible we use > a real java Unit class (which knows its symbol). The extent is holding onto > a value as a String (an unparsed string since it is a CDATA section. > Perhaps we could back up and look at what data is being communicated here? > We already have CRSEnvelope and boundingBoxes and others in the mix trying > to capture this information. > I would like to make use of these facilities; extending CRSEnvelope if we > need to cover additional dimensions. > Jody > > On 05/03/2010, at 8:53 PM, Björn Harrtell wrote: > > FYI I got ahead of myself so the patch is now updated, fixed and > including tests :) > > Den 4 mars 2010 19.51 skrev Björn Harrtell <bjorn.harrt...@gmail.com>: > > A long time ago a colleague of mine wrote a patch to support Dimension > > and Extent tags in WMS capabilities documents. It lives here > > https://jira.codehaus.org/browse/GEOT-2305 > > I was wondering if I can gather any interest in accepting this patch? :) > > If so I'm willing to contribute test cases and I'm happy with it > > getting into 2.6 only. > > Regards, > > /Björn Harrtell > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
