Hi Michael.
Thanks for discovering this problem, and submitting a patch. I haven't had
a chance to look at in detail yet, but will try to this week.
Martin
On Mon, Nov 4, 2013 at 1:23 PM, Michaël Michaud <[email protected]>wrote:
> Hi Martin,
>
> Any chance you consider this problem ?
>
> I just commited new plugins in OpenJUMP which clearly shows that
> points refering to the end of lines are always located at the start.
> OpenJUMP > Tools > Generate > Linear Referencing
> (version > r3780)
>
> Best regards,
>
> Michaël
> > Hi Martin,
> >
> > After much time spent to understand the rational behind LinearIterator
> and
> > LinearLocation, I get a solution. I'm not completely satisfied by the
> > design,
> > because it happens lately in the process, is based on a naive if/else
> > solution,
> > and has to be duplicated in two classes...but at least, it seems to pass
> > all the
> > unit tests.
> >
> >
> > First the test case which makes the current version fail :
> > AbstractIndexedLineTest :
> > public void testOffsetEndPoint()
> > {
> > runOffsetTest("LINESTRING (0 0, 13 13, 20 20)", "POINT(20 20)",
> > 0.0, "POINT (20 20)");
> > runOffsetTest("LINESTRING (0 0, 10 0, 20 0)", "POINT(20 0)", 1.0,
> > "POINT (20 1)");
> > runOffsetTest("LINESTRING (0 0, 20 0)", "POINT(10 0)", 1.0, "POINT
> > (10 1)"); // point on last segment
> > runOffsetTest("MULTILINESTRING ((0 0, 10 0), (10 0, 20 0))",
> > "POINT(10 0)", -1.0, "POINT (10 -1)");
> > runOffsetTest("MULTILINESTRING ((0 0, 10 0), (10 0, 20 0))",
> > "POINT(20 0)", 1.0, "POINT (20 1)");
> > }
> >
> > Now the fix for LengthIndexedLine
> > public Coordinate extractPoint(double index, double offsetDistance)
> > {
> > LinearLocation loc = LengthLocationMap.getLocation(linearGeom,
> index);
> > LineSegment segment = loc.getSegment(linearGeom);
> > if (loc.isEndpoint(linearGeom)) {
> > return segment.pointAlongOffset(1.0, offsetDistance);
> > } else {
> > return segment.pointAlongOffset(loc.getSegmentFraction(),
> > offsetDistance);
> > }
> > }
> >
> > And the same for LocationIndexedLine
> > public Coordinate extractPoint(LinearLocation index, double
> offsetDistance)
> > {
> > LineSegment segment = index.getSegment(linearGeom);
> > if (index.isEndpoint(linearGeom)) {
> > return segment.pointAlongOffset(1.0, offsetDistance);
> > } else {
> > return segment.pointAlongOffset(index.getSegmentFraction(),
> > offsetDistance);
> > }
> > }
> >
> > Hope that helps,
> >
> > Michaël
> >
> >> Hi Martin,
> >>
> >> I found a small problem in linear referencing package (JTS 1.13).
> >>
> >> If I extract a point at distance 100 on LINESTRING(0 0, 100 0)
> >> - I get 100, 0 with extractPoint(100) : test in testbuilder
> >> - I get 0, 0 with extractPoint(100, 0) : test through OpenJUMP
> >>
> >> The result is not the same with the single parameter method
> >> and the two parameters method.
> >>
> >> I think the problem comes from LengthLocationMap#getLocationForward
> >> It computes the following LinearLocation (which seems OK so far)
> >> getSegmentIndex = 1 (virtual second segment)
> >> getSegmentFraction = 0.0 (first point)
> >>
> >> but in this particular case, LinearLocation#getSegment() returns
> >> segment n-1 and not segment n (probably needed to be able to compute
> >> offset).
> >> To be consistent , returned LinearLocation should probably have
> >> segmentIndex = 0
> >> segmentFraction = 1.0
> >>
> >> Not sure if the problem is in LengthLocationMap#getLocationForward
> itself
> >> or in LinearIterator#isEndOfLine() which is used by the former and
> returns
> >> false if (componentIndex >= numLines)
> >> or maybe I missed the point,
> >>
> >> thanks for your help
> >>
> >> Michaël
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> October Webinars: Code for Performance
> >> Free Intel webinars can help you accelerate application performance.
> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from
> >> the latest Intel processors and coprocessors. See abstracts and
> register >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Jts-topo-suite-user mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Jts-topo-suite-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
