Rob Atkinson ha scritto: > Hi Andrea > > can you provide a bit more information about the circumstances that a > gml:id needs to be externally provided?
I have two cases: - a distributed network of servers whose data needs to be kept in synch. If one server generates a new feature, all of the other servers need to get exactly the same feature with the same id (to make sure everyone calls the same feature the same way so that future updates also hit the same feature). - an application that mixes geographic data access with other non geographic data access. The primary key is generated by the non geographic part of the application and needs to be set into the features. The need might be to follow a specific PK generation convention, mandated by the organization, or to make sure certain referential integrity constraints are preserved (especially true in the multicolumn primary key case) Mind, in both cases we're not talking of WFS explicitly, the need arises at the GeoTools coding level. I was drawing a parallel with WFS because they also cite the case of assigned primary keys as a valid one. > The reason I ask is that there is some debate about the whole nature > of feature ids. > > The semantics of gml:name is an id provided by named party (the > attribute codeSpace is used to determine who sets the id). gml:id is > locally scoped to the response document, although the WFS > getFeatureByID exploits this however under the assumption that it is > scoped to the set of features served by the WFS. > > gml:name is multi-valued, but there is no good way in WFS 1.1 of > specifying which gml:name a query might be referring to. This is > solved in WFS 1.2 Is there a WFS 1.2 spec? Last time I checked they were working on 2.0 > GML 3.2 provides a extension of gml:name called gml:identifier which > behaves explicitly like the way WFS assumes gml:id to behave - a > single stable id defined by the data provider. > > So, I would think your solution is OK - but it might be worth noting > its a workaround in a problem in the specs. Thus, IMHO, we are pretty > free to make any behaviour we find useful, but should not > over-engineer a solution as things may change. I guess the local JDBC approach I proposed would fit the bill then. It would trigger only if the user purposedly creates a valid feature id for the specific column setup (typename.number, typename.string, typename.v1&v2&v3), the code would keep on behaving like this if the feature id is randomly generated instead Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
