Hi,
a few minutes trying WFS data store on Geoserver and I already
discovered enough issues to make it a difficult candidate for
inclusion even as an extra...
If you have to provide authentication, things won't work due
to the combinatio of geot-993 and geot-994.
Once you get past those (that required geos-771 to be fixed)
the feature type names you get from a cascade Geoserver instance
would look like topp:countries, so that the full name in the
local instance becomes topp:topp:countries... and this in
turn leads to isses in the generated GML (invalid xml...)
I'm also unable to preview a map of the layer with mapbuilder...
What do you suggest? Fixing all these may require a new gt2 release...
Cheers
Andrea
Hmmm...
I'd say don't worry about authentication for now, just get it working with WFS's that don't require authentication and revisit that later. Though if they are quick fixes then get them in GeoTools.
And then go ahead and make the fix for the cascading names. It has a jira issue: http://jira.codehaus.org/browse/GEOT-860 Though the solution he puts is probably a bad way to solve it since that line of code is going to be called millions of times and this is definitely an edge case.
I don't think these are important enough for us to spend time making another GeoTools release, indeed the cascading WFS stuff was low on my list. But we can get them in to GeoTools so that if someone else makes a release we can just use it, or we may have more fixes later that makes sense for us to release.
Chris
Andrea Aime wrote:
Hi,
a few minutes trying WFS data store on Geoserver and I already
discovered enough issues to make it a difficult candidate for
inclusion even as an extra...
If you have to provide authentication, things won't work due
to the combinatio of geot-993 and geot-994.
Once you get past those (that required geos-771 to be fixed)
the feature type names you get from a cascade Geoserver instance
would look like topp:countries, so that the full name in the
local instance becomes topp:topp:countries... and this in
turn leads to isses in the generated GML (invalid xml...)
I'm also unable to preview a map of the layer with mapbuilder...
What do you suggest? Fixing all these may require a new gt2 release...
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,453f8719142281702038478!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Sharing a conversation on the geoserver-devel list where we're having
some issues with the WFSDataStore returning feature type names
like "topp:states" instead of just "states", and the consequences on
the generated gml and the like.
Should be of interest in particular of the WFS data store mantainer,
but also for anyone interested in FeatureType naming.
Chris Holmes ha scritto:
Once you get past those (that required geos-771 to be fixed)
the feature type names you get from a cascade Geoserver instance
would look like topp:countries, so that the full name in the
local instance becomes topp:topp:countries... and this in
turn leads to isses in the generated GML (invalid xml...)
I'm also unable to preview a map of the layer with mapbuilder...
...
And then go ahead and make the fix for the cascading names. It has a jira issue: http://jira.codehaus.org/browse/GEOT-860 Though the solution he puts is probably a bad way to solve it since that line of code is going to be called millions of times and this is definitely an edge case.
Hmm... it seems to me the right fix would be change the WFS data store
so that it does strip the prefix from feature names, or change it... hum, maybe better change the ":" it with an _, otherwise we may have problems with feature types with the same name coming from different servers, right? (which is somethig we already have if you try to set up two "states" feature types, one coming from postgis and the other from
shapefiles afaik).
On the other side, it occurs to me that we should forbid the usage of ":" in all feature type names. It's not something that other data stores
do use at the moment, but nothing forbids to create a feature type using it (just checked FeatureTypeBuilder in 2.2.x)
I don't think these are important enough for us to spend time making another GeoTools release, indeed the cascading WFS stuff was low on my list. But we can get them in to GeoTools so that if someone else makes a release we can just use it, or we may have more fixes later that makes sense for us to release.
Ok
Cheers
Andrea
Andrea Aime ha scritto:
Hmm... it seems to me the right fix would be change the WFS data store
so that it does strip the prefix from feature names, or change it... hum, maybe better change the ":" it with an _, otherwise we may have problems with feature types with the same name coming from different servers, right? (which is somethig we already have if you try to set up two "states" feature types, one coming from postgis and the other from
shapefiles afaik).
Looking into the WFS datastore code there are a couple of points where
the featuretype name is split and only the part after ":" is taken, but
they do seem localized fixes, not a datastore wide decision... it would
be nicer IMHO if that was managed at the FeatureSetDescriptor class,
exposing "prefix_name" to geotools and only using "prefix:name" to the
requests forwarded to the WFS server.
Jesse, Richard, any opinion on this?
Cheers
Andrea
Andrea Aime wrote:
Andrea Aime ha scritto:
Hmm... it seems to me the right fix would be change the WFS data store
so that it does strip the prefix from feature names, or change it... hum, maybe better change the ":" it with an _, otherwise we may have problems with feature types with the same name coming from different servers, right? (which is somethig we already have if you try to set up two "states" feature types, one coming from postgis and the other from
shapefiles afaik).
Looking into the WFS datastore code there are a couple of points where
the featuretype name is split and only the part after ":" is taken, but
they do seem localized fixes, not a datastore wide decision... it would
be nicer IMHO if that was managed at the FeatureSetDescriptor class,
exposing "prefix_name" to geotools and only using "prefix:name" to the
requests forwarded to the WFS server.
Jesse, Richard, any opinion on this?
I think this makes sense, it's definitely the 'better' fix. And reasonable if you're cascading to. Ccing David Z, as I think he may still be the module maintainer? He originally coded it, so maybe he can tell us if there was a specific reason for that decision, or if it was just the easy way to handle it.
Chris
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,45407f70252971365099012!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris,
I recall this … we talked about it a bunch.There were some inconsistencies for how to write / request (for example the request to get a schema from galdos) w.r.t the feature type name, where some servers included the prefix in the name, while others did not. I believe the thought was to make the feature type name exactly as the server provided it. This helped with the encoding of the FeatureType name when making some requests (you can always tell is the prefix is included …).
A fix would be to add a field(s?) to the capabilities doc stored in a connection to include a flag for the prefix as part of the server generated name.
In the back of my head there was also a UI concern for this … but that’s not a good reason to leave it as is.
HTH
David
On 10/26/06, Chris Holmes <cholmes@anonymised.com> wrote:
Andrea Aime wrote:
Andrea Aime ha scritto:
Hmm… it seems to me the right fix would be change the WFS data store
so that it does strip the prefix from feature names, or change it…
hum, maybe better change the “:” it with an _, otherwise we may have
problems with feature types with the same name coming from different
servers, right? (which is somethig we already have if you try to set up
two “states” feature types, one coming from postgis and the other from
shapefiles afaik).
Looking into the WFS datastore code there are a couple of points where
the featuretype name is split and only the part after “:” is taken, but
they do seem localized fixes, not a datastore wide decision… it would
be nicer IMHO if that was managed at the FeatureSetDescriptor class,
exposing “prefix_name” to geotools and only using “prefix:name” to the
requests forwarded to the WFS server.
Jesse, Richard, any opinion on this?
I think this makes sense, it’s definitely the ‘better’ fix. And
reasonable if you’re cascading to. Ccing David Z, as I think he may
still be the module maintainer? He originally coded it, so maybe he can
tell us if there was a specific reason for that decision, or if it was
just the easy way to handle it.
Chris
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,45407f70252971365099012!
–
Chris Holmes
The Open Planning Project
http://topp.openplans.org
David Zwiers ha scritto:
Chris,
I recall this ... we talked about it a bunch.There were some inconsistencies for how to write / request (for example the request to get a schema from galdos) w.r.t the feature type name, where some servers included the prefix in the name, while others did not. I believe the thought was to make the feature type name exactly as the server provided it. This helped with the encoding of the FeatureType name when making some requests (you can always tell is the prefix is included ...).
Well, my proposal was to keep the feature type name exactly as provided
for the wfs communications, just to strip the prefix in the feature type
name seen by geotools (or change the ":" with "_").
That is, the datastore would read from the server "topp:states" but
the FeatureType returned by getSchema(xxx) would be named simply "states" or "topp_states".
A fix would be to add a field(s?) to the capabilities doc stored in a connection to include a flag for the prefix as part of the server generated name.
Hmm... that would be error prone in Geoserver because we let all
parameters be seen as is by the user. If the user decides to
include the prefix we're doomed...
Cheers
Andrea
Perhaps we are missing the point a little here. What is the point of advertising a feature type at all? If it has no potentiall meaning, but is just an identifier, its more honest just to assign it a unique identfier - perhaps a UUID would be correct.
In the context of Spatial Data Infrastructures - the main driver of open standards and the deployment of re-usable data access services - the feature type must be recognisable by the client. The client will bind to a specific feature type, having discovered this in some fashion from a registry - maybe via a persistent binding like a Web Map Context docuement,
in this case, can someone please explain just how a "Cascading WFS" would be used practically?
I can see that for a desktop GIS application, the WFS source just wants to be bound to objects you can manpulate - but the name (machine id) should not form part of the user experience, you should assign an arbitrary identifier to reflect the arbitrary semantics you intend, and propagate the Title and other metadata to the user interface. (including possible the Title of the source server). If you want to exploit the source feature _type_ - for example apply an SLD that is declared to work against it, then you are almost back in case #1 - the feature type must be unchanged. I say almost, because if you are not advertising them outside the scope of your client application, you could maintain another layer of abstraction, mapping "real feature types" to local identifiers. I doubt we are proposing this level of re-engineering 
.
So, lets not put in a hack that will get in the way of a proper solution at a later date!
If you cant propagate the feature type unchanged, but want a WFS data store for uDig, can we simply disable it for Geoserver WFS? Possibly marginally OK for WMS, but not for SLD support, but I'd still reckon giving it an anonymous layer name and not pretending it should behave like any known feature type if you can actually handle it (accept an SLD that references that feature type for example)
Rob Atkinson
Andrea Aime wrote:
David Zwiers ha scritto:
Chris,
I recall this ... we talked about it a bunch.There were some inconsistencies for how to write / request (for example the request to get a schema from galdos) w.r.t the feature type name, where some servers included the prefix in the name, while others did not. I believe the thought was to make the feature type name exactly as the server provided it. This helped with the encoding of the FeatureType name when making some requests (you can always tell is the prefix is included ...).
Well, my proposal was to keep the feature type name exactly as provided
for the wfs communications, just to strip the prefix in the feature type
name seen by geotools (or change the ":" with "_").
That is, the datastore would read from the server "topp:states" but
the FeatureType returned by getSchema(xxx) would be named simply "states" or "topp_states".
A fix would be to add a field(s?) to the capabilities doc stored in a connection to include a flag for the prefix as part of the server generated name.
Hmm... that would be error prone in Geoserver because we let all
parameters be seen as is by the user. If the user decides to
include the prefix we're doomed...
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
in this case, can someone please explain just how a "Cascading WFS" would be used practically?
1) A WFS that only does basic filters - like mapserver - could be cascading behind one that can handle all filters.
2) A WFS that only outputs GML could be cascaded to one that outputs shapefiles, mapinfo files, kml, ect.
3) A more reliable WFS could suck a cascaded WFS in to its own caching database, so that if the original WFS went down it would remain up.
I agree that 1 and 3 beg an unchanged featureType to function in that ideal SDI vision. 2 does less so, where the WFS is kind of a format converter.
What about if we were to just get rid of the prefix instead of changing it to an underscore? Then admins will be able to set their namespaces and prefixes to match those of the WFS they are cascading.
Chris
I can see that for a desktop GIS application, the WFS source just wants to be bound to objects you can manpulate - but the name (machine id) should not form part of the user experience, you should assign an arbitrary identifier to reflect the arbitrary semantics you intend, and propagate the Title and other metadata to the user interface. (including possible the Title of the source server). If you want to exploit the source feature _type_ - for example apply an SLD that is declared to work against it, then you are almost back in case #1 - the feature type must be unchanged. I say almost, because if you are not advertising them outside the scope of your client application, you could maintain another layer of abstraction, mapping "real feature types" to local identifiers. I doubt we are proposing this level of re-engineering .
So, lets not put in a hack that will get in the way of a proper solution at a later date!
If you cant propagate the feature type unchanged, but want a WFS data store for uDig, can we simply disable it for Geoserver WFS? Possibly marginally OK for WMS, but not for SLD support, but I'd still reckon giving it an anonymous layer name and not pretending it should behave like any known feature type if you can actually handle it (accept an SLD that references that feature type for example)
Rob Atkinson
Andrea Aime wrote:
David Zwiers ha scritto:
Chris,
I recall this ... we talked about it a bunch.There were some inconsistencies for how to write / request (for example the request to get a schema from galdos) w.r.t the feature type name, where some servers included the prefix in the name, while others did not. I believe the thought was to make the feature type name exactly as the server provided it. This helped with the encoding of the FeatureType name when making some requests (you can always tell is the prefix is included ...).
Well, my proposal was to keep the feature type name exactly as provided
for the wfs communications, just to strip the prefix in the feature type
name seen by geotools (or change the ":" with "_").
That is, the datastore would read from the server "topp:states" but
the FeatureType returned by getSchema(xxx) would be named simply "states" or "topp_states".
A fix would be to add a field(s?) to the capabilities doc stored in a connection to include a flag for the prefix as part of the server generated name.
Hmm... that would be error prone in Geoserver because we let all
parameters be seen as is by the user. If the user decides to
include the prefix we're doomed...
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-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:1003,454128fb42014820651628!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes wrote:
in this case, can someone please explain just how a "Cascading WFS" would be used practically?
1) A WFS that only does basic filters - like mapserver - could be cascading behind one that can handle all filters.
2) A WFS that only outputs GML could be cascaded to one that outputs shapefiles, mapinfo files, kml, ect.
3) A more reliable WFS could suck a cascaded WFS in to its own caching database, so that if the original WFS went down it would remain up.
I agree that 1 and 3 beg an unchanged featureType to function in that ideal SDI vision. 2 does less so, where the WFS is kind of a format converter.
OK - concede that once munged into an anonymous generalised typing system the semantics is lost anyway!
What about if we were to just get rid of the prefix instead of changing it to an underscore? Then admins will be able to set their namespaces and prefixes to match those of the WFS they are cascading.
+1
Chris
I can see that for a desktop GIS application, the WFS source just wants to be bound to objects you can manpulate - but the name (machine id) should not form part of the user experience, you should assign an arbitrary identifier to reflect the arbitrary semantics you intend, and propagate the Title and other metadata to the user interface. (including possible the Title of the source server). If you want to exploit the source feature _type_ - for example apply an SLD that is declared to work against it, then you are almost back in case #1 - the feature type must be unchanged. I say almost, because if you are not advertising them outside the scope of your client application, you could maintain another layer of abstraction, mapping "real feature types" to local identifiers. I doubt we are proposing this level of re-engineering .
So, lets not put in a hack that will get in the way of a proper solution at a later date!
If you cant propagate the feature type unchanged, but want a WFS data store for uDig, can we simply disable it for Geoserver WFS? Possibly marginally OK for WMS, but not for SLD support, but I'd still reckon giving it an anonymous layer name and not pretending it should behave like any known feature type if you can actually handle it (accept an SLD that references that feature type for example)
Rob Atkinson
Andrea Aime wrote:
David Zwiers ha scritto:
Chris,
I recall this ... we talked about it a bunch.There were some inconsistencies for how to write / request (for example the request to get a schema from galdos) w.r.t the feature type name, where some servers included the prefix in the name, while others did not. I believe the thought was to make the feature type name exactly as the server provided it. This helped with the encoding of the FeatureType name when making some requests (you can always tell is the prefix is included ...).
Well, my proposal was to keep the feature type name exactly as provided
for the wfs communications, just to strip the prefix in the feature type
name seen by geotools (or change the ":" with "_").
That is, the datastore would read from the server "topp:states" but
the FeatureType returned by getSchema(xxx) would be named simply "states" or "topp_states".
A fix would be to add a field(s?) to the capabilities doc stored in a connection to include a flag for the prefix as part of the server generated name.
Hmm... that would be error prone in Geoserver because we let all
parameters be seen as is by the user. If the user decides to
include the prefix we're doomed...
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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-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:1003,454128fb42014820651628!
David Zwiers ha scritto:
You could do this ... just beware of different conventions for FT names (with / without prefix) for different server types. If you decide to start stripping the prefixes in the datastore, you will need to store the convention for the server somewhere (which andrea rejected ...).
Did I? No, I did not expressed myself properly. That's exactly what I wanted to do, that is, keep inside the datastore a mapping between the
name we use to communicate with the wfs server, and the name we show to
the gt2 user.
You are really trying to fix a bug in the specification, where the intended use/format of the featuretype name was not clearly defined, and the implementations did not come to a consistent convention.
This is indeed something that should be worth pushing on OGC for a clarification in the standard.
How does Galdos' server cascade? How does Degree's Server cascade (open source)? How do these servers (with mapserver) publish featureTypes? How do these servers expect the FT to be named in a request?
It may be interesting to check Degree... about Galdos, there is indeed
a 30 days evaluation...
Answers to these questions will dictate how this needs to be fixed (if at all).
If you don't look after the convention issue (always an option), perhaps the datastore should be renamed to GeoServerDataStore ... thus advertising more acurately the intended use :). This option probably has some speed inprovements availiable too ... but might open a can of worms (filled with sockets?).
Well, this allows me to voice something I had in the back of my mind...
when uDig or whatever app based on gt2 communicates with geoserver, it would be nice to allow the usage of transport protocol more space efficient and less cpu intesinve than GML. It does not even need to be
"our little secret", we can leverage stuff as java serialization (if only Feature was serializable, another big annoyance imho) or use protocols such as Hessian (http://www.caucho.com/resin-3.0/protocols/hessian.xtp),
which is both binary, simple and language independent.
It would still be WFS, just with a smarter encoding...
Cheers
Andrea Aime
Rob Atkinson ha scritto:
Perhaps we are missing the point a little here. What is the point of advertising a feature type at all? If it has no potentiall meaning, but is just an identifier, its more honest just to assign it a unique identfier - perhaps a UUID would be correct.
In the context of Spatial Data Infrastructures - the main driver of open standards and the deployment of re-usable data access services - the feature type must be recognisable by the client. The client will bind to a specific feature type, having discovered this in some fashion from a registry - maybe via a persistent binding like a Web Map Context docuement,
in this case, can someone please explain just how a "Cascading WFS" would be used practically?
I can see that for a desktop GIS application, the WFS source just wants to be bound to objects you can manpulate - but the name (machine id) should not form part of the user experience, you should assign an arbitrary identifier to reflect the arbitrary semantics you intend, and propagate the Title and other metadata to the user interface. (including possible the Title of the source server).
The issues that I was talking about are totally technical, you can in fact show title to the user, but not use it in GML encoding.
If your feature type name is "xxx:yyy" and you add it another prefix you
get something like "ppp:xxx:yyy" which is an invalid element name in XML, so you're generating invalid GML.
As for the title, hum... it occurs to me that we're probably not
cascading all the feature type metadata, but just using the feature type name (that's because we are treating the WFS data store just like
any other data store, ignoring that it can provide us more info about
the feature type compared to other data stores).
This is another place where gt2 data stores do not match the WFS expectations, that is, we have no place for title, abstract, metadata urls, keywords... We should add it, and we would need to advertise
this extra info in a "capabilities" object that we sorely lack, too,
in our datastore architecture.
Cheers
Andrea Aime
hmmm... just striping out the prefix wouldn't be a little naive?
what about a server providing bilbao:roads, madrid:roads and ny:roads ?
It could work as long as the namespace is properly preserved on each
FeatureType, though, which I don't know if it's the case currently
Gabriel
On Saturday 28 October 2006 11:38, Andrea Aime wrote:
David Zwiers ha scritto:
> You could do this ... just beware of different conventions for FT names
> (with / without prefix) for different server types. If you decide to
> start stripping the prefixes in the datastore, you will need to store
> the convention for the server somewhere (which andrea rejected ...).
Did I? No, I did not expressed myself properly. That's exactly what I
wanted to do, that is, keep inside the datastore a mapping between the
name we use to communicate with the wfs server, and the name we show to
the gt2 user.
> You
> are really trying to fix a bug in the specification, where the intended
> use/format of the featuretype name was not clearly defined, and the
> implementations did not come to a consistent convention.
This is indeed something that should be worth pushing on OGC for a
clarification in the standard.
> How does Galdos' server cascade? How does Degree's Server cascade (open
> source)? How do these servers (with mapserver) publish featureTypes? How
> do these servers expect the FT to be named in a request?
It may be interesting to check Degree... about Galdos, there is indeed
a 30 days evaluation...
> Answers to these questions will dictate how this needs to be fixed (if
> at all).
>
> If you don't look after the convention issue (always an option), perhaps
> the datastore should be renamed to GeoServerDataStore ... thus
> advertising more acurately the intended use :). This option probably has
> some speed inprovements availiable too ... but might open a can of worms
> (filled with sockets?).
Well, this allows me to voice something I had in the back of my mind...
when uDig or whatever app based on gt2 communicates with geoserver, it
would be nice to allow the usage of transport protocol more space
efficient and less cpu intesinve than GML. It does not even need to be
"our little secret", we can leverage stuff as java serialization (if
only Feature was serializable, another big annoyance imho) or use
protocols such as Hessian
(http://www.caucho.com/resin-3.0/protocols/hessian.xtp),
which is both binary, simple and language independent.
It would still be WFS, just with a smarter encoding...
Cheers
Andrea Aime
-------------------------------------------------------------------------
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
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
If you don't look after the convention issue (always an option), perhaps the datastore should be renamed to GeoServerDataStore ... thus advertising more acurately the intended use :). This option probably has some speed inprovements availiable too ... but might open a can of worms (filled with sockets?).
Well, this allows me to voice something I had in the back of my mind...
when uDig or whatever app based on gt2 communicates with geoserver, it would be nice to allow the usage of transport protocol more space efficient and less cpu intesinve than GML. It does not even need to be
"our little secret", we can leverage stuff as java serialization (if only Feature was serializable, another big annoyance imho) or use protocols such as Hessian (http://www.caucho.com/resin-3.0/protocols/hessian.xtp),
which is both binary, simple and language independent.
It would still be WFS, just with a smarter encoding...
Luis Sevilla of gvSig is working to organize a bit of an interoperability to focus on better WFS performance. Definitely high on the list of things to investigate is a nice binary transport format.
It would be very nice if the next iteration of WFSDataStore decoupled the WFS protocol stuff from the response type - I feel like they're pretty closely coupled now. Ideally we could support the binary format we decide to use, and even be able to use shapefile as a transport protocol for flat responses, reusing our existing shapefile code.
Another option may be the bxml stuff that cubewerx was pushing awhile ago:
http://www.w3.org/2003/08/binary-interchange-workshop/05-cubewerx-position-w3c-bxml.pdf
http://www.cubewerx.com/main/cwxml/
Chris
Cheers
Andrea Aime
-------------------------------------------------------------------------
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:1003,4543252d263462095110867!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org