Latest Contributions by RyanKoschatzky

Samuel,   Interesting, a few thoughts as I percolate on the idea, the domain list for layer and especially type might get to long and that could lead to selection of incorrect types. Secondary the QC to ensure that doesn’t happen might be too complex and/or time intense.   Depending on construction techniques (really stepping outside my knowledge base) the events changes might be at more intervals and time than the data model can support as one event at least conceptually in my mind.   I could see breaking out the pavement event to include more event tables: ie Seal Coat, Surface, Binder, Base Subbase etc. Then creating a product outside R&H that overlays the events onto the linework. Calculate a field that takes into account all the pavement layers and gives the total for that segment.     Also, just spit balling, why not also add in a date field, you can capture when the material was applied.   I don’t think you should call it surface event as it is more than just that. Something like pavement event might be more appropriate to encompass all aspects of the event. ... View more

Colin, Instead of changing event 1 and retiring event 2. Why not add event 3 to the new alignment, using beginning and end toggle button. That should retire event 1 and 2. A manual option to cover behavior.  ... View more

Blaine, Sarah's team has done a good job setting this up for our enterprise to use inside and out of R&H. I would recommend verifying locations after running the tool as we have had areas that did not repopulate with new points and measures. BUG-00110740, fixed in 10.6.1 according to esri. As we are still at 10.5.1 I cannot confirm that. We did take the intersection point fc to help identify where milepoint was not connected to the network. MilePoint_ID in (select distinct milepoint_id from rome.LRSN_MilePoint_evw where todate is null except select distinct routeid milepoint_id from rome.LRSI_IntersectionPoint_evw where todate is null) and todate is null Found 11 legacy system routes that where islands onto the network that I am not sure I would have come across any time soon and another 33 routes that had topology issues. Most of the 33 routes go back to 10.3.1 days when we didn't have the robust system in place that we do now to catch these issues.  ... View more

@Nicole, that is how we have been using polygons to date. I think that having temporal polygons would be helpful for when people are using the timeslider, so the boundary data would match the routes and events vs having current boundaries and old routes and events. That sorta begs the following question, are people using the timeslider?  I uploaded an old GIS-T presentation that might help illustrate the issue of temporal polygons (pg 12-14). When I have time in the future I will try update the illustrations to be more useful.     GIST-T 2016 NCDOT evolution of temporal polygons for spatially derived events.pdf  ... View more

A few questions: Anyone using temporal polygons (ie city/town/county boundaries)?  Anyone doing any temporal QC’ing? If you have any routes that have been edited multiple times and the timeslices don’t line up correctly, is the delete routes tool (10.6 or higher) working for you? Did you have any coroutes involved? Would a delete timeslice option be preferred? Have you tried to save your event data and how did that go?  ... View more

We have a few location like this, two that come to mind are both Interstates. I-73/74 in Randolph and Montgomery counties and I-73/85 in Guilford county. For NC to follow your example US-54 would be the dominate route regardless of direction. All events* in R&H would go on US-54. Only US-54 would be counted for mileage as the dominate route. AADT is collected wherever/however we represent the route. We only collect AADT on ramps if safe and grade separated. Pavement is collected wherever/however we represent the route. They are a great resource to make sure we have all routes divided when they should be. If they have no place for the data, they are a unhappy customer.  Samples, we do not collect samples on ramps. We do have a different route type for ramps. Our HPMS coordinator is out til Oct, but I don't she would collect on a route/ramp flyover in these cases. *Fed Truck Route/STAA is different but that is story for a different time but we would have Truck Route marked on US-54 if it applied. ... View more

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