Latest Contributions by AmitHazra

‎09-24-2020

Hi Colin Congratulations! It sounds like your Roads and Highways implementation is really starting to mature and now you’re bringing multiple stakeholders and business units into the system. That’s awesome and exactly what the software was designed to handle but with this “power” comes a little bit of extra configuration... There are several important issues to consider once you begin to build out your Roads and Highways solution to a more enterprise scale like you are describing (multiple Event Editor configurations for specific asset program units). The primary concern you'll want to consider is data integrity when multiple users are editing LRS networks and/or events in a versioned geodatabase. In order to avoid versioning conflicts and/or measure discrepancies on routes and events you’ll want to enable the Roads and Highways Conflict Prevention capability. This will allow your users to interactively “lock” routes and events to prevent any route and/or measure-based discrepancies as a result of geodatabase versioning. Once you’ve enabled Conflict Prevention I suggest you have versions specific to the users who are making edits in the system. We tend to call these types of configurations “workgroup implementations” where Roads and Highways Event Editor configurations are specific to a user rather than a business unit workflow and/or role. If you’re really interested in these implementation patterns you can reference a UC tech workshop we did a few years ago. From a configuration standpoint and assuming you’re using Conflict Prevention, you’ll want to: Create a portal group for each asset program and add the appropriate users to each of those groups. As you publish federated services, create web maps and apps, share each configuration item with only the groups that need access to those specific items. Portal sharing model. For each user, create an Event Editor geodatabase version that is a child of the Lock Root version. Publish your LRS-enabled services either to your Default or Lock Root version. Create a specific configuration of Event Editor for each user or asset program unit (e.g., myAssetProgram.json). For each Event Editor configuration, you’ll want to create a default web map with the LRS-enabled service and any reference layers that group needs. Here's where the Referent Points comes into play. Publish a separate map service for this layer that is not LRS-enabled and optionally, using an underlying DB user connection with Event Viewer privileges. When you configure your Event Editor webmap, add that item to your web map along with the LRS web service. Your asset program units will be able to see the referent locations but will not be able to edit them. Share each configuration of each webmap to the appropriate group. For each Event Editor configuration, disable the allowChangeVersions, allowCreateVersions, allowDeleteVersions versioning properties. By allowing only the allowReconcileAndPost option, they’ll still be able to release conflict prevention locks. In portal, create/register/share specific versions of the Event Editor for each asset program using URL parameters. Example: https://myAwesomeRHSite.esri.com/EventEditor/?config=myAssetProgram.json. For each user, create a browser bookmark/URL favorite to their respective Event Editor configuration and version using URL parameters. Example: https://myAwesomeRHSite.esri.com/EventEditor/?config=myAssetProgram.json&version=LRS.ColinS. Have a look at our Smart launching in the Event Editor through URL parameters resource doc if you need more information on this type of configuration. As to your second question about whether to protect the Default version, if you are using Conflict Prevention and the Default version is your Roads and Highways version then it must be Public so Event Editor users can Reconcile/Post edits to release event locks. If you are using a surrogate to Default to represent your Lock Root version than yes you could absolutely Protect Default and simply let users rec/post to Lock Root. Hope this gives you a good reference point for expanding your R&H solution. Should you need further assistance please give us a call! -amit@esri Esri LRS Transportation Team

‎09-16-2020

Hello - This is a difficult question to answer without fully understanding the data format you're working with. You mentioned Google Maps in your post and this an Esri GeoNet forum devoted to the enterprise location referencing system solution called Roads and Highways which leverages the Esri geodatabase model. For the purposes of trying to get you going I will assume you've created a GIS dataset in an Esri-supported format such as a shapefile and/or geodatabase feature class. I'll also assume you're either using ArcGIS Desktop (ArcMap) or ArcGIS Pro to complete your analysis. With these assumptions I would recommend you take a look at either of these geoprocessing tools: Generate Points Along Lines (ArcGIS Pro) or Generate Points Along Lines (ArcMap) Either geoprocessing tool will allow you to extract point features along a polyline feature at a specified distance (in your case 0.2 meters). Once you've extracted those points as features you can add fields such as Latitude and Longitude to that feature class attribute table and then use ArcGIS Desktop to compute the X/Y geographic coordinates for each point using a number of different options including the Calculate Geometry Attributes GP tool. I should mention both the Add Fields and Calculate Geometry Attributes tools also have ArcGIS Pro analogs. -amit@esri Esri LRS Transportation Team

