REST API - AddFeatures issue (duplicate feature geometry created)

ChristopherJennings · ‎08-13-2010

Hi all,
I'm successfully adding a point feature to a feature service via the REST API's AddFeature endpoint. However, when inspecting the x,y coordinates of the features, they are identical to the feature that existed prior to the REST request. e.g. my feature class had 12 points. Running my REST request successfully adds a 13th point, but the x,y coords for this point are identical to the 12th point, although the geometry sent in the request is different.
Has anyone else experienced this?

FYI, refreshing the map service and clearing the REST cache do not fix this, and should not really be a factor anyway. I can successfully add points using the Flex Viewer 2.0 and their coordinates appear to be correct. This is only an issue when adding points via code (C#) using the REST API.

Thanks,
Chris

RahulRavikumar · ‎08-15-2010

Could you post the source code for the C# client that you are using to make the REST request ?

The REST API does not make any distinction when handing requests. It treats all clients (Silverlight, JavaScript, Flex, iOS etc the same). It actually does not matter where the request is made from. If adding a point works in Flex, then you should use something like Fiddler, to make sure that the REST request you make to the server is identical to the one made by Flex.

ChristopherJennings · ‎08-17-2010

Unfortunately, it's not practical to post the code because it's part of a larger C# library I wrote.

Strangely, I've gotten this to work using a slightly different method. So far, the only real difference between my two approaches is how I'm handling the x/y geometry values in C# before creating a JSON string. It behaves strangely when the geometry values are converted from decimals --> strings, but succeeds when staying with strings the entire time. It makes no sense because the JSON sent to the REST API looks the same either way...

Ex: "geometry" : {"x" : 12345, "y" : 23458}.

Still investigating, but I'll chalk this one up to user error for now.