Recently I used gt2 shapefile module to read shapefile and save them
into JTS geometry types: point, line, polygon. For simple polygon,
this works great. But sometimes I got this error message:

expected class com.vividsolutions.jts.geom.Polygon got
com.vividsolutions.jts.geom.MultiPolygon

so I am wondering in JTS and GT2, when I got a multipolygon geometry,
how can I create a feature of that type?
can I use something like this:
Feature polygonFeature = polygonFac.create(new Object[]{polygon});

Thanks a lot

Xun

Someone was doing some profiling on a GeoTools codeset and found the
following as a potential speedup...:

(GeometryFilterImpl.java): the bounding box filter implementation relied
on the jts intersect method... unfortunately this method is not
optimized and doesn't check for simple bounding box containment... I've
added this check and got another good overall speedup.

If I understand the problem correctly, the situation is that you know that one
of your geometries is a BoundingBox (Envelope, in JTS parlance) and you would
like to optimize the intersection test.  In face, we have the same situation in
JCS (e.g. for selecting all features within a selection box), and have developed
a special EnvelopeIntersector class to optimize this.

It might be nice to have this more integrated with JTS, but unfortunately in OGC
there is no notion of a BoundingBox subclass of Geometry, so there is no way to
tell JTS explicitly that a Geometry is a BoundingBox.  The only other
possibility is to check every Geometry at the start of operations to see if it
is a rectangle.   I rejected this as introducing too much overhead for a case
which is usually known explicitly.

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


> -----Original Message-----
> From: Paul Ramsey [mailto:pramsey@...]
> Sent: Thursday, January 02, 2003 1:07 PM
> To: jts_discussion@...
> Subject: [jts_discussion] Found on GeoTools-Devel
>
>
> Someone was doing some profiling on a GeoTools codeset and found the
> following as a potential speedup...:
>
> (GeometryFilterImpl.java): the bounding box filter
> implementation relied
> on the jts intersect method... unfortunately this method is not
> optimized and doesn't check for simple bounding box
> containment... I've
> added this check and got another good overall speedup.
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
> http://ca.yahoo.com/docs/info/tos.html
>
>
>

I am not sure if that is the case, or if the simpler shortcut is what is
being described: ie, if the bounding boxes of these two geometries do
not intersect, then nor do the geometries, return.

P.

Martin Davis wrote:
> If I understand the problem correctly, the situation is that you know
> that one of your geometries is a BoundingBox (Envelope, in JTS
> parlance) and you would like to optimize the intersection test.  In
> face, we have the same situation in JCS (e.g. for selecting all
> features within a selection box), and have developed a special
> EnvelopeIntersector class to optimize this.
>
> It might be nice to have this more integrated with JTS, but
> unfortunately in OGC there is no notion of a BoundingBox subclass of
> Geometry, so there is no way to tell JTS explicitly that a Geometry
> is a BoundingBox.  The only other possibility is to check every
> Geometry at the start of operations to see if it is a rectangle.   I
> rejected this as introducing too much overhead for a case which is
> usually known explicitly.
>
> Martin Davis, Senior Technical Specialist Vivid Solutions Inc. Suite
> #1A-2328 Government Street   Victoria, B.C.   V8T 5G5 Phone: (250)
> 385 6040    Fax: (250) 385 6046 EMail: mbdavis@...
> Web: www.vividsolutions.com
>
>
>
>> -----Original Message----- From: Paul Ramsey
>> [mailto:pramsey@...] Sent: Thursday, January 02, 2003
>> 1:07 PM To: jts_discussion@... Subject: [jts_discussion]
>> Found on GeoTools-Devel
>>
>>
>> Someone was doing some profiling on a GeoTools codeset and found
>> the following as a potential speedup...:
>>
>> (GeometryFilterImpl.java): the bounding box filter implementation
>> relied on the jts intersect method... unfortunately this method is
>> not optimized and doesn't check for simple bounding box
>> containment... I've added this check and got another good overall
>> speedup.
>>
>>
>> To unsubscribe from this group, send an email to:
>> jts_discussion-unsubscribe@...
>>
>>
>>
>> Your use of Yahoo! Groups is subject to
>> http://ca.yahoo.com/docs/info/tos.html
>>
>>
>>
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
> http://ca.yahoo.com/docs/info/tos.html
>
>


--
        __
       /
       | Paul Ramsey
       | Refractions Research
       | Email: pramsey@...
       | Phone: (250) 885-0632
       \_

That's what I thought at first too.  However, JTS does in fact check for
disjoint bounding boxes and returns immediately with the appropriate result. 
After reading the note a little more closely I think that they are in fact
referring to an optimized way of checking containment in a BoundingBox.

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