‎09-16-2020

Hello Masao - The decision on whether to create a multi-field, single-field, or autogenerated Route ID is truly a business decision relative to the needs of your organization; the system obviously supports any of these so long as the Route ID you choose is unique. Many organizations embarking on Roads and Highways implementation projects tend to have well defined geodatabase design activities since they are migrating their legacy systems to R&H and need to plan out their projects in detail.This is why I mentioned modeling ahead of time.. However, there is no specific rule that you need to model ahead of time. If you wish to use the out of the box tools to create the LRS container and LRS Network you can always go back to the network feature class after network creation, add the fields you want to concatenate for Route IDs, and then run the Modify LRS Network GP and also the Modify Route ID Padding GPs to configure your concatenation logic. -amit@esri Esri LRS Transportation Team

‎09-15-2020

Hello Masao It sounds like you are using the out of the box Location Referencing tools to create and configure the LRS and network for your Roads and Highways Pro data model. When you use the Create LRS and Create LRS Network GP tools the R&H Pro model is created assuming you are going to be leveraging the “Autogenerated Route ID” network Route ID configuration. That configuration requires a “Route Name” field that is synonymous with a unique ID that is more human-readable than a GUID. This Route Name concept is configured more commonly with our Pipeline Referencing users but since we are actively trying to align the development of the enterprise LRS product users will begin to see additional enhanced functionality blended from the surface transportation and pipeline industries. If you intend to use these creation/configuration tools to start your data model and you wish to use a Single-Field Route Id or a concatenated Multi-Field Route ID then you’ll want to add the fields you need to your network feature class and then run the Modify LRS Network GP so you can change the “Route ID Field Configuration” parameter to your liking. Alternatively, you can reference our information model definitions and choose to model your entire LRS ahead of configuring it. In this case, you'll use the Create LRS From Existing Dataset and Create LRS Network from Existing Dataset GP tools. -amit@esri Esri LRS Transportation Team

‎07-31-2020

Hello Courtney The object relationship and editing scenarios you're describing between centerlines, routes, and events is one of the primary reasons for why we built ArcGIS Roads and Highways. In the Roads and Highways data model, centerlines form the foundation for route geometry. Roads and Highways tools are utilized to build and maintain routes upon the centerlines, and event feature classes are maintained on the routes the events are characterizing. You can read more about the information model in our LRS data modeling document. The solution incorporates advanced rules to manage the relationship of centerlines to routes and automates the update of event measures and shapes based on configurable location event rules called "behaviors". In addition to these fundamental desktop editing capabilities and automated rules, Roads and Highways provides a rich Server-based solution including a JavaScript REST API to develop web-based apps on. If you'd like to talk more about bringing enterprise LRS capabilities to your organization please reach out to us anytime, Amit@esri Esri LRS Transportation Team

‎07-31-2020

Hello Saranya This is the expected ArcGIS Desktop (ArcMap) output for publishing the GenerateReport geoprocessing tool for Roadway Reporter. Now that the tool has been run you're ready to publish it as a GP service and subsequently configure the Roadway Reporter app. Refer to our deployment resource documentation for further information: Publishing the Generate Report tool to a service—ArcGIS Roads and Highways Server | Documentation for ArcGIS Enterprise -amit@esri Esri LRS Transportation Team

‎04-02-2020

