Question

Issue with Linear referencing

  • 31 October 2016
  • 5 replies
  • 4 views
pschout
Badge +1

Hi All,

i have a problem with linear referencing in FME! I use a filegeodatabase (see attached zip file) that contains a event tabel with a subset of traffic jams, a route key (route) and measures (hm) are included in the table. In the database there is also a roadnetwork featureclass that contain measures. The common route field in the roadnetwork is "ROUTE_CH". In the fme workbench a tried to do a linear ferencing with those event tabel and route feature class but the result is not what i expect. The tabel contain 250 features but the output in the FME workbench has only 94 features as output (the "ArcGis" method results in an output of 250 features), output feature class from the workbench is "Trafficjams2016_FME"..

Of course i can use ArcGis for linear referencing but i prefer FME because i wil made a complete automatic proces that wil daily update and publish the trafficjams on Dutch highways.

So what is going wrong in my workbench? I expect in the FME output feature class all the items from the table!

(the attached zip file contains the fgdb en de FME workbench)

Thanks for your help!

Peter

1 Attachment

5 replies

fmelizard
Rank
Userlevel 4
Badge +13

Don't know the complete reason yet but I took a peek at FME 2017 seems to end up creating a pile of warnings in the log coming out of the Snipper. So understanding those is the first thing.

The second thing is that the Snipper is creating 185 points and 65 lines. And so those points will not be able to be written into the same table in file geodatabase as lines.

I suspect this is not expected, and so understanding the Snippers complaints as noted in the log will be key.

itay
Rank
Badge +16

Hoi @poppendamme, alles goed?

You are feeding the snipper aggregates that make him choke......so by adding a deaggregator you get the 250 results you desire.

The original lines are partially composed of aggregates (multi-lines), succes!

nwbfiles.png

itay
Rank
Badge +16

Hoi @poppendamme, alles goed?

You are feeding the snipper aggregates that make him choke......so by adding a deaggregator you get the 250 results you desire.

The original lines are partially composed of aggregates (multi-lines), succes!

nwbfiles.png

 

As @daleatsafe noted, lots of warnings resulting in my case too, beware!
pschout
Badge +1

Hi @itay,

Thank you so far! The dedeaggrgator split the lines in parts with the same route key, that results in a lot of warnings (because every Traffic Jam feature can be joined to more than one line part). I think I resolve this problem with the use of a set of transformers. At first I extract the measure from the network shape (use MeasureExtractor/Listexploder), then I aggregate the line parts by Route key and line part number and calculate the minimum and maximum measure for each line part, for this I used the Statisticscalculator. This result can be joined to the deaggregated lines. Then an InlineQurier is used to join de TrafficJams and the lines (joined on route key and the TrafficJam hm position is equal or between the minimum and maximum measures of the lines). This results in a attributable with all the traffic jams but also the attribute line_part_number is including in the output. A featuremerger join the TrafficJams and route lines (joined on route key and line_part_number so that I’m sure that the trafficjams are joined to the right route line). The Snipper makes the point features based on the Hm position of the traffic jam table (start and ending point = Hm).

Almost all the traffic jams will be referenced correct to the network (some features don’t have correct or have missing Hm values, they will be ignored) and I have less warnings! I think there is an easier way to do this job but for now it works!

Peter

workbench-lrs.png

M
Badge +2

I've attached a variation on your first workspace which might be a little more straightforward than your revised version. It's more or less the same as your first version. but I've reversed the inputs on the FeatureMerger so that you join the events to the LRS routes. As you mentioned, since there are multiple segments for each route you get duplicate joins. But we can thin these out by testing the event measure against the start/end measure of each segment. I hope this helps.

test-lrs-v01-2016.fmwt

Reply


Community Stats

28,731
Posts
109,530
Replies
36,565
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.