Calculating a distance matrix

I agree with @redgeographics - the neighbour finder is the way to go here

matrix.fmwt

Oh sh*t, I didn't think about NeighborFinder combined with lists. That makes life indeed a lot simpler. Thanks

YESSS, this really helps. It even allows me to expand to large data sets. Many thanks @egomm

The tricky bit really is knowing what attributes to expose, I've had some success using python to create a schema to write out dynamically where the ID's aren't known at run time

FYI, here is another approach with cross join: distance-matrix.fmwt (FME 2019.0.1)

Using a neighborfinder in this case seems a waste of processor time.

It's just a Cartesian product. ( as @rhcb and @takashi both remark)

So a unconditional merger would do. Attributecreator to calc the distance between points.(basic calculus)

(zero distance etc., yes discard, its the diagonal)To fascilitate your matrix view , id the objects with a counter and use that as mergkey)

Hi Takashi,

A python solution just to add to the list :-)

distance_matrix_python.fmwt

This answer helps me but I have a question, can you help me with this code to get distance matrix when my input are id,x,y, length and I don't need to calculate distance, just write length to the right place based on ID.

In principle the basic approach outlined by @takashi and @gio is what is generally followed by using Cartesians/Cross Joins. To reword the question, it is asking "What is the Isochrone Chart of these N Nodes if each Node connects to each of the (N-1) others?". There are lots of examples online on how to do this for Isochrones using Network/Graphing techniques, but in SQL it is just:

SELECT A.NodeID AS OriginNode, B.NodeID AS DestinationNode, (B.XCoord-A.XCoord)*(B.XCoord-A.XCoord)+(B.YCoord-A.YCoord)*(B.YCoord-A.YCoord) AS DistanceSqrd FROM Nodes A CROSS JOIN Nodes B WHERE A.NodeID<>B.NodeID

Feeding this as the SQL into InlineQuerier would return 12 x 11 rows of all OriginNodeID vs (DestinationNodeID + DistanceSquared) combinations (Not 12x12 because the "WHERE A.NodeID<>B.NodeID" cancels out a match of the Node to itself. If instead want the self-matches left in the result, then delete the WHERE clause component).

Whilst the table is not formatted as a "12 rows x 12 columns" generally in data handling you don't want to do this. Trying to run downstream analyses or queries on tables that have been transposed/pivoted like this are usually that much harder to carry out since you will have a high, and variable number of columns (N columns). It is generally instead better to keep the separate pairs of Nodes as just extra rows of data of Node A vs Node B combinations and then you only ever have 2 Node ID columns/fields to deal with in the resultant table (Node A ID vs Node B ID), no matter how many Nodes N there are. But there may be legitimate reasons for formatting them into row x column combinations.

As SQLite used by InlineQuerier has no native Sqrt function, instead the returned table can have "DistanceSquared" field returned converted to Distance by using the FME functions exposed in AttributeCreator to take the square root of the value returned by InlineQuerier.