Latest Contributions by JamesCrandall

‎03-12-2020

Hi Aaron, Thank you for the quick response on this! The distance measured using the Measure too in the AGOL webmap viewer is 200 meters.

‎03-10-2020

Update: Android Android I believe. (will follow up shortly to verify). Thanks!

‎03-10-2020

We're seeing some gaps between tracks being collected (AGOL Hosted Service) with inexplicable time differences. In some cases that time difference using the location_timestamp value makes sense (it may have taken 30 seconds to travel that distance). However, in other cases that time difference in the location_timestamp is 1-2 seconds and simply an impossibility. Just hope to get some insight as to what might be occurring to help explain.

‎03-09-2020

FWIW, we opted to implement James' solution and have it running on a Windows Server 2012 via a scheduled task. Not sure if Jake's is the same but I liked the idea of appending to the existing FGDB originally downloaded rather than creating a new copy. This is mostly because we are moving features down from an ESRI tracker service to archive prior to any purge. From what I recall, I had to work the .py source just a bit to make it work (nothing too crazy) but may be an issue if you're without any python dev support. One big mistake I made initially was to name the FC's with an underscore "_" in them, which this caused most of the failure I had been having with it. Once I did that it all worked pretty smoothly.

‎03-09-2020

Absolutely!

‎03-06-2020

