Latest Contributions by RyanKoschatzky

Colin, I think at least for me what is confusing is the use of the word realignment. That is a route action to me and if using R&H internal events would be subjected to event behavior rules. The use of word realignment when talking about events just doesn't compute to me.    Your realignment happened before the existing event record measures and your expecting the X,Y to stay the same and the measures to update. It appears the data is not being applied the correct event behaviors for the new timeslice of the route measures.   I think you can use the edit log and view the xml data for the shift for individual routes. Example of one of our realigns NetworkId="1" RouteId="40001002013" NewRouteId="40001002013" OperationTime="2015-04-29T00:00:00" FirstM="0" LastM="9.552051" IsPerformDownstreamCalibration="true" DoNotApplyEventBehaviors="false" IsFirstPointTouches="true" IsLastPointTouches="true">     <RealignedPortion OldFromMeasure="8.185709" OldToMeasure="8.423989" NewFromMeasure="8.185709" NewToMeasure="8.421265" />     <DownStreamPortion OldFromMeasure="8.423989" OldToMeasure="9.552051" NewFromMeasure="8.421265" NewToMeasure="9.549327" />     <UpStreamPortion OldFromMeasure="8.169544" OldToMeasure="8.185709" NewFromMeasure="8.169544" NewToMeasure="8.185709" />   You can also use Export Network for a more system changes. Haven’t look at that export data enough but I know some folks use that to update event data in external system. Just not up on code to help you with that on either method. ... View more

Colin, Depending on your event behavior (Stay Put shown below keeps XY, updates measures), internally you should have the following records for a realign in the middle of the route Route: From Date: 2010/01/01 To Date: 2015/01/01        Measure 1.0 Route: From Date: 2010/01/01 To Date:  NULL                 Measure 1.5 Assuming full coverage event records Event: From Date: 2010/01/01 To Date: 2015/01/01          Measure 1.0 Event: From Date: 2015/01/01 To Date:  NULL                 Measure 1.5 If the event is not full coverage, you would still have the same timeslices (2) but the measures would depend on where the event began/ended was in relation to the realigned section. I think your on the right track for an event layer for each route timeslice. I am not sure of workflow to simplify that work effort. ... View more

Hi Courtney, Another resource for active users of the R&H product is RHUG, Roads and Highways User Group (RHUG) . Lots of good information all over the site. Most of the members (State, County and City) are not currently using the Pro version of the software as it is not at a 1:1 match for desktop functionality for most of our uses/business practices but it may be at that point for your use. Most folks are using 10.5.1 and have or in process of migrating to 10.7.1 til Pro is ready for us to make to that switch. For 10.5.1 we use SDE and have many different business units internal and external editing and consuming the data. Hope that helps. ... View more

Maja, We don't do desktop event editing. Nathan Easley should be able to answer your question about the toolbar. What I prefer to do is analysis the event data and issues on desktop and fix the issue in the table view within Event Editor or reapply new data and retire the existing records. When doing the table edits I use the Identify LRS Route location tool set to my event precision and select the location along the route where the event should change, then in Event Editor query the route id on that event layer. I use a copy/paste of the location measure from Identify LRS Route location tool and apply the values in the correct to/from fields.  Outside of individual editing we have used 3d party vendor tools to modify event data statewide. We can talk offline about that if you wish. ... View more

Nicole, We have made very similar fixes but I have some additional questions that might impact the fix or at least for us it can.  We use from date as the route start date, does 343D have the same from date as what 24D would have? Is 343D is built correctly if it was 24D? Does 343D have to exist when the fix is complete? I am also going to assume 24A is dominant over 343D, is that correct? Is 24D an active route anywhere else? What version are you using? We are still on 10.5.1 so it might would slightly different for you.   Our rules would require us to coroute 24A and 24D where possible, so 24D would start from the end of 24A to the start of 24A unless the begin/end is divided/couplet situation. Where corouted we would only apply event data on 24A and not 24D. Event data for 24D would only exist where 24D is the dominant route. To fix assuming 24D exists nowhere else and dates are equal between 24D and 343D, I would create 24D along its correct alignment, so it would be corouted with 343D and click apply updates, the events would not move up the route stack to 24D because of a bug and stay with 343D. Then retire 343D with it's same from date and click apply updates. By having the same from/to date 343D would not exist anymore in the data which seems to be correct as the route number was in error. You can still find the location but you would not have the timeslice active to select again. The events that where on 343D should then be applied to 24D and there should not be any changes to the 24A events. For us 343D would have a direction event of southbound and 24D would be have a direction event of westbound. We would have to edit the event record to show this change as opposed to adding a new record as the event timeslice would then still show an error. Other event data might also need to be updated if a similar event type scenario exists. ... View more

Kevin, Your link is password protected.  ... View more

Kevin, 1. Back in 2017 I would have identified the issue as the events changed values. Now based on the other esri tickets I would probably say the event measures where not applied correctly to the route geometry. I was able to spot the issue on the direction event before and after a roundabout/divided sections and the values were not correct. However, I don't believe it is an event specific issue. The easiest way to find any issue is after you run the tool, run lastedited queries for the date (not date and time) and editor that ran the tool on your data. If like us, what you find may be surprising. It may not be wrong but something was changed that we did not expect. For me that suggests an unknown problem we didn't know about. That route should be researched before posting fixes to ensure that was the best method and you can live with any downstream effects.  2. The tool in some areas created micro centerline segments because of some arc geometry we had introduced. Using that geometry later on has created issues with editors creating multipart routes. I think reloading the routes might have been a better option but no without its own challenges at that time. That condition is what was I tried to fix last year. Too many centerlines where edited and we decided to realign the routes in those area to fix the issue and have known incorrect history then to have other unknown issues. As mentioned above event data may have shifted. 3. It all depends on what was identified as being edited by the tool or what Data Reviewer returns. Not a helpful answer but too many variables to give a simple answer. 4. Because we have conflict prevention turned on, I recommend no editing and locks in the system when running the tool to prevent issues. For us the easiest way to guarantee no editing is at a quarter freeze with no one else in the system. In an enterprise environment it can be difficult to keep 30+ users in different groups/locations on the same page. 5. We use Data Reviewer, there is a table check for unique ids. Another method is to cartographic realign the offending route out of the road bed and retire the route as opposed to using a future delete routes tool not available at 10.5.1 to remove the route. You can add a new route in the correct location.  ... View more