POST
|
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
08-01-2019
09:38 AM
|
0
|
1
|
1008
|
POST
|
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
07-31-2019
05:18 AM
|
2
|
0
|
654
|
POST
|
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
07-18-2019
07:35 AM
|
0
|
0
|
475
|
POST
|
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
06-20-2019
10:05 AM
|
1
|
0
|
2693
|
POST
|
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
06-13-2019
04:31 AM
|
1
|
1
|
1201
|
POST
|
I know Nathan has stated the Lrs_Edit_Log is not meant for human consumption and I don’t disagree, but one can still find what I believe is useful information, especially if you compare years. Here is the type/number of edits I calculated for NCDOT for 2018 using 10.5.1: TransactionDate > '1/1/2018' AND TransactionDate < '1/1/2019' AND ActivityType = X Edit log Code/R&H Route action name/number of records 1 Create Route 4684 3 Reverse Route 140 4 Retire Route 1260 5 Extend Route 1070 6 Reassign Route 1020 7 Realign Route 349 12 Cartographic Realignment 19139 What are your stats?
... View more
06-11-2019
05:59 AM
|
5
|
35
|
7206
|
POST
|
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
06-04-2019
05:07 AM
|
1
|
0
|
535
|
POST
|
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
06-03-2019
10:34 AM
|
0
|
0
|
2402
|
POST
|
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
05-29-2019
06:09 AM
|
0
|
0
|
2402
|
POST
|
@ 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
05-29-2019
05:18 AM
|
0
|
2
|
2402
|
POST
|
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
05-28-2019
05:52 AM
|
0
|
4
|
2402
|
POST
|
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
05-23-2019
10:18 AM
|
1
|
8
|
2402
|
DOC
|
Recorded meeting https://meetny.webex.com/meetny/lsr.php?RCID=da6bb1e7e47249769a9eceb016e9038c
... View more
05-10-2019
10:04 AM
|
0
|
0
|
225
|
POST
|
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
05-03-2019
06:23 AM
|
0
|
0
|
3451
|
Title | Kudos | Posted |
---|---|---|
1 | 4 weeks ago | |
1 | 08-15-2024 03:57 AM | |
1 | 02-01-2024 03:46 AM | |
2 | 08-13-2024 04:41 AM | |
1 | 06-13-2024 04:25 AM |
Online Status |
Offline
|
Date Last Visited |
Thursday
|