Re: [Geotools-devel] polymorphism and rendering

[Andrea A. <and...@ge...>]

On Mon, Dec 20, 2010 at 9:33 AM, Niels <nie...@cs...> wrote:

> So the attributes are not "all the attributes",  but only the ones the
> SLD author
> explictly mentioned in the SLD in the <geometry> elements (plus the
> default ones).
> So to answer your question "Isn't it enough
>  to create a BBOX for the geometry type that is used for rendering" the
> answer is yes, that's exactly what we're doing.
>
> You're right, it does only loop over the attributes used in the style, I did
> know that, perhaps I wasn't clear about that.
> I still don't understand why it loops over all the attributes used in the
> style's filters? The filters don't really have anything to do with the
> geometry that is used, have they? Isn't it just the default geometry that is
> used? That's what I understood from the drawing code.

There is some truth there but it's not the whole story.
Yes, that method extract all of the attributes used in the style, whether
they are used in a filter or in the symbolizers, and to build the bbox
we would just need the ones used in the symbolizers.

But no, we don't just use the default geometry. I said that in the
previous mail already, all symbolizers have a <geometry> element
which can contain a PropertyName to select whatever geometry
attribute you want out of the feature.
Using the default geometry is the default behavior, the SLD author
can however use <xyzSymbolizer><geometry>...</geometry></xyzSymbolizer>
to specify a certain geometry to be painted, different than the default
one.

Or, in your case, as a custom extension, apply a funcion on top of it
to transform it (see
http://blog.geoserver.org/2010/03/17/extending-your-map-styling-with-geometry-transformations/)

> Alternatively we could have some kind of hint be passed down
> in expression evaluation that forces the property accessors to
> just throw an exception if the attribute is not there.
> Haven't checked if that is possible at all, just thinking out loud here
>
> Haha, but something like that already exists, because I implemented it!

Does it work on simple features as well?

> There is a property in AttributeExpressionImpl to make it throw an expection
> on invalid property names, for exactly that purpose, that is used by
> app-schema. (It was used because people had exactly the same problem with
> non-existing column names in the app-schema mapping file).
> We could use that to report the error at time of the evaluation of the
> property name against a specific feature, rather than in advance.
> One issue: I am not sure if this would eliminate the problem with
> polymorphism completely though. Because doesn't polymorphism imply that some
> x-paths won't be able to be evaluated against some features - in which case
> they probably should be ignored?

Is there any way to know if not finding the property is legit due to
polymorphism
or if it's a mistake?
Whatever we do mind the simple feature path does not have to suffer functional
or performance regressions.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584962313
fax:     +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------