Jody Garnett wrote:
> My last message was too long :-)
>
>> gml:AbstractFeatureType
>> <>--- gml:LocationPropertyType
>> <>--- gml:AbstractGeometryType
>
> They have this organization because they LocationPropertyType is
> actually adding value; it is used as a choice between a Geometry and a
> couple other things :-)
>
> There model explicitly wants a choice here between a number of
> different options; and so we are going to explicitly represent this.
> If we were doing it in Java code we would need to break out a separate
> class to handle the situation - so our feature model is no worse then
> Java.
>
>> The information we are trying to convey has only two GeoAPI objects:
>
> Modified diagram:
>
> Feature <>--the_geom-- Geometry
>
> And you can represent that; but for many of the GML models you are
> looking at they want something more resulting in extra complexity on
> their side. If you just have that relationship above then there is a
> very simple representation of that in our feature model. An attribute
> called "the_geom" of type Geometry
Right. Yet, at encoding time, since geometry bindings are special, they
follow the property/Object pattern implicitly and take the_geom as
_being_ of type gml:PointPropertyType:
<sf:archsites gml:id="archsites.1">
<sf:the_geom>
<gml:Point>
<gml:pos>-103.8267530611134 44.38171313822482</gml:pos>
</gml:Point>
</sf:the_geom>
<sf:cat>1</sf:cat>
<sf:str1>Signature Rock</sf:str1>
</sf:archsites>
If the bindings (or the encoder) weren't assuming all and every GeoAPI
geometry attribute is to be encoded as a propertyType the output would
just be <the_geom><gml:pos>.... as it is for any other primitive type
attribute.
I think Ben is trying to get the encoder that smart for all the cases...
but I disagree there's no more separation of concerns. You have your
object model, coming from your database tables and the relationship
between them, and the mappings app-schema datastore process provide for
that separation of concerns? sort of, in the end you _could_ have a
simpler GeoAPI model that maps to a more complex one _at encoding time_.
Sort of moving the type mapping from the app-schema datastore to the
encoder, right Ben? Imho that would lead to just moving where the
coupling is tighter that it should... why do the encoder should be an
encoder and also a type mapper? And then, where are you going to
"unroll" queries against the target schema to the underlying data model?
Note the current design, conceded it builds a GeoAPI FeatureType as
complicated as the target schema, also allows to "easily" run complex
queries against the target schema, otherwise we could as easily have
gone with XSLT for the encoding part...
That said, if there's a simpler way of doing things I'm all ears, it's
just a matter of where all the two-way magic happens.
Cheers,
Gabriel
>
>
> Jody
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
