Latest Contributions by KevinPiraino2

Hayden, Nope, both map and data are in the exact same coordinate system (NAD 1983 StatePlane Illinois East FIPS 1201 (US Feet); WKID 3435). Everything related to this project was in the same coordinate system. Again, I'm not entirely sure what the issue is, it appears on the surface to be how the Desktop GUI software is interpreting certain values vs. what is either stored in GDB and accessed by python or how the python interface is interpreting the data. Basically the Desktop GUI will read and write the whole number 41618.00, but the python interface interprets that as 41617.99235 either because that's what is stored in the GDB / geometry or something else entirely.   ... View more

Hayden, Yes, I checked both the coordinate systems and they are the same. I also tested the geodesic parameter and that also did not resolve the issue (it didn't seem to affect the result in any meaningful way; not sure if it's a scale thing).  I'm also not sure if it's a precision thing between what is stored in the geodatabase and what is being read by python. When attempting alter a point's M value from 41617.703125 to 41618.0 using the regular GP tools, the M value will read the appropriate whole number, but when querying the point via arcpy, it will return a floating point number (e.g. 41617.99328513). In any case, I was able to build a workaround for this issue by creating an Event Table, populating it with the routes and M values needed, and then using the GP tool "Make Route Event Layer". This created the necessary points along each route at the intended locations. My unfamiliarity with the available linear referencing GP tools in ArcGIS Pro caused me to not read into it deeply enough. ... View more

I'm not sure that's necessarily the issue though. I believe the issue I am running into is due to the fact the first point's M value is a float value and not an int (whole) number; the first point's M value in the polyline is 41617.703125. The next nearest M value along the line divisible by 100 should be found using the following method: 100 - (first point M value % 100) --> 100 - (41617.703125 % 100) --> 82.296875 --> lineFeature.positionAlongLine(82.296875) --> should return point at M value 41700.00 (but doesn't). Is there a level of imprecision that this geometry function has baked in? Are their differences between what an M value is and what is returned by positionAlongLine function (i.e. can't use the return of the modulo as its calculated based on M value as the "measure" distance value in the function)?  Using your suggestion of casting the return from the modulo line from float int did not resolve the issue. The updated function below: #AGOL community post function: def get_measures(in_lines: str, out_points: str, measure: int=100): with( arcpy.da.SearchCursor(in_lines, ['OID@', 'SHAPE@']) as line_cur, arcpy.da.InsertCursor(out_points, ['OID@', 'SHAPE@']) as point_cur ): for oid, line in line_cur: oid: int line: arcpy.Polyline #name = line[1] fp = arcpy.PointGeometry(line.firstPoint, line.spatialReference) lp = arcpy.PointGeometry(line.lastPoint, line.spatialReference) point_cur.insertRow((oid, fp)) first_meas = 100 - int((line.firstPoint.M % measure)) for m in range(int(first_meas), int(line.length), measure): point_cur.insertRow((oid, line.positionAlongLine(m))) point_cur.insertRow((oid, lp)) The results:   ... View more

@HaydenWelch, thanks for the reply. Unfortunately, neither code block was the solution to my problem; I also tried your comment from the addendum and this also was not the solution. Below are two screenshots that show the results of the suggestions you provided. The first screenshot shows the results of the code block without the addendum suggestion (both the longer one and the simplified one). The second screenshot is with the added addendum suggestion. The red labeling in both screenshots is the "Measure" or M value's as derived from the line for each point while the black labeling M values needed. Basically the points need to be exactly in the location of the lines labeled station points/tick marks.  As you can see from the first screenshot, just the code block as is (no addendum / modulo), the created points do not fall at the correct interval and are instead at 100 ft intervals starting from the 1st point. The second shot shows that the included addendum gets closer to the solution, but still does not get the exact measures/locations needed (see red labeling vs. black labeling).  From my own testing and python hacking, I originally came to the same conclusion as you regarding the use of the modulo (line.firstPoint.M % measure), but ultimately the results of my own python code block were about the same as the second screenshot. What I was finding though was after returning the first point after the starting point that has an M value divisible by 100 (use the modulo method), the value needed to measure along line (use positionAlongLine function; line 12 and 13) did NOT find a point at the location on the line where the stationing / M value was a value divisible by 100 even though the "dist_to_meas" value + firstPoint.M == M value divisible by 100 (EX: 41700). I'm not sure if its a geometry thing or spatial reference/coordinate system thing, but I couldn't figure out the correct method to find the "dist_to_meas" value to use in the positionAlongLine function that would return a point at the exact station / M value needed.  My Code Block: #lines_data --> list/array of line data as pulled using SearchCursor for line in lines_data: pts_array = [] #empty array to store points line_geo = line[-1] #get line geometry firstPoint = line_geo.firstPoint #get first point in line firstPoint_M = firstPoint.M #get first point station val lastPoint = line_geo.lastPoint lastPoint_M = lastPoint.M pts_array.append(firstPoint) pts_array.append(lastPoint) #needs to be exact dist_to_meas = 100 - (firstPoint_M % 100) #find distance till next station divisible by 100 nextPt = line_geo.positionAlongLine(dist_to_meas,False) #returns point geometry pts_array.append(nextPt[0]) interval = nextPt[0].M #starting measure #print(interval) while interval < lastPoint_M: interval += 100 dist_to_meas += 100 #print(interval) nxtPt = line_geo.positionAlongLine(dist_to_meas,False) pts_array.append(nxtPt[0]) Code Block as-is:  Code Block w/ Addendum (modulo):     ... View more

