RE: [jts-devel] Does Oracle support a "MultiPolygon which containsa MultiPolygon".
Indeed, thanks Simon for the investigation, Mapinfo products call those multipolygon but you seems totaly right, There are actually polygon with multiple inner shells. And after investigation, it seems that jts-io actually load it well. I've been testing the geometry in/out oracle and in/out jts, displaying the wkt result at each step and the geometry is correct at each step. So thanks a lot guys, and Martin sorry for the worries, the problem must be somewhere else. Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 4:35 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] Does Oracle support a "MultiPolygon which containsa MultiPolygon". Good stuff, Simon. So Jonathan, what behaviour are you actually seeing? Is an exception being thrown, or does the output not match what you'd expect to see? Simon Greener wrote: > Martin et al, > > My first reaction to Jonathan's post and your question was to say that, no, > Oracle (as an OGC SFS and SQL/MM compliant product) does not support a > "MultiPolygon which > contains a MultiPolygon". I thought, though, that I should examine the actual > geometry in detail so I converted Jonathan's WKT geometry below back into an > Oracle SDO_GEOMETRY and examined its SDO_ELEM_INFO array. This is the result: > > SDO_ELEM_INFO(1,1003,1,1743,2003,1,2041,2003,1,2071,1003,1,2779,2003,1) > > This is: a simple polygon outer shell (1,1003,1) followed by 4 inner shells > (2003): > > 1743,2003,1, > 2041,2003,1, > 2071,1003,1, > 2779,2003,1 > > Note that there is only 1 outer shell. Even if there were many outer shells > with each having many inner shells, the result would still be a single > multipolygon. > > My test harness is after my salutation at the very end of this email. > > regards > Simon > >> Date: Wed, 11 Feb 2009 11:24:23 -0800 >> From: Martin Davis >> Subject: Re: [jts-devel] jts-io mutipolygon >> To: JTS Topology Suite Development >> Message-ID: <499325e7.90...@refractions.net> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Under the OGC SFS spec there is no such thing as a "MultiPolygon which >> contains a MultiPolygon". Does Oracle actually support this? >> >> If this is truly the case, I think you're seeing the workaround - JTS >> maps the geometry to something which fits in its model. (Although this >> situation was probably never designed for - I'm actually surprised that >> it works). >> >> Houde, Jonathan wrote: >> >>> Hi all, >>> >>> I’ve been using jts-io to read geometries from oracle database. >>> >>> I have a certain case where the geometry is a MultiPolygon which >>> contains MultiPolygon, >>> >>> It seems that jts-io is not excepting this and doesn’t load it correctly. >>> >>> It read the inner Multipolygon as single Polygon >>> >>> You can see the geometry at the corresponding wkt geometry at the >>> bottom of my mail. >>> >>> Any fix planned for that or possible workaround? >>> >>> Thanks, >>> >>> Jonathan >>> >>> SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 >>> 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, >>> -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 >>> > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
[jts-devel] > Radius Topology is that successfull (in terms of sales)
Stefan, > you know - it is kind of nice if JTS or something (Oracle, Mapinfo) can > read such data and other things. But it gives me a headache since people > start exploiting these options and standards don't make sense then > anymore. And one wonders why people do the efforts to setup standards > and why others teach what is correct. I think my post shows that Oracle complies with the standards and that the posted geometry was not a MultiPolygon within a MultiPolygon (you can't construct such a beast in Oracle). > Sales departments probably > consider this as feature while I would call it a bug ;) "Embrace and Extend", my friend, "Embrace and Extend"! (I am part of that cynical group of practitioners who believe vendors get on standards bodies not to make them practical or work but to make them dumb so thy can market their more useful extensions to the basic standard.) > PS: ...of course there was a reason why Radius Topology is that > successfull (in terms of sales) Can you explain why you say this? regards Simon -- 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...@spatialdbadvisor.com Voice: +613 9016 3910 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) NAC:W80CK 7SWP3 ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
Re: [jts-devel] Does Oracle support a "MultiPolygon which contains a MultiPolygon".
Good stuff, Simon. So Jonathan, what behaviour are you actually seeing? Is an exception being thrown, or does the output not match what you'd expect to see? Simon Greener wrote: Martin et al, My first reaction to Jonathan's post and your question was to say that, no, Oracle (as an OGC SFS and SQL/MM compliant product) does not support a "MultiPolygon which contains a MultiPolygon". I thought, though, that I should examine the actual geometry in detail so I converted Jonathan's WKT geometry below back into an Oracle SDO_GEOMETRY and examined its SDO_ELEM_INFO array. This is the result: SDO_ELEM_INFO(1,1003,1,1743,2003,1,2041,2003,1,2071,1003,1,2779,2003,1) This is: a simple polygon outer shell (1,1003,1) followed by 4 inner shells (2003): 1743,2003,1, 2041,2003,1, 2071,1003,1, 2779,2003,1 Note that there is only 1 outer shell. Even if there were many outer shells with each having many inner shells, the result would still be a single multipolygon. My test harness is after my salutation at the very end of this email. regards Simon Date: Wed, 11 Feb 2009 11:24:23 -0800 From: Martin Davis Subject: Re: [jts-devel] jts-io mutipolygon To: JTS Topology Suite Development Message-ID: <499325e7.90...@refractions.net> Content-Type: text/plain; charset=windows-1252; format=flowed Under the OGC SFS spec there is no such thing as a "MultiPolygon which contains a MultiPolygon". Does Oracle actually support this? If this is truly the case, I think you're seeing the workaround - JTS maps the geometry to something which fits in its model. (Although this situation was probably never designed for - I'm actually surprised that it works). Houde, Jonathan wrote: Hi all, I’ve been using jts-io to read geometries from oracle database. I have a certain case where the geometry is a MultiPolygon which contains MultiPolygon, It seems that jts-io is not excepting this and doesn’t load it correctly. It read the inner Multipolygon as single Polygon You can see the geometry at the corresponding wkt geometry at the bottom of my mail. Any fix planned for that or possible workaround? Thanks, Jonathan SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
Re: [jts-devel] Re: [jump-users] Question on JTS Geometry#buffer( )
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 jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
[jts-devel] Does Oracle support a "MultiPolygon which contains a MultiPolygon".
Martin et al, My first reaction to Jonathan's post and your question was to say that, no, Oracle (as an OGC SFS and SQL/MM compliant product) does not support a "MultiPolygon which contains a MultiPolygon". I thought, though, that I should examine the actual geometry in detail so I converted Jonathan's WKT geometry below back into an Oracle SDO_GEOMETRY and examined its SDO_ELEM_INFO array. This is the result: SDO_ELEM_INFO(1,1003,1,1743,2003,1,2041,2003,1,2071,1003,1,2779,2003,1) This is: a simple polygon outer shell (1,1003,1) followed by 4 inner shells (2003): 1743,2003,1, 2041,2003,1, 2071,1003,1, 2779,2003,1 Note that there is only 1 outer shell. Even if there were many outer shells with each having many inner shells, the result would still be a single multipolygon. My test harness is after my salutation at the very end of this email. regards Simon > Date: Wed, 11 Feb 2009 11:24:23 -0800 > From: Martin Davis > Subject: Re: [jts-devel] jts-io mutipolygon > To: JTS Topology Suite Development > Message-ID: <499325e7.90...@refractions.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Under the OGC SFS spec there is no such thing as a "MultiPolygon which > contains a MultiPolygon". Does Oracle actually support this? > > If this is truly the case, I think you're seeing the workaround - JTS > maps the geometry to something which fits in its model. (Although this > situation was probably never designed for - I'm actually surprised that > it works). > > Houde, Jonathan wrote: >> >> Hi all, >> >> I’ve been using jts-io to read geometries from oracle database. >> >> I have a certain case where the geometry is a MultiPolygon which >> contains MultiPolygon, >> >> It seems that jts-io is not excepting this and doesn’t load it correctly. >> >> It read the inner Multipolygon as single Polygon >> >> You can see the geometry at the corresponding wkt geometry at the >> bottom of my mail. >> >> Any fix planned for that or possible workaround? >> >> Thanks, >> >> Jonathan >> >> SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 >> 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, >> -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 -- 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...@spatialdbadvisor.com Voice: +613 9016 3910 Mobile: +61 418 396391 Skype: sggreener Longitude: 147.20515 (147° 12' 18" E) Latitude: -43.01530 (43° 00' 55" S) NAC:W80CK 7SWP3 create table crap ( geom sdo_geometry ); declare v_clob clob; begin DBMS_LOB.CREATETEMPORARY ( v_clob, true ); DBMS_LOB.APPEND(v_clob,CAST( 'MULTIPOLYGON (((-71.33959188 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 46.79944101, -71.29670184 46.79947
[jts-devel] Re: jts-io mutipolygon
you know - it is kind of nice if JTS or something (Oracle, Mapinfo) can read such data and other things. But it gives me a headache since people start exploiting these options and standards don't make sense then anymore. And one wonders why people do the efforts to setup standards and why others teach what is correct. Sales departments probably consider this as feature while I would call it a bug ;) stefan PS: ...of course there was a reason why Radius Topology is that successfull (in terms of sales) Message: 1 Date: Wed, 11 Feb 2009 12:05:23 -0800 From: Martin Davis Subject: Re: [jts-devel] jts-io mutipolygon To: JTS Topology Suite Development Message-ID: <49932f83.2080...@refractions.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Probably not too complicated. The real issue for me is building up a dev environment for that codebase - I don't have one running right now (and obviously it needs an Oracle instance - which isn't a showstopper, just more time). If you have some funding to cover this it could happen much more quickly... Please email me directly if this is of interest. Martin ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
Re: [jts-devel] Re: [jump-users] Question on JTS Geometry#buffer( )
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 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
>> 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
>>> jump-us...@lists.jump-project.org
>>> http://lists.refractions.net/mailman/listinfo/jump-users
>>>
>>
>>
>>
> ___
> jts-devel mailing list
> jts-devel@lists.jump-project.org
> http://lists.refractions.net/mailman/listinfo/jts-devel
>
___
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
Re: [jts-devel] jts-io mutipolygon
Probably not too complicated. The real issue for me is building up a dev environment for that codebase - I don't have one running right now (and obviously it needs an Oracle instance - which isn't a showstopper, just more time). If you have some funding to cover this it could happen much more quickly... Please email me directly if this is of interest. Martin Houde, Jonathan wrote: Would it be a minor code change? That's kind of a show stopper for our current project. Thanks, Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 2:44 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] jts-io mutipolygon Yes, that makes good sense. Houde, Jonathan wrote: Thanks Martin for the quick answer, Yes, both product we are using in that project (oracle spatial and mapinfo product) are correctly managing those polygon Which are typical city boundaries provided by data provider. JTS seems to load the coordinate list of sub polygon as if it was a single one, so that result in weird geometry. Since oracle support it and OGC doesn't define it (which is a little weird since jts-io is in the middle of both), A good solution could be to flatten the inner multipolygon to multiple polygons. For example my polygon which look like this: MULTIPOLYGON (((pointList)(PointList))((pointList)(PointList))) Would be interpreted as: MULTIPOLYGON Polygon Polygon Polygon Polygon Instead of oracle representation MULTIPOLYGON MULTIPOLYGON Polygon Polygon MULTIPOLYGON Polygon Polygon Do you think it would make sense? Thanks, Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 2:24 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] jts-io mutipolygon Under the OGC SFS spec there is no such thing as a "MultiPolygon which contains a MultiPolygon". Does Oracle actually support this? If this is truly the case, I think you're seeing the workaround - JTS maps the geometry to something which fits in its model. (Although this situation was probably never designed for - I'm actually surprised that it works). Houde, Jonathan wrote: Hi all, I've been using jts-io to read geometries from oracle database. I have a certain case where the geometry is a MultiPolygon which contains MultiPolygon, It seems that jts-io is not excepting this and doesn't load it correctly. It read the inner Multipolygon as single Polygon You can see the geometry at the corresponding wkt geometry at the bottom of my mail. Any fix planned for that or possible workaround? Thanks, Jonathan SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 46.79944101, -71.29670184 46.79947998, -71.29514484
RE: [jts-devel] jts-io mutipolygon
Would it be a minor code change? That's kind of a show stopper for our current project. Thanks, Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 2:44 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] jts-io mutipolygon Yes, that makes good sense. Houde, Jonathan wrote: > Thanks Martin for the quick answer, > Yes, both product we are using in that project (oracle spatial and mapinfo > product) are correctly managing those polygon > Which are typical city boundaries provided by data provider. > > JTS seems to load the coordinate list of sub polygon as if it was a single > one, so that result in weird geometry. > Since oracle support it and OGC doesn't define it (which is a little weird > since jts-io is in the middle of both), > A good solution could be to flatten the inner multipolygon to multiple > polygons. > > For example my polygon which look like this: > MULTIPOLYGON (((pointList)(PointList))((pointList)(PointList))) > Would be interpreted as: > MULTIPOLYGON > Polygon > Polygon > Polygon > Polygon > > Instead of oracle representation > MULTIPOLYGON > MULTIPOLYGON > Polygon > Polygon > MULTIPOLYGON > Polygon > Polygon > > Do you think it would make sense? > Thanks, > Jonathan > > -Original Message- > From: jts-devel-boun...@lists.jump-project.org > [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis > Sent: February 11, 2009 2:24 PM > To: JTS Topology Suite Development > Subject: Re: [jts-devel] jts-io mutipolygon > > Under the OGC SFS spec there is no such thing as a "MultiPolygon which > contains a MultiPolygon". Does Oracle actually support this? > > If this is truly the case, I think you're seeing the workaround - JTS > maps the geometry to something which fits in its model. (Although this > situation was probably never designed for - I'm actually surprised that > it works). > > > > Houde, Jonathan wrote: > >> Hi all, >> >> I've been using jts-io to read geometries from oracle database. >> >> I have a certain case where the geometry is a MultiPolygon which >> contains MultiPolygon, >> >> It seems that jts-io is not excepting this and doesn't load it correctly. >> >> It read the inner Multipolygon as single Polygon >> >> You can see the geometry at the corresponding wkt geometry at the >> bottom of my mail. >> >> Any fix planned for that or possible workaround? >> >> Thanks, >> >> Jonathan >> >> SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 >> 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, >> -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 >> 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, >> -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 >> 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, >> -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 >> 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 >> 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, >> -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 >> 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, >> -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 >> 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, >> -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 >> 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, >> -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 >> 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, >> -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 >> 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, >> -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 >> 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, >> -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 >> 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, >> -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 >> 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, >> -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 >> 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, >> -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 >> 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, >> -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 >> 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, >> -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 >> 46.79944101, -71.29670184 46.79947998, -71.29514484 46.79955, >> -71.29308096 46.79794602, -71.29086588 46.79930601, -71.29037808 >> 46.79964396, -71.28884088 46.79904996, -71.28909 46.79869104, >> -71.289432 46.
Re: [jts-devel] jts-io mutipolygon
Yes, that makes good sense. Houde, Jonathan wrote: Thanks Martin for the quick answer, Yes, both product we are using in that project (oracle spatial and mapinfo product) are correctly managing those polygon Which are typical city boundaries provided by data provider. JTS seems to load the coordinate list of sub polygon as if it was a single one, so that result in weird geometry. Since oracle support it and OGC doesn't define it (which is a little weird since jts-io is in the middle of both), A good solution could be to flatten the inner multipolygon to multiple polygons. For example my polygon which look like this: MULTIPOLYGON (((pointList)(PointList))((pointList)(PointList))) Would be interpreted as: MULTIPOLYGON Polygon Polygon Polygon Polygon Instead of oracle representation MULTIPOLYGON MULTIPOLYGON Polygon Polygon MULTIPOLYGON Polygon Polygon Do you think it would make sense? Thanks, Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 2:24 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] jts-io mutipolygon Under the OGC SFS spec there is no such thing as a "MultiPolygon which contains a MultiPolygon". Does Oracle actually support this? If this is truly the case, I think you're seeing the workaround - JTS maps the geometry to something which fits in its model. (Although this situation was probably never designed for - I'm actually surprised that it works). Houde, Jonathan wrote: Hi all, I've been using jts-io to read geometries from oracle database. I have a certain case where the geometry is a MultiPolygon which contains MultiPolygon, It seems that jts-io is not excepting this and doesn't load it correctly. It read the inner Multipolygon as single Polygon You can see the geometry at the corresponding wkt geometry at the bottom of my mail. Any fix planned for that or possible workaround? Thanks, Jonathan SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 46.79944101, -71.29670184 46.79947998, -71.29514484 46.79955, -71.29308096 46.79794602, -71.29086588 46.79930601, -71.29037808 46.79964396, -71.28884088 46.79904996, -71.28909 46.79869104, -71.289432 46.79797104, -71.28956304 46.79744004, -71.28958896 46.79699004, -71.28958896 46.79654103, -71.28953784 46.796112, -71.28814896 46.79647497, -71.28803808 46.79639604, -71.28792288 46.79633502, -71.28769284 46.79638803, -71.28747612 46.79644599, -71.28604512 46.79676198, -71.28557496 46.79742798, -71.28549 46.79740602, -71.28499212 46.79727804, -71.28476316 46.797201, -71.28412884 46.79831997, -71.28360396 46.79897103, -71.28347004 46.79910999, -71.27986104 46.79923104, -71.27493984 46.79961903, -71.27479692 46.79946999, -71.273295 46.79827497, -71.26933716 46.797615, -71.26868196 46.79684496, -71.26807716 46.796259
RE: [jts-devel] jts-io mutipolygon
Thanks Martin for the quick answer, Yes, both product we are using in that project (oracle spatial and mapinfo product) are correctly managing those polygon Which are typical city boundaries provided by data provider. JTS seems to load the coordinate list of sub polygon as if it was a single one, so that result in weird geometry. Since oracle support it and OGC doesn't define it (which is a little weird since jts-io is in the middle of both), A good solution could be to flatten the inner multipolygon to multiple polygons. For example my polygon which look like this: MULTIPOLYGON (((pointList)(PointList))((pointList)(PointList))) Would be interpreted as: MULTIPOLYGON Polygon Polygon Polygon Polygon Instead of oracle representation MULTIPOLYGON MULTIPOLYGON Polygon Polygon MULTIPOLYGON Polygon Polygon Do you think it would make sense? Thanks, Jonathan -Original Message- From: jts-devel-boun...@lists.jump-project.org [mailto:jts-devel-boun...@lists.jump-project.org] On Behalf Of Martin Davis Sent: February 11, 2009 2:24 PM To: JTS Topology Suite Development Subject: Re: [jts-devel] jts-io mutipolygon Under the OGC SFS spec there is no such thing as a "MultiPolygon which contains a MultiPolygon". Does Oracle actually support this? If this is truly the case, I think you're seeing the workaround - JTS maps the geometry to something which fits in its model. (Although this situation was probably never designed for - I'm actually surprised that it works). Houde, Jonathan wrote: > > Hi all, > > I've been using jts-io to read geometries from oracle database. > > I have a certain case where the geometry is a MultiPolygon which > contains MultiPolygon, > > It seems that jts-io is not excepting this and doesn't load it correctly. > > It read the inner Multipolygon as single Polygon > > You can see the geometry at the corresponding wkt geometry at the > bottom of my mail. > > Any fix planned for that or possible workaround? > > Thanks, > > Jonathan > > SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 > 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, > -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 > 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, > -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 > 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, > -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 > 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 > 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, > -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 > 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, > -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 > 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, > -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 > 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, > -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 > 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, > -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 > 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, > -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 > 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, > -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 > 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, > -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 > 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, > -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 > 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, > -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 > 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, > -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 > 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, > -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 > 46.79944101, -71.29670184 46.79947998, -71.29514484 46.79955, > -71.29308096 46.79794602, -71.29086588 46.79930601, -71.29037808 > 46.79964396, -71.28884088 46.79904996, -71.28909 46.79869104, > -71.289432 46.79797104, -71.28956304 46.79744004, -71.28958896 > 46.79699004, -71.28958896 46.79654103, -71.28953784 46.796112, > -71.28814896 46.79647497, -71.28803808 46.79639604, -71.28792288 > 46.79633502, -71.28769284 46.79638803, -71.28747612 46.79644599, > -71.28604512 46.79676198, -71.28557496 46.79742798, -71.28549 > 46.79740602, -71.28499212 46.79727804, -71.28476316 46.797201, > -71.28412884 46.79831997, -71.28360396 46.79897103, -71.28347004 > 46.79910999, -71.27986104 46.79923104, -71.27493984 46.79961903, > -71.27479692 46.79946999, -71.273295 46.79827497, -71.26933
Re: [jts-devel] jts-io mutipolygon
Under the OGC SFS spec there is no such thing as a "MultiPolygon which contains a MultiPolygon". Does Oracle actually support this? If this is truly the case, I think you're seeing the workaround - JTS maps the geometry to something which fits in its model. (Although this situation was probably never designed for - I'm actually surprised that it works). Houde, Jonathan wrote: Hi all, I’ve been using jts-io to read geometries from oracle database. I have a certain case where the geometry is a MultiPolygon which contains MultiPolygon, It seems that jts-io is not excepting this and doesn’t load it correctly. It read the inner Multipolygon as single Polygon You can see the geometry at the corresponding wkt geometry at the bottom of my mail. Any fix planned for that or possible workaround? Thanks, Jonathan SDO_UTIL.TO_WKTGEOMETRY(GEOLOC) MULTIPOLYGON (((-71.33959188 46.81182897, -71.33935608 46.81166004, -71.33922 46.81155897, -71.33990904 46.811142, -71.34054516 46.81077003, -71.34058512 46.81073304, -71.340696 46.81068102, -71.34135804 46.81030401, -71.34409296 46.80851202, -71.34414192 46.80847998, -71.34545592 46.80764199, -71.343018 46.80610002, -71.34094512 46.80466497, -71.34071184 46.804464, -71.34021612 46.80437697, -71.340561 46.804158, -71.340885 46.803951, -71.34116508 46.803753, -71.34076692 46.80349497, -71.33945904 46.802592, -71.33939784 46.80254304, -71.33729688 46.80118296, -71.33686092 46.80076896, -71.33577984 46.80012303, -71.33559084 46.79998398, -71.33625216 46.79952597, -71.33724684 46.79883603, -71.33749416 46.79865801, -71.33794488 46.79830098, -71.33819688 46.79814996, -71.33790996 46.79795097, -71.33463108 46.795716, -71.33407812 46.79536698, -71.33373792 46.795131, -71.333622 46.79505504, -71.33354892 46.79501004, -71.5884 46.79488899, -71.33295996 46.794663, -71.33289192 46.79461296, -71.332632 46.79441901, -71.33231916 46.79428203, -71.33225004 46.79420697, -71.33213304 46.79413803, -71.33148396 46.79369901, -71.33063112 46.79428302, -71.33045004 46.79444799, -71.329779 46.79475498, -71.32923288 46.79450001, -71.328843 46.79409402, -71.32458996 46.79113698, -71.32326588 46.79012601, -71.31896316 46.79295903, -71.31807504 46.7937, -71.31714192 46.79440398, -71.31676392 46.79468604, -71.31672684 46.79470098, -71.31666888 46.79473896, -71.31675996 46.79489304, -71.31726288 46.79562096, -71.31776112 46.79612604, -71.31794796 46.79631801, -71.31829212 46.79659503, -71.31825396 46.79660304, -71.316342 46.79725401, -71.31629592 46.79726004, -71.31624804 46.79726598, -71.31537216 46.79782596, -71.31445488 46.798074, -71.31286404 46.79795403, -71.31171492 46.79800101, -71.31133008 46.79801397, -71.31109212 46.79802198, -71.31061404 46.79803899, -71.30965896 46.79807301, -71.30778984 46.79812404, -71.30221596 46.79880804, -71.30202192 46.79883297, -71.29750392 46.79941302, -71.29716804 46.79944101, -71.29670184 46.79947998, -71.29514484 46.79955, -71.29308096 46.79794602, -71.29086588 46.79930601, -71.29037808 46.79964396, -71.28884088 46.79904996, -71.28909 46.79869104, -71.289432 46.79797104, -71.28956304 46.79744004, -71.28958896 46.79699004, -71.28958896 46.79654103, -71.28953784 46.796112, -71.28814896 46.79647497, -71.28803808 46.79639604, -71.28792288 46.79633502, -71.28769284 46.79638803, -71.28747612 46.79644599, -71.28604512 46.79676198, -71.28557496 46.79742798, -71.28549 46.79740602, -71.28499212 46.79727804, -71.28476316 46.797201, -71.28412884 46.79831997, -71.28360396 46.79897103, -71.28347004 46.79910999, -71.27986104 46.79923104, -71.27493984 46.79961903, -71.27479692 46.79946999, -71.273295 46.79827497, -71.26933716 46.797615, -71.26868196 46.79684496, -71.26807716 46.79625996, -71.26799184 46.79613603, -71.26794792 46.79610597, -71.26788996 46.79609004, -71.26759908 46.79621604, -71.26745004 46.79631702, -71.26674588 46.79684703, -71.26624188 46.79717904, -71.26656192 46.79756397, -71.26378992 46.798101, -71.26417116 46.798659, -71.26353612 46.79881803, -71.26060716 46.79959797, -71.25963012 46.79886402, -71.25922188 46.79868996, -71.25895512 46.79853399, -71.25928416 46.79840304, -71.26074396 46.79778699, -71.26125912 46.79757, -71.26142688 46.79751204, -71.262729 46.79700102, -71.26360812 46.79671302, -71.26456716 46.79646003, -71.26560792 46.79627796, -71.26727688 46.79608302, -71.26738596 46.796076, -71.26774488 46.79604702, -71.26769592 46.79589303, -71.26765416 46.79576802, -71.26729092 46.79524701, -71.26722684 46.79515602, -71.26706484 46.79498196, -71.26800192 46.79476002, -71.26819884 46.79471196, -71.26839684 46.79466399, -71.26803108 46.79438499, -71.267337 46.79372403, -71.26682184 46.79337699, -71.26657596 46.79319402, -71.26642116 46.79305902, -71.26622388 46.79288496, -71.26604784 46.79273097, -71.26593696 46.79262801, -71.26560504 46.79234298, -71.26500996 46.791864, -71.26468308 46.79160003, -71.26434288 46.79136999, -71.26427412 46.79132202, -71.26392996 46.
[jts-devel] Re: [jump-users] Question on JTS Geometry#buffer( )
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 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
jump-us...@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jump-users
___
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
[jts-devel] Re: [jump-users] Question on JTS Geometry#buffer( )
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 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
jump-us...@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jump-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
___
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
[jts-devel] Re: [jump-users] Question on JTS Geometry#buffer( )
(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
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
Re: [jts-devel] Running JTS code in a web browser
Thanks Martin, guess I saved you some trouble then. What kind of performance metrics you would like to see? The project was setup last night: http://sourceforge.net/projects/jts4gwt/source code is available though SVN and the tracker has already tickets which I will clear in my own spare time Regards On Mon, Feb 9, 2009 at 2:44 PM, Martin Davis wrote: > Excellent work, Alexandre. > Funnily enough, a colleague of mine suggested doing this exact experiment > just last week. Can't beat that for turnaround time... 8^) > > I think your idea of creating a new SourceForge project is excellent. Post > to this list if you need technical assistance. > > I look forward to seeing some performance metrics coming out > > Martin > > Alexandre Pretyman wrote: > >> Hello all. >> >> I spent a few hours this weekend porting JTS 1.10 to GWT. For those who >> don't know GWT (Google Web Toolkit), it is a web programming framework >> released by Google in which you develop in Java and it compiles and >> generates the corresponding JavaScript code. It manages to do so by >> emulating a good part of the Java Runtime Environment. However not all, for >> example, since web browsers have no file access, I had to strip out the >> classes which did file IO, because such classes are not emulated and I had >> to re-implement some of the code in the classes to make it compatible with >> GWT. >> >> This effort was made because after a post in the GWT group, people started >> showing interest in using JTS with google maps, although while I was porting >> it, I noticed that not all can be ported with a one to one relationship, for >> example, JTS Polygons can have holes in them, while Google Maps Polygons >> (apparantly) can't. >> >> Here is an example project I setup that does the buffer operation on the >> client (web browser) and sends it to a server through a RPC call, which >> merely clones it, and returns it, just to test Serialization in GWT : >> http://www.4shared.com/file/85146364/98e14118/jts4gwt.html it is 20 megs >> because it has all required libraries to run included - sorry, windows only >> for now, if you run other platform, you can try downloading GWT for your >> platform and swapping the libraries. >> To run the example you have to import it in eclipse, click the down arrow >> beside the Debug button, choose Debug Configurations... and in the following >> dialog, choose JTS4GWT under Java Application on tree view on the left and >> click Debug. It might take a little while to start because it must compile >> all Java sources into JavaScript when it starts debugging, then 2 windows >> will open, one being the window of the web browser, with a google map and a >> button beneath it to test the buffer function on the client side. >> >> With Martin Davis approval (and everyone else involved in making JTS) I >> would setup a jts4gwt project in SourceForge and continue the port (there is >> still work to do), also, with the project in SourceForge, whoever needs a >> function which is not implemented yet in the GWT version, can implement it >> and contribute. >> >> Google Maps is not the only option in mapping for GWT, there is a binding >> for OpenLayers as well, so I think one could use JTS geometries with >> OpenLayers too. >> >> Regards, >> Alexandre Pretyman >> >> >> ___ >> jts-devel mailing list >> jts-devel@lists.jump-project.org >> http://lists.refractions.net/mailman/listinfo/jts-devel >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > ___ > jts-devel mailing list > jts-devel@lists.jump-project.org > http://lists.refractions.net/mailman/listinfo/jts-devel > ___ jts-devel mailing list jts-devel@lists.jump-project.org http://lists.refractions.net/mailman/listinfo/jts-devel
