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. -Jukka Rahkonen- > -----Alkuperäinen viesti----- > Lähettäjä: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Puolesta Sunburned Surveyor > Lähetetty: 16. marraskuuta 2007 1:42 > Vastaanottaja: List for discussion of JPP development and use. > Aihe: [JPP-Devel] Question about persistent feature identification... > > I know that OpenJUMP uses a FID to uniquely track features > during a "session" or period of time when the program is > executing. I believe from earlier discussions on this list > and in my work with the code that this FID is generated when > a data source is loaded into a FeatureCollection. > > I'm working on a very simple spatial relationship plug-in > that I can use as a demo for an OSGeo article. The plug-in > will allow the user to query information about the spatial > relationships in features on the same layer or in different > layers. I'm going to try storing this information > persistently in an HSQL database. > > Here is the challenge I am facing. I need a way to uniquely > identify features between sessions of OpenJUMP, or it does me > no good to store the spatial relationship information. Since > OpenJUMP supports a number of different file formats for the > storage of features, the only sensible way (it seems to me) > to do this is with a "special" attribute of the Feature. The > attrubute would be named something like "persistent_id" and > could store an int or long value. > > Here are some of my questions for the other OpenJUMP programmers: > > [1] I can't imagine that I will be the only plug-in developer > that will want to identify features between sessions of > OpenJUMP. Could we decide on a standard attribute name and > data type to do this? I'll use just about anything that makes sense. > > [2] Is there a more elegant solution that I am missing? The > solution I describe could have some problems. For example, > what happens when you copy features and their attributes to a > new layer? The persistent ID would be duplicated. (One way > around this obstacle would be to use the layer name as part > of the identification mechanism.) There could be other > problems. For example, I think I would need to include a > simple plug-in that could add this attribute to a Feature > Collection's schema if it did not exist and generate values > for this attribute on each of the features. > > I appreciate any thoughts or suggestions on this. Perhaps > OpenJUMP already has the ability to persistently identify > features and I am overlooking it. > > The Sunburned Surveyor > > -------------------------------------------------------------- > ----------- > 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
