(I'm posting this to the JTS list, since it's really a JTS question)
This seems to be geodetic month for JTS! Answers to your questions: 1. JTS is not "coordinate system-aware", and does not use the SRID in its calculations. So you can set it or not, and it won't make any difference 2. JTS assumes that the coordinates of geometries are located in an infinite Cartesian (flat) 2D coordinate system. All quantities (length, area, distance, angle, etc) are relative in this coordinate system. So since you are providing your input in decimal degrees, those are the units that the buffer distance must be expressed in. Of course, this doesn't work all that well for large distances in a geodetic (ellipsoidal) coordinate system - the computed geoemtry will be only an approximation to the true shape. What people often do is project their geodetic data to a local planar projection, compute there, and then reproject. There's been a bit of a thread about this on the JTS list recently. (No code, though - which would be nice to have). As you point out, Oracle appears to do the "right thing" in this case - kudos to them. They seem to seamlessly blend geodetic and planar data handling, which is certainly nice to have. Maybe one day JTS will support this - but it's complex to implement. Davis Ford wrote: > Hi, > > If I have an Oracle table with an SDO_GEOMETRY column, and I insert a > point into it - example: > > MDSYS.SDO_GEOMETRY(2001, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, > 1), MDSYS.SDO_ORDINATE_ARRAY(-82.90755596903085, 42.40409951227155)) > > Then I can use the SDO_GEOM.SDO_BUFFER function to get a buffer around > it (and specify the units in miles) -> > > // 1.5 miles, 0.5 tolerance > SELECT SDO_GEOM.SDO_BUFFER(a.geometry, 1.5, 0.5, 'unit=mile') geom > FROM MY_TABLE a.id = 1; > > Simple enough, but how do I do the same thing in JTS? If I try the following: > > Geometry point = new WKTReader().read("POINT(-82.90755596903085 > 42.40409951227155)"); > > // question1: should I set the SRID? Oracle uses 8307 for WGS:84, but > JTS seems to ignore SRID in calculations, is this true? > > // question2: what units does buffer take? I make the assumption of > meters, but this is wrong > > // try converting 1.5 miles to meters > double meters = 2414.016 > Geomtry buffer = point.buffer(meters); > > This is very wrong since it gives me polygon with coordinates that are > outside -180/180, -90/90. Do I assume then that buffer takes radians > I guess? > > I'm just trying to accomplish the same thing I can do in Oracle above with JTS. > > Thanks in advance, > Davis > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 _______________________________________________ jts-devel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jts-devel |
You can't do this just with the JTS API - you need to use a projection
library. JHLabs has one, as does GeoTools. You'll have to check the documentation for those libraries for how to use them. (Unfortunately using those libraries tends to be kind of complicated. It seems to me it would be nice to have at least a cookbook for doing this kind of thing, or even better a simple API in JTS to support geodetic computation. This could be done fairly quickly if there was sponsorship to do it ($$$) - otherwise it will go in the queue as a nice idea...) Davis Ford wrote: > Martin / Larry - thanks for the info. > > Any tips / pointers / clues on how to do the projection / > re-projection using the JTS API? > > Regards, > Davis > > On Wed, Feb 11, 2009 at 11:43 AM, Martin Davis <[hidden email]> wrote: > >> (I'm posting this to the JTS list, since it's really a JTS question) >> >> This seems to be geodetic month for JTS! >> >> Answers to your questions: >> >> 1. JTS is not "coordinate system-aware", and does not use the SRID in its >> calculations. So you can set it or not, and it won't make any difference >> >> 2. JTS assumes that the coordinates of geometries are located in an infinite >> Cartesian (flat) 2D coordinate system. All quantities (length, area, >> distance, angle, etc) are relative in this coordinate system. So since you >> are providing your input in decimal degrees, those are the units that the >> buffer distance must be expressed in. Of course, this doesn't work all that >> well for large distances in a geodetic (ellipsoidal) coordinate system - the >> computed geoemtry will be only an approximation to the true shape. >> >> What people often do is project their geodetic data to a local planar >> projection, compute there, and then reproject. There's been a bit of a >> thread about this on the JTS list recently. (No code, though - which would >> be nice to have). >> >> As you point out, Oracle appears to do the "right thing" in this case - >> kudos to them. They seem to seamlessly blend geodetic and planar data >> handling, which is certainly nice to have. Maybe one day JTS will support >> this - but it's complex to implement. >> >> Davis Ford wrote: >> >>> Hi, >>> >>> If I have an Oracle table with an SDO_GEOMETRY column, and I insert a >>> point into it - example: >>> >>> MDSYS.SDO_GEOMETRY(2001, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, >>> 1), MDSYS.SDO_ORDINATE_ARRAY(-82.90755596903085, 42.40409951227155)) >>> >>> Then I can use the SDO_GEOM.SDO_BUFFER function to get a buffer around >>> it (and specify the units in miles) -> >>> >>> // 1.5 miles, 0.5 tolerance >>> SELECT SDO_GEOM.SDO_BUFFER(a.geometry, 1.5, 0.5, 'unit=mile') geom >>> FROM MY_TABLE a.id = 1; >>> >>> Simple enough, but how do I do the same thing in JTS? If I try the >>> following: >>> >>> Geometry point = new WKTReader().read("POINT(-82.90755596903085 >>> 42.40409951227155)"); >>> >>> // question1: should I set the SRID? Oracle uses 8307 for WGS:84, but >>> JTS seems to ignore SRID in calculations, is this true? >>> >>> // question2: what units does buffer take? I make the assumption of >>> meters, but this is wrong >>> >>> // try converting 1.5 miles to meters >>> double meters = 2414.016 >>> Geomtry buffer = point.buffer(meters); >>> >>> This is very wrong since it gives me polygon with coordinates that are >>> outside -180/180, -90/90. Do I assume then that buffer takes radians >>> I guess? >>> >>> I'm just trying to accomplish the same thing I can do in Oracle above with >>> JTS. >>> >>> Thanks in advance, >>> Davis >>> >>> >>> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> _______________________________________________ >> jump-users mailing list >> [hidden email] >> http://lists.refractions.net/mailman/listinfo/jump-users >> >> > > > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 _______________________________________________ jts-devel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jts-devel |
In reply to this post by Martin Davis
well..
- Geotools: http://geotools.codehaus.org/Module+Matrix and - degree: http://wald.intevation.org/plugins/scmsvn/viewcvs.php/docs/documentation/crs/?root=deegree (I hope that is the correct link) have projection functions I know this as we, from OpenJUMP, ponder with an implementation of those - probably the latter one. Meanwhile we have only this plugin-workaround: http://www.openjump.org/wiki/show/Working+with+Projections but to write back to oracle is probably a difficult part too? stefan Davis Ford wrote: > Martin / Larry - thanks for the info. > > Any tips / pointers / clues on how to do the projection / > re-projection using the JTS API? > > Regards, > Davis > > On Wed, Feb 11, 2009 at 11:43 AM, Martin Davis <[hidden email]> wrote: >> (I'm posting this to the JTS list, since it's really a JTS question) >> >> This seems to be geodetic month for JTS! >> >> Answers to your questions: >> >> 1. JTS is not "coordinate system-aware", and does not use the SRID in its >> calculations. So you can set it or not, and it won't make any difference >> >> 2. JTS assumes that the coordinates of geometries are located in an infinite >> Cartesian (flat) 2D coordinate system. All quantities (length, area, >> distance, angle, etc) are relative in this coordinate system. So since you >> are providing your input in decimal degrees, those are the units that the >> buffer distance must be expressed in. Of course, this doesn't work all that >> well for large distances in a geodetic (ellipsoidal) coordinate system - the >> computed geoemtry will be only an approximation to the true shape. >> >> What people often do is project their geodetic data to a local planar >> projection, compute there, and then reproject. There's been a bit of a >> thread about this on the JTS list recently. (No code, though - which would >> be nice to have). >> >> As you point out, Oracle appears to do the "right thing" in this case - >> kudos to them. They seem to seamlessly blend geodetic and planar data >> handling, which is certainly nice to have. Maybe one day JTS will support >> this - but it's complex to implement. >> >> Davis Ford wrote: >>> Hi, >>> >>> If I have an Oracle table with an SDO_GEOMETRY column, and I insert a >>> point into it - example: >>> >>> MDSYS.SDO_GEOMETRY(2001, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, >>> 1), MDSYS.SDO_ORDINATE_ARRAY(-82.90755596903085, 42.40409951227155)) >>> >>> Then I can use the SDO_GEOM.SDO_BUFFER function to get a buffer around >>> it (and specify the units in miles) -> >>> >>> // 1.5 miles, 0.5 tolerance >>> SELECT SDO_GEOM.SDO_BUFFER(a.geometry, 1.5, 0.5, 'unit=mile') geom >>> FROM MY_TABLE a.id = 1; >>> >>> Simple enough, but how do I do the same thing in JTS? If I try the >>> following: >>> >>> Geometry point = new WKTReader().read("POINT(-82.90755596903085 >>> 42.40409951227155)"); >>> >>> // question1: should I set the SRID? Oracle uses 8307 for WGS:84, but >>> JTS seems to ignore SRID in calculations, is this true? >>> >>> // question2: what units does buffer take? I make the assumption of >>> meters, but this is wrong >>> >>> // try converting 1.5 miles to meters >>> double meters = 2414.016 >>> Geomtry buffer = point.buffer(meters); >>> >>> This is very wrong since it gives me polygon with coordinates that are >>> outside -180/180, -90/90. Do I assume then that buffer takes radians >>> I guess? >>> >>> I'm just trying to accomplish the same thing I can do in Oracle above with >>> JTS. >>> >>> Thanks in advance, >>> Davis >>> >>> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> _______________________________________________ >> jump-users mailing list >> [hidden email] >> http://lists.refractions.net/mailman/listinfo/jump-users >> > > > jts-devel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jts-devel |
Hi all,
there is c library http://trac.osgeo.org/proj/, which has jni extension for java, but this is under GPL. See http://trac.osgeo.org/proj/browser/trunk/proj/jniwrap/README I don't use this java connector. I was using the Python extension of Proj.4 and it was easy to use and configure. There is new project on OSGEO with focus on projection library "unification". (At least on metadata level) See http://wiki.osgeo.org/wiki/MetaCRS Regards, Zdenek On Wed, Feb 11, 2009 at 5:39 PM, Stefan Steiniger <[hidden email]> wrote: > well.. > > - Geotools: http://geotools.codehaus.org/Module+Matrix > > and > > - degree: > http://wald.intevation.org/plugins/scmsvn/viewcvs.php/docs/documentation/crs/?root=deegree > (I hope that is the correct link) > have projection functions > > I know this as we, from OpenJUMP, ponder with an implementation of those - > probably the latter one. Meanwhile we have only this plugin-workaround: > http://www.openjump.org/wiki/show/Working+with+Projections > > but to write back to oracle is probably a difficult part too? > > stefan > > Davis Ford wrote: >> >> Martin / Larry - thanks for the info. >> >> Any tips / pointers / clues on how to do the projection / >> re-projection using the JTS API? >> >> Regards, >> Davis >> >> On Wed, Feb 11, 2009 at 11:43 AM, Martin Davis <[hidden email]> >> wrote: >>> >>> (I'm posting this to the JTS list, since it's really a JTS question) >>> >>> This seems to be geodetic month for JTS! >>> >>> Answers to your questions: >>> >>> 1. JTS is not "coordinate system-aware", and does not use the SRID in its >>> calculations. So you can set it or not, and it won't make any difference >>> >>> 2. JTS assumes that the coordinates of geometries are located in an >>> infinite >>> Cartesian (flat) 2D coordinate system. All quantities (length, area, >>> distance, angle, etc) are relative in this coordinate system. So since >>> you >>> are providing your input in decimal degrees, those are the units that the >>> buffer distance must be expressed in. Of course, this doesn't work all >>> that >>> well for large distances in a geodetic (ellipsoidal) coordinate system - >>> the >>> computed geoemtry will be only an approximation to the true shape. >>> >>> What people often do is project their geodetic data to a local planar >>> projection, compute there, and then reproject. There's been a bit of a >>> thread about this on the JTS list recently. (No code, though - which >>> would >>> be nice to have). >>> >>> As you point out, Oracle appears to do the "right thing" in this case - >>> kudos to them. They seem to seamlessly blend geodetic and planar data >>> handling, which is certainly nice to have. Maybe one day JTS will >>> support >>> this - but it's complex to implement. >>> >>> Davis Ford wrote: >>>> >>>> Hi, >>>> >>>> If I have an Oracle table with an SDO_GEOMETRY column, and I insert a >>>> point into it - example: >>>> >>>> MDSYS.SDO_GEOMETRY(2001, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, >>>> 1), MDSYS.SDO_ORDINATE_ARRAY(-82.90755596903085, 42.40409951227155)) >>>> >>>> Then I can use the SDO_GEOM.SDO_BUFFER function to get a buffer around >>>> it (and specify the units in miles) -> >>>> >>>> // 1.5 miles, 0.5 tolerance >>>> SELECT SDO_GEOM.SDO_BUFFER(a.geometry, 1.5, 0.5, 'unit=mile') geom >>>> FROM MY_TABLE a.id = 1; >>>> >>>> Simple enough, but how do I do the same thing in JTS? If I try the >>>> following: >>>> >>>> Geometry point = new WKTReader().read("POINT(-82.90755596903085 >>>> 42.40409951227155)"); >>>> >>>> // question1: should I set the SRID? Oracle uses 8307 for WGS:84, but >>>> JTS seems to ignore SRID in calculations, is this true? >>>> >>>> // question2: what units does buffer take? I make the assumption of >>>> meters, but this is wrong >>>> >>>> // try converting 1.5 miles to meters >>>> double meters = 2414.016 >>>> Geomtry buffer = point.buffer(meters); >>>> >>>> This is very wrong since it gives me polygon with coordinates that are >>>> outside -180/180, -90/90. Do I assume then that buffer takes radians >>>> I guess? >>>> >>>> I'm just trying to accomplish the same thing I can do in Oracle above >>>> with >>>> JTS. >>>> >>>> Thanks in advance, >>>> Davis >>>> >>>> >>> -- >>> Martin Davis >>> Senior Technical Architect >>> Refractions Research, Inc. >>> (250) 383-3022 >>> >>> _______________________________________________ >>> jump-users mailing list >>> [hidden email] >>> http://lists.refractions.net/mailman/listinfo/jump-users >>> >> >> >> > _______________________________________________ > jts-devel mailing list > [hidden email] > http://lists.refractions.net/mailman/listinfo/jts-devel > jts-devel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jts-devel |
Regarding Geotools, there is also the current work by Martin
Desruisseaux on 'Geotidy', a refactored version of some of the Geotools 2.x code. Well worth a look... http://geotidy.geomatys.fr/javadocs/ Michael _______________________________________________ jts-devel mailing list [hidden email] http://lists.refractions.net/mailman/listinfo/jts-devel |
Free forum by Nabble | Edit this page |