is it possible to configure a transactional WFS-Featuretype and another
non-transactional WFS-Featuretype at the same time within one geoserver
instance? The servicelevel (Basic/transactional) of the WFS-Configuration
concerns to all configured Featuretypes, doesn't it?
Unfortunately you can not configure access control on feature types
separately. As you say its all or nothing.
One workaround that I have seen used in the past is when using a
relational database. You can revoke all modification privileges from a
particular table and then add the table as a feature type in GeoServer.
When a wfs client tries to execute a transaction request against that
feature type an exception should be reported back stating that the data
is read only.
Or perhaps someone else may have a more clever scheme.
-Justin
stoff wrote:
Hi,
is it possible to configure a transactional WFS-Featuretype and another
non-transactional WFS-Featuretype at the same time within one geoserver
instance? The servicelevel (Basic/transactional) of the WFS-Configuration
concerns to all configured Featuretypes, doesn't it?
So we have to run a UMN mapserver instance at the same time to provide the
WMS functionallity.
I don't find it handy to configure a choice of applications at the same time
... but it happens ..
Cheers and thanks again,
Christoph
Justin Deoliveira-4 wrote:
Unfortunately you can not configure access control on feature types
separately. As you say its all or nothing.
One workaround that I have seen used in the past is when using a
relational database. You can revoke all modification privileges from a
particular table and then add the table as a feature type in GeoServer.
When a wfs client tries to execute a transaction request against that
feature type an exception should be reported back stating that the data
is read only.
Or perhaps someone else may have a more clever scheme.
-Justin
stoff wrote:
Hi,
is it possible to configure a transactional WFS-Featuretype and another
non-transactional WFS-Featuretype at the same time within one geoserver
instance? The servicelevel (Basic/transactional) of the WFS-Configuration
concerns to all configured Featuretypes, doesn't it?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
So we have to run a UMN mapserver instance at the same time to provide the
WMS functionallity.
I don't find it handy to configure a choice of applications at the same time
... but it happens ..
WMS? Or you do mean plain WFS (without the T?)
A properly configured GeoServer 1.6.0beta4 should
be able to offer you enough speed to match MapServer
(if you have them work under the same conditions,
that is, same antialiasing, same output format and so on).
As for WFS/WFS-T distiction, nothing prevents you from
deploying two GeoServer instances in your web container
and configure one for basic WFS and the other for WFS-T,
thus reducing the number of actual software you have to
play with. Just name the first geoserver-ro.war and the other
geoserver-rw.war and you'll have two geoserver running
at two different urls (the first at http://localhost:8080/geoserver-ro
and the other at http://localhost:8080/geoserver-rw).
Another option you might consider is to sponsor a quick
security subsystem enhancement so that data in different
namespaces can be accessed only by different users, and lock
down a few of them with a username/password you don't provide
to the rest of the world (making them effectively read only).
Oops, you are right! I thought about WFS and not WMS. We need a WFS to
have the possibility of selecting and snapping. And the WFS-T to enable
on-screen digitizing.
We thought of UMN mapserver because of proven performance abilities.
Perhaps we should have a look at Geoserver's beta ... versioning might
be worth testing as well.
Thanks for your input, Andrea!
Cheers,
Christoph
aaime wrote:
stoff ha scritto:
Thanks for your answer, Justin!
So we have to run a UMN mapserver instance at the same time to provide
the
WMS functionallity.
I don't find it handy to configure a choice of applications at the same
time
... but it happens ..
WMS? Or you do mean plain WFS (without the T?)
A properly configured GeoServer 1.6.0beta4 should
be able to offer you enough speed to match MapServer
(if you have them work under the same conditions,
that is, same antialiasing, same output format and so on).
As for WFS/WFS-T distiction, nothing prevents you from
deploying two GeoServer instances in your web container
and configure one for basic WFS and the other for WFS-T,
thus reducing the number of actual software you have to
play with. Just name the first geoserver-ro.war and the other
geoserver-rw.war and you'll have two geoserver running
at two different urls (the first at http://localhost:8080/geoserver-ro
and the other at http://localhost:8080/geoserver-rw).
Another option you might consider is to sponsor a quick
security subsystem enhancement so that data in different
namespaces can be accessed only by different users, and lock
down a few of them with a username/password you don't provide
to the rest of the world (making them effectively read only).
Hope this help
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
