|
|
Jody Garnett created an issue |
|
WFS Transaction insert returns incorrect FeatureIds for Shapefile |
|
Issue Type: |
|
|---|---|
|
Assignee: |
|
|
Components: |
WFS |
|
Created: |
10/Mar/14 7:00 PM |
|
Priority: |
|
|
Reporter: |
Major|
Have reports of WFS-T shapefile returning incorrect FeatureIds. We are having an issue when users create features and want to immediately edit them in maploom because the wfs-t doesn’t return the proper feature id if the layer is backed by a shapefile. … For us to insert a feature and immediately edit it we’ll have to check to see if the feature id looks like new# in which case perhaps send out a GetFeature with the bound of the feature that we just created (or getfeatureinfo…) . If the response has multiple features we can separate which one it is by comparing the geometry that comes back with what we had sent up (might have to deal with floating point error). Not that it is the end of the world but curious if you expect clients to have to deal with this themselves since it has complications and perhaps even performance implications if it was to be handled ‘as expected’ by geoserver. Since the geometry is of the form “newXXX” it sounds like the temporary (pre commit) values are leaking out into the Transaction response. Calling commit should update each FeatureId “in place” replacing with the correct value based on row number. Scary workaround is to follow each insert if with a GetFeatureInfo request, and compare returned geometry for a match! |
|
|
|
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) |
|
|
