What is returned by ST_Line_Locate_Point, when the input geometry is a MultiLineString?

[Jim]

I have a MulitLineString that defines a road (a partial dual carriageway road).

When I apply ST_Line_Locate_Point against that MultiLineString using a point at a known distance from the beginning of the road, I get a totally incorrect answer.

Specifically, the point is known to be .10 from the beginning of the road and the answer I get is .4525.

Is this simply the result of incorrect usage of ST_Line_Locate_Point e.g, using that function against a MultiLineString?

Is there a solution to accurately find the 'location' of the point on the MultiLineString?

Regards,
Jim

[Brad Hards]

On 13/10/12 13:21, Jim wrote:
> When I apply ST_Line_Locate_Point against that MultiLineString using a
> point at a known distance from the beginning of the road, I get a
> totally incorrect answer.
>
> Specifically, the point is known to be .10 from the beginning of the
> road and the answer I get is .4525.

Can you show me a really simple command line example of this problem?

I tried it with a trivial case, and it looks like it works for me:
spatialite> SELECT Line_Locate_Point(GeomFromText("LINESTRING(0 0, 10
6)"), GeomFromText("POINT(5 3)"));
0.5
spatialite> SELECT Line_Locate_Point(GeomFromText("MULTILINESTRING((0 0,
10 6))"), GeomFromText("POINT(5 3)"));
0.5

I certainly believe that you have an issue. It will be easier for us to
investigate if you can demonstrate that issue.

Brad

[a.fu...@lqt.it]

On Fri, 12 Oct 2012 19:21:26 -0700 (PDT), Jim wrote:
> I have a MulitLineString that defines a road (a partial dual
> carriageway road).
>
> When I apply ST_Line_Locate_Point against that MultiLineString using
> a
> point at a known distance from the beginning of the road, I get a
> totally incorrect answer.
>

Hi Jim,

using some MultiLinestring and LineLocatePoint could easily lead to
really odd and unexpected results.

the total length for a MultiLinestring simply is the sum of individual
Linestrins.
so we have a first problem: how are individual Linestrings ordered
within the collection ? this obviously has a strong influence in
determining "where" e.g. the 13% or 86% percent position would assumed
to be.

but we surely have a second problem: which is the orientation for
each individual Linestring ?
A->B isn't at all the same of B->A when we are using percent positions.

and finally we have a third problem: how are individual Linestrings
spatially arranged ? are they consecutive ? or are they parallel ?
(you are using dual carriageway roads, so I guess they are parallel)

please consider the attached figure: there are several "odd conditions"
where a very slight shift in positioning the reference point could
have a dramatic effect on percent positioning.

upper example:
--------------
here we have two consecutive Linestrings, and the reference point P1
could intercept both A-B or B-C quite indifferently, because it falls
very near to B.
then it fully depends on individual Linestring's orientation and item
ordering; assuming B->A and C->B (B-A coming first), you can get a
percent position of 0.0001% or 99.999% simply by applying a minimal
shift to the reference point P1 :-D

lower example:
--------------
here we have to parallel Linestrings, and the reference point P2
falls exactly in the middle ... once again, a very minimal shift
applied to the reference point P2 will have dramatic effects.
and item ordering / orientation will lead to messy chaos.

conclusion:
-----------
using LineLocatePoint *and* MultiLinestrings should be avoided
as far as possible, because it depends on too much variable
factors very difficult to be effectively controlled :-D

bye Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

[Jim]

Brad and Sandro,

I was afraid that the issues presented were the cause of the problem especially after the problems I had determining the one-way length of a road which is more an issue with the OSM data than with Spatialite.

I 'solved' the latter problem rather crudely by simply cutting in half the length of any road segment that had oneway_fromto=1 and oneway_toform=0 which I observed empirically seemed to be the case for any dual-carriageway segment.  I actually got some  surprisingly accurate one way lengths for highways (I'm only interested in highways).  I 'validated' the results using several navigation systems and Google Maps and Earth.

Now I am trying to use the data with input GPS data to approximate the mile-mark I am near as I travel down a highway.  I get close with a straight-line distance except in those areas where the roads wind around a lot (like where I live in the US Rocky Mountains).

So I will continue to try to find another obscure, rough approximation, WAG which will serve my purposes.

Regards,
Jim