RE: [Geoserver-devel] RE:Config branch winding down - About Featu reTypeConfig

[ROLDAN_Gabriel_raul]

when I say:

So, I think geoserver should manage feature types by a custom id, wich by
default it's ok to be the same as the feature type.
   

I think you may be right (sigh). I *really* don't have budget to fix
this one (I am running over right now).

I have been bothered by the need to keep the datastore/typename unique
at the same time as keeping the namespace/typename.
Keeping them orthogonal is the right answer. Adding "view" based
FeatureTypes only complicates the problem.

I need to revisit WMS spec, but I think it would be of great help to be able
of declaring views, for cascaded layers
and the like. Anyway, I agree that such a functionality may be dificult to
manage in WFS, due to locks... for WMS it would be enough with the actual
<definitionQuery config element to declare the filtered type...

What would be perfect is to have that DataStore getView( Query ) method
completed. And make the GeoServer just keep track of FeatureSource
instances. Making use of Query to change the typeName/namespace in the
same manner as we change attributes and coordinate systems.

It should... I think I don't really get the whole idea... (I get it for
.getView, but can't figure out how to maintain WFS and WMS in sync in the
case that both services serve different datasets...)

Is getNamespace in FeatureType just for GML Writer?

yeah, I think so. Shouldn't namespace be obtained directly from the
datastore reference holded in featuretypeconfig? (I don't remember right now
if ftypeconfig has a datastore association, but I think yes) As a lot of
other things, I've put it there just as the start action in the migration
process, hoping to iterate later to beatufy the design. And unfortunatelly
time has eat me, leaving lots of inconsistencies and garbage. I apologize.

If you have time to work on this - I can arange a delay or something. We
are building a ui on top of GeoServer so such fundemental changes have
big consequences. The only saving grace here is that we are not finished
the AttributeType/FeatureType handling today. But we will be on Tuesday.

I have no time right now
I need to finish some work for a meeting on wed. in madrid. sorry.

On a related note - could I ask you to look at DataStore.getView (The
method does not exists - the comments for it do). I would really like to
steal you View code, which I am impressed with, from GeoServer inorder
to implement such a beast.

sure, i'll take a look, and hope to be able of putting my hands on over
friday...
no way of doing it before from my side but feel free to ask anything
related
to my code, I'll be glad of helping in some manner.

Cheers,

Jody

best regards,

gabriel

[jive]

ROLDAN, Gabriel raul wrote:

I have been bothered by the need to keep the datastore/typename unique at the same time as keeping the namespace/typename.
Keeping them orthogonal is the right answer. Adding "view" based FeatureTypes only complicates the problem.

I need to revisit WMS spec, but I think it would be of great help to be able
of declaring views, for cascaded layers
and the like. Anyway, I agree that such a functionality may be dificult to
manage in WFS, due to locks... for WMS it would be enough with the actual
<definitionQuery config element to declare the filtered type...

Actually this kind of thing is fine for WFS - the views share the same FID (and the fid is locked).
Oh wait - I think we are never supposed to serve up different content with the same FID from a WFS.

If it is a true view then we should be ok I suppose. I need chris or a WFS expert to chime in here

What would be perfect is to have that DataStore getView( Query ) method completed. And make the GeoServer just keep track of FeatureSource instances. Making use of Query to change the typeName/namespace in the same manner as we change attributes and coordinate systems.
   
It should... I think I don't really get the whole idea... (I get it for
.getView, but can't figure out how to maintain WFS and WMS in sync in the
case that both services serve different datasets...)

I *really* want to have the definition of the DataStores handled by the Data(implements Catalog) and have WFS/WMS maintain their own list of FeatureTypes that they want to serve up. Maybe as part of defining what the WMS serves up we could define additional "layers" as getView requests, rather than getFeatureSource requests.

We really need to answer the FID question before we can proceed on this one. If we need to process the "view" requests as they go over the wire: say tacking on the view name as the start of the FID: "roadView.road.12345" for the roadView of the road Feature "road.12345"

Is getNamespace in FeatureType just for GML Writer?

yeah, I think so. Shouldn't namespace be obtained directly from the
datastore reference holded in featuretypeconfig? (I don't remember right now
if ftypeconfig has a datastore association, but I think yes) As a lot of
other things, I've put it there just as the start action in the migration
process, hoping to iterate later to beatufy the design. And unfortunatelly
time has eat me, leaving lots of inconsistencies and garbage. I apologize.

Let me rephrase the question is the FeatureType namespace is used for anything?

If you have time to work on this - I can arange a delay or something. We are building a ui on top of GeoServer so such fundemental changes have big consequences. The only saving grace here is that we are not finished the AttributeType/FeatureType handling today. But we will be on Tuesday.
   
I have no time right now I need to finish some work for a meeting on wed. in madrid. sorry.

That is okay it sounds like we need to sort out this data modeling issue before we can proceed. We can try again in feb and then you can play with all the configuration ramifications

On a related note - could I ask you to look at DataStore.getView (The method does not exists - the comments for it do). I would really like to steal you View code, which I am impressed with, from GeoServer inorder to implement such a beast.

sure, i'll take a look, and hope to be able of putting my hands on over
friday...
no way of doing it before from my side but feel free to ask anything
related to my code, I'll be glad of helping in some manner.

Cheers nice to work with you. We can try to have a run at this later.

Jody

[Chris_Holmes1]

>>I have been bothered by the need to keep the datastore/typename unique
>>at the same time as keeping the namespace/typename.
>>Keeping them orthogonal is the right answer. Adding "view" based
>>FeatureTypes only complicates the problem.
>>
>>
>>
>
>I need to revisit WMS spec, but I think it would be of great help to be able
>of declaring views, for cascaded layers
>and the like. Anyway, I agree that such a functionality may be dificult to
>manage in WFS, due to locks... for WMS it would be enough with the actual
><definitionQuery config element to declare the filtered type...
>
>
>
Actually this kind of thing is fine for WFS - the views share the same
FID (and the fid is locked).
Oh wait - I think we are never supposed to serve up different content
with the same FID from a WFS.

I'm still trying to figure out my feelings on this whole thread, but if
the types are in different namespaces than they are in fact different
fids. The fid includes the namespace, so app1:road.343 is different than
app2:road.343. They can each be referenced in an xml document uniquely
(at least as far as I know.)

Overall on the thread though, I personally think this view stuff can wait
a bit, does not need to be figured out right now. It'll need a nice
iteration to get the config stuff for it right as well, and should be
outside of Jody's scope right now. It's a cool feature, but it can wait a
bit. Super advanced users like Gabriel can make use of it as they will
and hopefully we can roll their changes in later.

Chris