David - This is an interesting workflow. Would you mind going into more detail about this workflow? The basics of what I am trying to achieve is send updates that are made to certain datasets internally (cadastral data) to an AGOL hosted feature layer regularly via the distributed collaboration workspace. I would like to avoid sharing services from the production SQL server into the workspace and instead share services from the publication SQL server, but this may not be feasible based on your comments. Basically, I am trying to leverage AGOL hosting certain datasets that are in high demand to reduce load on our standalone ArcGIS Server site that would normally host this data. ... View more

Timo, The only other thing I will add regarding this is that we do not currently have "replica tracking" enabled on the feature datasets/feature classes we are trying to share into the workspace. While I'm not entirely sure that this is the reason for the issue, it is another configuration option I need to look into. Upon initial testing, it didn't appear that not having "replica tracking" enabled mattered, but reading into the ESRI documentation a bit further makes it sound like it may be necessary.  I also found a different ESRI Community post discussing what happens behind the scenes when "replica tracking" is enabled.  Replica Tracking GP tool: https://pro.arcgis.com/en/pro-app/3.4/tool-reference/data-management/enable-replica-tracking.htm  Replica Tracking behind the scenes info: https://community.esri.com/t5/arcgis-pro-questions/enable-replica-tracking/td-p/1382804  ... View more

Timo, A couple answers to your questions and comments: I believe your Version Creation setting should be set to “Create a version for each downloaded map.” I have tested this and I do not believe the configuration is necessary even for a branch versioned database. I was able to successfully publish, share to the collaboration (with AGOL creating the hosted "copy" layer), make an edit in the Portal layer, and sync the workspace successfully. With your initial successful syncs, are they only for newly published feature services that haven’t been shared to the collaboration workspace? Yes, I did not test this workflow using another already published feature service. I did not want to use the production Parcel Fabric feature service to test this against and we do not have any other feature services in our publication side to test against. What happens if you sync the feature layer twice on the same day, before the nightly replicate/copy process runs? If your theory is correct, the sync should work both times since the replica would still be in place. Ensure there is a change in the feature layer before doing the re-sync test. If I sync the feature service twice on the same day, it works fine and is able to successfully sync. Even when performing an edit on the Portal side, the edit does come through on the AGOL side (as long as its within the same day).  What error messages appear in the sync status collaboration logs? You can find these at /portal/sharing/rest endpoint > Home > Portals > Self > Collaborations > [COLLABORATION-ID] > Workspaces > [WORKSPACE-ID] > Sync Status The message from the "Sync Status" page:  Unable to sync item '46bb45cb5a0f4086b40bf2e0e4de77e9'. Error retrieving Sync info or replicas for peer 'neJvtQ4PXvnQ86MJ'. Cross checking your sync status logs, are your initial successful syncs real-time or scheduled syncs? The interesting thing about the real-time vs. scheduled sync, is that even on an initial sync, the workspace tries to perform both the real-time and scheduled sync. I'm not sure if that's intended or if I just set up the workspace incorrectly, but on the initial sync it will attempt both and one will inevitably fail (because its trying to create two AGOL layers with the same ID). After the initial sync though, its fine and the scheduled sync that is performed on the same day succeeds, but any subsequent syncs on following days fails.  ... View more

Denis, was ESRI technical support ever able to give you an answer about why restarting the DynamicMappingHost service resolved the issue or did they provide you a long term solution if this continues to occur? ... View more

@GlenterpriseUK I have not seen this article before. Looking into the details of the article and comparing other cached tile services we have published (that are not experiencing this issue), this "Dynamic Layers" setting is enabled for these other services. Not sure if it matters, but the other services were originally published with ArcMap (and upgrade to the ArcGIS Pro runtime through AGS manager), while the service with the issue was originally published from ArcGIS Pro. One thing I have noticed when comparing the service with the issue vs. other similar cached tile services, the service with the issue does not have a fully populated "caching" page. I believe this information is populated from one of the "config" files (conf.xml, conf.cdi, conf.properties), but its unclear if these are the issue or not.  Does the error message log in the log file provide any information? The "Missing parameter: MapName" is throwing me for a loop.   ... View more

@GlenterpriseUK The service uses Dedicated instances and caching is from a tile cache stored on a file server. This service was also published using ArcGIS Pro. ... View more

The service as it stands does not allow the end user to visualize the data at all scales. We do not have multiple sets of contours, just the 1ft contours. This could potentially be a solution to use the standard service, but I am still looking for any insight regarding the error messaging / log file from ArcGIS Server. The error code/text is fairly generic and any googling I have done has not been very helpful.  ... View more