bSI-InfraRoom / IFC-Specification

IfcDoc baseline to produce the documentation
24 stars 25 forks source link

Linear Referencing Method Concepts #350

Open clfey opened 2 years ago

clfey commented 2 years ago

Linear Referencing Method concepts

The concept of a Linear Referencing Method (LRM) has many aspects and therefore deserves a thorough but step-by step explanation.

The Ifc schema follows closely the ISO 19148:2012 standard. An IfcAlignment corresponds to what is called the Linear Element (LE) in ISO 19148.

Referents in IFC

A referent is a semantic entity holding information which is needed when expressing locations without the use of CRS coordinates. A given referent is nested by exactly one alignment. By nesting we mean that the alignment has a linked list where each referent occurs once and in a given sequence from the first referent to the last referent - a socalled unique and ordered collection.

In its most general form, an alignment does not need to have an associated geometry, but it can still have referents.

The referents applicable to LRMs are IfcReferent elements of predefined type REFERENCEMARKER or STATION (or USERDEFINED).

The REFERENCEMARKER and the STATION referents - the piano teacher and the fire hydrant use cases

The following use case recounts the story of a stranger in town, trying to find the piano teacher, or the guy who needs to install a new fire hydrant. The analogy in a railway context would be the maintenance guy trying to locate a device along an old railway line (where the actual geometry has not been surveyed), or a supplier who needs to install a new sensor close to the track (also without survey data).

A reference marker represents a commonly recognizable location. It is useful when one party needs to communicate a location to another party, for instance "The library", a stately old building, easily recognizable even for strangers in town. If we also mention a recognizable alignment such as a named street, then we can speak of "The library on Baker street".

Since "Baker street" has a start and an end, we may now speak of a distance along Baker street, from zero (its start) to L (its total length). If the main entrance door of the library building projects orthogonally on Baker street at a distance of 700 meters from the start of Baker street, then we may speak about the location as "700 meters from the start of Baker street". This is a socalled point by distance expression in IFC. We can be even more precise by stating that the exact spot we are thinking of is the bottom center of the main entrance door (having a staircase in front of it), located at 6.7 meters to the right of the centerline of Baker street, 1.3 meters above the center-of-pavement's height above mean sea level.

A stranger comes by and asks us where the town's only piano teacher lives. The teacher's house is located two blocks after the library, also on Baker street, but at a distance 950 meters from the start of Baker street. However, most people don't have a notion of the exact spot where Baker street starts, and it would also be quite impractical to measure 950 meters by walking from the start of Baker street since the stranger and we are already quite close to the library. It is much more natural to use the library ahead as a reference and state that the piano teacher's house is located 250 meters after the library (still on Baker street). Thus, "250 meters after the library, on Baker street" is a relative linear address of type STATION, using the library as its REFERENCEMARKER. Had we known that the teacher's house number is actually 17, then we could have given the teacher's house location directly as a reference marker, as "House number 17 on Baker street", making life easier for the stranger.

Our stranger then starts to walk in the direction of increasing house numbers towards the library, but gets bewildered. He stops to ask an old lady about the piano teacher's house. She happens to know the piano teacher well, and she says that his house is located "just fifty feet after the locksmith, you can't miss the locksmith store, it has a large neon sign with a key above its door". So the stranger now has two linear referencing measurements - STATIONs - for the same location: "250 meters after the library" and "50 feet after the locksmith" (Baker street being implicitly meant). Note that these referencing methods are different - the first one uses meters, the second one uses feet. None of them needs to know the station value of the referent, it is sufficient to just find the referents and then walk an estimated 250 meters from the library, or 50 feet from the locksmith.

In this very realistic example we do not know the geometry of Baker street, and it is not needed. The stranger has no problem of finding and following Baker street using a street map and reading the signs at street/avenue corners. Furthermore, we would not even need a station value at our referents, it could implicitly be zero if not mentioned. We don't need to know the distance from the start of Baker street. The only numbers involved are the relative distances - measured along the center line of Baker street - from the named referents to the target location.

Station or PointByDistanceExpression?