> -----Original Message-----
> From: Paul Ramsey [mailto:pramsey@...]
> Sent: Monday, January 06, 2003 10:09 AM
> To: jts_discussion@...
> Subject: Re: [jts_discussion] Found on GeoTools-Devel
>
>
> I am not sure if that is the case, or if the simpler shortcut
> is what is
> being described: ie, if the bounding boxes of these two geometries do
> not intersect, then nor do the geometries, return.
>
> P.
>
> Martin Davis wrote:
> > If I understand the problem correctly, the situation is
> that you know
> > that one of your geometries is a BoundingBox (Envelope, in JTS
> > parlance) and you would like to optimize the intersection test.  In
> > face, we have the same situation in JCS (e.g. for selecting all
> > features within a selection box), and have developed a special
> > EnvelopeIntersector class to optimize this.
> >
> > It might be nice to have this more integrated with JTS, but
> > unfortunately in OGC there is no notion of a BoundingBox subclass of
> > Geometry, so there is no way to tell JTS explicitly that a Geometry
> > is a BoundingBox.  The only other possibility is to check every
> > Geometry at the start of operations to see if it is a rectangle.   I
> > rejected this as introducing too much overhead for a case which is
> > usually known explicitly.
> >
> > Martin Davis, Senior Technical Specialist Vivid Solutions Inc. Suite
> > #1A-2328 Government Street   Victoria, B.C.   V8T 5G5 Phone: (250)
> > 385 6040    Fax: (250) 385 6046 EMail: mbdavis@...
> > Web: www.vividsolutions.com
> >
> >
> >
> >> -----Original Message----- From: Paul Ramsey
> >> [mailto:pramsey@...] Sent: Thursday, January 02, 2003
> >> 1:07 PM To: jts_discussion@... Subject: [jts_discussion]
> >> Found on GeoTools-Devel
> >>
> >>
> >> Someone was doing some profiling on a GeoTools codeset and found
> >> the following as a potential speedup...:
> >>
> >> (GeometryFilterImpl.java): the bounding box filter implementation
> >> relied on the jts intersect method... unfortunately this method is
> >> not optimized and doesn't check for simple bounding box
> >> containment... I've added this check and got another good overall
> >> speedup.
> >>
> >>
> >> To unsubscribe from this group, send an email to:
> >> jts_discussion-unsubscribe@...
> >>
> >>
> >>
> >> Your use of Yahoo! Groups is subject to
> >> http://ca.yahoo.com/docs/info/tos.html
> >>
> >>
> >>
> >
> >
> > To unsubscribe from this group, send an email to:
> > jts_discussion-unsubscribe@...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://ca.yahoo.com/docs/info/tos.html
> >
> >
>
>
> --
>        __
>       /
>       | Paul Ramsey
>       | Refractions Research
>       | Email: pramsey@...
>       | Phone: (250) 885-0632
>       \_
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
http://ca.yahoo.com/docs/info/tos.html

Hello JTS folks,
As you can see from below, Coordinate System, SRID and Geometries are being
discussed on the geotools email list.

I suspect you wil have useful opinions on this matter that you may want to
share with us.

This may be an issue which we can solve with the GeoInterfaces project
proposal which will provide interfaces for all the key Geographic Classes and
numerous projects can impliment these interfaces.

On Wednesday 08 Jan 2003 5:35 pm, Martin Desruisseaux wrote:
> Hello all
>
> Chris Holmes wrote:
>  > [...snip...] So I thought I'd see if we should maybe start creating
>  > geometries with SRID's. Doing so would definitely be useful from my
>  > perspective.
>
> I think that if we have the info, we are better to provide it in all
> created geometries. User can ignore the SRID if he doesn't care. But
> for many peoples, this is an important information.
>
>  > I'm doing transactional stuff on the postgis datasource, and it
>  > requires the proper SRID when inserting, which I currently hack
>  > together by quering the postgis database to find the SRID I should
>  > insert. Of course, if I were to use the SRID of the geometries
>  > passed in, that would make things less permissive, as we would throw
>  > exceptions if clients tried to insert geometries that did not match
>  > those stored in the db. But perhaps the behaviour we want?
>
> I would said that this is what we want. If the database use lat/lon and
> I'm trying to insert a geometry in meters, this is an error. It is
> difficult to tell where (400 km, 500 km) is located relative to (45°N,
> 60°W); I need to express both coordinates in the same Coordinate System
> first.
>
> In a future version, the PostGIS datasource should be intelligent enough
> to transforms geometries itself when needed. For example if the database
> use lat/lon and if I'm inserting a geometry in meters, the PostGIS
> datasource should be able to automatically transform the geometry in
> lat/lon. It can do that with CoordinateTransformationFactory.
>
>  > A happy medium would be if the SRID was not set (-1), then we'd use
>  > the database's SRID.
>
> Indeed. Or maybe we should log a warning?
>
>  > But do shapefiles even have an SRID? Will our future datasources
>  > have srids? I know that all that conform to SFS for SQL will...

No, shapefiles do not have a CoordinateSystem or SRID.  However, I agree that
we should enforce a CoordinateSystem on a ShapefileDataSource, even if the
CoordinateSystem is set to a null or default CoordinateSystem.

>
> I think they should.
>
> I feel there is an important problem with current JTS's API: it use an
> integer code for SRID instead of an org.opengis.cs.CS_CoordinateSystem
> object. It have the following consequence:
>
> 1) Integer code need to be converted to CoordinateSystem object before
>     to be used, which is done by CoordinateSystemEPSGFactory. This is
>     an important overhead if we need to do that everytime we want the
>     coordinate system.
>
> 2) The other way around (converting an arbitrary CoordinateSystem to
>     an EPSG code) is not implemented.
>
> 3) Only Coordinate System declared in the EPSG database can be used.
>     It is impossible to use a geometry with a custom coordinate system.
>
>
> The obvious right thing to do would be to replace the SRID integer by
> the OpenGIS's interface (or maybe the Geotools's class). This is the
> object-oriented way (using 'int' is not object-oriented; it is not
> extensible at all). However, it would introduces a dependency of JTS
> toward OpenGIS or Geotools, which may not be acceptable for JTS as an
> independant library. This problem may be better solved if JTS and
> Geotools were merged projects.
>
> In summary, with JTS as a separated project, the SRID will probably be
> suboptimal and very difficuly to extent. Merging JTS and Geotools would
> help a lot. Is it doable?
>
>  Martin.
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Cameron Shorter              http://cameron.shorter.net
Open Source Developer        http://mapbuilder.sourceforge.net
Software Engineer/Team Lead  http://www.adi-limited.com/

