On Tue, Jun 26, 2012 at 10:26 PM, Michael Romero <[email protected]>wrote:
> I created a custom coverage store for forecasted METOC data and use the > TIME and ELEVATION dimensions pretty heavily. > Nice. Is this store something that could be of general use? What kind of data source does it use? (just curious) > The problem I have is that not all of the data has elevation in meters. > Some data has elevation in mbar, C, etc. The units and unitSymbol in the > WMS (1.3.0) capabilities document is hard coded to meters in > DimensionHelper.java. I am planning on imlemeting a solution to this and > submitting a patch but, since it touches various component, I thought I'd > run it by the GeoServer developers first. > Good call :) > > To be a complete capability it requires adding functionality to the admin > web UI, the REST interface, and capabilities document(s) transformer. Since > the WMS Specification requires the units for TIME be ISO8601 without a > unitSymbol I plan on only adding these fields to the ELEVATION web UI. > > > > Makes sense, but wondering if it would not be better to have a single drop down with the list of the ISO units. Isn't the unit symbol implied by the chosen unit? > The units/unitSymbol will need to be stored in the DimensionInfoImpl class > so it can be retrieved the capabilities transformer. Adding these > attributes to the capabilities document is relatively simple. > > <Dimension name="elevation" default="2.0" units="unit_name" unitSymbol=" > unit_symbol">2.0,4.0,6.0</Dimension> > > As far as adding the functionality to the REST interface it would look > like this: > > <metadata> > <entry key="elevation"> > <dimensionInfo> > <enabled>true</enabled> > <attribute>elev_attribute</attribute> > <presentation>LIST</presentation> > <units>unit_name</units> > <unitSymbol>unit_symbol</unitSymbol> > </dimensionInfo > </entry> > </metadata> > > The examples in the documentation of adding a coverage via the REST API do > not include the TIME/ELEVATION dimensions so I was panning on adding this > including the units/unitSymbol. > > I have already read Annex C of the WMS 1.3.0 Specification about handling > multi-dimensional data. I will also take into account WMS 1.1.1. Are there > any potential pitfalls to adding this unit support? > Sigh... yes, there are, it is a combination of bad design on my part and bad timing vs the 2.2.0 release. The above would be API changes, since you'd need new fields, which are not allowed anymore now since we are releasing a RC this week, tomorrow if all goes well, which means trunk is becoming the new stable series and its API is cast in stone. In particular we have to ensure that it's possible to move forwards and backwards within the stable series using the same data dir, so no new explicit configuration fields can be added Normally we handle that by using the open ended MetadataMap that is available in most CatalogInfo objects, sticking the new values in it on the stable series, and add the new fields on the unstable one so that the XML persistence format does not change along a stable series ... unfortunately I forgot to add that into DimensionInfo, and doing that now is yet another API change... The only clean way to handle this now is to make it happen on the new trunk, which is going to become 2.3.0 in six months, once we branch off the current one to a new 2.2.x branch (see also GSIP 77, time boxed releases, on how we are going to handle API changes from now on). > What is the best process for submitting a patch? Create a ticket now and > attach the patch when I'm done or wait to create the ticket until the patch > is finished? The reason I ask is because I am under the impression that > JIRA tickets with patches (and unit tests) attached have a higher priority. > As far as I can tell there is no way to check the "patch/unit test > attached" check box after the ticket is created. Also is the preferred > method of patching to use github and fork/pull request or attach an svn > diff to the JIRA ticket. > There is not official policy but yes, during the weekend I try to review jiras that have patches attached. There was a way to locate jiras with attachments, and I was looking at that to find the tickets to review, now it's gone due to a Jira upgrade but I've found that looking for recently created/modified tickets that have the word "patch" in the works well enough Cheers Andrea -- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead 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://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf
<<GeoServerDimensionWithUnits.png>>
------------------------------------------------------------------------------ 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