In the example above, the stranger needed a STATION, a rough but precise enough description of a location.

The next day, the fire department needs to install a fire hydrant outside the teacher's house, connecting it to the underground water pipe with a new valve. The STATION "250 meters after the library" is given orally to the installation guys to direct them to the right spot in town. They park their car in the vicinity and step outside with their equpiment. Looking at the installation instructions, they find a text being the name of another, much more precise STATION: "Follow the left curbside of Baker street, in the 'up' direction of Baker street (increasing house numbers), where the curbside meets with the road's asphalted surface, then locate the center of sewer drainage sink number 38 (its number is shown on a small plate on a nearby house wall), go 5.7 feet in the up direction of Baker street, go 13 inches left (i.e., being on the sidewalk) and drill to a depth of 5 feet 8 inches below sidewalk surface level, where you will meet the underground pipe.".

The above STATION did not rely on surveyed data, i.e. the actual geometry of the curbside and of Baker street were not stored as alignments in a coordinate system.

The year after, city management decided to map all resources in a suitable Coordinate Reference System. All street centerlines were surveyed and stored as IfcAlignments with horizontal geometry and vertical profile. The left and right curbsides of all streets were also surveyed, but they were chopped up at every street / avenue corner. There are 15 blocks on Baker street, so it has 15 left curbside alignments and 15 right curbside alignments. All 30 curbside alignments have nominated Baker street as their reference alignment for their full length (from one street/avenue corner to the next).

The fire hydrant in question is located inside block number 7 on Baker street. The installation personnell download an Ifc file from the city's brand new Ifc database, containing the alignments BakerStreet and BakerStreet_LeftCurbside_007. The file also contains several referents of type REFERENCEMARKER, named Library - the library on Baker street (nested to the BakerStreet alignment) and BS_left_drain_38 being the center of drain hole number 38 (nested to the BakerStreet_LeftCurbside_007alignment). Finally, their Ifc file contains one STATION referent (nested to the BakerStreet alignment) with name Library+250m, and one more precise STATION (nested to the BakerStreet_LeftCurbside_007 alignment) named BS_drain_38+6'8.4" / 1'1" left / 5'8" deep. In addition to the referent's human-readable name, the referent also contains an IfcPointByDistanceExpression, which places the location at DistanceAlong="87.337", LateralOffset="0.330", VerticalOffset="-1.727"(using meters as the measurement unit). This PointByDistanceExpression is fed into their portable survey equipment, which automatically calibrates its own position to the GPS satellites and recognizes the curbside and drain hole 38 from a realtime scanner, and then points a laser beam at the exact spot. Then they drill.

