Hi Bill,<br><br>I must correct me.<br><br>more preferable (better) then using the UUID should be use the MD%.<br><br>You could calculate the MD5 of the single record (or of the single geometry).<br>And when you retry a new record with same MD5 you can understand that it<br>
is the same record.<br><br>Regards.<br><br><br><div class="gmail_quote">2012/1/9 aperi2007 <span dir="ltr"><<a href="mailto:aperi2007@gmail.com">aperi2007@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Bill,<br>
<br>
I guess perhaps you could calculate the<br>
PointOnSurface (don't the centroids) for every single feature received.<br>
<br>
The PointOnSurface (available on spatialite for example)<br>
Will Allow you to understand if a new Features received is the same or is another.<br>
<br>
Another technics should be calculate the UUID of every feautre received.<br>
<br>
I guess this technics should allow to understand almost pretty well if a feature is repeated or not.<br>
<br>
Regards,<br>
Andrea.<br>
<br>
<br>
Il 09/01/2012 15:29, Bill Clay ha scritto:<br>
> All,<br>
><br>
> Thanks to Andrea Peri, I have just discovered that WFS 1.0.0 apparently<br>
> does NOT require a WFS server to report a unique feature ID with every<br>
> feature it transmits (a typical newbie misconception?).<br>
><br>
> The OGC specs are so nested and versioned, it's hard to be certain I've<br>
> understood them correctly. Could someone be kind enough to enlighten me<br>
> on the following?<br>
><br>
> 1. Can you confirm or correct the following understandings:<br>
><br>
> a. Every WFS server (versions 1.0.0 and 1.1.0) must have a permanent<br>
> unique identifier for every feature.<br>
><br>
> b. WFS GetFeature responses version 1.0.0 may or may NOT provide a<br>
> unique "fid" attribute with each <feature> element, provided the layer<br>
> is not editable (WFS-T).<br>
><br>
> c. WFS GetFeature responses version 1.1.0 MUST provide a unique "fid"<br>
> attribute with each <feature> element.<br>
><br>
> 2. Are you aware of any common implementation of WFS 1.0.0 that does NOT<br>
> always report a "fid" attribute with every <feature> element? (I<br>
> understand TinyOFS can be configured not to do so.)<br>
><br>
> 3. Do you believe that WFS services that do not always provide a "fid"<br>
> with every feature are unusual enough that the QGIS WFS client can<br>
> simply disable all feature caching for such servers?<br>
><br>
> The proposal at item 3 would require GetFeatures to be requested for the<br>
> entire canvas extent every time any previously un-fetched area is<br>
> exposed on the canvas. Practically speaking, this means potentially long<br>
> delays on every pan and zoom-out on maps containing WFS layers with many<br>
> features that are hosted by such servers.<br>
><br>
> Doubtless this is old news to everyone but me. Sorry for the static.<br>
><br>
> Bill Clay<br>
><br>
><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty אטלעש<br>-----------------<br><br>