Hi, Your use case is what transactional Web Feature Service (WFS-T) is meant for. Unfortunately WFS-T in not well supported yet. Obviously there is something in the standard that makes is hard to implement, and therefore interoperability between different servers and clients is poor.
- GeoServer and deegree-WFS are open source servers supporting WFS. Geoserver has best support for WFS version 1.0.0, while both support WFS 1.1.0. - Current OpenJUMP WFS plugin from deegree folks should support WFS-T v. 1.1.0 against deegree server out-of-the-box. - OJ WFS plugin does not quite do transactions against GeoServer with WFS 1.1.0 Issues should not be very hard to solve. - I have a feeling that OJ WFS plugin has more bugs with WFS 1.0.0 transactions. - I do not know of any other GIS client than OpenJUMP supporting WFS-T v. 1.1.0 - More open source clients support WFS-T v 1.0.0, for example uDig and gwSIG look promising. We are building a system that has much in common with your plan. Our GIS client will read GIS data from database through WFS, but for off-line work the response is stored as shapefiles. We have to send WFS feature ids also within a normal attribute field or otherwise our client woud not store them into shapefile. After off-line editing the client is forming WFS-T requests and updates and deletes can now take correct WFS fids from the shapefile. For inserts WFS-T server generates fids as usually. -Jukka Rahkonen- > Lähettäjä: [EMAIL PROTECTED] puolesta: Kurt Heston > Some background... > I've build a MapServer/PostGIS Java app and am using OpenJump for editing. My Java code changes attribues, but OpenJump handles any geos changes. > I was hoping to use the PostGIS OJ plugin directly, but I'm unable to get any writes to the DB to happen without errors. So, I'm relegated to editing SHP files in OpenJump and have to develop some strategy to manage population of changes into the PostGIS repository. > I think I'll use the GID values that go along with any new PostGIS row and copy them to an attribute in the SHP files. I'll then need to build some simple add/update/delete logic into transfers between OpenJump and PostGIS (and make it multi-user). > Ideas appreciated and thanks for confirming my findings. > Stefan Steiniger wrote: >> Martin is right, also ArcGIS creates own "dynamic" FIDs > >> Martin Davis wrote: >>> That's correct. FIDs are intended for internal JUMP use only. If >>> you need unique IDs, you need to define your own strategy for >>> creating and maintaining them. (This situation is not unique to JUMP >>> - in my experience you should pretty much never rely on an arbitrary >>> piece of software to define unique IDs for you - you just don't have >>> enough control and guarantee over their behaviour). >>> >>> Kurt Heston wrote: >>>> Nevermind. >>>> I should have read the code in OJ before I tried this. It appears >>>> FIDs are newly assigned each time a shapefile is opened, pretty >>>> useless when trying to tie systems together with a unique ID. >>>> >>>>> Kurt Heston wrote: >>>>> In looking at the instructions at: >>>>> http://openjump.org/wiki/show/Working+with+GML >>>>> >>>>> This line in the example GML template seems to infer the FID will >>>>> be output: >>>> >>>>> <property name="FID"><%=COLUMN fid%></property> >>>>> >>>>> But I get "Unrecognized attribute name: FID" when I try it. >>>>> Anybody gotten this to work? >>>>> >>>>> >>>>> Kurt Heston wrote: >>>>>> I'm using shp2pgsql to convert my OpenJump data to PostGis. It >>>>>> ignores the FID column. Is there a good way I can convert my SHP >>>>>> files to PostGis and retain the FIDs? >>>>>> _______________________________________________ _______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
