Latest Contributions by MichaelDavis3

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: 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", [sightingGeometry.envelope.center x], [sightingGeometry.envelope.center 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: As you can see the values for Sighting Location are now displaying a very small number for Lat/Long based on the same attributes (feature.envelope.center).  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? ... View more

We are using GUID fields in one of our new apps to store primary/secondary keys.  In the past we've used GUID/UUID but stored them in plain old text fields. When querying this data in the ArcGIS Runtime using an AGSQuery object we are running into some strange behavior. If we select a GUID field out as an NSString or NSUUID object it returns something like this: 9f6d8cac-19b4-4e24-af96-4654aac8287e Note that this is not quite the same as GUIDs when viewed in ArcGIS - they don't have the curly brackets {}.  The strange thing is that if I then try to use this value in a query, say to get all records for a feature with this primary key, I have to manually add the brackets back in like so:     query.whereClause = [NSString stringWithFormat:@"SurveyID = '{%@}'",[self.surveyID uppercaseString]]; Note that in addition to manually adding the curly brackets back in, I've also had to convert the string to upper case.  If I don't do this I have to use the LIKE operator instead of =. Any idea why GUID fields are behaving so strangely?  I'm worried that records I create in the mobile app using a new UUID (iOS version of GUID) won't check in correctly, or the value will be altered when checked in. Any ideas why the query behavior of this data type is so inconsistent? ... View more