The short answer is that because the method you are using to create geometries
(i.e. via repeated overlay operations) has resulted in geometries which cause
robustness failures in JTS.  This is likely because the geometries are
MultiPolygons containing many components, some of which contain extremely narrow
angles and small segments.

I'm impressed that the AWT  routines are robust enough to handle this.  I wish I
knew if they were using any special techniques to achieve this.

The saving grace for JTS is that your application appears to be somewhat
artificial (from a GIS point of view), so this shouldn't cause too much concern
for more conventional applications.

What exactly *is* your application, by the way?

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


-----Original Message-----
From: David Rafkind [mailto:daver@...]
Sent: Thursday, January 09, 2003 1:26 PM
To: Martin Davis
Subject: why does this fail in JTS 1.2?


I am using JTS 1.2. The attached short program fails with the following stack
trace:

Exception in thread "main" com.vividsolutions.jts.util.AssertionFailedException:
found null Directed Edge
         at com.vividsolutions.jts.util.Assert.isTrue(Unknown Source)
         at com.vividsolutions.jts.graph.EdgeRing.computePoints(Unknown Source)
         at com.vividsolutions.jts.graph.EdgeRing.<init>(Unknown Source)
         at
com.vividsolutions.jts.operation.overlay.MaximalEdgeRing.<init>(Unknown Source)
         at
com.vividsolutions.jts.operation.overlay.PolygonBuilder.buildMaximalEdgeRings(Un\
known Source)
         at com.vividsolutions.jts.operation.overlay.PolygonBuilder.add(Unknown
Source)
         at com.vividsolutions.jts.operation.overlay.PolygonBuilder.add(Unknown
Source)
         at
com.vividsolutions.jts.operation.overlay.OverlayOp.computeOverlay(Unknown
Source)
         at
com.vividsolutions.jts.operation.overlay.OverlayOp.getResultGeometry(Unknown
Source)
         at com.vividsolutions.jts.operation.overlay.OverlayOp.overlayOp(Unknown
Source)
         at com.vividsolutions.jts.geom.Geometry.difference(Unknown Source)
         at Builder.main(Builder.java:34)

I know my logic is fine, because it works dandy with the java.awt.geom.*
classes. Any thoughts?

import java.io.*;
import com.vividsolutions.jts.geom.*;
import com.vividsolutions.jts.io.*;

public class Builder {

     public static void main( String [] args ) {

	 PrecisionModel pm = new PrecisionModel();

	 Geometry big = createCircle( 5000, 5000, 4950, 100, pm );


	 for ( int i = 1; i < 10; i++ ) {
	     Geometry cut = createCircle( 5000, 5000, i * 500, 100, pm ).
		 difference( createCircle( 5000, 5000, i * 500 - 200, 100, pm ) );

	     big = big.difference( cut );
	 } // end for

	 for ( double y = -5000; y < 15000; y += 1000 ) {
	     Geometry cut = createCircle( 5000, y, 4500, 100, pm ).
		 difference( createCircle( 5000, y, 4400, 100, pm ) );

	     big = big.difference( cut );

	 } // end for

	 for ( double x = -5000; x < 15000; x += 1000 ) {
	     System.out.println( x );
	     Geometry cut = createCircle( x, 5000, 4500, 100, pm ).
		 difference( createCircle( x, 5000, 4400, 100, pm ) );

	     big = big.difference( cut );

	 } // end for

	 WKTWriter w = new WKTWriter();

	 System.out.println( w.writeFormatted( big ) );

     } // end main

     public static Geometry createCircle( double cx, double cy, double radius,
int npoints, PrecisionModel pm ) {
	 Coordinate [] points = new Coordinate[ npoints+1 ];

	 for ( int i = 0; i < npoints; i++ ) {
	     double ang = 2.0 * Math.PI * (double) i / npoints;
	     double x = cx + Math.cos( ang ) * radius;
	     double y = cy + Math.sin( ang ) * radius;

	     points[ i ] = new Coordinate( x, y );
	 } // end for

	 points[ npoints ] = points[ 0 ];

	 return new Polygon( new LinearRing( points, pm, -1 ), pm, -1 );
     } // end createCircle

} // end class Builder

While I am using GT2 shapefile module to read esri shapefiles and
then construct JTS geometry objects. The program works fine with
polygon shapefiles and some of the line shapefiles. But for some
shapefile with line feature, I got the following error message:
Can somebody help?

java.lang.IllegalArgumentException: point array must contain 0 or >1
elements at com.vividsolutions.jts.geom.LineString.<init>
(LineString.java:73)at
com.vividsolutions.jts.geom.GeometryFactory.createLineString
(GeometryFactory.java:310) at
org.geotools.shapefile.MultiLineHandler.read
MultiLineHandler.java:101) at org.geotools.shapefile.Shapefile.read
(Shapefile.java:195)


Thanks

Xun

Sigh...  This whole issue of Coordinate System is somewhat ill-defined, IMHO. 
The SFS specifies an int, GML specifies a URI, it looks like the "big" OGC
standard specifies an actual object..  what's a poor API designer to do?

Personally, from a JTS perspective I'd like to punt on the whole issue.  JTS
currently does nothing with SRID's except carry them around - which to me says
"cruft".  I would love to remove them from the API completely, and leave them up
to another layer (the Feature layer?) to specify.

Would this cause problems for people?

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


