L_M_To and L_M_from in network-rail-gis-main

[Ajay Gupta]

Hi all,

I am exploring the network-rail-gis-main available on https://github.com/openraildata/network-rail-gis

A sample VectorLinks in the network-model looks like:

OBJECTID...................................5381.0

ASSETID.....................................9001027934

L_LINK_ID...................................17748

L_SYSTEM..................................M

L_VAL..........................................N

L_QUALITY.................................1.0

ELR.............................................LTN1

TRID............................................3701

TRCODE.....................................37

L_M_FROM................................3.1252

L_M_TO......................................3.1322

VERSION_NU.............................1.04

VERSION_DA.............................20160208130700.123

SOURCE....................................TRACK VIEW

EDIT_STATU..............................AWAITING FEEDBACK

IDENTIFIED................................NONE

TRACK_STAT.............................IN USE

LAST_EDITE..............................AIS

LAST_EDI_1..............................2016/01/20 00:00:00.000

CHECKED_BY...........................AIS

CHECKED_DA...........................2016/01/20 00:00:00.000

VALIDATED_..............................NaN

VALIDATE_1...............................NaN

EDIT_NOTES.............................NaN

PROIRITY_A..............................NaN

SHAPE_Leng.............................63.541325

geometry......LINESTRING (538296.6097999997 184083.660399999...

L_M_FROM and L_M_TO variables appear to be the mileages but I am unsure on how to interpret their format.

I understand it cannot be miles.chains as 1 mile has 80 chains so the decimal part should be an integer from 0 to 80.

My guess is that it could be miles.yards e.g., 3.1252 translates to 03M 1252y as used in GeoFurlong recently.

Would anyone here be able to shed more light on this?

Thanks,

Ajay Gupta

[Evelyn Snow]

Hi Ajay,

I'm not sure why you're guessing anything! I've measured one of the links myself, and the length in metres appears
correct for the given length in miles and yards.

Not at all surprising, miles and chains are too coarse, decimal fractions of miles would be nonsensical, and miles
and yards are what we use in the hazard directory.

Evelyn

[Ajay Gupta]

Hi Evelyn,

Thank you for measuring and confirming.
I had not used this data set before therefore I was not sure.

Cheers,
Ajay Gupta

> --
> You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/Zk4ern91T8nBbY76%40evelyn.moe.

[Alan Morrison]

Ajay,

The L_M_FROM and L_M_TO columns are indeed in the form of miles.yards, so 3 miles 44 yards would be stored as 3.0044. These can be considered as forming the reported length of the ELR, whereas the SHAPE_Leng column is the geometrically measured distance along the virtual centreline of the ELR, and is recorded in metres. It is very common to have a disparity between the reported (when converted to metric) and measured lengths, sometimes very significantly. Further details on this topic are noted at https://www.geofurlong.com/help/main/.

Alan

[Ajay Gupta]

Many thanks, Alan! This is helpful and clarifies a few observations that I made too.

[Guido Eco]

Please check the "L_SYSTEM" value as "M" values are in miles and chains, "K" are in kilometres and metres. From memory the Heathrow Express and HS1 are metric.

G