Latest Contributions by MichaelDavis3

‎01-29-2015

We have dealt with this by using a scheduled task to go to our database, archive the full size attachment to a folder structure, and then re-attach a reduced resolution version for viewing on mobile devices. Not perfect, but it does significantly reduct the database size.

‎01-29-2015

I was having trouble filtering data from a runtime geodatabase based on date fields (not using a time-aware database). I finally figured it out: https://geobits.azurewebsites.net/querying-esri-runtime-database-featuretable-with-datetime-field/ The quick-and-dirty version is that you need to do string comparisons of your date field and whatever NSDate variable you want to compare against, like this: query.whereClause = [NSString stringWithFormat:@"strftime('%%Y-%%m-%%d %%H:%%M:%%S', DateTime) >= '%@'", [Utility returnStringFromDate:mapViewController.filterDate withDateFormat:@"yyyy-MM-dd 00:00:00 +0000"]]; [Utility returnStringFromDate: withDateFormat:] is just a wrapper for an NSDateFormatter and string conversion function. -Mike

‎01-09-2015

I believe this is just a pass-through of the CLLocation speed property. It is meters/second.

‎01-08-2015

The documentation for AGSLocation defines the velocity attribute as follows: The velocity. That's it. Does anyone have any more information on this attribute - like perhaps the unit of velocity? Meters/sec? MapUnits/sec? Thanks!

‎12-23-2014

Here's a snippit of our code to query all the contents of a non-spatial table: -(void) loadSites { NSError* error; _gdb = [AGSGDBGeodatabase geodatabaseWithName:@"msm" error:&error]; self.environmentFeatureTable = [_gdb featureTableForLayerName:@"SurveyEnvironment"]; NSArray *fields = [[NSArray alloc] initWithObjects:@"DateTime", @"EffortStatus", @"DateTime", @"EnvironmentID", nil]; AGSQuery *query = [[AGSQuery alloc] init]; query.orderByFields = @[@"DateTime DESC"]; query.whereClause = @"1=1"; //query.outFields = @[@"*"]; query.outFields = fields; query.returnGeometry = NO; [self.environmentFeatureTable queryResultsWithParameters:query completion:^(NSArray *results, NSError *error) { self.environmentQueryResults = results; [self.tableView reloadData]; }]; } If we are trying to access related records we would pass in the key when we fire up this view and set it as an item in the whereClause.

‎12-23-2014

We just use an AGSQuery object and execute it against the "feature table". I put that in quotes because it doesn't have to be a feature layer - a non-spatial table works just fine... as long as we set the returnGeometry flag to NO.

‎12-23-2014

We went down that road when we first implemented offline related features and ran into some issues. For us it has been more reliable to abandon ESRI's relationships entirely and maintain our own using machine generated keys. When doing this it is relatively easy to pass the key in and run a query against the table.

‎12-23-2014

The ios 7 & 8 updates introduced changes to the way views address each other. You need to reset your development target in XCode and debug the new errors that pop up.

‎12-04-2014

From experience the answer is probably yes - the GPS is causing battery drain. For our survey apps where the GPS is burning full time (aerial survey and the like) we see device life cut almost in half. To mitigate we usually tell our field crews to bring along cabling to connect to vehicle power (12v port) or we include one of those cheap monoprice battery boosters. That said - there is a lot you can do to optimize battery life by switching the GPS off when you don't need it. Even when we are doing stuff like collecting a track log we've found we can flip the GPS on in the background, wait for the accuracy to settle down, add a point to the log, and then shut it down until we want to add another point. It would be fantastic if ESRI posted a sample with the tracking code they use in the newer versions of Collector, would love to know if they have any tricks for maintaining the balance between power usage and tracking capabilities.

‎11-18-2014

Hi Al - We finally ran into this bug again. I've emailed you a copy of the geodatabase that throws the extent error, as well as a working geodatabase generated from the same service after republishing (and zooming out slightly)

‎10-28-2014

Noticed a somewhat related post here: https://community.esri.com/message/349283#349283 I think what was happening is that the geodesic move may have been executing in Web Mercator. Not sure why, as I was firing up a new geometry engine for the task and explicitly creating a WGS84 point to move. Either way I changed up some variable types (bearing and distance as double vs. integer) and magically everything started working. Now have a check to do a geodesic measure back between the original point and new point and it checks out every time. Weird - but whatever. -Mike

‎10-28-2014

Check this link: http://support.esri.com/cn/knowledgebase/techarticles/detail/42579 The script mentioned has worked well for us with orphaned data in .geodatabase files.

‎10-28-2014

use the script mentioned here: http://support.esri.com/cn/knowledgebase/techarticles/detail/42579 Works great for us on stuck .geodatabase files.

‎10-27-2014

I'm using geodesicMovePoints to record locations of marine mammals using a bearing and distance provided by the user. So far everything is working smoothly using something like this //create point for platform location AGSPoint* vesselPoint = [AGSPoint pointWithX:[platX doubleValue] y:[platY doubleValue] spatialReference:[AGSSpatialReference wgs84SpatialReference]]; //drop it in an arrray for move NSArray *pointArray = [NSArray arrayWithObject:vesselPoint]; //move points AGSGeometryEngine *pointEngine = [[AGSGeometryEngine alloc]init]; NSArray *movedPoints = [pointEngine geodesicMovePoints:pointArray byDistance:distance inUnit:AGSSRUnitMeter azimuth:bearing]; AGSPoint* updatedPoint = [movedPoints firstObject]; However it doesn't seem like the point are being moved far enough... for instance I have collected a couple test points using a base TPK with some buffered distances baked in from some test points: The first point was collected with an offset of 10 meters at bearing 180. The second point was collected with an offset of 50 meters, also at 180. The actual measurements from the test point are 7.7 and 45.8 meters. Can someone explain a bit about what is going on in the geodesicMovePoints function? Any ideas what might be accounting for the discrepancy in distance? Matt Cooper‌

‎10-09-2014

Our workaround has generally been to do some sort of dice or gridding of the large complex geometries to break them up into smaller chunks. I doesn't fix the issue, but it reduces the size and visibility of the drawing artifacts. Is this something that will be addressed by an SDK update (drawing issue), or is it something on the geodatabase creation side that will require an ArcMap update?

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by MichaelDavis3

Re: Syncing and photo attachments.

Using runtime date fields as a query parameter

Re: Units for AGSLocation velocity?

Units for AGSLocation velocity?

Re: Offline Use - Related Table query

Re: Offline Use - Related Table query

Re: Offline Use - Related Table query

Re: GIS crashed with IOS SDK 10.1.1-u2, iOS 8.1.1

Re: Excessive Battery Consumption, GPS the cause?

Re: The geometry cannot fall outside the replica extent error

Re: Geodesic offset not returning expected results

Re: Sync Error with Collector and Ipads.

Re: Hi, Collector is not syncing for me now

Geodesic offset not returning expected results

Re: Error with multipart geometry in runtime geodatabase

Re: Windows Support as Amazon Store is End of Life

Icon source for callout buttonimage

Re: Trying to create an ESRI portal for my organiz...

Re: Backup In Progress impeding work 2.9.2

Re: Publish Multiple Feature Services From One Ent...

Esri Forestry Group (EFG)

Alaska GIS Users