Doh - this is the feedback we need when trying to represent "default
geometry" - we proceeded with <PropertyName></PropertyName> under the
assumption this was an invalid XPath .... it looks to me like this is
already covered by the use case you describe so we need a new trick :-(
So justin I think this is a case of "you win" - and now you have some
work to do :-(
You going to walk through the SLD case in order to confirm that it
agrees with WFS GetFeaures (which is where you example comes from?)
My understanding of what SLD does is this:
<Rule>
....
<ogc:Filter>
<ogc:Not>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>TYPE</ogc:PropertyName>
<ogc:Literal>highway</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Not>
</ogc:Filter>
...
</Rule>
For the <ogc:Filter> (if supplied) I think they have to be in agreement
with what you do for WFS GetFeatures? If a user does not supply one we
assume Filter.INCLUDES etc... There is no problem here; time to move on.
The other place this appears is
<Rule>
....
<LineSymbolizer>
<Stroke>
<CssParameter name="stroke">#319738</CssParameter>
<CssParameter name="stroke-width">2</CssParameter>
</Stroke>
</LineSymbolizer>
</Rule>
That is the LineSymbolizer has not specified what geometry is being
used, We should represent this as lineSymbolizer.getGeometryExpression()
= Expression.NULL - Right now in the Renderer code we detect this; and
make a <PropertyName/> just so we can hook into the
PropertyAcessorFactory thing you made ... we need an alternate way to do
this; I would still like to see it part of PropertyAccessor (since we
are accessing a "default" property after all).
Cheers,
Jody
> Hi all,
>
> The reason for my last question about BinarySpatialOperator was this filter:
>
> <Filter>
> <Intersects>
> <PropertyName />
> <Envelope>
> ...
> </Envelope>
> </Intersects>
> </Filter>
>
> Note the empty property name. How i need to interpret this is as run the
> intersection against every geometric attribute in the type. My question
> is how do I do that.
>
> With the PropertyAccessor interface, we can handle some "special"
> property names given some context. For instance an empty string "" with
> a Geometry.class returns the default geometry of a feature.
>
> Now we could recognize the "*" string with a Geometry context, but that
> would imply that a collection should be returned. I am weary of
> implementing this as I am sure not much of our code out there is ready
> to handle this case of multiple properties mapping to a single property
> name.
>
> Tough one. Anyone have any thoughts.
>
> -Justin
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
