Something must be wrong with your mysql installation or the .ini settings.
Just tested a geospatial index on my old mac (10.6.8 / MySQL 5.2).
That configuration is similar to yours and I tested the big geodata dump
(9 million records).
I did this query:
SET @radius = 30;
SET @center = GeomFromText('POINT(51.51359 7.465425)');
SET @r = @radius/69.1;
SET @bbox = CONCAT('POLYGON((',
X(@center) - @r, ' ', Y(@center) - @r, ',',
X(@center) + @r, ' ', Y(@center) - @r, ',',
X(@center) + @r, ' ', Y(@center) + @r, ',',
X(@center) - @r, ' ', Y(@center) + @r, ',',
X(@center) - @r, ' ', Y(@center) - @r, '))'
);
SELECT geonameid, SQRT(POW( ABS( X(point) - X(@center)), 2) + POW( ABS(Y(point) - Y(@center)), 2 ))*69.1
AS distance
FROM TABLENAME AS root
WHERE Intersects( point, GeomFromText(@bbox) )
AND SQRT(POW( ABS( X(point) - X(@center)), 2) + POW( ABS(Y(point) - Y(@center)), 2 )) < @r
ORDER BY distance;
It took just 0.0336 sec.
I do use the above query e.g. for comparisons between tables where the table where just the lat/lng values for @center come from has a plain INDEX from city_latitude/city_longitude and the 9-12 Mio. table from geonames.org has a geospatial index.
And I just wanted to add that when anybody inserts the big data in a table it might be more performant to add the index after INSERT.
If not it will take longer for each row you add ...
[but that's not important]
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
There is a spatial function called
ST_Union
that would help, but you may not have the right version of MySQL to use it.Here's a way that you can manipulate the WKT directly using
GROUP_CONCAT
. It will allow you to create aMULTILINESTRING
. Alternatively, you could create aGEOMETRYCOLLECTION
the same way.Note that you may run out of memory, so have a look at the
group_concat_max_len
variable.I suppose an alternative to all this would be to view the table in QGIS directly:
Import MySQL Spatial vector layer in QGIS