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

Reply via email to