Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.
I've tried to collect all my findings here: http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+request
Please comment on the ml, I'll update the document along the way.
Cheers
Andrea
One question, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
If we have diverse datastores, then what do we do? Aggregate and only report what all are able to do? Perhaps we need a spec change, or at least need to ask the WFS list what others are doing?
One other thing to note, our MaxIncFIDMapper actually will perform fine with UseExisting _and_ GenerateNew. And would work with ReplaceDuplicate without _too_ much work, and wouldn't be super dangerous since we're doing things outside of the database, not messing with serial indexes and the like. (We just do a max(columname) on the fid column to determine what the next fid should be).
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here: http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+request
Please comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel!DSPAM:1003,453cf470137661362196140!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?
It is specified on the "Insert" statement itself.
If we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS list what others are doing?
I agree, it sure would be nice for the server implementors to be able to
advertise it in the capabilities at the feature type level which modes
are available. The downside being it is more of a hassle for the client
to have to check it.
One other thing to note, our MaxIncFIDMapper actually will perform fine
with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not messing
with serial indexes and the like. (We just do a max(columname) on the
fid column to determine what the next fid should be).
Maybe I am missing something but I am not sure I see how it applies to
UseExisting? How does this allow the datastore to use a fid that was
specified by the user?
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here:
http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+requestPlease comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642!DSPAM:1004,453cfe28146271995013331!
------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel!DSPAM:1004,453cfe28146271995013331!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?It is specified on the "Insert" statement itself.
I was talking about the capabilities reporting of it, if we have to report per server, or if we can per featureType
If we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS list what others are doing?I agree, it sure would be nice for the server implementors to be able to
advertise it in the capabilities at the feature type level which modes
are available. The downside being it is more of a hassle for the client
to have to check it.One other thing to note, our MaxIncFIDMapper actually will perform fine
with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not messing
with serial indexes and the like. (We just do a max(columname) on the
fid column to determine what the next fid should be).Maybe I am missing something but I am not sure I see how it applies to
UseExisting? How does this allow the datastore to use a fid that was
specified by the user?
Because it can just take whatever value the user supplied and stick it in to the column. This would take a bit of code adjustment, but what I meant is that it wouldn't be some infrastructure change on the database side. MaxIncFID would generate the next key if the user specified none, if they did then it'd be fine to just use it - as it doesn't rely on a serial key or any other kind of auto-incrementing device.
Chris
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here:
http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+requestPlease comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel!DSPAM:1004,453cfe28146271995013331!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Actually, taking a look at the xml schema for the capabilities doc, it
appears you can specify operation metadata globally and at the feature
type level.
Chris Holmes wrote:
Justin Deoliveira wrote:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?It is specified on the "Insert" statement itself.
I was talking about the capabilities reporting of it, if we have to
report per server, or if we can per featureTypeIf we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS list what others are doing?I agree, it sure would be nice for the server implementors to be able to
advertise it in the capabilities at the feature type level which modes
are available. The downside being it is more of a hassle for the client
to have to check it.One other thing to note, our MaxIncFIDMapper actually will perform fine
with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not messing
with serial indexes and the like. (We just do a max(columname) on the
fid column to determine what the next fid should be).Maybe I am missing something but I am not sure I see how it applies to
UseExisting? How does this allow the datastore to use a fid that was
specified by the user?Because it can just take whatever value the user supplied and stick it
in to the column. This would take a bit of code adjustment, but what I
meant is that it wouldn't be some infrastructure change on the database
side. MaxIncFID would generate the next key if the user specified none,
if they did then it'd be fine to just use it - as it doesn't rely on a
serial key or any other kind of auto-incrementing device.
Ahh, gotcha.
Chris
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here:
http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+requestPlease comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642!DSPAM:1004,453d033c150951665516417!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,453d033c150951665516417!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Are you sure? In the WFS schema I see you can do a wfs:OperationType, but it's defined as:
<xsd:simpleType name="OperationType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Insert"/>
<xsd:enumeration value="Update"/>
<xsd:enumeration value="Delete"/>
<xsd:enumeration value="Query"/>
<xsd:enumeration value="Lock"/>
<xsd:enumeration value="GetGmlObject"/>
</xsd:restriction>
Which just says what the operations are. Or am I missing something?
Justin Deoliveira wrote:
Actually, taking a look at the xml schema for the capabilities doc, it
appears you can specify operation metadata globally and at the feature
type level.Chris Holmes wrote:
Justin Deoliveira wrote:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?It is specified on the "Insert" statement itself.
I was talking about the capabilities reporting of it, if we have to
report per server, or if we can per featureTypeIf we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS list what others are doing?I agree, it sure would be nice for the server implementors to be able to
advertise it in the capabilities at the feature type level which modes
are available. The downside being it is more of a hassle for the client
to have to check it.One other thing to note, our MaxIncFIDMapper actually will perform fine
with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not messing
with serial indexes and the like. (We just do a max(columname) on the
fid column to determine what the next fid should be).Maybe I am missing something but I am not sure I see how it applies to
UseExisting? How does this allow the datastore to use a fid that was
specified by the user?Because it can just take whatever value the user supplied and stick it
in to the column. This would take a bit of code adjustment, but what I
meant is that it wouldn't be some infrastructure change on the database
side. MaxIncFID would generate the next key if the user specified none,
if they did then it'd be fine to just use it - as it doesn't rely on a
serial key or any other kind of auto-incrementing device.Ahh, gotcha.
Chris
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here:
http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+requestPlease comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,453d033c150951665516417!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Oops, you are correct, I got this type confused with the ows:Operation
element from the ows schema. And yes, it appears that they can only be
specified globally under the operationsMetadata section of the root
WFS_Capabilities element.
Chris Holmes wrote:
Are you sure? In the WFS schema I see you can do a wfs:OperationType,
but it's defined as:<xsd:simpleType name="OperationType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Insert"/>
<xsd:enumeration value="Update"/>
<xsd:enumeration value="Delete"/>
<xsd:enumeration value="Query"/>
<xsd:enumeration value="Lock"/>
<xsd:enumeration value="GetGmlObject"/>
</xsd:restriction>Which just says what the operations are. Or am I missing something?
Justin Deoliveira wrote:
Actually, taking a look at the xml schema for the capabilities doc, it
appears you can specify operation metadata globally and at the feature
type level.Chris Holmes wrote:
Justin Deoliveira wrote:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?It is specified on the "Insert" statement itself.
I was talking about the capabilities reporting of it, if we have to
report per server, or if we can per featureTypeIf we have diverse datastores, then what do we do? Aggregate and only
report what all are able to do? Perhaps we need a spec change, or at
least need to ask the WFS list what others are doing?I agree, it sure would be nice for the server implementors to be
able to
advertise it in the capabilities at the feature type level which modes
are available. The downside being it is more of a hassle for the client
to have to check it.One other thing to note, our MaxIncFIDMapper actually will perform
fine
with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not
messing
with serial indexes and the like. (We just do a max(columname) on the
fid column to determine what the next fid should be).Maybe I am missing something but I am not sure I see how it applies to
UseExisting? How does this allow the datastore to use a fid that was
specified by the user?Because it can just take whatever value the user supplied and stick it
in to the column. This would take a bit of code adjustment, but what I
meant is that it wouldn't be some infrastructure change on the database
side. MaxIncFID would generate the next key if the user specified none,
if they did then it'd be fine to just use it - as it doesn't rely on a
serial key or any other kind of auto-incrementing device.Ahh, gotcha.
Chris
Chris
Andrea Aime wrote:
Hi all,
thinking about this subject it seems to me we need to change
how gt2 datastore behave and add at least some minimal capabilities
support to them in order to manage properly the required WFS 1.1
idgen attribute for transaction operations.I've tried to collect all my findings here:
http://docs.codehaus.org/display/GEOTOOLS/idgen+support+for+WFS+1.1+transaction+requestPlease comment on the ml, I'll update the document along the way.
Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4. Please !
If we have diverse datastores, then what do we do? Aggregate and only report what all are able to do? Perhaps we need a spec change, or at least need to ask the WFS list what others are doing?
To do things the same way as last time we would need to "bring up" any datastore to the level needed to support a WFS implementation. Even if we cannot do this cleanly (say for shapefile) we can document a way to do it (make use of a shapefile "fid" attribute if available etc...).
Cheers,
Jody
Jody Garnett ha scritto:
Chris Holmes wrote:
One question, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4. Please !
Agreed, that would be nice. Who can do that?
To do things the same way as last time we would need to "bring up" any datastore to the level needed to support a WFS implementation. Even if we cannot do this cleanly (say for shapefile) we can document a way to do it (make use of a shapefile "fid" attribute if available etc...).
That would mean adding support for FIDMappers on other datastores I guess, and make them visibile
thru the API instead of keeping them as a internal tool to solve a problem like in jdbc datastores.
Cheers
Andrea
Chris Holmes ha scritto:
One question, on the spec itself, can we specify the behavior per
featureType? Or do we only have the option to set globally?
Capabilities are specified globally, not per type.
If we have diverse datastores, then what do we do? Aggregate and
only report what all are able to do? Perhaps we need a spec change,
or at least need to ask the WFS list what others are doing?
Spec change, but I'm going to ask on the OGC WFS lists as well.
One other thing to note, our MaxIncFIDMapper actually will perform
fine with UseExisting _and_ GenerateNew. And would work with
ReplaceDuplicate without _too_ much work, and wouldn't be super
dangerous since we're doing things outside of the database, not
messing with serial indexes and the like. (We just do a
max(columname) on the fid column to determine what the next fid
should be).
MaxIncFIDMapper is the most ugly and miserable of FID mappers
because there's no guarantee that FIDs generated by it are really
unique in a concurrent access situation where the transaction isolation
level is lower than SERIALIZABLE (and that level would kill performance
big time). You can think of it as a toy, but I would never use it in production.
Unless I'm missing something that can make it work properly?
As for not having problems with it because there are no sequences around,
hmm... I don't get it. If I provide you a value that's near the long values overflow,
that +1 may trigger an overflow error, or if you're lucky, make it turn to the other
side of the integer range (-maxint). Say I do it twice, first to make it round, then
to reset it to 0, and then let the dance of duplicate primary keys begin.
MaxIncFIDMapper is designed to "work" in a "GenerateNew" fashion, trying to
make it work following a different principle is a way to look for trouble IMHO.
Cheers
Andrea
Andrea Aime wrote:
stion, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4. Please !
Agreed, that would be nice. Who can do that?
TOPP, although I asked Chris because I was under the impression he is attending the conference calls.
To do things the same way as last time we would need to "bring up" any datastore to the level needed to support a WFS implementation. Even if we cannot do this cleanly (say for shapefile) we can document a way to do it (make use of a shapefile "fid" attribute if available etc...).
That would mean adding support for FIDMappers on other datastores I guess, and make them visibile
thru the API instead of keeping them as a internal tool to solve a problem like in jdbc datastores.
Indeed, I do feel we need to "upgrade" the DataStore API in order to respond the needs of WFS 1.1 (ie we need sorting as an easy example). I expect justin to be making suggestions as he goes here, but perhaps this has fallen to you Andrea?
Jody
Jody Garnett ha scritto:
Andrea Aime wrote:
stion, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4. Please !
Agreed, that would be nice. Who can do that?
TOPP, although I asked Chris because I was under the impression he is attending the conference calls.
I also have written a mail to wfs-dev@anonymised.com, but it seems
to me there's no much traffic here and the ml is really hidden
in the ogc site (too bad).
Indeed, I do feel we need to "upgrade" the DataStore API in order to respond the needs of WFS 1.1 (ie we need sorting as an easy example). I expect justin to be making suggestions as he goes here, but perhaps this has fallen to you Andrea?
No, not really, it's still Justin work, I just chimed in for a review
and try to understand where Geoserver is going (the new architecture in ows4 is really promising), and was trying to fix wfs transaction operation as an exercise to learn wfs better 
Anyways, yes, I agree on upgrading the datastore api, I'd just like to have a smooth transition path, not a "stop the world" approach where
we do for a change on all datastores at once. Anyways, +1 on sorting, +1
on capabilities, and +1 on first level fid handling too.
Cheers
Andrea
Jody Garnett wrote:
Andrea Aime wrote:
stion, on the spec itself, can we specify the behavior per featureType? Or do we only have the option to set globally?
No - but if you could please put it down as a change request for OWS-4. Please !
Agreed, that would be nice. Who can do that?
TOPP, although I asked Chris because I was under the impression he is attending the conference calls.
I've tried to dispel this notion of yours several times. Our role on OWS-4 is much different from yours on OWS-3. We're not working on a new spec, we're implementing an existing one. So we don't have a recommendation paper on spec changes at the end, we don't talk about the specs on calls.
TOPP is a member of OGC so we can submit change requests, but it's not because of OWS-4 involvement. If/when we hear back on wfs-dev I'll put in the appropriate requests.
Chris
To do things the same way as last time we would need to "bring up" any datastore to the level needed to support a WFS implementation. Even if we cannot do this cleanly (say for shapefile) we can document a way to do it (make use of a shapefile "fid" attribute if available etc...).
That would mean adding support for FIDMappers on other datastores I guess, and make them visibile
thru the API instead of keeping them as a internal tool to solve a problem like in jdbc datastores.Indeed, I do feel we need to "upgrade" the DataStore API in order to respond the needs of WFS 1.1 (ie we need sorting as an easy example). I expect justin to be making suggestions as he goes here, but perhaps this has fallen to you Andrea?
Jody
!DSPAM:1003,453e35df298071429667743!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes wrote:
I've tried to dispel this notion of yours several times. Our role on OWS-4 is much different from yours on OWS-3. We're not working on a new spec, we're implementing an existing one. So we don't have a recommendation paper on spec changes at the end, we don't talk about the specs on calls.
Sorry Chris if I have misunderstood you - I do understand that you are not producing a specification (or even change requests). But I am pretty sure you are providing an implementation report? And as such you have an opportunity to report on problems such as this one.
TOPP is a member of OGC so we can submit change requests, but it's not because of OWS-4 involvement. If/when we hear back on wfs-dev I'll put in the appropriate requests.
Thank you very much Chris, I was not trying to suggest we change anything (as that is indeed not your mandate for OWS-4), but we do need to report difficulties (and if something is truely broken break out vendor specific parameters).
In this case something does not seem very broken, to produce that capabilities document you probably need to take a lowest common of the data sources in the configuration, or in worst case produce several capabilities documents.
Jody
Jody Garnett wrote:
Chris Holmes wrote:
I've tried to dispel this notion of yours several times. Our role on OWS-4 is much different from yours on OWS-3. We're not working on a new spec, we're implementing an existing one. So we don't have a recommendation paper on spec changes at the end, we don't talk about the specs on calls.
Sorry Chris if I have misunderstood you - I do understand that you are not producing a specification (or even change requests). But I am pretty sure you are providing an implementation report? And as such you have an opportunity to report on problems such as this one.
As far as I know we don't. Though there has been some mention of documentation at the end, so maybe then? But on our weekly phone calls we don't really discuss it.
TOPP is a member of OGC so we can submit change requests, but it's not because of OWS-4 involvement. If/when we hear back on wfs-dev I'll put in the appropriate requests.
Thank you very much Chris, I was not trying to suggest we change anything (as that is indeed not your mandate for OWS-4), but we do need to report difficulties (and if something is truely broken break out vendor specific parameters).
In this case something does not seem very broken, to produce that capabilities document you probably need to take a lowest common of the data sources in the configuration, or in worst case produce several capabilities documents.
I agree we need to change something, the spec needs to be improved. I'm just saying it's not a function of OWS-4 involvement, and I don't have any more access to changes or even feedback than any ogc member.
Chris
Jody
!DSPAM:1003,453e4681310901775926497!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org