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.
------------------------------------------------------------------------------
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
