Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jts-dev] Parallel Offset!
Damm,

After doing all this I realised that iterating over the points of a linestring and simply looking to see if the point is in the second line as multipoint, one looses the ordering so it is possible to remove a point that is not part of the second line (perhaps a crossing poiint).

Simon

On Thu, 11 Oct 2018 10:39:39 +1100, Simon (SPDBA) Greener <simon@xxxxxxxxxxxx> wrote:

Martin,

I converted the first geometry to a multiPoint and also the second,

I then looped over the coordinates of the first mutipoint testing each against the multiPoint of the line to be removed using:

boolean equals = p.relate(multiPoint2,"0FFFFF0F2");

And it now works as needed.

Here is the method:

private static Geometry _pointsRemover(Geometry _line1,
 Geometry _line2,
 int _precision)
{
 PrecisionModel pm = new PrecisionModel(Tools.getPrecisionScale(_precision));
 GeometryFactory gf = new GeometryFactory(pm, _line1.getSRID());

Collection newCoords = new ArrayList();
 Coordinate[] coordinates = null;

 Geometry line1 = GeometryPrecisionReducer.reduce(_line1,pm);
 Geometry line2 = GeometryPrecisionReducer.reduce(_line2,pm);
int numPoints = line1.getNumPoints();
 coordinates = line1.getCoordinates();
Coordinate c = null;
 Point p = null;
 if (coordinates.length > 1) {
 Geometry multiPoint2 = _convertToMultiPoint((LineString)line2);
 for (int i=0;i<numPoints;i++) {
 c = coordinates[i];
 p = gf.createPoint(c);
 boolean equals = p.relate(multiPoint2,"0FFFFF0F2");
 if ( ! equals ) {
 newCoords.add(c);
 }
 }
 }
 Geometry rLine = null;
 if ( newCoords != null && newCoords.size() > 2 ) {
 Coordinate[] ca = (Coordinate[])newCoords.toArray(new Coordinate[0]);
 rLine = new LineString(gf.getCoordinateSequenceFactory().create(ca),gf);
 rLine.setSRID(_line1.getSRID());
 }
return rLine;
 }


Simon

Yes, it's frustrating how hard it is to get a decent offset curve algorithm.  I've seen some Chinese CAD papers about it too - they look complicated!

Hopefully there will be some time in the future to review the other implementations and perhaps use them as motivation for a JTS implementation.

I think I did extract the GeoTools code at one point and make it usable standalone.  It wasn't too hard to do I think.

On Wed, Oct 10, 2018 at 4:08 PM Simon (SPDBA) Greener <simon@xxxxxxxxxxxx> wrote:
I consider line offset to be a vital algorithm (esp for the dynamic segmentation side of linear referencing) but your comments confirmed what I thought: it is hard! I've seen some papers by Chinese scholars implemented in CAD packages (not open source).....

I'm trying the multipoint approach but it is not returning what I want at the moment.

S

On Thu, 11 Oct 2018 09:47:07 +1100, Martin Davis <mtnclimb@xxxxxxxxx> wrote:

Ha!  There is *nothing* "simple" about parallel offset curves!   Despite it seeming simple on the surface...  it's an implementation challenge to handle all or even most reasonable inputs.

The closest thing in JTS is the Single-Sided Buffer functionality [1].  But this returns a polygon.  It would be necessary to do something like the line removal approach to turn this into a proper offset curve.

I think GeoTools has some code for this [2] - if you dare to go there.

PostGIS also has this [3].  Probably needs to get added to JTS sometime...  



[3] https://postgis.net/docs/ST_OffsetCurve.html

On Wed, Oct 10, 2018 at 3:33 PM Simon (SPDBA) Greener <simon@xxxxxxxxxxxx> wrote:


On a related topic, how does one execute a simple parallel offset linestring in JTS?




--
Regards
Simon
--------------------------------------------------------------------------------------------------------
Spatial Advice & Solutions Architecture
Database Spatial Stored Procedure Designer
Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE FME
Awarded "2011 Oracle Spatial Excellence Award for Education and Research"
A: 39 Cliff View Drive, Allens Rivulet, 7150, Tas, Aust
W: www.spdba.com.au
E: simon@xxxxxxxxxxxx
V: +61 362 396 397
M: +61 418 396 391
GITC Supplier: T1005
Skype: sggreener
Long: 147.20515 (147° 12' 18" E)
Lat: -43.01530 (43° 00' 55" S)
GeoHash: r22em9r98wg
NAC:W80CK 7SWP3



--
Regards
Simon
--------------------------------------------------------------------------------------------------------
Spatial Advice & Solutions Architecture
Database Spatial Stored Procedure Designer
Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE FME
Awarded "2011 Oracle Spatial Excellence Award for Education and Research"
A: 39 Cliff View Drive, Allens Rivulet, 7150, Tas, Aust
W: www.spdba.com.au
E: simon@xxxxxxxxxxxx
V: +61 362 396 397
M: +61 418 396 391
GITC Supplier: T1005
Skype: sggreener
Long: 147.20515 (147° 12' 18" E)
Lat: -43.01530 (43° 00' 55" S)
GeoHash: r22em9r98wg
NAC:W80CK 7SWP3



--
Regards
Simon
--------------------------------------------------------------------------------------------------------
Spatial Advice & Solutions Architecture
Database Spatial Stored Procedure Designer
Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE FME
Awarded "2011 Oracle Spatial Excellence Award for Education and Research"
A: 39 Cliff View Drive, Allens Rivulet, 7150, Tas, Aust
W: www.spdba.com.au
E: simon@xxxxxxxxxxxx
V: +61 362 396 397
M: +61 418 396 391
GITC Supplier: T1005
Skype: sggreener
Long: 147.20515 (147° 12' 18" E)
Lat: -43.01530 (43° 00' 55" S)
GeoHash: r22em9r98wg
NAC:W80CK 7SWP3

Back to the top