The above example is a metaphor on how maintenance personnel need rough stations to locate the item that shall be fixed (assuming that it has been installed and is recognizable once you get there), but installation personnel also need a more exact PointByDistanceExpression to find the exact location where they shall install something. Although the PointByDistanceExpression has an exact formulation in IFC such as IFCPOINTBYDISTANCEEXPRESSION(IFCNONNEGATIVELENGTHMEASURE(0.0),$,$,$,#61);` this is not very legible for humans. That's why the design software should also supply a STATION referent with an IfcReferent.Name attribute having a nice, human-readable text string.

Combining several referents and LRMs into one compound, custom LRM

Note that in the fire hydrant example, the exact location was expressed as a combination of two linear elements: "Baker street" (its center line) and "the left curbside of Baker street". We did not specify whether the curbside alignment runs more or less parallel to the Baker street alignment. When we say "13 inches left from the curbside (on the sidewalk) this translates to using the right/left concept as inherited from Baker street, which is here the reference alignment for the left and right curbside alignments. To sum up: The longitudinal reference measures along the centreline of Baker street, where as the lateral and vertical offsets use the left curbside's sidewalk surface level as a more local reference, much safer to use than to measure "25 ft 6 in to the left of the centerline of Baker street".

In a railway context, the analogy would be that one track plays a special "reference" role through the railway station, the other tracks being dependent, naming that special track as their reference for use in longitudinal linear addressing. The lateral and vertical offsets are better formulated using the track which is closest to the location in question.

Absolute LRM

The simplest LRM type is the ABSOLUTE LRM, one of the three predefined LRM types . It defines a monotonously increasing stationing function starting at the beginning of the alignment, increasing as you follow that alignment from start to end. The ISO 19148:2012 standard allows to state a non-zero starting value. By choice of design, it has been decided that the IFC schema does not allow absolute LRMs with non-zero starting value. If a non-zero start value is needed, then you must use a relative or a userdefined LRM.

Relative LRM

The next predefined LRM type is the RELATIVE LRM. It needs at least one REFERENCEMARKER referent to fulfil its purpose, which is to (indirectly) reference a known location (the reference marker) and to assign a definite value to all locations followingafter the refernce marker. The way the predefined LRM does this is to search the alignment for its closest preceding nested REFERENCEMARKER which has been tagged as an LRM of predefined type RELATIVE, read its station value, then add or subtract the delta in DistanceAlong between the location being measured and the reference marker's location. The DistanceAlong values are obtained from the two location's PointByDistanceExpressions with respect to the alignment in question. If the closest preceding and matching reference marker states that the associated LRM's sawtooth function shall Decrease from the referent and onwards (in the direction of increasing DistanceAlong values), then you subtract the DistanceAlong difference from the reference marker's station value. Otherwise, you add it.

The mandatory interpretation of predefined LRM type RELATIVE is the calculation of the Pset_Stationing.Station value. How you decide to format the referent's name - most often a human-readable name - is up to the authoring software. The Pset_LinearReferencingMethod.LRMName may contain a name which gives the user a hint about how to interpret the LRM and how to format the referent's name using that LRM. Each railway infrastructure manager will have its favourite LRM types, each one with a suitable name.

Stationing jumps, Mileposts and Chainbreaks

With relative LRM, the associated sawtooth function may "jump" at referents. If referent A is located at DistanceAlong Da and the next referent B (of matching LRM type) is located at DistanceAlong Db, then let d=Db-Da be their difference. Let Sa be the stated Pset_Stationing.Station value at referent A, and let Sb be the station value stated at referent B. If Sb-Sa is larger than d then we have a positive stationing jump. If Sb-Sa is lower than d, then we have a negative stationing jump.

If provided, the optional Pset_Stationing.IncomingStation is expected to be Sa+d. If the incoming station is not equal to Sa+d within a certain tolerance, then a validation of the Ifc file's syntax will fail. The tolerance should be specified explicitly or should be left up to the individual Ifc authoring tool or Ifc viewer.

In a railway application, a Milepost is a referent marking an integer number of kilometers (or hundreds of meters, or miles, or other suitable unit) from a specified point-of-origin in the railway network. The word "Mille" stems from the old Roman road system, where you counted the number of thousand double-steps away from Rome made by an average running soldier. One step is approximately 80 centimers, making 1000 * 2 * 0,8 = 1608 meters = 1 mile. The milepost was marked physically with a stone having the mile number carved on it. Today's railway "mileposts" are often called "kilometrration boards" and carry an integer number of kilometers from the network origin.

Most of the European railway networks are legacy installations where the mileposts have not been placed with high accuracy. With the advent of better measuring techniques, the exact distance from milepost to milepost has been surveyed. However, with hundreds of thousands of existing drawings which rely on the legacy placement of milepost referents for relative addressing, we cannot move the mileposts to their exact distance from the origin. Instead, we associate a rather small correction number to each milepost (kilometration board), telling what the difference is between the announced distance (1 kilometer, or 100 meters, or 1 mile etc) and the exact distance from the closest previous referent of matching type. This correction is called a milepost jump value.

The chain break represents that the railway line has been cut and rejoined, resulting in a lengthening or a shortening of the line. There will generally be one location where the reconstruction started and one at the other end of the reconstruction works. It is customary to let the stationing sawtooth function increase seamlessly past the first location, but to create a referencemarker being named as a chain break at the second location. There may also be new milepost markers between the two reconstruction location referents.

Predefined Interpolative LRM

The third predefined LRM type is INTERPOLATIVE. The predefined type shall be interpreted as having station values between 0 and 1. If no REFERENCEMARKERS with predefined type INTERPOLATIVE have been given, then the start of the alignment shall implictly be treated as station value 0.0 and Increasing, treating the end of the alignment as an implicit reference marker with incoming station value 1.0.

If an imported Ifc file contains an object with an interpolative LRM station value of 0.5, it means that it shall be placed halfway in the alignment to which it is nested. To place it on a computer screen you would have to assess the total length L of the alignment, compute the object's DistanceAlong as d = Station * L, and then place it in the drawing.

Custom Interpolative LRM - the "Schematic Twin" drawing

As in relative LRMs, this family of useful interpolative LRMs defines a sawtooth function that either increases or decreases from one referent to the next. However, the Increasing attribute is not used here. Instead, a STATION referent's preceding REFERENCEMARKER holds a station value As, and the subsequent REFERENCEMARKER holds an incoming station value Bi. If no incoming station value has been stated in B, then Bi = Bs, the station value of B. The STATION referent holds a station value between 0.0 and 1.0, representing an interpolated value from As to Bi. As an example, let As = 45662 and Bi = 50220. Their difference is 4558. If a STATION referent between these two has a station value of 0.5, then it is said to represent the value 45662 + 0.5 * (50220-45662)/2 = 47941, no matter what the difference in DistanceAlong is from referent A to refrent B in the scheamtic drawing. This would translate, in an authoring tool, to moving the object at station 0.5 each time you move referent A or referent B (or both). It is meaningful to move the refernts A and B in order to make enough space in the schematic drawing that object's symbols don't overlap.

One possible usage for interpolative LRMs are schematic drawings which have been machine-generated from geographical drawings. The schematic drawing's alignments will topologically be equivalent to their 'real' counterparts, but they will be drawn as straight lines meeting at 45 degrees angles. Since real distances cannot be measured as differences in DistanceAong the alignments, we have to intepolate distances between known locations.

Let A and B represent two known locations in the real rail network, for instance the stock rail joints of two consecutive points "503" and "505". Each of A and B will be declared in the schematic model as referents of type REFERENCEMARKER, and they would be given referent names such as "SRJ-503" and "SRJ-505". Let us assume that there is an established reference alignment system in the geographical model, so that each location in the geographical model has a definite overall kilometration system value, computed from that location's projection onto the nominated reference alignment.

Let KmA be the overall kilometration value for SRJ-503, and let KmB be the overall kilometration value for SRJ-505. Assign KmA as the Pset_Stationing.Station value at referent A, and KmB as Pset_Stationing.Station at B. We assume that there are no other REFERENCEMARKERS between these two referents.

In the schematic drawing, there will be a 2D symbol for SRJ-503 and another symbol for SRJ-505. These will be drawn on the computer screen at (X,Y) positions P503 and P505 respectively. Between P503 and P505 there is a succession of tangent segments and curved segments which more-or-less closely represent its geographical twin. The total length of these 'schematic' segments is Ls. The corresponding length along the tracks in the geographical model is Lg, which is also the difference in DistanceAlong values.

**Numerical example*** Let KmA = 17334 and KmB = 17997. The physical distance along the path between them (they do not need to belong to the same alignment) is 668.1 meters. 668.1 can be different from the difference in station values, 17997-17334=663. This would be so because the path in our example did not coincide with the station's reference alignment and was not entirely parallel to the reference alignment(s).

We want to represent a signal C in the schematic drawing. Let us assume that its geographical kilometric position is KmC = 17568 [meters] (as measured in the reference alignment). We compute (17568-17334)/(17997-17334) = 0.353, meaning that the signal is placed at 35.3% of the kilometric distance between SRJ-503 and SRJ-505, speaking in kilometers along the reference alignment and not in DistanceAlong the path between these two. Let us assume that the schematic representation of the path between SRJ-503 and SRJ-505 has a length Ls = 27.928 drawing units. Now we place the signal at 0.353 * 27.928 = 9.856 drawing units measured along the schematic path from SRJ-503 to SRJ-505. We then produce a STATION referent for signal C, with Pset_Stationing.Station value being 0.353 and the LRM type being of a custom type and interpolative. The human-readable expression uses KmA = 17334 from referent A and IncomingStation = Station = 17997 at referent B along with its own interpolative station value of 0.353 to produce the interpolated kilometer value 17334 + (17997-17334) * 0.353 = 17568, presented as "Km.17,568" in the STATION referent's name.

Note on chain breaks and mileposts with interpolative LRMs If the signal C had been located between SRJ-503 and a subsequent REFERNCEMARKER providing a sawtooth function discontinuity (a milepost or a chain break), then we would interpolate between the Station value of SRJ-503 and the IncomingStation value of the milepost / chain break.

Other useful referent types

A reference marker can be tagged as 'Start-of-alignment', to provide a textual expression for the station value at the start of the alignment as well as a start value for relative addressing.

Reference alignments

Reference alignment examples

In a railway track setting, it is customary to select one track through a given station to represent the overall distance measurement system from the network's origin. The German name is "Bezugskilometer", the French name is "Point Kilométrique de Ligne" or just "PK ligne", the Norwegian name is "Bestemmede spors kilometer" or just "Kilometer", abbreviated "Km". These are custom-specified LRM types, each with its own name and interpretation.

The German system also has a variant of LRM type which includes an explicit mention of the 4-digit database identity of the alignment along which the "Km" distance measurements are made. The German network has several thousands of such reference alignments. Before a greenfield project is allowed to start construction, its reference alignments must be published in the reference alignment database. The German regulations mandate that the reference line for a double-track section shall be halfway between the two tracks' centerlines. Note that this alignment does not represent a physical track, just a geometric reference for surveying and kilometration purposes. More rules exist to handle the situations where two different railway lines join or split.

If the infrastructure is changed at a later stage, then the published German reference alignment will usually NOT be changed. Let us illustrate this closer. Let the fictitious station "Xberg" be a short station with four tracks, connected to a single-track line in both directions. The published reference alignment is the centreline of track 1, which allows the highest speed through Xberg. Then Xberg track 2 is extended for 2000 meters to allow two freight trains to cross. In the process, the curvature of track 1 is improved, resulting in a slight sideways displacement of track 1 for a portion of its length. The already published reference alignment is kept unchanged. So now the track 1 centerline has a small lateral offset from the reference alignment, and track 2 has several meters.

The German regulations also require that the horizontal tangent direction along any path set through the network of reference alignments shall at all times be differentiable. In this way, there will be no 'dead zones' in the overall positioning system, even though the individual track's alignments are allowed to have abrupt (but small) changes in tangent direction. Such abrupt changes are due to the insufficiencies of surveying equipment and in the subsequent regression analysis which treats the network in small parts at a time.

Dealing with such reference alignment systems is known to and used by all railway administrations, either explicitly (as in the German case, publishing reference alignments in a database) or impiclitly (as in the French or Norwegian case).

Ifc representation of reference alignments.

For a given alignment, the absence of appointing another alignment as its reference alignment shall be understood as the alignment being its own reference alignment.

If an alignment shall rely on another alignment for network kilometration purposes, then it shall nest a referent of predefined type STATION with the attribute Pset_ReferentCommon.ReferenceAlignment containing a reference to the kilometration reference alignment. This STATION referent may have a PointByDistanceExpression which gives us a DistanceAlong that can be used by a viewer to find the exact locations in the XY plane where the alignment's associated reference alignment changes.

In a typical Ifc viewer or authoring tool, the user will move the CAD cursor around inside a model (schematic or geometrical, 2D or 3D). The cursor position will be used to pick up the closest alignment. The application will check the alignment's STATION referents and locate the closest preceding occurence of the optional attribute Pset_ReferentCommon.ReferenceAlignment. Then the application will "shoot" from the CAD cursor's position onto the referenced alignment. It will then produce a transient STATION measurement using the currently user-selected LRMType and LRMName and print on the computer screen the resulting text string so the user can "see where he is".

image

image

The nitty-gritty process of producing an orderly referent name

:construction: [TODO] :construction:

czapplitec commented 2 years ago

Thanks for this very informative work. If I understand correctly, if a STATION S is placed by DistanceAlong on Alignment A, and the Pset_ReferentCommon.ReferenceAlignment is R, then its Pset_Stationing.Station should be defined based on R. Am I right? My questions are:

clfey commented 2 years ago

Good questions, Chi. I am not sure how this best done.

ReferenceAlignment shall not be a relation, since relations are not LinearEvents. The referents fit beautifully, I think, because they can be both locally placed and linearly placed. So you can express the reference alignment system even if you don't (yet) know the actual geometry of the alignments involved - this is quite powerful. For instance saying that "after crossing Windsor avenue, the Baker street will be your reference alignment for kilometration".

ReferenceAlignment cannot be an attribute of IfcAlignment either, because it is a refernce with a location that must be stored.

It could also be possible to declare an array as part of IfcAlignment, each one with a DistanceAlong value and the id of a (new) reference alignment from that DistanceALong an onwards. But this would force us to require linear placement.

==>So nested IfcReferents are the best solution that I can think of - they can have linear placement, local placement or no placement.

As you might have grasped already, the standard "where-is-the-object", what I call a "compound LRM expression", as used in France, Germany and Norway "shoots" from the object in question onto the reference alignment "R" and expresses a "Line kilometer" = "Reference alignment longitudinal measurement", as measured in R. But it also "shoots" onto the object's own alignment, ignores the DistanceAlong, but grabs the LateralOffset and the VerticalOffset values and presents them along with the "reference alignment kilometer" measure.

Let us assume that we are speaking about a signal "Sig" inside an IFC model (file). The signal "Sig" might have a Pset where it can store a reference to its "own alignment (*)" ("A" in your example), explaining to reading tools to which alignment the signal "belongs". Then alignment "A" nests a referent which has the Pset attribute "ReferenceAlignment" pointing to "R" from your example (for its entire length, i.e. no more occurrences of the ReferenceAlignment attribute in A). The reading tool does not need to know more than this to be able to produce its own "compound LRM expressions" as explained above, using projections onto R for the line kilometer and onto A for the lateral/vertical offsets.

What would be stored in the IFC file? I don't know!

*) The "own aligment" is usually a very close track, or the track for which a train movement is signalled, or the track for which a cantilever is intended for)