A note about the comments regarding removing centerline geometry duplication in Roads and Highways as it relates to route concurrency (overlapping route geometry) and route dominance. Although my reply does not necessarily address the original GeoNet question, I do want to bring to the community’s attention the relative importance in de-duplicating centerlines in Roads and Highways for ALRS networks where route dominance is configured. For this example, I present to you four routes where the concurrency rules are set such that the greater, alphanumeric Route ID is the dominance rule. Example 1: Routes “zRoad” and “aRoad” are concurrent. Each route has its own centerlines and those centerlines overlap in the highlighted region below (not de-duplicated): Here is the corresponding centerline sequence table for Example 1: Example 2: Routes “xRoad” and “bRoad” are concurrent. Each route shares the middle centerline where they overlap in the highlighted region below (de-duplicated): Here is the corresponding centerline sequence table for Example 2. Note the yellow highlighted records represent the concurrent centerline segment: Now, suppose we need to run the Calculate Route Concurrencies GP tool to calculate and report the concurrent route segments within the LRS Network and determine what routes are dominant for a given section of roadway. Here is what the output of the GP tool should look like for Example 2: In this example, the GP tool traverses the centerline sequence table to determine routes in networks that share centerline sections and based on the configured network concurrency rules determines what the dominant route is along the concurrent section (re: DominantFlag). However, without de-duplicating centerlines for Example 1, the output result from the geoprocessing produces an empty recordset: Finally, running the Remove Centerline Geometry Duplication utility on the ALRS and then re-running Calculate Route Concurrencies GP yields this result for Example 1 and Example 2: The moral of the story here is that no matter why or when you introduced centerline geometry duplication into your ALRS, if you have overlapping/concurrent route definitions you really need to be cognizant that route dominance depends of keeping your centerline sequence table nice and tidy. Hope that helps! amit@esri roads and highways team

Re: esri roads and highways · ‎03-09-2020

Hello Christoper If I'm interpreting your post correctly it sounds like you have a GIS feature class representing your bike path extents but the features do not have LRS route and measure information associated to them. I'm assuming these features may or may not be coincident with your network geometry. I'm assuming you'd like to derive route and measure information for each feature and then use Location Referencing Append Events GP to bulk load the paths rather than simply using Event Editor. I would suggest as a first pass looking at the core Linear Referencing tool called Locate Features Along Routes. The output from this tool is a table that provides the relative route and measure information for your spatial features. Be cautious when using this tool on linear data as the algorithm to convert lines to linear events uses a cluster tolerance which can sometimes yield unsatisfactory results. There are other more workflow-centric and custom GP-based patterns but I'd be curious to know whether this tool gets you a good part of the way on your migration. -Amit@esri Roads and Highways team

‎01-17-2020

Hello Ana, Although there seems to be some ambiguity in our docs, the redline feature class should not be M or Z enabled if you choose to use route redlining in the Roads and Highways Event Editor. To resolve your issue you could create a new redline feature class and replace the old one. In order to make this GDB feature class swap you'll want to be sure there are no services running that contain the current redline. Thanks, Amit@esri Roads and Highways Practice

‎12-11-2019

Hello Joseph, Assuming you are using ArcGIS Desktop 10.5.1 or later there is a COTS-based workflow to bring your routes back from retirement. This workflow assumes you want/need to preserve all timeslices for the route in question and that you may have custom/intermediate calibration points. The process is simpler if you are reloading a route using geometric length or do not have intermediate calibration. For the route in question, clear the TVD (temporal view date) for the network and calibration point feature classes. Select the route and calibration features for all time slices of the route in question. Export those route and calibration point feature classes to a file geodatabase. In the exported route and calibration point feature classes, carefully edit the To Dates for the records you retired back to <null>. Using the Roads and Highways Load Routes tool, use the edited route feature class to reload the route in question. Once the routes are loaded, you'll be prompted to choose a calibration method. If you have no custom/intermediate calibration you could simply choose from the source route measures or geometric length. If you have custom/intermediate then it does not matter what you choose as you'll need to apply an additional workflow to bring that calibration back. Optionally, choose to remove centerline duplication at the end of the calibration process Prior to opening an ArcMap Edit session, open the Roads and Highways Advanced Editing options and check the option to "not apply event behaviors to manual calibration point changes". Add the exported and edited calibration point feature class to the map. With the TVD still cleared, open an edit session and select all the calibration points for the route in question. Delete those points. Select and copy/paste the exported calibration points for the route in question into the R&H calibration point feature class. Apply edits and save/close your edit session. Be sure your events’ temporal dates match the routes as you wish. You may also wish to test this workflow in a version or file GDB export to be sure it yields the results you desire. -Amit@esri Roads and Highways team

