Jo-4
|
Re: geos-devel Digest, Vol 82, Issue 7
|
|
|
Hi, I'm fighting with some memory leaks at the moment, and I was wondering what's the best way to release an object created with GeometryFactory; for instance: geos::geom::GeometryFactory::createPoint(geos::geom::Coordinate const&)
Is it GeometryFactory::DestroyGeometry ? Sorry, but I did not see any reference on how to do this on the documentation or examples; if I missed it, it would be great if you could point me there... Thanks in advance,
regards, Jo 2009/8/5 <[hidden email]>
Send geos-devel mailing list submissions to
[hidden email]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/geos-devel
or, via email, send a message with subject or body 'help' to
[hidden email]
You can reach the person managing the list at
[hidden email]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of geos-devel digest..."
Today's Topics:
1. Re: Porting LengthIndexedLine.project? (strk)
2. Re: Polygonizer returns inner rings on their own? (Martin Davis)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Aug 2009 20:51:58 +0200
From: strk <[hidden email]>
Subject: Re: [geos-devel] Porting LengthIndexedLine.project?
To: David Turner <[hidden email]>, Martin Davis
<[hidden email]>, GEOS Development List
<[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii
Martin forgot to answer publically, anyway, he mentioned
tests are here: test.jts.junit.linearref
NOTE: they are only in CVS:
:pserver:[hidden email]:/home/cvs/jts
--strk;
Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
http://foo.keybit.net/~strk/services.html /\ Keep it simple!
On Sun, Aug 02, 2009 at 03:23:18PM +0200, strk wrote:
> Let's ask Martin...
> Are unit tests for LengthIndexedLine available or to be made ?
>
> --strk;
>
> On Sat, Aug 01, 2009 at 12:02:07AM -0400, David Turner wrote:
> > On Mon, 2009-07-27 at 17:42 -0400, David Turner wrote:
> > > On Thu, 2009-07-23 at 21:53 +0200, strk wrote:
> > > > On Thu, Jul 23, 2009 at 11:13:34AM -0400, David Turner wrote:
> > > > > JTS has a class called LengthIndexedLine with a method "project", which
> > > > > lets you figure out the nearest point on a line to a given point. This
> > > > > is useful, for instance, if you are trying to figure out what street a
> > > > > person is on from (possibly slightly inaccurate) GPS observations.
> > > > >
> > > > > http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/linearref/LengthIndexedLine.html#project(com.vividsolutions.jts.geom.Coordinate)
> > > > >
> > > > > PostGIS calls this function st_line_locate_point.
> > > > >
> > > > > GEOS doesn't seem to have it, even though I was under the impression
> > > > > that GEOS was merely a port of JTS. If I port JTS's project function
> > > > > and related functions such as extractPoint to GEOS, would that patch be
> > > > > likely to be accepted? Or am I missing something about the relationship
> > > > > between JTS and GEOS?
> > > >
> > > > Your patch would be welcome. Make sure to include unit testing please.
> > >
> > > I have a patch. Unfortunately, I do not yet have unit tests, because I
> > > cannot find the relevant Java unit tests to port. I could write my own,
> > > but it seems like some of the other code uses ported Java unit tests,
> > > and I want to follow the common practice.
> > >
> > > Can you point me to the Java unit tests?
> >
> > Just wanted to follow up to be sure this wasn't lost. The example I'm
> > looking at, in case I'm missing something, is:
> >
> > tests/unit/algorithm/RobustLineIntersectionTest.cpp
> >
> > which claims to be:
> >
> > Ported from JTS junit/algorithm/RobustLineIntersectionTest.java
> >
> > I assume there are probably similar tests for the linearref stuff, but
> > the JTS CVS appears to be empty or down or something, and Googling turns
> > up nothing.
> >
> > _______________________________________________
> > geos-devel mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/geos-devel
>
> --
>
> Free GIS & Flash consultant/developer () ASCII Ribbon Campaign
> http://foo.keybit.net/~strk/services.html /\ Keep it simple!
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
------------------------------
Message: 2
Date: Wed, 05 Aug 2009 09:01:07 -0700
From: Martin Davis <[hidden email]>
Subject: Re: [geos-devel] Polygonizer returns inner rings on their
own?
To: GEOS Development List <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The Polygonizer creates every possible polygon defined by the input
linework. That is, it forms the linework into a polygonal coverage.
That's why the hole also has a polygon filling it.
This is one common requirement for polygonization. Howwever, I can see
that it might be useful to be able to specify that the Polygonizer
should return only a (Multi)Polygon out of the input linework, which
sounds like it would meet your need. This would compute the depth
parity of the (potentially nested) polygons, and discard those with even
parity. I might try and add this to JTS shortly.
Frederik Ramm wrote:
> Hi,
>
> why is it that the (C++) Polygonizer, when given the following four
> geometries,
>
> "LINESTRING(1 1, 1 10, 10 10)"
> "LINESTRING(10 10, 10 1, 1 1)"
> "LINESTRING(20 20, 20 30, 30 30, 30 20, 20 20)"
> "LINESTRING(3 3, 3 4, 4 4, 4 3, 3 3)"
>
> (1 and 2 together form a shell, 3 forms a disjunct shell, 4 forms an
> inner ring of 1+2)
>
> returns a collection of three polygons:
>
> POLYGON ((1.00 1.00, 1.00 10.00, 10.00 10.00, 10.00 1.00, 1.00 1.00),
> (3.00 3.00, 4.00 3.00, 4.00 4.00, 3.00 4.00, 3.00 3.00))
> POLYGON ((20.00 20.00, 20.00 30.00, 30.00 30.00, 30.00 20.00, 20.00
> 20.00))
> POLYGON ((3.00 3.00, 3.00 4.00, 4.00 4.00, 4.00 3.00, 3.00 3.00))
>
> I'm ok with the first and second, but the third one has already been
> used as a "hole" inside the first and should not be returned again -
> or is there a misunderstanding on my part?
>
> Bye
> Frederik
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
------------------------------
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
End of geos-devel Digest, Vol 82, Issue 7
*****************************************
-- "#define QUESTION ((bb) || !(bb))" (Shakespeare)
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
|
