适用于 Location Referencing 许可。
The linear referencing system (LRS) is a collection of feature classes and tables that allow the storage and editing of calibrated routes.
The LRS supports the use of a single polyline feature class, known as a centerline, to store the geometry for multiple routes. Centerline geometry, along with route definitions, are stored in a network feature class.
A many-to-many relationship exists between the routes in the network and the centerlines providing the geometry. This means that routes are typically composed of multiple centerline features, and centerline features can participate in multiple routes in multiple networks.
In addition to geometry, routes must also have measures. The LRS uses route measures so that event layers appear in their correct locations on a map. Measures are added to routes through a process known as calibration. To explicitly control how routes are calibrated, the LRS uses a calibration point feature class.
Calibration points are point features that store measure values, route references, and network IDs. The combination of these three items constitutes a linear referencing method (LRM). LRMs are created by applying calibration points to routes to create an LRS Network.
The LRS is comprised of the following feature classes and tables:
- Centerline—The polyline feature class that stores route geometry.
- Centerline Sequence—The cross-reference table that manages the relationship between centerlines and routes.
- Calibration Point—The point feature class that stores route measure values.
- Redline—The polyline feature class that stores markup features for communicating LRS changes.
注：
Feature classes and tables are created with all necessary fields when running the Create LRS tool.
Feature dataset requirement
为了在 Pipeline Referencing 中支持对数据进行基于服务的编辑，LRS 数据模型中的某些要素类必须位于地理数据库中的要素数据集。 如果提前对要素类和表进行建模，则以下要素类为必需项并且必须包含在要素数据集中：
- 校准点
- 中心线
- 事件
- 交叉点
- 网络
- 红线
Version Management requirement
LRS data you publish as a service must be branch versioned, and the version management capability must be enabled when it is published as a service.
All LRS feature classes and tables must have the additional fields required for version management, such as GlobalIDs, added before publishing.
Learn more about registering a dataset using branch versioning requirements
Learn more about publishing with linear referencing and version management
LRS dataset
A linear referencing system (LRS) dataset is found in a feature dataset in the geodatabase, along with all the feature classes that participate in the LRS.
注：
You can view the hierarchy for an LRS from the Contents or Catalog pane.
The following tools create an LRS dataset, as of ArcGIS Pro 2.3:
- Create LRS —The newly created centerline, calibration point, and redline feature classes will be created inside a feature dataset with the same name as the provided LRS name.
- Create LRS From Existing Dataset —The existing centerline, calibration point, and redline feature classes that are not yet registered with an LRS must be inside a common feature dataset. The feature dataset name can be different from the LRS name.
- Modify LRS —The existing centerline, calibration point, and redline feature classes that are registered with an LRS must be inside a common feature dataset. The feature dataset name can be different from the LRS name.
The LRS dataset is required to run the following tools:
- All Configuration toolset tools
- Append Events
- Append Routes
- Apply Event Behaviors
- Delete Routes
- Derive Event Measures
- Generate Calibration Points
- Generate Events
- Generate Intersections
- Generate Routes
- Remove Overlapping Centerlines
注：
Use the Migrate Object ID to 64 Bit geoprocessing tool to migrate the LRS dataset to 64-bit Object IDs.
Upgrading a dataset to 64-bit Object IDs is useful when Object ID values exceed 2.1 billion or if data is coming from cloud data warehouses.
Some of the information contained in the LRS controller dataset can be read by using an arcpy.Describe function. To read the LRS metadata and event behavior rules for a geodatabase with an LRS controller dataset, use the following functions:
FileGDB:
desc = arcpy.Describe("C:\\Data\\LRData\\LrsSchema.gdb\\Lrs\\Lrs")
lrsXML = desc.lrsMetadata
eventBehaviors = desc.eventBehaviorRulesEnterpriseGDB:
desc = arcpy.Describe("C:\\Data\\LRData\\LrsSchema.sde\\GPRefresh.DBO.LRS\\GPRefresh.DBO.LRS")
lrsXML = desc.lrsMetadata
eventBehaviors = desc.eventBehaviorRulesWriting to a file:
txtFile = open("C:\\Data\\LRData\\lrsXML.xml", "w")
txtFile.write(lrsXML)
txtFile.close()Centerline feature class
The centerline feature class provides a single source of geometry for all of the LRS Networks you build in an LRS.
Every feature in the centerline feature class represents a single unit of pipe. These can be used to represent a one-to-one relationship with routes or be combined to form larger routes.
注：
The tolerance and resolution settings of the centerline feature class are propagated to the networks, intersections, and event feature classes registered with Pipeline Referencing. The spatial reference, x,y-tolerance and resolution, and z-tolerance and resolution of the centerline feature class must match that of the source routes used to load data into your LRS.
注：
The centerline feature class must be z- enabled.
The LRS requires that the centerline feature class have a centerline ID field. The Create LRS and Create LRS From Existing Dataset tools allow you to map a centerline ID field.
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| Centerline ID | GUID | Yes | Unique ID for the centerline geometry |
注：
The CenterlineID field is a system-maintained field. This field should not be edited manually.
Centerline sequence table
The many-to-many relationship between routes and centerlines is maintained through a cross-reference table known as the centerline sequence table. Since route IDs are not unique in the LRS, the centerline sequence table also contains a reference to the network ID field of the LRS Network. The combination of the network ID and route ID creates a way of uniquely identifying each route in the LRS. The use of the network ID helps differentiate between LRMs, as route IDs may not be unique across networks.
One centerline feature can participate in many routes, and a route can be comprised of more than one centerline. The centerline sequence table must have at least one record for each centerline-network combination.
The minimum fields for the centerline sequence table are as follows:
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| Centerline ID | GUID | Yes | The unique ID for the centerline geometry | |
| FromDate | Date | 8 | Yes | The date that the portion of the centerline becomes active |
| ToDate | Date | 8 | Yes | The date that the portion of the centerline is retired |
| RouteId |
String or GUID | 38 or greater | Yes | The unique ID for the route |
| NetworkId | Short Integer | 5 | Yes | The unique ID for the LRS network in which each route participates |
注：
Records in the centerline sequence table should not be edited manually.
注：
The NetworkID field is registered with the dLRSNetworks coded value domain when the LRS is created.
Calibration point feature class
Route measures are assigned to routes in the network using the calibration point feature class. Routes are calibrated by calculating an interpolated distance between any two calibration points along the route. Calibration points are specific to an LRS Network and make up the measure component of the LRM. Calibration point rules are as follows:
- There is only one calibration point feature class for all LRS networks registered with the LRS.
- A minimum of two calibration points is required for each route.
- Calibration points should be monotonic, meaning strictly increasing or decreasing in measure along a route. Nonmonotonic routes will calibrate but can result in undefined event locations and event behavior.
- Add a calibration point to a particular location to maintain a specific measure value.
注：
The calibration point feature class should have the same spatial reference, x,y- and z-tolerance, and resolution as the centerline feature class.
The calibration point feature class must be z-enabled and cannot be m-enabled.
The minimum fields for the calibration point feature class are as follows:
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| Measure | Double | 8 | Yes | The measure value stored for routes in an LRS Network |
| From Date | Date | 8 | Yes | The date that the calibration point becomes active |
| To Date | Date | 8 | Yes | The date that the calibration point is retired |
| Route ID |
String or GUID |
Same type and length as the RouteID field in the centerline sequence table | No | The unique ID for the route |
| Network ID | Short Integer | 5 | Yes | The unique ID for the LRS Network |
注：
The NetworkID field is registered with the dLRSNetworks coded value domain when the LRS is created.
Use the Generate Calibration Points tool to generate calibration points.
Redline feature class
The redline feature class contains the basic information required to perform many of the route editing functions available in Pipeline Referencing. This markup feature is a placeholder for a future route editing operation used to alert an LRS Editor to necessary changes.
注：
The redline feature class should have the same spatial reference and x,y-tolerance and resolution as the centerline feature class.
The redline feature class must be z-enabled and cannot be m-enabled.
The minimum fields for the redline feature class are as follows:
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| From Measure | Double | 8 | Yes | The starting measure of the alignment change |
| To Measure | Double | 8 | Yes | The ending measure of the alignment change |
| Route ID |
String or GUID |
Same type and length as the Route ID field in the centerline sequence table | No | The unique ID for the target route |
| Route Name | String | 38 | Yes | The name for the route |
| Effective Date | Date | 8 | Yes | The date that the route change becomes effective. This date is applied to events affected by the change if the effective date applies. |
| Activity Type | Short Integer | 5 | Yes | The edit activity that should be made, such as Extend Route |
| Network ID | Short Integer | 5 | Yes | The unique ID of the LRS Network |
注：
The NetworkId field is registered with the dLRSNetworks coded value domain, and the ActivityType field is registered with the dActivityType coded value domain when the LRS is created.
Redline features can be specific or general. A GIS analyst should verify that the redline feature has accurate geometry in the database. A roughly sketched redline indicates that a change to the LRS is required and provides the general location of the change.
Network feature class
The network feature class contains the route features used in the LRS. These routes have attributes, geometry from the centerline feature class, and calibration from the calibration point feature class.
Combined, these elements constitute a route in the LRM that can be used to locate events on that route. Each route should have a unique route identifier, called a route ID.
The route ID field data should be consistent throughout networks, events, calibration point feature classes, and the centerline sequence feature table.
The RouteId field data type should be consistent throughout networks, events, redline, calibration point feature classes, and the centerline sequence feature table.
注：
If the network feature class is modeled before the LRS is created, ensure that the x,y- and z-tolerances and resolutions match those of the centerline feature class. The m-tolerance and resolution for the network is based on the units of measure of the spatial reference for the network feature class and the units of measure for the LRM being used. If the units of measure are the same, the m-tolerance and resolution match the x,y-tolerance and resolution. If the units of measure are different, you need to convert the x,y-tolerance and resolution to the corresponding m-tolerance and resolution.
For example, a network feature class has a spatial reference in meters, with an x,y-tolerance of 0.001 meters and x,y resolution of 0.0001 meters. If the units of measure for the LRM are in meters, the m-tolerance would be 0.001 and the m-resolution would be 0.0001. However, if the units of measure for the LRM are in kilometers, the x,y-tolerance and resolution values would need to be converted from meters to kilometers for the m-tolerance and resolution. In this example, the m-tolerance would be 0.000001 and the resolution would be 0.0000001.
Learn more about tolerance and resolution settings for the LRS
The minimum fields for the network feature class are as follows:
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| From Date | Date | 8 | Yes | The date that the portion of centerline becomes an active part of the route |
| To Date | Date | 8 | Yes | The date that the portion of centerline becomes a retired part of the route |
| Route ID |
String or GUID |
Same type and length as the RouteId field in the centerline sequence table | No | The unique ID for the route |
|
Route Name | String | 255 | No | The unique name for the route |
注：
The network feature class fields should not be directly edited. They are maintained by Location Referencing.
The following fields should be configured if creating an LRS Network that supports lines, such as an Engineering Network:
注：
It is recommended that line order be configured using increments of 100. In such a configuration, the first route has a line order of 100 and line order increases in increments of 100 for each route along the same line (100, 200, 300, and so on).
| Field | Data type | Length | IsNullable | Description |
|---|---|---|---|---|
| Line ID |
String or GUID | Same type and length as the Route ID field in the centerline sequence table | Yes | The unique ID for the line |
| Line Name |
String |
Same length as the Route Name field | Yes | The name of the line |
| Line Order | Long | Yes | The order of the route on the line |