Latest Contributions by RyanKoschatzky

Nicole, My understanding is R&H Route dominance is all or nothing system wide and as you make changes to that configuration it will only apply moving forward and not update existing event data. It will only really apply to location where there is concurrency. It has been my experience in 10.5.1 the event data will also only move events down the stack of routes with an edit operation (realign or retire) to the correct route. The event data will not move up the route stack if you add a more dominant route in that location. You/business owners will have to go into Event Editor and reapply those events manually to the new route and depending on your business rules and data checks you will also have to manually retire the other events in those locations.  For NCDOT, based on our 11 digit route id (see below) we have applied these rules, lesser is applied to all of the following: RouteClass, RouteQualifier, RouteNumber, RouteInventory, the reason for having inventory at the end is we have a few cases where routes flow opposite of each other (example I-73/74 in Richmond, Montgomery and Randolph Counties). If looking at only inventory direction of concurrent routes on a divided highway, you would have to show both sides. I-73 Northbound (inventory) is corouted with I-74 Westbound (opposite inventory) and I-73 Southbound (opposite inventory) is corouted with I-74 Eastbound (inventory). I-73 is the dominant route, regardless of the inventory code.  Hope this helps. ... View more

Maja, All our LRS editors have a training class on our documented business rules that must complete before they are allowed to edit in production. This includes them editing individually on a lower stage and having an experienced editor seat with them for while when they start editing on production. Our route id is 11 digits. Different routes classes have different uniqueness. Some are one number per county and others for the state. We have a simple counter program to track the next number. Roads and Highways does have some time overlap prevention and warnings built in. On top of that we have a robust data reviewer process set up that editors must run before posting. We also run system wide checks frequently to ensure bad data is not getting through. Since we edit in SDE, we can and do delete editors version when there is issues. While that might be extreme, it is quicker and safer to redo the work then to troubleshoot the existing problem and deal with unknown downstream issues. Most folks learn from these experiences and helps to prevent future issues. Its not 100% but education, training and verification help to cut down on the issue.  Hope this helps and answers your question.  ... View more

Kyle,   I would have done any work in a version and not on default, so you have an easy way to back out. I agree that a smaller batch would be better to try. While overall it might take longer, the risk is minimized with smaller data sets.   I know when we have run our statewide spatially derived tool our adds and deletes are over 350K each for the three different event feature classes. I run this in a "edit" version, as you may recall this is at two levels removed from default (default, lockroot, edit) for NCDOT. Between each run, I would post to lockroot, others would post further but before they do, they run analyze, reconcile, post, sync replicas, analyze and compress before the next run.   If you have to end the process, I would restore to before the process. You last known good.    Some questions I would have are: do you need that many gaps? For our data we find it best practice to renumber the other side of the gap. For us the route name is not part of the route id. That is done as an event (streetname). Do you have an index and are there any null values on those indexes that could be slowing things down? Are you running any log files. As I recall with our spatially derived process I had filled up the log files and that crashed the process. ... View more

Anyone else using this workaround for when snapping is not working. What has been your experience?  Working with Andrew on this workaround, we have discovered a new issue with using feature cache and cartographic realignment. If you have route measure anomalies check on (highly recommend it), you get a route measures unknown (NaN) error for the route you are cartographically realigning when using feature cache. Without using feature cache North Carolina doesn't have that same issue and we use cartographic realignment on almost all routes. We will be writing this issue up and submitting to esri very soon.  ... View more

Maja,  Nathan demo'ed the new functionality at a RHUG meeting. Maybe Nathan or someone recalls what month that was. Then you see the demo yourself at LINKS - RoadsAndHighwaysUserGroup  What was demo'ed looked promising from what I recall but to my knowledge has not been put through the paces to see how route actions and event behaviors work.   I am still working on my gaps document and while I can say the small sample test on newly created routes was positive, I had editor have an issue arise with a gap route being created that introduced around 2 miles extra to the length of the route. That case (02260994) has been written up and submitting to esri. It is too new to know anything at this time. Will follow up when more is known.  ... View more

Yes, from WMX it took 3.5 minutes to display the table of contents and another 1.5 minutes to finish loading. I had no layer turned on. I have 27 layers, 16 in 3 groups layer. Only about half of the layers are coming from R&H. ... View more

Yes, NCDOT (10.5.1) have also experienced long arcmap load times. We are still investigating the issue.  ... View more

