Thank you for your enquiry. We have checked the data you mentioned and found it to be correct. We have assumed your query is about the southbound off ramp to Uhlman Road (from 18.48 to 19.05km) as that is the only one in that area fitting your description.
Our ramp chainage convention is that regardless of driving direction, a ramp starts where it meets the through carriageway, IE at 18.48km at the exit point to the ramp and ends at a greater chainage, IE 19.05km at the intersection with Uhlman Road – even though it’s south of the start point.
In the 18/11/2020 dataset, NA49_3 (starting from TDIST 2.365) and U15_R (10.945) appear to be specifying points approximately every 50m however TDIST is increasing by 10m. Interestingly those roads also have TDIST as multiples of 5 (e.g. 2.365, 2.375, 2.385...etc) , rather than the usual 10. So I'm not sure whether the co-ordinates not right, or whether TDIST should be jumping by 50m (e.g. something like 2.35, 2.40, 2.45, 2.50...), or whether I'm misunderstanding that particular dataset. All other roads are fine.
The other thing I noticed is that the sorting order has changed to something slightly less helpful for a large dataset like that. It's now sorted by ROAD_SECTION_ID and TDIST_START and previously by ROAD_SECTION_ID and CARRIAGEWAY_CODE. Just wondering if that was by accident or by design. It just means that roads are interleaved in a way that is not topological and provides less value when reading them sequentially, e.g. U15_R, U15_B, U15_2, U15_A are interleaved.
The sorting caused me some grief. I have a script that loads a postgis database which assumes the previous sort order. I found I can resort to ye olde sort quite quickly with this shell script
error found in 10A_Q at about 18K
southbound off ramp chainages are increasing south instead of north
Hi Peter,
Thank you for your enquiry. We have checked the data you mentioned and found it to be correct. We have assumed your query is about the southbound off ramp to Uhlman Road (from 18.48 to 19.05km) as that is the only one in that area fitting your description.
Our ramp chainage convention is that regardless of driving direction, a ramp starts where it meets the through carriageway, IE at 18.48km at the exit point to the ramp and ends at a greater chainage, IE 19.05km at the intersection with Uhlman Road – even though it’s south of the start point.
Regards,
TMR Debbie
Permanent Reference Mark (ARMIS)
Is there any chance this marker could be added to this dataset?
Possible errors in NA49_3 and U15_R
In the 18/11/2020 dataset, NA49_3 (starting from TDIST 2.365) and U15_R (10.945) appear to be specifying points approximately every 50m however TDIST is increasing by 10m. Interestingly those roads also have TDIST as multiples of 5 (e.g. 2.365, 2.375, 2.385...etc) , rather than the usual 10. So I'm not sure whether the co-ordinates not right, or whether TDIST should be jumping by 50m (e.g. something like 2.35, 2.40, 2.45, 2.50...), or whether I'm misunderstanding that particular dataset. All other roads are fine.
The other thing I noticed is that the sorting order has changed to something slightly less helpful for a large dataset like that. It's now sorted by ROAD_SECTION_ID and TDIST_START and previously by ROAD_SECTION_ID and CARRIAGEWAY_CODE. Just wondering if that was by accident or by design. It just means that roads are interleaved in a way that is not topological and provides less value when reading them sequentially, e.g. U15_R, U15_B, U15_2, U15_A are interleaved.
The sorting caused me some grief. I have a script that loads a postgis database which assumes the previous sort order. I found I can resort to ye olde sort quite quickly with this shell script
file="Road location and traffic data.txt"
tail -n +2 "$file" |sort -o sort.txt -t ',' -k 1,1 -k 2,2 -k 3,3n
Typo in header
Hi, just noticed that "Latitude" has been misspelled as "LATTITUDE" in the Feb 2022 file.
Hi Chris.
Thanks for letting us know, the file has been updated.
Regards,
TMR Open Data Team