Stefan, Can I get the source code for your plug-in. I think it will be rather simple to modify it to add a UUID as an attribute to each feature in a layer.
Thanks, SS On Wed, Oct 8, 2008 at 9:14 AM, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > well I have done a plugin which just enumerates all items in a layer - but I > doubt this will help when working with several layers. > > adding that plugin to oj-core can be done - if wished - in a few minutes. > > stefan > > Sunburned Surveyor wrote: >> >> Jukka wrote: " I am not >> sure what could be a good solution for you, else than making read/write >> database connector to OJ. " >> >> I thought about writing a little plug-in that would automatically add >> a UUID attribute to all the features in a layer and would then >> generate valid UUID values for that attribute. >> >> SS >> >> On 10/3/08, Rahkonen Jukka <[EMAIL PROTECTED]> wrote: >>> >>> 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 >>> >> _______________________________________________ >> jump-users mailing list >> [email protected] >> http://lists.refractions.net/mailman/listinfo/jump-users >> >> > _______________________________________________ > jump-users mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jump-users > _______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
