Re: [Geoserver-devel] Getting nuts trying to encode custom made complex features

[Gabriel R. <gr...@op...>]

On Mon, 2011-03-21 at 15:03 +0100, Andrea Aime wrote:
> On Mon, Mar 21, 2011 at 2:55 PM, Justin Deoliveira <jde...@op...> wrote:
> > Glad you found a working setup. I did spend some time over the weekend
> > working with the extension you sent out but unfortunately did not get very
> > far. I experimented with changing the structure of the schema and the built
> > complex feature to try and find a combination that worked but no luck. There
> > are some inherent assumptions that the encoding chain makes with regard to
> > complex features that obviously are not being met. Unfortunately more time
> > is needed to debug and figure out what they are.
> 
> Yep, that is the same conclusion I reached: complex feature encoding works only
> in the very specific setup generated by the app-schema store.
> I did look hard in that code trying to find the secret sauce to
> mikick, but could not get it
> to work in any way...
> 
> The overall impression I have is that the complex feature support is really the
> app-schema store, either use it, or you don't get a usable way to build, encode
> and manipulate complex features.
That shouldn't be the case encoding wise, though I can realize how
difficult it may be to keep it agnostic when the app-schema folks need
to get their specific use cases working.
Suggestion: submit a couple unit tests that set up a data structure as
you need. And ask the app-schema folks if that structure makes sense GML
"recommendations" wise (like I'm not sure how strict the property/Object
relationship is enforced, etc).

2c./
Gabriel
> 
> Unfortunately the assumption that a complex feature is just a joined,
> renamed and reorganized set of simple feature did not reflect what I
> needed so I could
> not go down that road...
> 
> Cheers
> Andrea
> 

-- 
Gabriel Roldan
gr...@op...
Expert service straight from the developers