[Geoserver-devel] How to force xml-xsd encoder to output an attribute it's not there?

GeoServer GeoServer Developer
1

Hi,
in the OWS5 OGC thread we're experimenting with an extension to
TextSymbolizer that would allow for better control on the generated
KML.

One of the extensions should allow for the specification or
arbitrary text bits that the server will interpret and use according
to the output format. This could be used as a replacement for time
templates, and for extrudes. For example:

<sld:TextSymbolizer>
     <sld:OtherText target="kml:extrude">
       <ogc:PropetyName>height</ogc:propertyName>
     </sld:OtherText>
   </sld:TextSymbolizer>

to specify the height of the current geometry. Now, to actually
encode this I have to:
* encode the z among the coordinates
* add a few elements between the geometry tags, for example:

<Polygon>
       <extrude>1</extrude>
       <altitudeMode>relativeToGround</altitudeMode>
       <outerBoundaryIs>
         <LinearRing>
           <coordinates>
             -122.366278,37.818844,30
             -122.365248,37.819267,30
             -122.365640,37.819861,30
             -122.366669,37.819429,30
             -122.366278,37.818844,30
           </coordinates>
         </LinearRing>
       </outerBoundaryIs>
       <innerBoundaryIs>
         <LinearRing>
           <coordinates>
             -122.366212,37.818977,30
             -122.365424,37.819294,30
             -122.365704,37.819731,30
             -122.366488,37.819402,30
             -122.366212,37.818977,30
           </coordinates>
         </LinearRing>
       </innerBoundaryIs>
     </Polygon>

As you can see I'm going out of the gml spec. For the
normal kml output I know how to handle this, I just need
to modify a few methods in the old style encoders and preprocess
the geometry so that the z coordinate in the geometries is
filled.

But ows5 kml output uses GML3 encoding as well, and here
come the troubles, because xml-xsd is schema driven, and
we're going out of the schema here. What do I have to do
in order to inject the extra elements into the geometry
encoding? Are propertyExtractors a solution?
Please keep in mind that I won't be adding the extra
attributes to all features, but only to those whose
text symbolizer specifies an extrusion.

Well, let me know. Chris, if doing the gml3 version is too
hard, what about adding a parameter that controls the
kind of geometry that we output, and do the extrusion
only for gml2?

Cheers
Andrea

2

Hi Andrea,

I think you have a couple of ways to do this. First you are correct is
with a PropertyExtractor. The second is with just using
ComplexBinding#getProperties(Object). Which one you use depends on how
much control you want to have over the type and how it gets encoded.

Implementing a PropertyExtractor is harder because you have to build up
the actual schema, the element, its type, the particle for the element,
etc... However you have full power to specify any type that is defined
in the schema. The downside to a property extractor is order... you
don't really have control of when the additional properties will be
added. I believe the way the encoder is written they will be added after
any properties produced by the bindings,

With ComplexBinding#getProperties(), you can return any additional
elements you want... but if those elements are not global ones known to
the schema they will be encoded as xs:anyType, which basically just
amounts to writing out the string representation. So this really only
works for simple types. Which in this specific use case looks like it
might work out ok. This case is kind of nice since it means that you can
simply extend PolygonTypeBinding or GeometryTypeBInding in geoserver,
implement getProperties() and then override the binding from the normal
gml configuration.

Does all that make sense? Clear as mud right :slight_smile:

-Justin

Andrea Aime wrote:

Hi,
in the OWS5 OGC thread we're experimenting with an extension to
TextSymbolizer that would allow for better control on the generated
KML.

One of the extensions should allow for the specification or
arbitrary text bits that the server will interpret and use according
to the output format. This could be used as a replacement for time
templates, and for extrudes. For example:

<sld:TextSymbolizer>
     <sld:OtherText target="kml:extrude">
       <ogc:PropetyName>height</ogc:propertyName>
     </sld:OtherText>
   </sld:TextSymbolizer>

to specify the height of the current geometry. Now, to actually
encode this I have to:
* encode the z among the coordinates
* add a few elements between the geometry tags, for example:

<Polygon>
       <extrude>1</extrude>
       <altitudeMode>relativeToGround</altitudeMode>
       <outerBoundaryIs>
         <LinearRing>
           <coordinates>
             -122.366278,37.818844,30
             -122.365248,37.819267,30
             -122.365640,37.819861,30
             -122.366669,37.819429,30
             -122.366278,37.818844,30
           </coordinates>
         </LinearRing>
       </outerBoundaryIs>
       <innerBoundaryIs>
         <LinearRing>
           <coordinates>
             -122.366212,37.818977,30
             -122.365424,37.819294,30
             -122.365704,37.819731,30
             -122.366488,37.819402,30
             -122.366212,37.818977,30
           </coordinates>
         </LinearRing>
       </innerBoundaryIs>
     </Polygon>

As you can see I'm going out of the gml spec. For the
normal kml output I know how to handle this, I just need
to modify a few methods in the old style encoders and preprocess
the geometry so that the z coordinate in the geometries is
filled.

But ows5 kml output uses GML3 encoding as well, and here
come the troubles, because xml-xsd is schema driven, and
we're going out of the schema here. What do I have to do
in order to inject the extra elements into the geometry
encoding? Are propertyExtractors a solution?
Please keep in mind that I won't be adding the extra
attributes to all features, but only to those whose
text symbolizer specifies an extrusion.

Well, let me know. Chris, if doing the gml3 version is too
hard, what about adding a parameter that controls the
kind of geometry that we output, and do the extrusion
only for gml2?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,4798d5c0325887082231907!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org