What is the return message? Check for: {'success': True} (I'm not implementing via the Python API but still working with AGOL items via urllib/urllib2/requests, but I still try to check for return messages when executing these types of things)

‎03-04-2020

I just moved the addfields and updatecursor processing after the CopyFeatures to in_memory step. For whatever reason it didn't honor the field lengths after adding fields.

‎03-04-2020

The os.path.join() had taken care of some other issue in the past (can't remember exactly what) but from then on just became the standard way in all of my implementations. In any event, I tried and get the same ERROR: 001156. Possibly this is related to a field mapping thing? It seems as tho that Intersect_analysis doesn't produce the same field lengths in the output to in_memory vs. to disk. Result of ListFields to in_memory: rel_objectid is a type of Integer with a length of 0 PO is a type of String with a length of 0 Vendor is a type of String with a length of 0 Same ListFields to same output but to disk: rel_objectid is a type of Integer with a length of 4 PO is a type of String with a length of 255 Vendor is a type of String with a length of 255

‎03-04-2020

Hi all, Not sure what I missing here. I am creating in_memory feature layer from the result of a arcpy.Intersect_analysis() operation and then attempting to apply CopyFeatures on that feature layer (it has an sql applied to it in order to filter prior to CopyFeatures). Of note in code below: setting up itsctRESULT variable to output to disk and everything works but fails with said Error when set to output to in_memory. I'd rather have it all operate in the in_memory workspace as it saves a bathtub full of processing time. landFC = os.path.join("in_memory", "landsToProc") arcpy.JSONToFeatures_conversion(jFileLands, landFC) trackFC = os.path.join("in_memory", "tracksToProc") arcpy.JSONToFeatures_conversion(jFileTracks, trackFC) itsctRESULT = os.path.join(r"in_memory", "itsctRESULT") #itsctRESULT = os.path.join(r"E:\someFolder", "itsctRESULT") <-doesn't cause error 001156 at CopyFeatures_management line below arcpy.Intersect_analysis(["tracksToProc","landsToProc"], itsctRESULT, "ALL", "#", "POINT") arcpy.AddField_management(itsctRESULT,'rel_objectid', "LONG") arcpy.AddField_management(itsctRESULT,'PO', "TEXT", 50) with arcpy.da.UpdateCursor(itsctRESULT,updFields) as cursor: for row in cursor: row[0] = purchaseOrder row[1] = vendorNumber inputFL = os.path.join("in_memory","fl_{0}".format(count)) outputFL = os.path.join("in_memory", "flResult_{0}".format(count)) sql = "Some Where Clause that filters correctly" arcpy.MakeFeatureLayer_management(itsctRESULT, inputFL, sql) arcpy.CopyFeatures_management(inputFL, outputFL) <- fails with ERROR 001156: Failed on input OID 1, could not write value '4500321321' to output field PO‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎02-28-2020

Hi Johnathan, Just to add to the conversation a bit, but I'll defer to Amy as she has a very good understanding of the full requirements. Please share a bit more about your workflow and why you think QuickCapture is the most suitable choice. Basic Requirements: 1. Map viewer & attribute entry on same screen layout. No hoping between pages or tabs. 2. Hotkeys as the attribute entry method. 3. Ability to draw points, lines or polygons. 4. onComplete of any draw feature action, click a hotkey to assign the attribute value to that feature. 5. Operate in a disconnected state and upon established connection, update each/all feature services. Have you considered using other apps more suited to this workflow, such as Collector or Survey123? Yes! However, both of these apps do not meet requirement #1 or #2 listed above. As you can tell, we seem to fall right between existing solutions of QuickCapture & Survey123/Collector. Thanks for any response and info you provide! Take care, James

‎02-18-2020

Of note: if you plan to use input geometry from another feature service to query the tracker feature service then it's important to have input geometry the same as the tracker service in that query. For example, we have a polygon feature service (WKID 102100/3857) and loop thru each feature and query the ESRI Tracker service with that geometry but when we initially query the polygon service we set the output SR to WKID 4326 so that the geometries will align.

‎02-17-2020

Update: It looks like any datetime queries against a hosted feature service on AGOL should be based on GMT time. There are some little things that can throw you off if not careful, for example it appears that adding the hosted feature service to a webmap viewer and applying queries with the built-in query builder will automatically adjust to your local time. I think. However, because I'm applying queries directly against the REST service query task, I need to make sure my input datetime values have been converted to GMT first. I can't just assume that my desired query will work to return a result of all features on January 31, 2020: timestampField BETWEEN TIMESTAMP '2020-01-31 00:00:00' AND TIMESTAMP '2020-01-31 23:59:59' this is because GMT vs. my local time (Eastern) must account for a 05:00:00 difference and would need to be applied as this to return the desired result: location_timestamp BETWEEN TIMESTAMP '2020-01-31 05:00:00' AND TIMESTAMP '2020-02-01 04:59:59' This was validated against a feature service with known edit datetimes and a query based upon a very short time range, but please jump in and disagree or show me where I'm wrong! Please! Here's what's in the webmap viewer. The OID's labelled are reflecting what I want to query, where the middle point of the 3 point features is the desired result so my query should return feature oid 91823: Here's the REST query task. The full query is converted to GMT from my localtime (look at the popup of the middle point is 2020-02-07 13:23:56 so I should return 1 feature with this query "location_timestamp BETWEEN TIMESTAMP '2020-02-07 18:23:55' AND TIMESTAMP '2020-02-07 18:23:58'"): Here's the REST query result: 1 feature and the OID matches!

‎02-12-2020

We are successfully using polygon features as the input Geometry on a point feature service to select those points that intersect. However, this same exact query fails using the same polygon features that we dissolved on an attribute to generate multi-part polygons. Is it possible to use the ring feature of a multi-part polygon as the input geometry for a rest query?

‎02-04-2020

So it appears that I should not include a timestamp on the input dates and simply format as yyyy-mm-dd then just allow the service to pick between midnight. Therefore in order to return all features on 2020-01-31 the correct query should be: timestampField BETWEEN '2020-01-31' AND '2020-02-01' Please comment if you see differently.

‎02-04-2020

Trying to query a hosted feature service on its timestamp field (epoch format, long integer) by passing in a TIMESTAMP value. Using this Where clause on the service query interface, timestampField BETWEEN TIMESTAMP '2020-01-31 00:00:00' AND TIMESTAMP '2020-01-31 23:59:59' However, it is returning features with a timestampField = 1580435690994 (epoch) which is: GMT: Friday, January 31, 2020 1:54:50.994 Your time zone: Thursday, January 30, 2020 20:54:50.994 GMT-05:00 So, I'm unsure to properly query this service using the input datetime values.

Online Status	Offline
Date Last Visited	‎01-22-2025 02:28 PM

My Ideas

Latest Contributions by JamesCrandall

Re: Gaps between track points

Re: Gaps between track points

Gaps between track points

Re: Download ArcGIS Online Feature Service or ArcGIS Server Feature/Map Service

Re: Why is the location tracking layer in WGS84?

Re: Using ArcPY to turn on labeling in an AGOL hosted feature layer view

Re: ERROR 001156 on CopyFeatures_management

Re: ERROR 001156 on CopyFeatures_management

ERROR 001156 on CopyFeatures_management

Re: Requested: polygon that doesn't stream

Re: Why is the location tracking layer in WGS84?

Re: Proper REST query for epoch

REST Query input geometry: dissolved polygons

Re: Proper REST query for epoch

Proper REST query for epoch

Re: Proper REST query for epoch

iterate hosted (AGOL) table attributes

Re: Export to KML Widget

Re: Security model approaches

Re: Python API to update attributes on feature lay...

Experience Builder Custom Widgets

Web AppBuilder Custom Widgets