Hi Justin and everyone,
All what FilterFactoryImplNamespaceAware does, is creating AttributeImpl
objects with the NameSpace information written in its hits. These hints
are then picked up by the FeaturePropertyAccessor (also defined in
app-schema) who can evaluate properties with namespaces.
I think what needs to happen is this.
The basic FilterFactory interface (and its impl) should support creating
properties with namespace information in their hints (optionally). This
is only a change of a few lines of code. The only concern here is, that
prefix:namespace mappings can be different per request or per file being
parsed. As a consequence, we cannot keep using one single filter factory
throughout the system, but rather need to create different instances
depending on namespace information, and the classes pass them (
optionally) on to each other; the good thing is that the support to pass
on filter factory instance seems to already exist in many classes.
In any case, there wouldn't be any need to build namespace support
everywhere overnight, since it remains an optional configuration option.
Namespace support can be built in gradually, I can start with where I
need it now (WMS) without hurting any other part of the system.
Also, optionally, we could merge the classes FeaturePropertyAccessor and
XPathPropertyAccessor in to one, because these are basically doing the
same thing. It wouldn't be necessary for it to work, but it would be a
performance improvement.
Regards,
Niels
On 25/11/10 23:23, Justin Deoliveira wrote:
Hi Niels,
You are correct, handling namespaces properly everywhere is a mountain
of work. Unavoidable side affect of geotools being originally designed
for simple features.
However I totally agree that moving the NamespaceAwareFilterFactory
into the core is a good place to start. And allow particular
subsystems (like rendering) to gradually support complex features.
What is involved in moving the class over? Does it have any
dependencies on app-schema stuff? Or is it pretty much standalone?
I think you are on the same page but I think it is important to make
the namespace aware filter factory optional... and not have it be the
default.
2c.
-Justin
On Wed, Nov 24, 2010 at 10:39 PM, Niels <[email protected]> wrote:
Hi,
I am currently working on making WMS work with complex features.
One of the main problems I am currently encountering, is that the
filters built from the SLD file are not working when applied in
the renderer, because the attributes inside them are x-paths, and
they can't be properly evaluated against the features.
However, I know that they would be evaluated perfectly if a
NameSpaceAwareFilterFactory (from app-schema) was used instead of
the default FilterFactory, correctly configured with the
prefix/namespace mappings provided by the user. So in fact the
implementation to evaluate these filters and expressions properly
already exists in the system, it is just not being used! And there
are some other side issues related to the same problem, like for
example, testing whether the attributes provided in the style
really exist for proper error reporting, etc... Of course we are
talking about code in the render and main packages, which aren't
aware of app-schema.
I think namespace support should not be a specific app-schema
thing, but something provided through the system. Everywhere in
the code I see hacks where namespaces are actively thrown away,
which is effectively causing bugs when people have different
properties with the same local name but different namespaces,
which should be supported. (see also
http://old.nabble.com/WFS-1.1-GetFeature-Attribute-missing-in-2.1-td30207470.html)
Why not move the implementation for the namespace awareness from
app-schema to the core of geotools, and allow the commonly used
filterfactory to be configured with namespace support?
I think this is the main milestone that needs to be reached before
WMS can support complex features. In fact I am pretty sure it is
the only issue that needs to be resolved, and it seems almost
impossible to work around it. And it would get rid of some buggy
behaviour!
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
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