‎12-09-2019

Hello James A common pattern among our enterprise-scale Event Editor deployments is to create business-unit and task specific configurations for editing events. In a practical sense, this means that for each configuration of Event Editor you'll publish one LRS-enabled service with only the event layers required by the end users' maintenance needs and then should they wish to have additional LRS event layers or other reference data layers (e.g. polygon boundaries etc) in their configuration you'll simply publish those layers as map services without LRS capability enabled. From your Portal you'll then manage access to those web layers through group sharing at the service, webmap, and app item level. Each Event Editor configuration will have a default webmap with the one LRS-enabled service and then you can also add in any number of reference map layers so long as they are not LRS-enabled. Hope that helps. If you have any other implementation questions please do not hesitate to ask. Amit@esri

‎11-05-2019

Hello Anthony, Assuming you use a GP tool like Multi-Part To Singlepart to explode any of your multi-part route (polyline M) features, you could add FromMeasure and ToMeasure fields (data type: double) to your route feature class. Once you have your fields, use the Field Calculator (python) to compute the measures where your FromMeasure = !Shape!.extent.MMin and ToMeasure = !Shape!.extent.MMax. Thanks Amit@esri

Re: Data Reviewer Checks in Pro · ‎10-24-2019

Hello Kyle, Cross-validation checks already exist in Data Reviewer for ArcGIS Pro as Event on Event checks. Check this out: https://pro.arcgis.com/en/pro-app/help/data/validating-data/event-on-event.htm. Thanks! Amit@esri

‎10-16-2019

Hello Colin - Export Network is expecting up to 9 arguments: When you open the parentheses on the tool it should look similar to: -Amit@Esri

‎10-16-2019

Hello Colin The easiest way to access this GP Tool is to add it to a custom toolbox and then reference that toolbox in your python code. 1) Create a new toolbox: http://desktop.arcgis.com/en/arcmap/latest/analyze/managing-tools-and-toolboxes/creating-a-custom-toolbox.htm 2) Right click the toolbox and add a new built-in tool: http://desktop.arcgis.com/en/arcmap/latest/analyze/managing-tools-and-toolboxes/adding-tools.htm#GUID-CA99C4ED-DB43-4038-8C2E-2099F173F3F0 3) Browse to your installation of Roads and Highways Desktop and look for the Location Referencing Tools: Ex: C:\Program Files (x86)\ArcGIS\LocationReferencing\Desktop10.7\ArcToolBox\Toolboxes 4) Check the Export Network GP Tool to add it to your new toolbox Now you can access this toolbox through some super basic Python like this: arcpy.ImportToolbox('C:\GISTemp\MyToolbox.tbx', 'LrsTool')‍ arcpy.LrsTool.ExportNetwork(add your GP arguments here...) ‍‍‍‍‍‍‍‍ Good luck, Amit@Esri

Online Status	Offline
Date Last Visited	3 weeks ago

My Ideas

Latest Contributions by AmitHazra

Re: Event Editor Version Structure/Workflows

Re: How can I extract all the latitude and longitude information of all the points 0.02m apart in a route created by Google Maps

Re: Route Name vs Route ID

Re: Route Name vs Route ID

Re: How can a route layer be connected to the layer it is based off of?

Re: roads and highways

Re: Where is Remove Duplicate Centerline Geometry in your process?

Re: esri roads and highways

Re: Roads and Highways ALRS Redline Properties

Re: Roads & Highways - Unretire route in RCE

Re: Portal and Event Editor: Users and the AnonymousWebUser

Re: Milepost information of split routes?

Re: Data Reviewer Checks in Pro

Re: Deploying Export Network as a service

Re: Deploying Export Network as a service

Re: Route ID Field Separators

Re: Create LRS Event GP Tool crashing in Pro 3.2

Re: Validating RouteName for Create Route

Re: REST Api operation queryEditLog missing from L...

Re: Overlay Route Events Error (ArcMap 10.8.1)

Roads and Highways User Group (RHUG)