Subscribe to this thread
Home - General / All posts - How to merge all lines that touch and are parallel
julmou29 post(s)
#06-Nov-23 23:20


How to merge all lines that touch and are parallel?


I've got a huge dataset with all the aerodromes/airport runways across Australia.

You can see a sample in the snapshot below. This sample consists of 4 lines. The whole dataset is like that, if two runways intersect, the line/runway is cut into two and I have two lines with the accurate dimension/length for both.

What I want is to recreate a dataset, where I have the entire length of the runway instead, and only one record per runway. So in the sample below, instead of having 4 lines, I want two lines, and the "dimension" attribute added up.

While I can easily do that manually for a small sample, the dataset contains 8191 records.

I want to find the most efficient/clever way to automate this.

  1. Spatially, the best description I could give is: where two lines touch, and are parallel to each other, then merge them. But I have no idea how I could to transpose this description into an SQL query.
  2. Based on the attributes, it could also be: where all attributes are equal, except "dimension" and "st_length(shape)", then merge the lines. Again, easy to do between two records, but how to do for the entire dataset?


7,449 post(s)
#07-Nov-23 11:17

No need for SQL. Sounds like the Transform pane's merge lines transform would do the trick. Merge using whatever attribute field is in common between the two runway lines. To form a single line with one branch from a line object with two or more branches, follow the merge lines transform with a normalize metric transform

julmou29 post(s)
#08-Nov-23 01:49

Thanks for the help. Indeed merge lines would do the trick. But I had another check and unfortunately the lines have no attribute in common.

Or said differently, the only attribute in common is the airport "name", but then all four runway segments have the same "name".

Is there a way I could create an attribute that only the two bits of runway I want to merge have in common? yves61 mentioned calculating the direction of the lines. I haven't found a Transform in Manifold to do that.


642 post(s)
#08-Nov-23 03:50

Could a computed geom field help? Create a field for geom (bearing)

In your example, you would have four records for Glen Innes ALA, with two lines each with the same bearing.

You could then follow Dimitri's workflow, and get the desired output.

Cool dataset by the way.


7,449 post(s)
#08-Nov-23 04:01

You could use expression transform to create a new field that is a text field that gives the bearing of each geom. Next, create a computed field (or another new field that is the result of an expression transform) which concatenates the bearing text with the name of the airport text, and then use that field for the merge.

For those who are interested in airport runways, the user manual has a step-by-step example showing how to extract airport runways from openstreetmap. OSM is a real beast of a data set but you can cut it down to whatever size you want by using a sequence of simple steps.

julmou29 post(s)
#14-Nov-23 06:08

Thanks so much for the help.

After creating a unique attribute in common, which combines the name of the airport + the bearing, and using that field for the merge, it works quite well.

However, I hadn't anticipated that in some airports, two different runways can run parallel to each other, thus having the same name and same bearing. They end up being merged into one line, although they are two different runways. See example below in attached image.

I think, one of the other conditions for two lines to merge is that they have to touch.

I haven't been able to successfully do a merge on the entire dataset, that would consider this spatial condition as well as the common attribute.



642 post(s)
#14-Nov-23 09:42

The dataset you have has runway names as well?

The centrelines at Parafield are for runways left and right.

So YMMB (Moorabbin) has 17L/35R and 17R/35L. If that field exists, you are nearly there.

julmou29 post(s)
#15-Nov-23 00:01

No it doesn't have runway names unfortunately.


642 post(s)
#15-Nov-23 04:45

Oh, frustrating.

Dimitri's touch count looks like the way forward then.


7,449 post(s)
#14-Nov-23 09:49

See this example. That teaches you how to add a "touch count" to each object. If the count is zero it touches no other objects. You can use the Select pane to select all other objects with a touch count greater than zero and then do the Merge transform, checking the box to use only the selection.

However... that approach won't work in cases where runways have more than one line associated with the same runway, for example, a short section of line incident at a right angle at the beginning or end of the "runway" which is a portion of taxiway that is considered part of the runway. I don't know if your data set has anything like that.

