POST
|
Will Survey123 support auto-complete? I have a picklist with many values that is tedious for users to scroll through as they look for their choice. It would be great if they could start typing and have the list advance to keep pace with their entry.
... View more
05-15-2016
04:42 PM
|
1
|
9
|
7385
|
POST
|
So far as I know, Collector does not support "smart form" functionality like calculations, conditional lookups, and so on. ESRI's Survey123 does support smart form functionality, but it is form-centric...not map-centric...and does not support edit of existing data.
... View more
10-15-2015
09:55 AM
|
1
|
2
|
426
|
POST
|
In order to prevent inadvertent edits to an ID field during data maintenance with ArcGIS Collector, I set the field to "read-only" in ArcMap prior to publishing the feature class to an AGOL hosted feature service. I exported the feature service back to FGDB format at the conclusion of data collection, but could not un-check the field's read-only setting. See the attached example. I can open an edit session on the FGDB, I can add fields, I can delete fields, and I can do any other sort of edit, but I cannot set that field back to editable. The exported FGDB is not a replica, It appears to be a FGDB of the plain vanilla variety. The work-around was easy enough...just add a new field, calc the ID values into it, and delete the original field. No problem. However, I remain curious about why I was prevented from setting the ID field back to an editable state. Any explanations are welcome.
... View more
07-14-2015
06:57 PM
|
0
|
0
|
2942
|
POST
|
Problem solved, crisis averted! A shout-out to Deb Traver at NPS for pointing me to this documentation of ESRI Bug 000084156 which, after making a backup of the folders in question, delivered a successful sync. http://support.esri.com/en/bugs/nimbus/QlVHLTAwMDA4NDE1Ng==
... View more
06-15-2015
08:24 AM
|
1
|
2
|
1394
|
POST
|
The sync process on a Samsung Galaxy Note Pro 12.2 hangs with no progress, no error message, and no timeout. It just sits there, despite a strong WiFi or 4G connection. See the attached Image1. This Samsung has successfully synced previous Collector projects without difficulty, so I know the device itself is capable. Other devices (iPad, Android phone, etc.) are successfully syncing the current Collector project, so I know the current project itself is not “broken”. This leads me to believe that something internal to the client_delta or geodatabase files on the Samsung have, somehow, gotten cooked. These files are visible in the Samsung’s ArcGIS_Collector folder. See the attached Image2. This text is in the SyncProcessRecoveryInfo file (you may have to scroll across to see all the content), and the clientDeltaPath value is correct. {"uploadId":"Upload Failed","clientDeltaPath":"/storage/emulated/0/ArcGIS_Collector/offline_data/cbeyerhelm.fpr_UjNGUFIubWFwcy5hcmNnaXMuY29t/8e53d896417a463885417d84604dd434/client_delta_1433811446075.geodatabase","createdClientDelta":true,"uploadedClientDelta":true,"acknowledgedUpload":false,"syncComplete":false,"syncStatusUrl":null} So, how can I either fix this problem, or make a backdoor retrieval of the data and attachments and get them into my feature service. There are 42 pending records and attachments that took field crews 2 weeks to collect. I'm in a little bit of a panic. Thank you...
... View more
06-13-2015
03:23 PM
|
0
|
5
|
5022
|
POST
|
Yes, maintaining geoprocessing history can be one source of MXD bloat. However, the most puzzling (and annoying) one is when you open an MXD, do nothing except click SAVE, exit ArcMap, and notice that the MXD has doubled in size.
... View more
10-01-2014
08:28 AM
|
0
|
0
|
260
|
POST
|
Thank you. That is interesting. I hadn't explored the nuances of saving down to prior versions. So, yes, it does seem like a bug if saving down to prior versions from arcpy results in smaller file size, but saving from arcpy to the current version does not reduce file size.
... View more
09-03-2014
08:55 AM
|
0
|
7
|
1101
|
POST
|
Thanks for the suggestion. This approach does represent a solution, though not quite what I had hoped for. It's shortcomings are that it is very slow because DocDefragmenter has to be re-executed for every MXD in mxdList (about 4.5 minutes to process 37 MXDs vs 8 seconds using the native DocDefragmenter executable), and the command line form of DocDefragmenter does not accommodate the same range of options available in the native DocDefragmenter dialog. Nevertheless, it is adequate for situations where a scripted, non-interactive MXD file size reduction is required. Otherwise, just running the native DocDefragmenter executable would be faster, and offers more options. Here is the working snippet that I tested... import arcpy, subprocess docDefrag = r"C:\Program Files (x86)\ArcGIS\Desktop10.1\Tools\DocDefragmenter.exe" inFolder = r"C:\Workspace\projects" outFolder = r"C:\Workspace\projects\backups\BackUp1" arcpy.env.workspace = inFolder mxdList = arcpy.ListFiles("*.mxd") for mxd in mxdList: inMXD = inFolder + "\\" + mxd outMXD = outFolder + "\\" + mxd[:-4] + "_Defrag.mxd" argList = [] argList.append(docDefrag) argList.append(inMXD) argList.append(outMXD) subprocess.call(argList)
... View more
09-01-2014
02:49 PM
|
0
|
1
|
1101
|
POST
|
I have a folder of 50+ MXDs that have been edited repeatedly, such that their file size has increased over the course of time. Applying File - Save A Copy from ArcMap, or the mapDoc.saveACopy() method in the Python window will reduce the current MXD's file size...but only for the MXD that is currently open in ArcMap. Applying the mapDoc.saveACopy() method to a long ArcPy list of MXDs does, indeed make a copy of the MXDs, but it does not also reduce their file size. So, the question is, is there a way to automate MXD file size reduction? I've explored the os.startfile(mxd_path) scenario, but it opens a new instance of ArcMap for each MXD...which is not satisfactory. Advice or insights are welcome. Thanks...
... View more
08-31-2014
01:42 PM
|
1
|
12
|
4802
|
POST
|
Hi Micheal. No specific time frame was given for fixing the issue, but ESRI did confirm that the bug persists through versions 10.2 and 10.2.1, and that a member of their development team has taken the issue on. Although lyr.replaceDataSource() would work, I elected to use mapDoc.findAndReplaceWorkspaces() as it is faster than iterating through each TOC layer.
... View more
01-28-2014
05:12 PM
|
0
|
0
|
236
|
POST
|
For information, this issue has now been registered as a bug with this reference: NIM098396: arcpy.mapping.replaceWorkspaces will break the data source connection to an Image Service Layer when replacing a workspace in a map document. Occurs with SDE workspaces, file geodatabases, and shapefiles.
... View more
01-28-2014
09:39 AM
|
0
|
0
|
236
|
POST
|
Yes, the replaceDataSource() method does seem like the only ArcPy work-around at this point. Thank you.
... View more
01-27-2014
08:39 AM
|
0
|
0
|
1069
|
POST
|
Your suggestion would be a good approach in a situation where we needed to update the Image Service layer sources. In this situation, however, I only need to update the SDE connections to accommodate the upgraded SDE environment. The Image Service environment is not changing, so there is no need or desire to update Image Server layers. To illustrate this issue further, the 3 attached images document the step-by-step results at crucial points in the replaceWorkspaces() process using the ArcMap Python interactive window. The first image is from just after the layers have been interrogated for their workspacePath and a TOC refresh. No signs of any trouble yet. All is well. The second image is from just 2 commands later�?�the replaceWorkspaces() and the TOC refresh commands. Here, the targeted SDE workspace has indeed been replaced successfully, but the replaceWorkspaces() method has also caused the non-target Image Sever Source properties to be deleted or corrupted. Clearly, something in the replaceWorkspaces() method has stepped on the Image Server content even though replaceWorkspaces() did not pertain to any Image Service layers. The third image follows mapDoc.save(), and illustrates that the broken doc cannot be saved. The bottom line is that replaceWorkspaces() successfully updates the intended target SDE connections, but it also has the unintended consequence of deleting or corrupting non-target Image Service source properties. If I've missed your point, please reply back...
... View more
01-26-2014
08:46 AM
|
0
|
0
|
1069
|
POST
|
For reference, the incident ID is: Esri Incident #1234321 (Thomas J) mapDoc.save() fails after mapDoc.replaceWorkspaces() in MXD with ArcGIS Image Service
... View more
01-24-2014
06:56 AM
|
0
|
0
|
1069
|
Title | Kudos | Posted |
---|---|---|
1 | 09-09-2023 09:43 PM | |
1 | 12-18-2021 09:16 AM | |
1 | 12-15-2021 07:14 PM | |
1 | 05-14-2021 07:12 AM | |
1 | 03-13-2021 04:11 PM |
Online Status |
Offline
|
Date Last Visited |
06-02-2024
06:14 AM
|