Bryce L Nordgren wrote: > I think I answered this in my last email, but was too chatty :). Let me > try to condense it some. > Thanks muchly > 1] It's not a complete rendering system. > > 2] It is a data model framework for describing the API of a portrayal > service independent of implementation, and *including* natural language > descriptions of functions, parameters, and algorithms. > > 3] The API's may be collected into PortrayalCatalogs. catalogs have unique > names. Similar concept to FeatureCatalogs. > > 4] A rendering engine (external to 19117) may use the services defined by > these PortrayalCatalogs. > > So, if I'm on the right track, the effect of integrating this architecture > into GT would be: > Okay I am with you so far, right now uDig uses an extension point to list the various Renderers( ie "PortrayalService"), and we ask each service to produce a metric describing if, and how well it can portray the content based on both content metadata (ie what) and user supplied metadata (aka style) information..
We also have used this design to work with external rendering systems (ie WMS) and external service chains (Feature Portrayal Service). So the approach sounds like the same one. > 1] Anything that "draws" (points, lines, polygons, rasters, wind barbs > etc.) would be factored out into a PortrayalService. > check. > 2] Renderers would be responsible only for: > 2a] connecting data with relevant PortrayalServices > 2b] configuring PortrayalServices (e.g. line styles...) > 2c] merging output of PortrayalServices > 2d] maintaining a z-order. > So most of what I am concerned about happens as part of 2a, the rest is kind of mechanical. Still this all looks pretty cool. > 3] Functionality in #2 could be factored out of the Udig or SLD renderers. > Um an SLD based renderer opperates as a specific kind of renderer for uDig (that is capable of rendering several kinds of content). I understand that I am supposed to use SLD for *everything* but life is too short. > 4] Specific renderers (e.g., SLD, Streaming) would be primarily responsible > for parsing their configuration files (e.g., mySLDmap.xml) and would > inherit most of #2. Alternatively, we could define a PortrayalConfigurator > interface which could translate from a specific format to the Portrayal > framework. > The "alternatively" is what we got going on in uDig. We actually allow lots of kinds of configuration content to be defined by the user, and can wire things up as needed. > 5] Most important, the majority of portrayal code becomes an implementation > of GeoAPI interfaces (say org.opengis.portrayal.*), therefore shareable. > Yep, I would love to have some formal APIs to hit. But I have to tell you separating out such an API from direct java dependence is hard (when it comes time to work on a buffer, or passing a "graphic" interface for the renderer to draw with. All the code I got is LGPL so we can grab as needed, but how much good it will do you will depend a bit on the details. > 6] Most important #2, this is a long-term architecture which supports both > production and development. > A bit worried that I can only help out on such things as they benefit uDig (short term gains and visibility), even for work like the FM branch I am on volunteer rather then work time. So lets plan a bit first to ensure this makes sense. I do need to wonder about 2a) - I work with a service "handle" to connect renderer to their data. > Coming at this from a professional standpoint, $107 (actually, with the GSA > discount, it's ~$90) to get a framework which a lot of highly paid people > have scrutinized is a bargain. :) It cost me more then $107 to come up with something similar to the above design, but I am afraid my personal budget is pinched on this one. > I don't think I could come up with a framework design for less than $107, and > I'm _sure_ > I couldn't get a contractor to produce one for that. :) However, for those > without a budget > line for this kind of thing, the first step will be to produce > well-documented GeoAPI interfaces. Perhaps we could even convince Patrick > to write a "19117 Primer", or a user's-guide-to-the-framework or even post > his master's thesis on the wiki. > I would settle for GeoAPI interface, would it be good to go through some of my more annoying technical concerns first? I suspect that 2a) and 2c) is where I am concerned. The rest of what makes uDig fun to work on comes down to API usability and attitude. > In the near term: I'm not an expert, but I can look up answers if people > have questions... > Sure a couple questions... Match Making: - look up of PortrayalService - just based on portrayal service metadata? Or does the portrayal service have a chance to poke at the data before reporting back? - same question but based on style metadata - (configuration in your summary) PortrayalService - do "rasters" go in and have data drawn on them? Or does an interface go in (like Graphic2D), or do rasters just come out? Concern here is for things like OpenGL or printing you cannot work with rasters effectively and need to use a Graphics2D interface. Go-1 - is this a straight alternative to Go-1 abstractions of Graphic, Canvas etc.... Thanks for the interesting conversation, 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
