Latest Contributions by RyanKoschatzky

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

Routes increase in the direction of travel. While we model addresses we do not maintain them, that is outside of our band width. We do maintain full name. I would not recommend modeling the data the same as we have for streetname. Of all our event data, streetname is the most problematic and I get the most returns for issues compared to other events. It is around 2:1 or greater for the number error hits. Our HPMS folks are setup for Collector, not sure if it is used for sample data but they do use it for small pipe inventory. Other business units are/going to be using Survey 123 but they are using that to collect data not on our route network. I can put you in touch with our mobile team if you like as that is outside my wheelhouse.  ... View more

NCDOT's Data Model as of April 2019.  ... View more

No problem. So back in the early days mid-2000's when the earth cooled and we started using esri products for LRS editing instead of the mainframe we had a little program called ARID, which is very much like Event Editor. Attached is some of the early work that I hope helps to illustrate how events can break and making many attribute sets with multiply passes to match can speed up data entry instead of adding all events at one time on one pass. I have attached an excel file of a more current file that our inventory folks use, it is at latest the fourth revision of the ARID project guide. For our LRS editors we only have a few events to maintain so one attribute set works easy enough to turn on/off event layers (DCGAttset).    ... View more

Trevor, All presentations are posted online for each year. That said I don’t know when and the website has changed so I cannot give you a good link outside of the generic page. Transportation.org – The home of transportation professionals.  ... View more

You guys did a good presentation.  ... View more

Maja, North Carolina had a simple number populated for the data load and is using a GUID for editing, in either cases that field has no meaning for us.  If I understand correctly you want to have a unique id value for the point that other data can be referenced. I would another field/s for the point id that you would maintain and populate. Just casually observing the field for linear events I don't think it would work the way you intent it to but I don't interact with point data that frequently to see if it behaves in the same manor.  Maybe someone from esri can example the intent/purpose of the field and how they envisioned its use? ... View more