Re: [udig-devel] SLD and Ecore

[Miles Parker <milesparker@xxxxxxxxx>]

Yes, I think that would be really useful. It actually would be a lot simpler to persist and work with, right? I might be missing something but my thinking is that right now if you want to create styles programmatically, you need to build the SLD xml up manually, correct? With the Styles and Expressions in EMF then you'd have a programming model and with a standard xml persistence, you could just emit the SLD xml for the actual implementation. Again, perhaps O'm missing something and there is already some sort of API for manipulating styles directly.

On Aug 7, 2010, at 4:48 PM, Jody Garnett wrote:

> We actually do use SLD and the GTRenderer to render things other than features.  The SLD classes all uses expressions to access data; and our expression implementation makes use of a "property accessor" extension which implementations exist for feature, feature with xpath, objects, beans and could be extended to access EObject eGet.
> 
> I have also considered implementing the Style and Expression classes in EMF for uDig (just so we can quickly make user interfaces for them.
> 
> Jody
> 
> On 08/08/2010, at 6:45 AM, Miles Parker wrote:
> 
>> Hi guys,
>> 
>> Perhaps the geotools list or wahtever would be a better place for this, but since the uDig approach is much more Ecore / Eclipse centric, I think I'll ask it here. I wonder if there has ever been any discussion about building an Ecore wrapper and/or similar higher level style description framework in Ecore (with XSD of course). I ask because SLD could be valuable as a more general style description specification (I mean outside of GIS).  I've defined a style description framework for agent-based models in the AMF tool but that is not even close to as fully featured and rather than build that out it would be nice to have a common base that other people had thought a lot about and implemented.  -- and there is probably a lot more than I need there so it might be nice to have a more modular approach.
>> 
>> I'm wondering chiefly because I don't want to be tied to XML based approaches. It is difficult to encode/decode and maintain outside of existing toolchains. Or at least I find it so, but then I'm still bumbling around quite a bit. In particular it would be really neat to have a programmatic model for directly interacting with styles. For example, I do a lot of code generation and it's actually pretty difficult to generate valid XML -- one missing > vs ;gt; or whatever and you've hosed the entire document. (XML is surprisingly and unnecessarily fragile I think.) And by having the full programming model you could easily (relativly) do things like having dynamically modifiying styles, etc.
>> 
>> cheers,
>> 
>> Miles
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
> 
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel