After analysing your MultiLineString, I can say that st_linemerge cannot merge it, not because it's not properly ordered, but because it's impossible to be ordered and merged into a single LineString containing all its 12 parts.
Therefore, st_linemerge works as expected, as stated in st_LineMerge, and, because merging cannot be done, it returns the original MultiLineString. (see st_linemerge_original_multilinestring.sql)
Now, the explanation:
1) Your MultiLineString contains 12 parts (LineStrings):
2) To understand better how to reorder the parts (or if the parts can be reordered) I've choosed to work "visually", in QGIS.
Here's a portion of the result, after I've finished to open the PostGIS table containing the MultiLineString:
It's easy to see that this MultiLineString' shape, cannot pass the st_linemerge geometry validation tests. Here's the shapefile, if you want to see it in QIS.
3) I've gone further with splitting the MultiLineString in LineStrings,
and after some makeover, i've obtained a more clearer picture of the twelve individual LineStrings:
This is the shapefile, also, for you to analyse it in QIS.
To proove that st_linemerge works well, when you make a correct choice of the parts, please, include in the command the following LineStrings: 1,2,4,5,7,8,10 and 12.
Here's the sql query: st_linemerge_only_eight_linestrings.sql
Running this, you'll get a single, long, merged LineString.
Of course, there are a lot of combinations, but I see no way to reorder the actual twelve parts, to fit together into a valid LineString.
Best Answer
if your linestring are not crossing each other on the mid points you can simply use
intersects
method from shapelyif the do intersect you can get first the mid points from the linestrings using shapely's method
interpolate
then you use
intersects
, note that these methods require that your points are exactly the mid points of your lines, if you're not sure about it you can use a buffer with a tolerance distance ( also available in shapely )