Latest Contributions by CliveReece

Hi Peter, Seems like Reload route is still a good option, although Retire Route (portion) backdated to when you first introduced the 'bad' centerline is an alternative.  Either way, I would recommend you testing each option out in a test ALRS geodatabase environment.   Realign Route using a correct centerline is yet another option (setting the date to when the 'bad' centerline was introduced.   Clive ... View more

Hi Peter, Perhaps we need to revisit what the purpose is for deleting one of the centerlines that compose the route? One thought is you could use the R&H activity Retire Route to retire the portion of the route that covers the centerline.  Another option would be to reload the route in question without the portion that covers the undesired centerline geometry.  Temporality would need to be considered when reloading.   However, it's hard to say which is the better approach without knowing more about what you are trying to achieve.   Thanks in advance, Clive ... View more

Yes Kyle.  Thanks for the positive feedback.  Our Esri Transportation Practice has developed a custom in-house tool for classifying self-intersecting routes.  We use it in helping our Roads and Highways customers sift through their data for route shapes that are not supported by Roads and Highways.  The results from the tool are a table summarizing the types of self-intersections found and a feature class of the input routes with a field added that contains the type of self-intersection.  We find the tool is extremely helpful in sorting out and prioritizing Data Reviewer results for self-intersections or polyline closes on self.   ... View more

Hi Ryan.  Data Reviewer will attempt to process additional checks if part of a batch job, even if it finds a record that fails the "Invalid Geometry Check".  That's my experience with routes that fail the check but do not contain fatal underlying geometry issues.  I tried it on my computer and it was able to find other data reviewer checks that I had set up.   Multiple data reviewer check issues can show up on routes.  It's a common issue we run into when performing ALRS data health checks on customer data.  We find it helps a lot to run a pivot by Route Id to find routes that contain multiple problems.   -Clive (Esri Transportation Practice) ... View more

Preston,  Records flagged by Data Reviewer as "Invalid Geometry" may *not* be critical issues.  I would categorize them as "Requires Review".  Case in point that is easy to test:  Create a lollipop shaped polyline as a single feature.  Run that feature through the Data Reviewer test, Check Invalid Geometry.  The record gets flagged as "Invalid Geometry: NotSimple".  The issue is that the feature intersects itself.  Nevertheless, lollipop features are supported by Roads and Highways for calibrating routes.  In this case, the "invalid geometry" result by Data Reviewer is a false positive, non-issue for Roads and Highways. (aside:  some lollipop shapes will be problematic if they are multipart features with parts out of order with the calibration direction) Again, I'm not saying all "invalid geometry" records are fine.  Many will be proven to be issues after looking into why Data Reviewer has flagged them.  And that is my advice, use "Invalid Geometry" as a call for further investigation.  You are going to cause yourself unnecessary anxiety about your data if you see a bunch of "invalid geometry" records and assume they are all critical issues. ... View more

Hi Preston,  The answer is sometimes not simple.  (okay, I couldn't resist that pun) In all seriousness, I would recommend you start with this page that describes the different kinds of data conditions that get flagged as "not simple":  http://desktop.arcgis.com/en/arcmap/latest/extensions/data-reviewer/finding-invalid-geometry.htm.  You then have to dig in and examine the records one by one.  Sometimes the condition will be a critical issue (e.g. short segments).  Sometimes the condition will be benign (e.g. self-intersection of a loop or lollipop, which are supported shapes).   Best of luck with the data sleuthing.  -Clive (Esri Transportation Practice) ... View more

Hello Colin, Good question.  Have you considered using signed mileage (kilometer) posts as point events on the primary route network that you can use as a referent point for locating events?  That is an alternative approach which alleviates the work of creating and maintaining a second route network whose only difference from the primary network is calibration.   -Clive (Esri LRS Consulting team) P.S. We all know how permanent and accurate mileposts are (ha!) 😉 ... View more

Hi Maja, Check out Amit's reply.  For one time copies (as moving data from Test to Production), I would recommend following his steps.  It's a pretty easy and proven method.   For cases where an ALRS needs to be moved from one environment to another periodically, I would recommend automating the process.  And I would recommend looking at a truncate/reload process into the destination ALRS objects so that you don't have to redo permissions.   ... View more

Yes, gapped routes are supported. That capability and options for calibrating across a route gap have been in the product since 10.3.  Here is the doc link:  Methods for calibrating routes with physical gaps—Roads and Highways Desktop | ArcGIS Desktop  Personally, I prefer separating branches into separate route ids. Preferably with a modifier that would allow someone to know that the routes are related. However, I have seen cases where an organization cannot or will not split routes because of a legacy business rule or connected system. I would recommend rapid protyping of the two options to test and review which fits your organization the best in terms of data and data management.  Cheers, ... View more

Hello Maja, Thanks for including the route diagram.  If I understand it correctly, the purple line represents a single route that has a main line which is calibrated from 0 to 900+, then a separate branch with measures from 1000 to 1200 which crosses the main line near measure 140, and finally a third branch with measures from 1300 to 1400 which crosses the main line around measure 900.  If that is correct, then that kind of route shape is not supported in Roads and Highways 10.5.1.  Roads and Highways only supports Loop and Lollipop types of self-intersecting shapes (c.f. here).  The only way to possibly create the route envisioned in the diagram and have Roads and Highways support it would be to introduce gaps in the routes so that the areas of intersection do not actually touch.  The collection could then be modeled as a gapped route (which is supported).   We have heard from the Roads and Highways product team that a future ArcGIS Pro-based Roads and Highways release will support additional kinds of self-intersecting routes shapes.  Until the route shape you show gets supported, I think the best approach will be to either model the route in the diagram as either three separate uniquely identified routes, or to create small gaps and model the line collection as a gapped route.   Regards, Clive ... View more

No, not from my experience.  There are many other potential issues that may be affecting your performance.  I would recommend logging a case with Esri technical support so they can work with you to track down the root cause(s).  ... View more

Hello Ana, I understand your trepidation about swapping out one of the ALRS feature classes with a copy that you modeled independently.  Be reassured, that is a valid method we commonly use in a professional services consulting engagements.  But  ... you do need to be very careful about matching the coordinate reference system and XY and M tolerance and resolution settings with those that match the ALRS.  If you don't, you'll break the data integrity model of the ALRS.  And (with near 100% confidence) the default settings when you create a new feature class are *not* going to match the XY/M tolerance and resolution settings for your ALRS.  I'll mention three tools that we use for re-ordering fields in a feature class:   TLDR ... skip ahead to #3. Notepad ++ Enterprise Architect (EA)(Sparx Systems) - We use EA when we are designing and documenting a new ALRS for a customer and we need the ability to iterate quickly on changes to route network and event design decisions from the customer.  The great thing about this tool is it knows about the Esri geodatabase.  That allows us to model all data objects in UML and then export directly to a geodatabase XML workspace.  If you need to tweak the data schema (including field order), then it is a simple matter of altering the UML design and re-exporting the geodatabase XML.  The down side to this tool is it requires a lot of expert knowledge on geodatabase objects and the Roads and Highways minimum schema.  There is also a huge learning curve before you become proficient with the tool.   X-Ray for ArcCatalog - This add-on for ArcCatalog provides a geoprocessing tool to re-order fields in a geodatabase table or feature class.  This will be the easiest tool for ad-hoc reordering any field EXCEPT it doesn't work on Shape or Shape_Length fields (sorry).  So X-Ray won't help you for your goal of moving the SHAPE_Length field to the end of the field list. Notepad++ with the XML Tools plugin - This will allow you to move the SHAPE_Length field to the end of the field list.  I use this method frequently for ad hoc feature class schema changes that include field re-ordering:  Export your current feature class to an XML Workspace document (schema only, no metadata) Open the XML in Notepad++ Using the XML Tools plugin, select "Pretty print (XML only - with line breaks)" Skip down to the xpath for /esri:Workspace/WorkspaceDefinition/DatasetDefinitions/DataElement/Fields/FieldArray Look for the XML section for SHAPE_Length:   <Field xsi:type='esri:Field'> <Name>SHAPE_Length</Name> <Type>esriFieldTypeDouble</Type> <IsNullable>true</IsNullable> <Length>8</Length> <Precision>0</Precision> <Scale>0</Scale> <Required>true</Required> <Editable>false</Editable> <ModelName>SHAPE_Length</ModelName> </Field> Copy(cut) this XML block and move(paste) at the place in the <FieldArray> block where you want the Shape_Length field to show up in your feature class (at the end).  Save the XML file Back in ArcGIS desktop, right-click your geodatabase and import the XML workspace Verify the field order is how you want it Note:  the Notepad++ method may take you a few trials to get it right, especially since you have to be careful not to mess up the XML structure, but it should accomplish what you want.   GOOD LUCK!  and let us know if this works for you ... View more

That's great news, Peter.  I was just taking a look at your data.  Glad to hear you have the data shift problem solved.   As a wrap up to our different methods of bringing in custom calibrations, the method Amit described should be used if there are custom calibration points *within* the extent of your route.  For example, some departments of transportation here in the States have historically set rounded value calibration measures at intersections along a route.  If your custom calibration only involves custom measures at the beginning and end points of a route, then the method I outlined will work for you (note that interior measures at vertices within the route will be linearly interpolated based on geometric length between the end point calibrations).  ... View more