> -----Original Message-----
> From: Cameron Shorter [mailto:cshorter@...]
> Sent: Wednesday, January 08, 2003 10:55 PM
> To: jts_discussion@...;
> geotools-devel@...
> Subject: [jts_discussion] Re: [Geotools-devel] SRID in jts objects.
>
>
> Hello JTS folks,
> As you can see from below, Coordinate System, SRID and
> Geometries are being
> discussed on the geotools email list.
>
> I suspect you wil have useful opinions on this matter that
> you may want to
> share with us.
>
> This may be an issue which we can solve with the
> GeoInterfaces project
> proposal which will provide interfaces for all the key
> Geographic Classes and
> numerous projects can impliment these interfaces.
>
> On Wednesday 08 Jan 2003 5:35 pm, Martin Desruisseaux wrote:
> > Hello all
> >
> > Chris Holmes wrote:
> >  > [...snip...] So I thought I'd see if we should maybe
> start creating
> >  > geometries with SRID's. Doing so would definitely be
> useful from my
> >  > perspective.
> >
> > I think that if we have the info, we are better to provide it in all
> > created geometries. User can ignore the SRID if he doesn't care. But
> > for many peoples, this is an important information.
> >
> >  > I'm doing transactional stuff on the postgis datasource, and it
> >  > requires the proper SRID when inserting, which I currently hack
> >  > together by quering the postgis database to find the
> SRID I should
> >  > insert. Of course, if I were to use the SRID of the geometries
> >  > passed in, that would make things less permissive, as we
> would throw
> >  > exceptions if clients tried to insert geometries that
> did not match
> >  > those stored in the db. But perhaps the behaviour we want?
> >
> > I would said that this is what we want. If the database use
> lat/lon and
> > I'm trying to insert a geometry in meters, this is an error. It is
> > difficult to tell where (400 km, 500 km) is located
> relative to (45°N,
> > 60°W); I need to express both coordinates in the same
> Coordinate System
> > first.
> >
> > In a future version, the PostGIS datasource should be
> intelligent enough
> > to transforms geometries itself when needed. For example if
> the database
> > use lat/lon and if I'm inserting a geometry in meters, the PostGIS
> > datasource should be able to automatically transform the geometry in
> > lat/lon. It can do that with CoordinateTransformationFactory.
> >
> >  > A happy medium would be if the SRID was not set (-1),
> then we'd use
> >  > the database's SRID.
> >
> > Indeed. Or maybe we should log a warning?
> >
> >  > But do shapefiles even have an SRID? Will our future datasources
> >  > have srids? I know that all that conform to SFS for SQL will...
>
> No, shapefiles do not have a CoordinateSystem or SRID.
> However, I agree that
> we should enforce a CoordinateSystem on a
> ShapefileDataSource, even if the
> CoordinateSystem is set to a null or default CoordinateSystem.
>
> >
> > I think they should.
> >
> > I feel there is an important problem with current JTS's
> API: it use an
> > integer code for SRID instead of an
> org.opengis.cs.CS_CoordinateSystem
> > object. It have the following consequence:
> >
> > 1) Integer code need to be converted to CoordinateSystem
> object before
> >     to be used, which is done by
> CoordinateSystemEPSGFactory. This is
> >     an important overhead if we need to do that everytime
> we want the
> >     coordinate system.
> >
> > 2) The other way around (converting an arbitrary CoordinateSystem to
> >     an EPSG code) is not implemented.
> >
> > 3) Only Coordinate System declared in the EPSG database can be used.
> >     It is impossible to use a geometry with a custom
> coordinate system.
> >
> >
> > The obvious right thing to do would be to replace the SRID
> integer by
> > the OpenGIS's interface (or maybe the Geotools's class). This is the
> > object-oriented way (using 'int' is not object-oriented; it is not
> > extensible at all). However, it would introduces a dependency of JTS
> > toward OpenGIS or Geotools, which may not be acceptable for
> JTS as an
> > independant library. This problem may be better solved if JTS and
> > Geotools were merged projects.
> >
> > In summary, with JTS as a separated project, the SRID will
> probably be
> > suboptimal and very difficuly to extent. Merging JTS and
> Geotools would
> > help a lot. Is it doable?
> >
> >  Martin.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Geotools-devel mailing list
> > Geotools-devel@...
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> --
> Cameron Shorter              http://cameron.shorter.net
> Open Source Developer        http://mapbuilder.sourceforge.net
> Software Engineer/Team Lead  http://www.adi-limited.com/
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
http://ca.yahoo.com/docs/info/tos.html

Hi all,
   what is the difference between JTS and GeoTools2 and which one
should i use?

At 10:02 AM 1/14/2003 +0000, you wrote:
>Hi all,
>   what is the difference between JTS and GeoTools2 and which one
>should i use?

I would say that the short answer is both!

JTS is a suite for handling geometries (as defined by OGC SimpleFeatures)
it is well tested and very robust, GeoTools 2 uses JTS to store and
manipulate geometries and then provides filtering, styling, rendering and
file conversion classes.

You may just want to use parts of GeoTools 2 with JTS, for example the
Shapefile or GML to JTS code, if so its modular enough for you to do that.

All the best

James

Urban Science is proud to announce the beta release of its first
Open Source Software Development project, Geotools.Net.
Geotools.NET is hosted on SourceForge.net, the largest repository of
Open Source code.  It is based on an Open Source Java implementation
(JTS) of the OpenGIS Simple Features Specification.  Details and
demos of Geotools.Net capabilities can be found on the home page.

Home page
http://geotoolsnet.sourceforge.net/Index.html

SourceForge project page
http://sourceforge.net/projects/geotoolsnet

Andrew Coats

Hi, Johannes.

The example below is a classic example of a robustness failure due to topology
collapse.  It's caused by the roundoff imposed by the PrecisionModel, which in
turn causes the internal algorithms to become "confused".  I'd love to something
about this, but unfortunately it's not at all easy (or at least, not according
to my current research - if someone has a brilliant solution to this I'd love to
hear about it).

