<br><br><div><span class="gmail_quote">On 29/08/2007, <b class="gmail_sendername">Brett Henderson</b> <<a href="mailto:brett@bretth.com">brett@bretth.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
David Siegel wrote:<br>> On 29.08.2007, at 09:41, Martijn van Oosterhout wrote:<br>><br>><br>>> On 8/29/07, Brett Henderson <<a href="mailto:brett@bretth.com">brett@bretth.com</a>> wrote:<br>>><br>
>>> There is already a --bounding-box filter task.  Presumably you're<br>>>> looking for something more accurate than a square ...  If so, I have<br>>>> some research to do, I don't know how to figure out if a point fits
<br>>>> inside a shape.  Hopefully the algorithm isn't too difficult.<br>>>><br>>> Don't write code you don't need to, see:<br>>> <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Polygon.html">
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Polygon.html</a><br>>> You can create a Polygon object and then call the contains() function.<br>>><br>>><br>><br>> I agree with Martijn. Don't write it yourself. AFAIK finding points
<br>> in a general polygon (not convex and with holes) is absolutly non-<br>> trivial. It becomes a lot easier for convex polygons without holes<br>> but it still requires very clever data structures and algorithms to
<br>> get it efficient. If you find that awt/Polygon is too slow you might<br>> want to take a look at the Java Topology Suite:<br>><br>> <a href="http://www.jump-project.org/project.php?PID=JTS&SID=OVER">
http://www.jump-project.org/project.php?PID=JTS&SID=OVER</a><br>><br>Bugger, I was getting excited about writing this :-)  I was planning on<br>drawing a line from a point to edge of the world and counting the number
<br>of edges crossed where odd=inside the polygon, even=outside.  But you're<br>both right, why re-invent it and get it wrong.  Another guy from work<br>with some background in geo-spatial apps suggested the java.awt.Polygon
<br>api as well.  The only issue is that a polygon is defined by integer<br>coordinates, not doubles.  I guess I could fudge it by multiplying<br>lat/lon by a fixed constant and losing some precision but it's not ideal ...
</blockquote><div><br><br>You should be able to use the java.awt.geom.GeneralPath class which is ... errm... more general (and uses floats). I don't know how this would impact on performance though. The java.awt.geom.Area
 may also be of interest for nice cag functionality.<br><br></div><br></div><br>