Patrick Webb <[EMAIL PROTECTED]> wrote on 06/20/2006 12:48:01 PM:
> I'm definitely warming up to the idea of the pluggable 19117 protocol. > > Would love to see this compared with the "Adaptive Rendering" used > > by uDig, and outlined in an OGC OWS-3 > > implementation report (if you can get your hands on such things). Ooooo goody! It looks like pluggability is becoming easier. > > Understood, but why not review the uDig implementation - the code > > can be back ported and it is working out > > perfectly. Me likes. > I've been on the developer list, just haven't really contributed > until now. Bryce, I don't have a copy of the 19117 format to peruse. > Do you happen to know of a place where I could acquire such > information? Being a red-blooded yank, you go to: http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO+19117%3A2005. If $107 is too rich for your blood and your department can't help out, I can FedEx you my copy. (You'll need to give it back when you're done.) > Also, is the uDig rendering system an alternative to the > 19117 format, or just a means of implementing a renderer (which could > just as well conform to 19117)? I'm not so well-versed about Udig, but my read of the above is that the Udig designers came up with an "Adaptive Rendering" technique. If this is a framework, it may be construed as a competitor to 19117. But it may also have a quite different scope than 19117. Many parts may be complementary. You can think of 19117 as "Interfaces" for the notion of portrayal. It encapsulates portrayal _separate_ from features, separate even from a particular implementation of a portrayal engine. As a bonus, it "fits in" with the rest of the 19100 standards well. You define a portrayal interface which does something specific (like portray wind barbs) and give it a unique name. You define any functions ("magnitude", "direction_func"), parameters ("speed", "direction"), and rules required to produce a portrayal. You provide a thorough (natural language) description of what each function is supposed to do, units of each parameter, etc. This whole spiel goes in a Portrayal catalog. (19117 essentially contains classes needed to construct portrayal catalogs and their entries. It's like having a method signature coupled with metadata.) Next you write a PortrayalService, with one method: portray(Feature, PortrayalCatalog). The rendering engine (outside of 19117) keeps track of z order and associates each layer's feature (data) with a particular PortrayalService (wind barbs, polygon, polyline, linestring, point, blah blah). It is at this stage that "feature attributes" are mapped to "portrayal parameters" (e.g., feature has attributes with names "wind_speed" and "wind_dir"; mapped to portrayal catalog's parameters: "speed" and "direction") There is a very high degree of isolation between data and portrayal. Note that 19117 does not even attempt to address merging the result of multiple portrayals. The Udig renderer probably does some of this external management. Bryce PS: let me know whether you're going to buy your own 19117 or if you need mine. _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
