Hi Justin; I had a go at using the color map stuff and got stuck so we started
in on the function implementation. As Michael indicated he started cleaning
them up to some degree.
I am not particularly attached to either way of doing things; the functions
were nice in that we could make use of them for working with features as well
as rasters.
Jody
On 03/12/2010, at 11:16 AM, Justin Deoliveira wrote:
> Sorry, "better implemented" was a bad term :) What I should have said is
> "better integrated" into the existing styling/rendering subsystems. And you
> will have to excuse me because i am out of my element here so maybe i am
> wrong. Is there any way to create a ColorMap object, or set some other
> property on a raster symbolizer with these functions and have them respected
> by the render?
>
> On Thu, Dec 2, 2010 at 6:13 PM, Michael Bedward <[email protected]>
> wrote:
> Hi Justin,
>
> What does "better implemented" mean ? I'm asking because since I know
> those functions well I can probably help.
>
> I'm happy to follow whatever line you think is best to get SE 1.1
> working for raster colormaps.
>
> BTW, here are relevant Jira issues...
>
> http://jira.codehaus.org/browse/GEOT-3001
> http://jira.codehaus.org/browse/GEOT-3097
>
> Michael
>
>
> On 3 December 2010 11:57, Justin Deoliveira <[email protected]> wrote:
> > Thanks Michael for the useful information.
> > That is more or less what I expected. I think for now in terms of getting a
> > parser working it might work best just to use the existing color map stuff.
> > It will be hacky but i think it is a good first step. And then once the
> > categorize/interpolate/etc... stuff are better implemented we can switch
> > over to that.
> >
> > On Thu, Dec 2, 2010 at 5:51 PM, Michael Bedward <[email protected]>
> > wrote:
> >>
> >> Hi Justin,
> >>
> >> I worked on the SE 1.1 functions (Interpolate, Categorize and Recode)
> >> with the eventual hope of using them in raster colormaps, so I'm very
> >> pleased to see you getting into this.
> >>
> >> My work on the functions started from code that had originally been
> >> written by Johann. It was a mix of working code and stubs, was sitting
> >> in the render module, and implemented Function directly. I just kept
> >> it all like that and, to tell the truth, I don't think I even noticed
> >> that the interfaces you mention existed.
> >>
> >> So long story short: the existing arrangement is my laziness rather
> >> than being part of a plan.
> >>
> >> Michael
> >>
> >> On 3 December 2010 11:33, Justin Deoliveira <[email protected]> wrote:
> >> > I guess you did not read my entire email. Of course I read the
> >> > specification, that is what lead me to those classes. My q
> >> >
> >> > On Thu, Dec 2, 2010 at 5:03 PM, Jody Garnett <[email protected]>
> >> > wrote:
> >> >>
> >> >> Have a look in the specification they define them as functions there
> >> >> (hence the classes you found). se:Categorize extends se:Function (where
> >> >> se:Function can have a default value if the function is not supported).
> >> >> Jody
> >> >> On 03/12/2010, at 5:05 AM, Justin Deoliveira wrote:
> >> >>
> >> >> Hi all,
> >> >> Recently I have started working on bindings for se 1.1 in order to
> >> >> implement a paser/encoder for se 1.1 and sld 1.1. I have a question
> >> >> regarding color maps.
> >> >> In SLD 1.0 a color map is defined as:
> >> >>
> >> >> <xsd:element name="ColorMap">
> >> >>
> >> >> <xsd:annotation>
> >> >>
> >> >> <xsd:documentation> A "ColorMap" defines
> >> >>
> >> >> either the colors of a pallet-type raster source
> >> >> or
> >> >>
> >> >> the mapping of numeric pixel values to colors.
> >> >> </xsd:documentation>
> >> >>
> >> >> </xsd:annotation>
> >> >>
> >> >> <xsd:complexType>
> >> >>
> >> >> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> >> >>
> >> >> <xsd:element ref="sld:ColorMapEntry"/>
> >> >>
> >> >> </xsd:choice>
> >> >>
> >> >> </xsd:complexType>
> >> >>
> >> >> </xsd:element>
> >> >>
> >> >> In SE 1.1 a color map is defined as:
> >> >>
> >> >> <xsd:complexType name="ColorMapType">
> >> >>
> >> >> <xsd:choice>
> >> >>
> >> >> <xsd:element ref="se:Categorize"/>
> >> >>
> >> >> <xsd:element ref="se:Interpolate"/>
> >> >>
> >> >> </xsd:choice>
> >> >>
> >> >> </xsd:complexType>
> >> >>
> >> >> <xsd:complexType name="CategorizeType">
> >> >>
> >> >> <xsd:complexContent>
> >> >>
> >> >> <xsd:extension base="se:FunctionType">
> >> >>
> >> >> <xsd:sequence>
> >> >>
> >> >> <xsd:element ref="se:LookupValue"/>
> >> >>
> >> >> <xsd:element ref="se:Value"/>
> >> >>
> >> >> <xsd:sequence maxOccurs="unbounded" minOccurs="0">
> >> >>
> >> >> <xsd:element ref="se:Threshold"/>
> >> >>
> >> >> <xsd:element ref="se:Value"/>
> >> >>
> >> >> </xsd:sequence>
> >> >>
> >> >> </xsd:sequence>
> >> >>
> >> >> <xsd:attribute name="threshholdsBelongTo"
> >> >>
> >> >> type="se:ThreshholdsBelongToType" use="optional"/>
> >> >>
> >> >> </xsd:extension>
> >> >>
> >> >> </xsd:complexContent>
> >> >>
> >> >> </xsd:complexType>
> >> >>
> >> >> <xsd:complexType name="InterpolateType">
> >> >>
> >> >> <xsd:complexContent>
> >> >>
> >> >> <xsd:extension base="se:FunctionType">
> >> >>
> >> >> <xsd:sequence>
> >> >>
> >> >> <xsd:element ref="se:LookupValue"/>
> >> >>
> >> >> <xsd:element maxOccurs="unbounded"
> >> >> ref="se:InterpolationPoint"/>
> >> >>
> >> >> </xsd:sequence>
> >> >>
> >> >> <xsd:attribute name="mode" type="se:ModeType"/>
> >> >>
> >> >> <xsd:attribute name="method" type="se:MethodType"/>
> >> >>
> >> >> </xsd:extension>
> >> >>
> >> >> </xsd:complexContent>
> >> >>
> >> >> </xsd:complexType>
> >> >>
> >> >> Quite a different structure. My question is what sorts of objects this
> >> >> should be parsed into. The ColorMap class as it exists seems more or
> >> >> less
> >> >> just a list of color entries, mirroring the sld 1.0 structure. But I
> >> >> also
> >> >> found a few classes living in the render package that mirror the SE
> >> >> structure:
> >> >> org.geotools.filter.visitor.Categorize
> >> >> org.geotools.filter.visitor.Interpolate
> >> >> These two are interfaces that extend Function but seem to have no
> >> >> implementation. However these two classes:
> >> >> org.geotools.filter.CategorizeFunction
> >> >> org.geotools.filter.InterpolateFunction
> >> >> Which seem to be related, although the classes don't implement the
> >> >> interfaces, they are direct implementations of Function.
> >> >> So... i am not sure what to do. Should I try to mash the new concepts
> >> >> into
> >> >> the existing ColorMap class... or should i try to use these new
> >> >> classes? I
> >> >> see Jody's name riddled on a few of those classes so hopefully he or
> >> >> others
> >> >> more familiar with se can provide some context.
> >> >> Thanks!
> >> >> -Justin
> >> >> --
> >> >> Justin Deoliveira
> >> >> OpenGeo - http://opengeo.org
> >> >> Enterprise support for open source geospatial.
> >> >>
> >> >>
> >> >> ------------------------------------------------------------------------------
> >> >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> >> >> Tap into the largest installed PC base & get more eyes on your game by
> >> >> optimizing for Intel(R) Graphics Technology. Get started today with the
> >> >> Intel(R) Software Partner Program. Five $500 cash prizes are up for
> >> >> grabs.
> >> >>
> >> >>
> >> >> http://p.sf.net/sfu/intelisp-dev2dev_______________________________________________
> >> >> Geotools-devel mailing list
> >> >> [email protected]
> >> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Justin Deoliveira
> >> > OpenGeo - http://opengeo.org
> >> > Enterprise support for open source geospatial.
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> >> > Tap into the largest installed PC base & get more eyes on your game by
> >> > optimizing for Intel(R) Graphics Technology. Get started today with the
> >> > Intel(R) Software Partner Program. Five $500 cash prizes are up for
> >> > grabs.
> >> > http://p.sf.net/sfu/intelisp-dev2dev
> >> > _______________________________________________
> >> > Geotools-devel mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >> >
> >> >
> >
> >
> >
> > --
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
> >
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: New IBM DB2 features make compatibility easy.
Learn about native support for PL/SQL, new data types, scalar functions,
improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools,
best practices and more - all designed to run applications on both DB2 and
Oracle platforms. http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
