Bryce L Nordgren wrote: > 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. > See other email, it comes down to step 2a) in your numbering. > 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.) > got it. > 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. > Still wondering how the PortrayalService "draws". The uDig renderers operate in two modes: - directly onto a supplied buffer (only useful for drawing onto the screen, or directly onto a volatile image) - directly against an "Graphic2D" like interface (implementations for SWT & AWT) useful for printing > 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. > Indeed, one thing that is clear from you description is a devision of concerns. The uDig rendering system is allowed to opperate without features. That is if you can figure it out from metadata rendering a WFS may consist of asking a WMS that has the same information to produce a map for you. So no portray( Feature ) method because we did not have to request features to produce the required visual.
So perhaps the "adpative" part has a few useful tricks after all. > PS: let me know whether you're going to buy your own 19117 or if you need > mine. > Thinking still, not confident of getting mail in this part of the world. Cost difference between mailing and buying is not going to be great. So if you guys are serious I will look into buying... Jody All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
