On Jun 20, 2006, at 1:26 PM, Bryce L Nordgren wrote:
>
>
> *snip
>
>>> Understood, but why not review the uDig implementation - the code
>>> can be back ported and it is working out
>>> perfectly.
>
> Me likes.
>
Me too. Where would one perhaps get a look at the uDig
implementation? Perhaps I'm blind, I'm just not seeing the source
code for download on the uDig site.
*snip*
>
> 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.
I should probably be able to shell out the $$$ for a copy of my own.
So, a question about where the SLD renderer (that's what GeoTools
currently uses, right?) fits into this scheme. The SLD renderer plugs
in the same as with any other arbitrary renderer that a
PortrayalService gets written for? So the current rendering engine
doesn't get thrown out, just made plug-in-able. Sorry if that sounds
like a fairly basic question, I just want to be clear.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