SergejMuhic commented 2 years ago

Couple of questions on Pset_ReferentCommon.ReferenceAlignment:

  1. Are we dealing with new requirements?
  2. Could you point me to the use case where such an exchange scenario is defined?
  3. Is this supposed to be part of AbRV?
  4. Any stakeholders or software vendors requesting the exchange of this information?
  5. What is the datatype of Pset_ReferentCommon.ReferenceAlignment?
clfey commented 2 years ago
  1. ReferenceAlignmentis a new, proposed, attribute to the established property set Pset_ReferentCommon

  2. See all the text above. Legacy railway data are often stored in text form or in an archaic, proprietary database format, with attributes such as: ObjectName, ObjectGUID, ObjectType, ObjectParameterSet, OwnTrackToWhichTheOjectBelongs, LateralOffsetFromTheOwnTrack, VerticalOffsetFromTheOwnTrack, ReferenceTrackInThisArea, LongitudinalPositionMeasuredAlongTheReferenceTrack

  3. What is AbRV?

  4. Software vendor Railcomplete is requesting an representation of the ReferenceAlignment information. The purpose is to enable conversion of legacy track data (and all sorts of alignment objects) into a standardised IFC Rail format. Of course, each point object could be exported with a specific Pset attribute which holds a reference to the correct ReferenceAlignment, but this would not enable us to compute ANY STATION in the network based on the alignments as received in an IFC Rail exchange file. We need referents nested by the alignments to pinpoint the exact DistanceAlong where the ReferenceAlignment changes.

  5. It is an IfcrelNest to an IfcAlignment. If that relnest needs a standardised name, then "ReferenceAlignment" could be it?