Re: [Jts-topo-suite-user] Builds a 3D geometry from a 2D geometry
Brought to you by:
dr_jts
From: Simon G. <si...@sp...> - 2013-03-27 23:20:50
|
Martin, > To add a bit more to this discussion, JTS already supports XY, XYZ, and XYZM CoordinateSequences (with XYZM only available via using a >PackedCoordinateSequence). There does need to be some work on making this a bit easier to use, however. I'm aware of the following: I have had a look at the trunk code and can't see how PackedCoordinateSequence supports XYZM. Can you give an example of how the OraReader could create an XYZM packed sequence for storing 4D SDO_GEOMETRY objects as you didn't do this when you revamped OraReader recently. > - add a method to determine the coordinate dimension of a Geometry That doesn't rely on examining the actual ordinate values. > - add a method to "slice" a Geometry to a lower coordinate dimension (using the same factory) or expand it to a higher dimension Agreed. > - various Readers and Writers need to be modified to respect coordinate dimensions. Probably answers my above question. > - there is no way to express XYM currently. I'm not sure this can be done in general without breaking API changes. But it could probably be >done with a custom CoordinateSequence implementation. This is an interesting issue. XYZM supposedly stores a packge sequence of ordinates, why can't XYM use the same mechanism since Coordinate does not have an M property? Perhaps then PackedCoordinateSequence should have a descriptor of what is in the XYZM (what about XYZMT?) similar to the Oracle SDO_GEOMETRY GTYPE? Oracle can store the LRS measure in the Z position by storing a descriptor that tells the programmer how the ordinates are organised eg sdo_gtype 3302 says the object has 3 ordinates the third of which is an LRS M and not a Z (3002 says 3 ordinates, third is Z). Currently the LRS position is ignored by OraReader - OraGeom.lrsDim() never used, but shouldn't be - and is not used by OraWriter. OraWriter has its own lrsDim() which does this: /** * Return LRS dimension as defined by SDO_GTYPE (either 3,4 or 0). * * @param geom * @return LRS dimension */ private int lrsDim(Geometry geom) { //TODO: implement measure support when available return 0; } In other words, nothing. > If anyone has any other ideas for how to make handling Geometrys of varying coordinate dimension easier, please bring them forward. Question. In both CoordinateSequence and PackedCoordinateSequence there is a dimension attribute which describes the coordinate dimension: public abstract class PackedCoordinateSequence implements CoordinateSequence { /** * The dimensions of the coordinates hold in the packed array */ protected int dimension; I can see why dimension is not a property Coordinate.java as it would add to memory overhead. (But what would one do to determine coordinate dimension when the object is a single point?) Given that the Geometry methods getDimension() are about topological dimension ie 0 points, 1 lines, 2 areas, perhaps these properties need renaming to coordinateDimension and getCoordDimension() methods exposed and used instead of examining the first coordinate records values. In addition, the PackageCoordinateSequence could have an lrsDim() inspector added to allow geometry objects and OraWriter.lrsDim() to inquire how the PackedCoordinateSequence is organised ie 1. Whether is is 2D, 3D etc 2. Whether it is measured and where is the measure; Thinking about this I can't see that the changes would be that radical or involve changes that invalidated existing code. But I don't know that much about JTS. regards Simon > > > On Tue, Mar 26, 2013 at 3:56 PM, Simon Greener <si...@sp...> wrote: >> Folks, >> >>> >>>> Le 25/03/2013 17:52, Martin Davis a écrit : >>>>> Sorry about the breaking change. I presume you are referring to the >>>>> change in rev 605, which changed CoordinateArraySequence to maintain a >>>>> true dimension size (2 or 3), rather than just hardcoding to 3? >>>> >>>> Yes, absolutely. I digged in the SVN history and found that. BTW, the >>>> code break has been the consequence of a incoherent use of dimension >>>> management, so don't worry too much about it ;-) BTW, I already fixed it :-) >>>> >>>> We've cheated, until now, to manage dimension on our side. We were >>>> instanciating only 3D geometries (well, except in the broken-but-fixed >>>> piece of code) and then played with Double.NaN, checking for its >>>> existence in the coordinates. >>> >>> Don't feel too bad - JTS has had basically the same approach for most of its life! It's only recently that dimension handling has emerged as >>>a design hotspot which needs to be addressed. >> >> In recent work with Martin on the Oracle input/output functions this reared its head. As I said to Martin then: >> >> The issue for me is that testing any coordinate value for NaN is fine for 99% of all cases but it is a guess. For example, I came across a >>situation with singlebeam soundings (think single transponder under a ship that pings a depth every x meters from leaving port to its return) >>at GeoScience Australia a few years ago. The singlebeam track is long/lat/depth, long/lat/depth, ... but occasionally at a long/lat they don't >>get a depth observation. But they don't throw the point away. It is kept in the sdo_ordinate_array (as it should). If you happened to test that >>ordinate for NaN (the representation of NULL in Java) then you could conclude the geometry is 2D (even though its SDO_GEOMETRY >>SDO_GTYPE attribute says its a 3D linestring) and return the wrong answer. >> >> It needs fixing, Martin knows this, but how to do so is what Martin is worrying about given the amount of source code dependent on JTS >>there is out there. >> >> -- Holder of "2011 Oracle Spatial Excellence Award for Education and Research." SpatialDB Advice and Design, Solutions Architecture and Programming, Oracle Database 10g Administrator Certified Associate; Oracle Database 10g SQL Certified Professional Oracle Spatial, SQL Server, PostGIS, MySQL, ArcSDE, Manifold GIS, FME, Radius Topology and Studio Specialist. 39 Cliff View Drive, Allens Rivulet, 7150, Tasmania, Australia. Website: www.spatialdbadvisor.com Email: si...@sp... Voice: +61 362 396397 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) GeoHash: r22em9r98wg NAC:W80CK 7SWP3 |