The key thing is that if there are two different runways, they should have different names. The usual nomenclature is to append an "R" or "L" for "right" or "left" to such parallel runways, for example runway 35L vs runway 35R. That helps avoid confusion when pilots are cleared to land on "runway 35 right" so they know based on what they see in front of them which one they are cleared to land on. Aviation uses English internationally so the R and L are used in all countries.

439 post(s)
#08-Nov-23 05:45

Julmou, I somehow used wrong naming, I should have said look for "bearing" instead of "direction".

You may find an example to calculate line "bearing" like here in the documentation/user manual:

Look on the page for

"Decompose Contour Lines into Segments"

"Create a Computed Azimuth Field"


688 post(s)
#08-Nov-23 08:56

Have a look at the attached map file for some inspiration. This approach assumes that the two airstrips have been splitted at the intersection in exactly two parts.

Attributes can be preserved.


julmou29 post(s)
#14-Nov-23 07:07

Thanks for the example.

I have been playing with your query.

One thing it does though, is that if I have a single standalone runway in my dataset, then it's not merged with anything and, as a result, disappears from the query results.

See your example below, where I added a separate single runway.

439 post(s)
#07-Nov-23 12:08

If needed, if there is no good common attribute, calculate the direction of the Lines. Where Lines touch and line directions are equal (within acceptable range) -> merge the lines.

10,094 post(s)
#08-Nov-23 06:09

A comment on the thread title and question: "all lines that touch and are parallel".

That has always been an empty set since Euclid. It's an axiom. (In Euclidean geometry.)

What is meant is, "all lines that touch and have exactly the same bearing".

As always, once you get the description of the problem right, in ordinary language, you are 90% of the way to an answer.

Before that, lost in space.

10,094 post(s)
#08-Nov-23 06:28

Having put the ordinary language right (in my opinion, might be wrong), the obvious approach becomes (in my opinion, might be wrong):

(1) Filter out bent lines. These can't be processed with the current assumptions.

(2) Assign bearing to all eligible lines. This could be exact, or use a tiny tolerance.

(3) Dissolve all lines on bearing. (So that all eligible lines having an equivalent bearing would become one object.)

(4) Normalize the result.

(5) Decompose.


7,449 post(s)
#08-Nov-23 07:40

You're right about the "parallel" bit, of course. But dissolving on bearing followed by normalization and decomposition will lose the individual attributes that the lines had before, such as the airport at which each line is located.

Knowing more about the attributes each line has would help. If it's a data set of airport runway line segments, one would expect (I know... it's a mistake to expect anything in a data set...) that in addition to the name of the airport there would be some sort of runway identifier that distinguishes the various runways from each other. Usually the name is some sort of concatenation of the runway bearings in each direction, like runway "90/270" or just the shortest direction from 0 to 180, like runway "90". If there are parallel runways on the same heading, as there are at many big airports around the world, they usually have postfixes like "90A" and "90B". So you could concatenate the airport name to the runway name to get a unique identifying field for the line objects associated with each runway.

You're also right about bent lines, since runways are generally thought of as straight.

But all the same, runways might well be represented by lines that are straight over their primary length but with right angle segment of about 100 meters at each end that represents the part of the taxiway at the beginning or end of the runway which legally is part of the runway. When planes are told by ground controllers to "hold short" of the runway on the taxiway, they have to stop before the multiple line demarcation drawn on the taxiway that's about 50 - 100 meters before the very long, straight, portion of the runway itself. I wouldn't be surprised if in a "runways" data set that short right-angled segment that is legally part of the runway is included as a line segment for that runway. There would also be a similar situation for short segments adjacent to the runway of any high speed taxiways connecting to the runway at locations between the beginning and end of the runway.

If attributes that uniquely identify each set of lines associated with a "runway" are available, then I think a merge based on attributes would deal with the above issues.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.