Latest Contributions by TI

The trouble with allowing feature access to views, is that feature access should allow updates to the data source from the client application.  This is not always possible with views.  However, I reckon ESRI should allow views to be used as data sources for feature access with the 'create', 'delete' and 'update' options unavailable, and the 'sync' option should work one-way only for these services.  It can't be that hard to implement. ... View more

My work around at my previous job (and will probably do the same here) is to use database views, and a script that automatically runs at regular intervals (eg, overnight or hourly) to copy the view into a feature class (truncating the feature class first).  This is not ideal, as the feature class becomes out-of-date as soon as anything in the original data changes.  However, it is good enough for many use-cases. In fact, I have used this work-around so extensively, that I ended up writing a generic view-to-feature-class script, that had a configuration section that specified all of the input views, their related output feature classes, and optionally the 'where' clause to use on the view if not all rows should be included in the output feature class.  This way, the one single script would update (copy) multiple views to feature classes all in one hit. ... View more

I have found that it will dutifully write the TIN to the folder that contains the fGDB (ie, the folder with the '.gdb' extension), but it is not actually part of the fGDB in the database sense. It's rather dangerous behaviour, as nothing should ever touch those .gdb folders except ArcMap, as there is a danger of corrupting the database.  It's crazy that ArcMap will just write other files there, where it cannot later see them (from Catalog, or ArcMap).  It can read them initially, but you can't manually load them from there through ArcMap later. ... View more

8 years later and this problem still exists with ArcMap 10.5.1! I have found a 'fix' (actually a work around) that resolves the problem...  at least in my case... I found that if I exported my source layer to a new feature class, added the new feature class to the map, and then used this new feature class as the source layer, the 'Grid Index Features' works fine. I had a similar problem with the 'Strip Map Index Features' (different error message), and this same work around fixed it for 'Strip Map Index Features' as well as for 'Grid Index Features'. I haven't done much analysis on why this may be, but my original source layer had a definition query.  I have found that some ArcMap tools do not play nicely with layers with a definition query, and some do not play nicely with layers with a join.  In such cases, I always export to a new feature class (or in arcpy, use 'FeatureClassToFeatureClass_management() to create a temporary 'in_memory' feature class), and use the new feature class as the tool input.  Then delete the new feature class when done. I hope this helps some other people who are experiencing trouble with this tool. ... View more

No, I am still experiencing the issue here when testing just now.  😞  iOS for us though.  No Android here. ... View more

Collector doesn't even give me the option to have it using location services 'Always' only 'While Using the App'. ... View more

Bit of a side-track, but recent versions of iOS can keep the GPS functioning while the device is idle/asleep.  The GPS/location hardware module caches all location updates internally, and when the device wakes (or the location cache gets full), only then is the app called with the series of all location updates since the last time it received them (for many apps, the app would ignore all but the last location in the series).  The app can save a HUGE amount of battery power by doing this (amongst other location/battery saving optimisations).  Apple calls it 'deferred location updates'. I would guess that Android has something similar. ... View more

Hi Brett, Thanks for looking into this for us.  Detailing your testing plans doesn't really reassure us much in this case where multiple people are experiencing a serious issue.  🙂 We are using a variety of iPhones and iPads here.  After my users informed me of the problem, I have replicated it on an iPhone XR running iOS 12.1.4.  As stated earlier, I'm using Survey123 version 3.3.64. The problem occurs irrespective of whatever survey may be used.  As William stated, you don't actually need to run any survey at all to experience the problem.  All that is required is to open Survey123, and then close it again (ie, return to the 'Springboard' app launcher view. You will then see the blue bar at the top of the screen in whatever app you are using, to indicate that location services are being actively used. As I stated earlier, the Settings app shows that Survey123 is configured to use location services only when app is in use.  However, it is somehow bypassing this setting. What sort of battery consumption are you seeing over what time period. How does Survey123 battery consumption compare to other mapping apps that always using your location (eg Collector, Google Maps etc.)? Are you running other apps and services while using Survey123? Are you operating in areas with wifi and/or mobile data coverage or in remote offline environments? I haven't left it running long enough to drain my battery before killing the app, but users tell me that it goes from 80% battery to dead flat in a few hours.  This did not happen with the previous version of Survey123. Other apps do not drain the battery like this.  Other apps tested include Collector, Apple's 'Maps', and my own mapping/navigation app which uses Location Services heavily (and which can use the location services in the background for a number of days without draining the battery - in airplane mode). I'm testing just in my office with WiFi and mobile data coverage.  Colleagues have experienced the problem where there is no network in remote offline environments. Yes, I always have a random series of other apps and services running while running Survey123.  However, I have just now restarted my iPhone XR (power off, power on) and then run Survey123, done nothing within Survey123 (not even opened a Survey), then closed Survey123 and it is now flat out draining my battery (blue bar at top of screen indicating location services is running).  I will now kill Survey123 to prevent my battery dying. ... View more

hmm... interesting.  It sure does some weird things with stdout and stderr.  I tried it with the print just now, but it didn't help in my case. ... View more

That work around doesn't work (at least in my case).  I suspect that it is because the error is not actually raising an exception, therefore it cannot be trapped by the try.  It simply logs an error without any actual real problems. It's not a big deal, because the script continues to run fine.  I would simply prefer it not to print spurious errors when an error hasn't actually occurred.  🙂 ... View more

pass makes more sense in this context than printing a whitespace character or empty string.  I don't see any point in printing an empty line in this context.  pass is a Python no-op, so actually legitimately does nothing in a context where a statement is required.  I think that print statement is an attempt at a no-op, but doesn't quite hit the mark, as it would generate an empty-ish line of text (which may not matter to some people, but might to others). ... View more

I'm getting the same error using ArcMap 10.5.1.  I have Python Add-In with several tools which invoke pythonaddins.GPToolDialog() .  In all cases they work perfectly well, but print out this error to the Python console: TypeError: GPToolDialog() takes at most 1 argument (2 given) I reckon it's a bug as the documentation clearly states that the function takes 2 arguments and it works fine with 2 arguments AND it doesn't appear to be a real problem as the tools all run perfectly well. (I have a python console open sometimes for diagnostic purposes when developing and running these tools which use 'print' commands to log their progress.) ... View more

Thanks Phil.  Unfortunately, the created by system field (editor tracking) is no good for us.  As explained earlier, this survey submits data via an ArcGIS Online feature service proxy using saved credentials for the actual ArcGIS Server feature service.  So all the same username gets logged for every survey in the editor tracking fields. We are stuck on version 2.8.2 for a while yet, due to our iPads being to old to upgrade any further.  But I'll keep trying to persuade management here that we need to upgrade in order to overcome some deficiencies in our current service. Cheers, Nik. ... View more