Jukka and Andreas, Thank you both for your responses. This has been helpful.
Andreas wrote: "But I cannot really see the point in trying to find a common name for an ID field, as that usually depends strongly on your use case" I didn't want a situation where a Feature Schema needs to have a persistent ID attribute for my schema and another persistent ID for another plug-in. I thought if we could come up with a fairly standard persistent ID attribute name and datatype that other plug-ins could use it as well. The Sunburned Surveyor On Nov 16, 2007 12:44 AM, Andreas Schmitz <[EMAIL PROTECTED]> wrote: > Rahkonen Jukka wrote: > > Hi, > > > I do not know how the WFS-plugin deals with feature id's, but for sure it > > must > >handle also external FIDs which are not changed during OJ session. That's > >because the current version that lat/lon is developing can also do WFS > >transactions (insert, delete, update) and delete and update would not be > >possible if OpenJUMP changes the fid that come with the GML package returned > >by > >WFS call. In insert case the WFS server must generate the FID in a way to > >suit > >the backend datastore so perhaps OpenJUMP is maintaining two set of FIDs > >during > >the session, internal FIDs and the ones from WFS service. I do not know if > >those WFS FIDs are kept if the features are copied to another layers. > >Perhaps > >there is something in WFS-plugin that might help you to get further. I think > >that Andreas Schmitz at lat/lon is now working on it. > > A WFS that deals with GML usually deals with Features that have a (within the > WFS) unique gml-ID. So you have two different "worlds". First, there's the > OpenJUMP world, which has unique FIDs, and which doesn't know anything about > GML-IDs. Second, there's the WFS world, which knows only about GML-IDs but not > about OpenJUMP's FIDs. > > That said, the WFSPlugin does dirty tricks when performing updates... It > actually identifies updated features by using the combination of all > properties > as filter. This is usually sufficient, as the data itself does very seldom > contain two identical features which only differ in the GML-ID. For the > deegree > WFS, for example, you can specify which parts/attributes of a feature should > be > used to identify it. Inserting will then fail, if these parts already exist > in a > feature. > > To summarize, you (Landon) should probably indeed store some ID in your HSQL > database, which should be sufficient to prevent trouble. But I cannot really > see > the point in trying to find a common name for an ID field, as that usually > depends strongly on your use case (in a perfect world, the WFSPlugin would use > the GML ids to identify features. In that perfect world, I'll add it someday, > since I'll have time for that ;-)). > > Best regards, Andreas > -- > l a t / l o n GmbH > Aennchenstrasse 19 53177 Bonn, Germany > phone ++49 +228 18496-11 fax ++49 +228 1849629 > http://www.lat-lon.de http://www.deegree.org > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHPViB737OVr+Ru7oRApnnAKDLWDWcVW3pU9X3K4f3xecMo8tuQQCeIfuG > xPqNslbaZFFZrYmiOLBkgio= > =+2qU > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
