Latest Contributions by RyanKoschatzky

Andrew,  While the date/time may help for the external system, any and all queries you do will need to account for the date/time. When we looked at doing something similar that added too much complexity to a complex issue. We discovered a number of events I had entered in bulk through EE had date/time and I worked to change the values to be date only. Probably thought of this but can you use last edited date to grab just the active route record you need and not the other benign records? ... View more

Does the dgn file have a projection file and/or is the projection extents way out? This have been two main issues we run into when using dgn's.  If you have microstation, you can try opening the file in microstation and clipping a smaller data area to use in the arcmap or possibly add a projection to the file. Hope that helps ... View more

For the most part I cannot foresee a scenario for overlaps but we all model the data differently with different events so there might be valid reason for your data. For gaps, are the gaps supposed to be there? For instance you have an event for curb and gutter, you probably should have gaps. If your modeling pavement type, there probably shouldn't be a gap in pavement type.   Based upon the event, how you model your data and what your temporal expectation is you can change the from/to measure in the table to fill the gap or remove the overlap. You can do this with the 'select by attribute tool' in Event Editor or use a third party tools. Additionally if the area is really bad I might retire all the records with the same from date creating a begin record using 'select by attribute tool' in Event Editor and then reapply new data with the same from date over that area with 'add linear events tool' in Event Editor. This method can help ensure that the temporal data is clean as well as opposite to just using 'add linear events tool' in Event Editor over the route to fix the area and retiring the bad data. Unfortunately I think when you are down this far in the QC fixing it is a route by route, event by event type analysis and fixing, there are no clean bulk fixing because what ever method you are using it has been my experience it is only the correct method half the time.   Hope this helps ... View more

Depending on the event and the error the fix is different. Sometimes we add data to fill a gap. Other times we change the from/to values. Is the overlap a case where event behavior or software not working properly, ie the overlap section should have one section retired and the other section active. Depending on how “bad” the area is, retiring all records on the route with the same from date to create benign records and then readding the event data to correctly reflect what is happening. To me, the reassign workflow would create incorrect temporality and would not work for NC.  Hope that helps. ... View more

Nice Andrew. Yes, we a have a few transactions but with up to 11 editors at one point I would hope so.   I had dropped out calibration point because our numbers would look over inflated as we typically have more then the traditional 2 points per route from our data load. For 2018 our Calibrate Route was 32463 records. We don't have any loaded routes because we did that work in 2016 before we started going live when we where fixing branched routes etc. Our 2017 number are slightly below 2018 totals but 2019 seems on pace with 2018 numbers. As with anything, I not 100% sure what numbers really mean other then we have touched a lot of data and if we want to put metrics behind them in the future we have something that can be comparable through the years.  ... View more

I don't see anything from a Roads and Highways prospective that would prevent you from incorporating active future routes in your data model, it would just require some careful analysis of your existing data model. For NC we have Projected Routes, which would act in the same manner your proposing. However we only do that for the project main line, typically a future Interstate or US route and not your smaller (state highways, county roads, etc ) routes or the whole construction project. Thinking out loud do you want to make it part of your route ids or is active routes an event. What limits do you have on your existing route id structure? If an event, how easily can you export the LRS and one or more events, do the analysis outside of R&H? As an event, how would your other business units know what is a real or imaginary route and would that concept be to difficult to follow in a normal editing workflow? What is the level of maintenance of the LRS, do you only have a few folks or a small dataset to maintain the LRS, so this type of work effort to change routes from imaginary to real may be a resource issue not a software issue.  Additional, nothing would really stop you from exporting your database and editing the linework outside of R&H for the imagery routes. That would be more of a manually effort but depending on your environment it might be the best option.  Hope this helps. ... View more

For item 10 fixing, Nathan has provided the following workflow to us. In order to fix these routes (and events), I would follow the workflow below:  Turn off Roads and Highways. Remove one of the vertices that are within tolerance on each centerline. Turn on Roads and Highways. Run Generate Routes on the routes that utilize the centerlines you editing in step 2. Run Generate Events on the events that utilize the routes you updated in step 4.  It’s a GP tool, so you can put selection sets of definition queries to significantly speed up this process and only run on the impacted events. I am working through testing this for us. If you just remove the vertex on centerline, as I had suggest for our users, apply updates will become active, after running you have the belief that you have also fixed milepoint and events. I have found that is not the case.  Hope this helps. ... View more

This blog was brought to my attention,  https://www.esri.com/arcgis-blog/products/data-reviewer/data-management/invalid-geometry-check-explained/ Which is where I had gotten the image to start with but the article couldn't be found for some time.  Hope this folks. ... View more

Preston, No problem. That is a goal of RHUG and this space to drive conversation that helps all stakeholders. Based on conversations I have had with others, I would agree that we are a highly specialized community and this is one way to help increase the existing knowledge base and hopefully our numbers.    ... View more

@ Clive, I agree that most routes usually do not have other issues if they have invalid geometry but that is no guarantee they won't and yes a route can multiply other issues outside of invalid geometry. @Preston, My experience has shown that for us, loops and lollipops return a line/polyline closes itself record and not a invalid geometry record.  Yesterday I ran a check on about 11,000 miles of our data. I had 1 invalid geometry return because of the vertex issue and 356 returns on routes that where loops and lollipops. That will shortly be 1 resolved record and 356 exception records.  Hope that helps. ... View more

It is my understanding (which I hope Clive/Esri can provide input if I am mistaken) that would not help. DR sees the route for lack of a better term as “broken” from a DR point of view not a R&H point of view and does not know how to handle the other checks with that route. Marking as exception would only stop the repopulation of the DR table not allow the continuation of other checks. I don’t recall off hand having any of our routes having multiple issues, so if the invalid geometry (vertex being a major of the issues) was fixed the route would not reappear with other problems. ... View more

I think they are a critical issue, it is my understanding that while DR found them under invalid geometries it prevents other DR checks from running on those records. Additionally having a null shape cause issues with having two route in the location without knowing about it.  My experience has been if you have used geoprocessioning steps for data migration you can run into 10. duplicate vertices at the begin/end of route. If you are z-aware, you have a 9 zero/NaN elevation. As a coastal state this can be a problem. It was also easier to find some issues of roads in the waterway/ocean. So it's a double edge sword.  For our editors I have instructed them to do the following:  There are two things to look for. Make milepoint (route/road layer) selectable (NCDOT by default has this layer as unselectable). Double click on the route in question and view its sketch properties.      Look for zero Z values along the route      Look along the route for duplicate or near duplicate X and Y values. Typically found at the start or end of route. Deselect the route and select the correct centerline, remove the second vertex. While it shouldn’t really affect the geometry ensure the route appears as you intended. Make milepoint unselectable again before continuing with your work. Yes you can also view the sketch properties on centerline but I find it easier to look the measure field for duplicates then both the X and Y fields. To each their own .   I don't recall running into the others. Additionally at 10.5.1 the data reviewer check and the CheckGeometry geoprocessing tool return different results with data reviewer picking up more issues if you happening to be using that tool. Hope that helps.  ... View more