AnsweredAssumed Answered

Strange geometry numbers after geodetic offset

Question asked by mikedmanak on Feb 19, 2016
Latest reply on Feb 19, 2016 by DGoyal-esristaff

I'm using the geodetic move function to calculate the location of marine mammal sightings based on the current vessel location and various bearing and distance values from different field gear (theodolite, Big Eyes, reticle binoculars, etc...)

NSArray *movedPoints = [pointEngine geodesicMovePoints:pointArray byDistance:distance inUnit:AGSSRUnitMeter azimuth:bearing];


When I first display the attributes things look fine:

Simulator Screen Shot Feb 19, 2016, 10.12.23 AM.png

As you can see the "Sighting Location" attribute is displayed as valid lat/long values.


That table row is displayed using the following logic:

AGSGeometryEngine *sightingEngine = [[AGSGeometryEngine alloc]init];

AGSGeometry* sightingGeometry = [sightingEngine projectGeometry:[self.feature geometry] toSpatialReference:[AGSSpatialReference wgs84SpatialReference]];

cell.detailTextLabel.text = [NSString stringWithFormat:@"%f, %f", [ x], [ y]];


If we perform the offset calculation again (say someone edits the reticle count and re-saves the record) the attributes displayed by the same cell logic produce this result:

Simulator Screen Shot Feb 19, 2016, 10.12.33 AM.png

As you can see the values for Sighting Location are now displaying a very small number for Lat/Long based on the same attributes (  This value appears to be the offset applied to the feature, not the actual Lat/Long of the geometry.  If I close down the view and reload (which re-selects the feature from the geodatabase) the table appears as expected, with the correct Lat/Long values.


Can anyone explain what I'm seeing here?  Is the geodetic offset being stored in a business table somewhere in the geodatabase until the AGSGDBFeature variable is de-allocated or something?  If that is the case, is there some way I can force the database to apply waiting edits to the feature besides saving it?