Anyway, in your case you can simply increase the precision of your Geometries
and the example will work fine (e.g using PrecisionModel(10,0,0) ).  I suspect
the same is the case for the remaining examples you sent.

By the way, please post to the JTS listserver, so everyone can share in this
information.

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


> -----Original Message-----
> From: Johannes Leebmann [mailto:leebmann@...]
> Sent: Tuesday, January 14, 2003 2:49 AM
> To: Martin Davis
> Subject:
>
>
>
> Dear Martin Davis,
>
>  one more ...
>
> only for:
> static PrecisionModel pm = new PrecisionModel(1,0,0);
>
> Regards,
> Johannes
>
>
>
>
> String wktA = "POLYGON ((474 324, 458 310, 457 315, 462 318,
> 474 324))";
>      String wktB = "POLYGON ((458 310, 441 307, 474 324, 458 310))";
>      Geometry a = wktRdr.read(wktA);
>      Geometry b = wktRdr.read(wktB);
>    Geometry c = a.union(b);
>

Andrew,
    This is quite amazing and unexpected! What led you to decide to do
this port?
    List in general. We now have two ports of JTS and soon will have
three when the GEOS port to C++ is complete. What are the implications
in terms of managing enhancements and updates to the algorithmic base of
JTS?
Paul

Andrew Coats wrote:
> Urban Science is proud to announce the beta release of its first
> Open Source Software Development project, Geotools.Net.
> Geotools.NET is hosted on SourceForge.net, the largest repository of
> Open Source code.  It is based on an Open Source Java implementation
> (JTS) of the OpenGIS Simple Features Specification.  Details and
> demos of Geotools.Net capabilities can be found on the home page.
>
> Home page
> http://geotoolsnet.sourceforge.net/Index.html
>
> SourceForge project page
> http://sourceforge.net/projects/geotoolsnet
>
> Andrew Coats


--
        __
       /
       | Paul Ramsey
       | Refractions Research
       | Email: pramsey@...
       | Phone: (250) 885-0632
       \_

At 02:51 PM 1/14/2003 +0000, you wrote:
>Urban Science is proud to announce the beta release of its first
>Open Source Software Development project, Geotools.Net.

Just a quick note to say that Geotools.Net is not related to the GeoTools
java project.

I'm a little surprised by the name as it may well lead to confusion.  That
said, if you are planning to port the GeoTools 2 library into C# in future
(SLD, Filtering, Features, GML, PostGIS connections etc.) then this would
be very exciting, providing the architectures could remain similar, if not
then having two projects with the same name doing similar things in
different languages seems a bit strange.

James

We found the OpenGIS simple features specification and liked it; I was
speaking to someone at SvgOpen about OpenGIS and how we would like to
implement Simple Features and they mentioned JTS.

