That is the purpose of the Auto Assign Attribute plugIn. Larry
On Wed, Oct 8, 2008 at 11: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 > -- http://amusingprogrammer.blogspot.com/
_______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