Andrew, Thanks for the follow up: BUG-000101392, I export out Bug List from RHUG  that Kyle G had taken from the google site, the export to excel was not clean and I selected the wrong number but for completeness the issue for bug is as follows: BUG-000101392 (TFS51810) Route Edit -  extend, realign Extending a route to create a concurrency then realigning the other route to remove the concurrency on the same date results in incorrect event behaviors for the non-concurrent events on the realigned route. I don't recall off hand the issue but I can research the use case if needed.  What I meant to copy was TFS51854 Route Edit - Reverse, Reassign Reverse and Reassign to Create Gap Causes Measures Downstream From Gap to be Incorrect.  Issue also occurs doing a reverse and retire to create a gap BUG-000117736 Events on the gap route does not updates correctly if the 'Gap calibration method’ field is set to ‘Applying Euclidian Distance’.  I don't recall off hand the issue to provide more information but I will be researching all our gap route issues this week and I will create a new post where we discuss gapped routes as a community.  ... View more

Thanks for the information Nathan. I have some gapped work coming up (making the gap smaller, at the start of the gap and the end of the gap) after I address the invalid geometries you and I have been working on.  ... View more

Clive, I will have to respectfully disagree with the definition that gaps are supported. The functionally to create gaps exists but there is still many issues with using other LRS edits and event behavior working correctly on gapped routes from our experience. Our practice is for our editors not to interact with or create gapped routes when possible. We use euclidean distance and are at version 10.5.1.  I believe these bugs still exist on gapped routes:  BUG-000117736 BUG-000114098 BUG-000114097 BUG-000101392 ... View more

Kevin,   Reader’s Digest version, we delete versions and do not attempt to resolve conflicts.   I would have to say that one is taking a gamble when using the edit calibration tool and other editors (desktop and RCE) are actively editing. I have used the tool and not seen the conflict. I would say looking back that I was lucky. For NC we have at least 4 times a year we are at state zero for SDE and have editing frozen to the enterprise. I have used that time to use the edit calibration tool to fix a number of our routes before allowing the enterprise to start editing again.   This past year we have had a number of what we call corruption issues of our production database, and because of that and an overabundance of caution, we delete versions because of the unknowns of allowing the data to posted. While it may appear fine, the concern is future editing of that route and the unknown of what may happen. We could have saved some versions as not all were impacted (desktop and rce wmx jobs) but a decision was made to restore the database to a last known good which meant the enterprise lost a few days’ worth of edits.    Below is the test case I used to recreate the issue as it matched our normal editing practices and I sent this to esri so they could also recreate the issue which they were able to do.    Two editors are making desktop R&H linework edits (cartographic realignment, create, extend, realignment, the order and routes edited doesn't matter) and posting data as they would do normally. While a third editor was using edit calibration point tool to modify the first calibration on a selected number of routes who’s starting calibration measure was not zero (in practice we don't recommend editors use this function in the course of normal editing. This was practice even before discovering the bug. We only use the tool when there is known issues and only on those problematic routes). While editing the calibration point, the third editor is prompted to gets locks for each route.  The other editors continue posting data.  The third editor is prompted to reconcile before getting a lock, reconciles and then selects yes to get a route lock. Tool finishes updating the calibration point. Third editor runs a manual apply updates to push measure changes downstream. Select in attribute table next calibration point. Select pan to selected calibration point and attempt to edit next route. Repeat until issue occurs.  For us, on the fourth edit to calibration points, after reconciling, the conflict box appeared for the third editor. Esri should be able to prove the internal triggers that create the error. We decide not to deep dive further on the issue as is was reproducible and easily preventable. Additionally while not practical we have a workaround that we can use to mitigate the occurrence.   Some of our lessons learned: 1. Post frequently but be cautious of impact to other editors who will have to reconcile (this is causing other operational issues, look for a future posting to discuss esri's enterprise solution)  2. When an issue is detected, report it immediately (we are actively monitoring the system's health and we have found that this can help contain issues and help prevent enterprise data loss) 3. Keep business units updated, communication is key with the enterprise spread out over multiple physical locations 4. Document issue for reporting to esri and future use Hope this helps, Ryan ... View more

@Clive, are you sure gapped routes are supported in 10.5.1? That has not been NC experience. @Maja, if your route is as Clive described that would be called a branch route and that is not supported at 10.5.1. Nathan demo'ed branch route support at another version and I think was Pro early in 2018 at a RHUG meeting, I just don't recall off hand which meeting it was to help you watch that meeting. I would recommend using Clive's idea of separate routes if possible and not using gapped routes. You can also add calibration points to the intersecting locations to set the measures (I would also split the centerline at those locations also), when using other R&H edit commands uncheck the edit recalibrate downstream. That should keep your route measures static. I don't like that method overall because if you export out that data it will lose that data manipulation.  ... View more