We are 100% Microsoft shop so switching to Java (or J#) was not really
an option. But Java is so close to c# that the conversion was relatively
easy (if time consuming). During the conversion process I learned that
Java is more like C# than it is different. There was a couple of Java
language features that were used in 1.2 (anonymous classes) that have no
direct c# equivalent (I believe the next version of c# will have them.).


I was already a huge Open Source advocate, this project proved the point
with my manager. In some ways I almost wish I worked in Java because
there is so much more Open Source code in Java. I must say the Eclipse
IDE is also superb.

I'm excited by a C++ implementation. I'm dreaming that if it was exposed
via COM interfaces, spatial SQL could be implemented in SQL Server using
extended stored procedures. In the mean time, we are waiting for Yukon
(the next version of SQL Server); this will allow us C# to implement
spatial SQL.

In terms of managing the updates - the change from JTS 1.1 to 1.2 was
pretty quick (a couple of days). The test cases helped enormously. Our
QA guy packed them up as NUnit (similar to JUnit).

http://www.svgopen.com/

Java to C#

-----Original Message-----
From: Paul Ramsey [mailto:pramsey@...]
Sent: Tuesday, January 14, 2003 12:12 PM
To: jts_discussion@...
Cc: GEOS Development List
Subject: Re: [jts_discussion] Geotools.Net released (C# port of JTS 1.2)

Andrew,
    This is quite amazing and unexpected! What led you to decide to do
this port?
    List in general. We now have two ports of JTS and soon will have
three when the GEOS port to C++ is complete. What are the implications
in terms of managing enhancements and updates to the algorithmic base of

JTS?
Paul

Andrew Coats wrote:
> Urban Science is proud to announce the beta release of its first
> Open Source Software Development project, Geotools.Net.
> Geotools.NET is hosted on SourceForge.net, the largest repository of
> Open Source code.  It is based on an Open Source Java implementation
> (JTS) of the OpenGIS Simple Features Specification.  Details and
> demos of Geotools.Net capabilities can be found on the home page.
>
> Home page
> http://geotoolsnet.sourceforge.net/Index.html
>
> SourceForge project page
> http://sourceforge.net/projects/geotoolsnet
>
> Andrew Coats


--
        __
       /
       | Paul Ramsey
       | Refractions Research
       | Email: pramsey@...
       | Phone: (250) 885-0632
       \_


To unsubscribe from this group, send an email to:
jts_discussion-unsubscribe@...



Your use of Yahoo! Groups is subject to
http://ca.yahoo.com/docs/info/tos.html

The name Geotools.Net was not exactly inspired. It seems all .Net
OpenSource projects either prefix their name with N (NUnit, NAnt, NDoc).


I'm hoping that other parts of the Java geotools will get ported. The
shapefile converter that is part of Geotools.Net is part of Geotools.
Although I love c#, I'm very jealous of Java programmers because of
Geotools. I imagine the architecture between Geotools and Geotools.Net
would be very similar; the only thing I can envision being different is
database access.

Regarding the other portions of Geotools, I do not envision Urban
Science porting other parts in the immediate future. Hopefully someone
else will have an interest. Geotools.Net + SVG gives us pretty much
everything we need for right now.

Andrew Coats


-----Original Message-----
From: James Macgill [mailto:j.macgill@...]
Sent: Tuesday, January 14, 2003 12:24 PM
To: jts_discussion@...
Subject: Re: [jts_discussion] Geotools.Net released (C# port of JTS 1.2)

At 02:51 PM 1/14/2003 +0000, you wrote:
>Urban Science is proud to announce the beta release of its first
>Open Source Software Development project, Geotools.Net.

Just a quick note to say that Geotools.Net is not related to the
GeoTools
java project.

I'm a little surprised by the name as it may well lead to confusion.
That
said, if you are planning to port the GeoTools 2 library into C# in
future
(SLD, Filtering, Features, GML, PostGIS connections etc.) then this
would
be very exciting, providing the architectures could remain similar, if
not
then having two projects with the same name doing similar things in
different languages seems a bit strange.

James


To unsubscribe from this group, send an email to:
jts_discussion-unsubscribe@...



Your use of Yahoo! Groups is subject to
http://ca.yahoo.com/docs/info/tos.html

Andrew,
I am excited to see that java GIS code is being ported to other languages and
would like to know:
1. What are your plans for the future of this project?  Are you planning to
contribute to it further or attract further interest?
2. The best ways for the java and C# communities to work together and to help
each other.  Since you have just done some porting, I assume you have some
ideas here.

I'd guess that standardizing on naming conventions and development processes
as much as possible would be useful, see http://geotools.org/gt2docs/ for
some ideas.

James has been proposing a  GIS Interfaces project which could easilly be
extended to include C# and C++ interfaces.
http://scoop.geoenabler.org/story/2002/10/10/55046/206

What else?

On Tuesday 14 Jan 2003 5:47 pm, Coats, Andy W wrote:
> The name Geotools.Net was not exactly inspired. It seems all .Net
> OpenSource projects either prefix their name with N (NUnit, NAnt, NDoc).
>
>
> I'm hoping that other parts of the Java geotools will get ported. The
> shapefile converter that is part of Geotools.Net is part of Geotools.
> Although I love c#, I'm very jealous of Java programmers because of
> Geotools. I imagine the architecture between Geotools and Geotools.Net
> would be very similar; the only thing I can envision being different is
> database access.
>
> Regarding the other portions of Geotools, I do not envision Urban
> Science prting other parts in the immediate future. Hopefully someone
> else will have an interest. Geotools.Net + SVG gives us pretty much
> everything we need for right now.
>
> Andrew Coats
>
>
> -----Original Message-----
> From: James Macgill [mailto:j.macgill@...]
> Sent: Tuesday, January 14, 2003 12:24 PM
> To: jts_discussion@...
> Subject: Re: [jts_discussion] Geotools.Net released (C# port of JTS 1.2)
>
> At 02:51 PM 1/14/2003 +0000, you wrote:
> >Urban Science is proud to announce the beta release of its first
> >Open Source Software Development project, Geotools.Net.
>
> Just a quick note to say that Geotools.Net is not related to the
> GeoTools
> java project.
>
> I'm a little surprised by the name as it may well lead to confusion.
> That
> said, if you are planning to port the GeoTools 2 library into C# in
> future
> (SLD, Filtering, Features, GML, PostGIS connections etc.) then this
> would
> be very exciting, providing the architectures could remain similar, if
> not
> then having two projects with the same name doing similar things in
> different languages seems a bit strange.
>
> James
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
> http://ca.yahoo.com/docs/info/tos.html
>
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
> http://ca.yahoo.com/docs/info/tos.html

--
Cameron Shorter              http://cameron.shorter.net
Open Source Developer        http://mapbuilder.sourceforge.net
                              http://geotools.sourceforge.net
Software Engineer/Team Lead  http://www.adi-limited.com/

hi all,
   i am interested in geotools2 but i could not get it, i always got
the error message like following

C:\>cvs -d:pserver:anonymous@...:/cvsroot/geotools
login
Logging in
to :pserver:anonymous@...:2401/cvsroot/geotools
CVS password:
cvs [login aborted]: connect to cvs.sourceforge.net
(66.35.250.207):2401 failed:
Connection reset by peer

can anybody tell me how to download geotools2, thanks!

At 08:06 AM 17/01/2003, cdlee456 wrote:
>hi all,
>   i am interested in geotools2 but i could not get it, i always got
>the error message like following
>
>C:\>cvs -d:pserver:anonymous@...:/cvsroot/geotools
>login
>Logging in
>to :pserver:anonymous@...:2401/cvsroot/geotools
>CVS password:
>cvs [login aborted]: connect to cvs.sourceforge.net
>(66.35.250.207):2401 failed:
>Connection reset by peer
>
>can anybody tell me how to download geotools2, thanks!

the annonymous pserver cvs is down at present, Have a look at :
http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#cvs for
more details.

Note however that this has nothing to do with JTS and should have been sent
to the geotools discussion list geotools-discussion@...
   where you would have already seen the answer.

Ian

Ian Turton, Director, Centre for Computational Geography, University of
Leeds, Leeds, LS2 9JT
http://www.geog.leeds.ac.uk/people/i.turton http://www.ccg.leeds.ac.uk
http://www.geotools.org
+44 (0) 113 343 3392 fax: +44 (0) 113 343 3308

--- "Coats, Andy W" <awcoats@...> wrote:
> We are 100% Microsoft shop so switching to Java (or J#) was not
> really an option. But Java is so close to c# that the conversion
> was relatively easy (if time consuming).

Microsoft has a "J#.net" tool that supposedly converts Java into C#.
Have you tried it?  Are there any other tools that could do the
conversion?  Seems like the perfect opportunity for such a tool .. for
someone ELSE to write.  :D :D :o

-B


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

I did try using the Java to C# tool from Microsoft (and another one
whose name I forget).  They did a reasonable job – but the resulting
code had thousands of errors which  need to be fixed. I did not try
using J# - although in hindsight I think that might be a better
approach especially for larger projects.

We took a more incremental approach to the conversion. Although this
was slower, we really did examine each line of the JTS code and this
helped us understand how it all worked and fitted together. It also
gave us an appreciation of the quality of the design and coding.

During the port we also made it more `.Net like'. For instance, .Net
methods and properties are Camal cased, implementing IEnumerable so
we could use C#'s foreach construct. Using properties instead of Get
and Set methods (one of the conversion tools tried to do this). One
thing I did not like about the Java coding style is the absence of
any kind of prefix on member variables. We prefixed an underscore in
front of member variables (as per the .Net coding convention).

There is some interesting work that is part of the Mono project (an
Open Source implementation of .Net) regarding interoperability
between .Net and Java. Someone is writing a Java Virtual Machine in
c#. This will allow .Net to directly call Java code.

http://www.go-mono.com
http://radio.weblogs.com/0109845/

Andrew Coats

--- In jts_discussion@y..., bit bot <bitbot_2000@y...> wrote:
> --- "Coats, Andy W" <awcoats@u...> wrote:
> > We are 100% Microsoft shop so switching to Java (or J#) was not
> > really an option. But Java is so close to c# that the conversion
> > was relatively easy (if time consuming).
>
> Microsoft has a "J#.net" tool that supposedly converts Java into
C#.
> Have you tried it?  Are there any other tools that could do the
> conversion?  Seems like the perfect opportunity for such a tool ..
for
> someone ELSE to write.  :D :D :o
>
> -B
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com

This is a bit off topic but anyway:
I agree with you regarding the member variables. I usually suffix them with
a _ (a habit I picked up from a company I worked for). Another way would be
to use "this." in front of the variable. But the biggest sin of Sun by far
is placing the opening braces on the same line. I know that people are very
opinionated about this, and I've fought battles with people inside my
company about this, but for me this makes the code much more unreadable :).
My speculation is that people who used to code in C and C++ prefer opening
braces on the next line, and that coders that began with Java simply adopted
the Sun recommendations. Ironically, because of this I find it somewhat
harder to read Sun's own source code for the Java platform, which *should*
be the most readable code.

Cheers,
Alex

PS. Pls don't ban me from the list because of this opinion :).

-----Original Message-----
From: Andrew Coats [mailto:awcoats@...]
Sent: January 18, 2003 8:43 AM
To: jts_discussion@...
Subject: [jts_discussion] Re: Geotools.Net released (C# port of JTS 1.2)


I did try using the Java to C# tool from Microsoft (and another one
whose name I forget).  They did a reasonable job – but the resulting
code had thousands of errors which  need to be fixed. I did not try
using J# - although in hindsight I think that might be a better
approach especially for larger projects.

We took a more incremental approach to the conversion. Although this
was slower, we really did examine each line of the JTS code and this
helped us understand how it all worked and fitted together. It also
gave us an appreciation of the quality of the design and coding.

During the port we also made it more `.Net like'. For instance, .Net
methods and properties are Camal cased, implementing IEnumerable so
we could use C#'s foreach construct. Using properties instead of Get
and Set methods (one of the conversion tools tried to do this). One
thing I did not like about the Java coding style is the absence of
any kind of prefix on member variables. We prefixed an underscore in
front of member variables (as per the .Net coding convention).

There is some interesting work that is part of the Mono project (an
Open Source implementation of .Net) regarding interoperability
between .Net and Java. Someone is writing a Java Virtual Machine in
c#. This will allow .Net to directly call Java code.

http://www.go-mono.com
http://radio.weblogs.com/0109845/

Andrew Coats

--- In jts_discussion@y..., bit bot <bitbot_2000@y...> wrote:
> --- "Coats, Andy W" <awcoats@u...> wrote:
> > We are 100% Microsoft shop so switching to Java (or J#) was not
> > really an option. But Java is so close to c# that the conversion
> > was relatively easy (if time consuming).
>
> Microsoft has a "J#.net" tool that supposedly converts Java into
C#.
> Have you tried it?  Are there any other tools that could do the
> conversion?  Seems like the perfect opportunity for such a tool ..
for
> someone ELSE to write.  :D :D :o
>
> -B
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com


To unsubscribe from this group, send an email to:
jts_discussion-unsubscribe@...



Your use of Yahoo! Groups is subject to
http://ca.yahoo.com/docs/info/tos.html

Martin Davis, Senior Technical Specialist

Vivid Solutions Inc.

Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5

Phone: (250) 385 6040    Fax: (250) 385 6046

EMail: mbdavis@...  Web: www.vividsolutions.com

-----Original Message-----
From: Ali Raza [mailto:aliraza@...]
Sent: Thursday, January 23, 2003 9:34 PM
To: jts_discussion@...
Subject: [jts_discussion] Help Required...

Hi everyone…………….

Can any one tell me where I can find information regarding Java Topology Suite. Please send me URL

My required information are

What is Java Topology Suite?

What’s it’s USES?

How we Use it in GIS?

What are the benefits for it?

I need complete information about JTS.

Thanx in advance.

Ali Raza

Aliraza@...

 

 

To unsubscribe from this group, send an email to:
jts_discussion-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--- In jts_discussion@y..., "Martin Davis" <mbdavis@v...> wrote:
> That's what I thought at first too.  However, JTS does in fact check
for disjoint bounding boxes and returns immediately with the
appropriate result.  After reading the note a little more closely I
think that they are in fact referring to an optimized way of checking
containment in a BoundingBox.
>

Yes, it is. The person that has optimized the
code path that involved the inclusion in a
bounding box... that's me. The real speedup
comes from the fact that I also exit immediately
if the bounding box is completely contained into
the reference bounding box.
Best regards
Andrea Aime

Greetings to all!
   Though I just joined this group but I have been following JTS for
some time now. I am someone who is just out of college but even for an
unexperienced fellow like me, I can very well state that such
professional code is not always written.
   I write this mail to confirm the rare robustness error while
computing buffers for LineString. Our observation is that it happens
with slightly curved geometries and large distances(I could be wrong
too).
   For example the following line string with a distance of 74332 gives
an depth error.

   LINESTRING (1099077 3990999, 1097952 3989135, 1096789 3987399,
1095287 3985544, 1092998 3982859,
   1090633 3980412, 1087855 3977925, 1086053 3976504, 1084213 3975201,
1082111 3973740, 1079032 3971648,
   1076742 3970305, 1074076 3968844, 1070322 3966831, 1066943 3965212,
1066606 3965072, 1065170 3964478,
   1060898 3963118, 1057368 3962131, 1054215 3961459, 1052112 3961024,
1047381 3960470, 1041823 3960232,
   1040472 3960192, 1038782 3960194, 1037757 3960195, 1034200 3960770,
1030667 3961779, 1030079 3961947,
   1025607 3963656, 1020896 3965973, 1018459 3967406, 1013386 3970384)

   We arrived at these values by trial and error with a combination of
real and experimental data.

   I tried a few things by removing a constant value from each
coordinate, but the error disappeared as well. And then I set about
debugging the whole process, and man was I impressed! I started from
the BufferOp class and went till the PolygonBuilder (by which time I
was hopelessly lost!) and found that if we do not make precise the
intersection point, the error was removed. But this obviously is not
we would like to have when we are working with fixed precision
calculations.

   Hope these experimental data would help you vividsolution fellows to
debug the code.
                                                         Barua.

Folks,

I am interested in using JTS overlay and union operations on polygons from
either shapefiles or PostGIS.  What is the best way of interfacing
JTS with shapefiles or PostGIS?  Via GeoTools2?

What I want to implement is a small utility to generate an intersection of
a polygon layer with one or a few polygons, and then produce a union of
the resulting polygons and produce the result as a polygon coverage.
It might be fine to work in either PostGIS or plain shapefiles.

Assuming building on GeoTools2 is the best approach to this, I think it would
be worthwhile adding a link to GeoTools2 in the links section.  Also, I think
it would be helpful to provide a link to the GEOS page from the JTS links page.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Frank Warmerdam wrote:
> Folks,
>
> I am interested in using JTS overlay and union operations on polygons from
> either shapefiles or PostGIS.  What is the best way of interfacing
> JTS with shapefiles or PostGIS?  Via GeoTools2?

Depends on what you mean by "best". :)
GeoTools2 has a PostGIS datasource already, and is built on JTS, so you
can use it to fairly quickly get together a Java app to read/write
PostGIS data. The shapefile code is a little primitive, but should get
better soon, as we have submitted back the updates to it we made via the
JCS project.

> What I want to implement is a small utility to generate an intersection of
> a polygon layer with one or a few polygons, and then produce a union of
> the resulting polygons and produce the result as a polygon coverage.
> It might be fine to work in either PostGIS or plain shapefiles.
>
> Assuming building on GeoTools2 is the best approach to this, I think it would
> be worthwhile adding a link to GeoTools2 in the links section.  Also, I think
> it would be helpful to provide a link to the GEOS page from the JTS links
page.

It would be, since GeoTools2 is a pretty significant project built on JTS.

P.

--
        __
       /
       | Paul Ramsey
       | Refractions Research
       | Email: pramsey@...
       | Phone: (250) 885-0632
       \_

Another option will be to use the JUMP (Unified Mapping Platform) API soon to be
delivered via the JCS project...

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis@...  Web: www.vividsolutions.com


> -----Original Message-----
> From: Frank Warmerdam [mailto:warmerdam@...]
> Sent: Wednesday, February 05, 2003 9:57 AM
> To: jts_discussion@...
> Subject: [jts_discussion] JTS Operating on Shapefiles or PostGIS
>
>
> Folks,
>
> I am interested in using JTS overlay and union operations on
> polygons from
> either shapefiles or PostGIS.  What is the best way of interfacing
> JTS with shapefiles or PostGIS?  Via GeoTools2?
>
> What I want to implement is a small utility to generate an
> intersection of
> a polygon layer with one or a few polygons, and then produce
> a union of
> the resulting polygons and produce the result as a polygon coverage.
> It might be fine to work in either PostGIS or plain shapefiles.
>
> Assuming building on GeoTools2 is the best approach to this,
> I think it would
> be worthwhile adding a link to GeoTools2 in the links
> section.  Also, I think
> it would be helpful to provide a link to the GEOS page from
> the JTS links page.
>
> Best regards,
>
> --
> ---------------------------------------+----------------------
----------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam@...
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial
> Programmer for Rent
>
>
>
> To unsubscribe from this group, send an email to:
> jts_discussion-unsubscribe@...
>
>
>
> Your use of Yahoo! Groups is subject to
> http://ca.yahoo.com/docs/info/tos.html
>
>
>