Hmmm... isn't your underlying data stored in a some kind of datastore?
So you will need to perform your search using the capabilities of that
datastore?
But I can see how you might be retrieving a set of candidate polygons
(based on an intersection with a candidate bounding box for the search
area), and then wanting to filter the results based on true distance.
I think you're going to have to compute a suitable bounding box for your
initial search in web mercator. This will require some ellipsoidal
calculation, I think.
To implement the secondary true distance filter you have two options -
reproject first, or use the (non-existant) ellipsoidal JTS distance
computation. It's not clear to me which would be more performant.
Reprojection costs cycles, but computing ellipsoidal distance takes (a
lot?) more cycles than Euclidean distance. It might be a toss-up about
which is faster. You can easily try it - it shouldn't be too hard to
code up a Distance class using the Vincenty distance.
Jeff Adams wrote:
Wow, what a conversation I started!
So here's my use case:
I have a web app that is displaying polygons and points (different
layers) on a "North America" scale (although of course you can zoom in
to any particular area of interest). All the data is in "Web
Mercator" projection.
1) I need to allow the user to choose a location and "search by radius
(in miles)" for features in one of the point or polygon layers.
2) I need to find the nearest polygon to a point (although this one is
less critical, as it's a hack to get around bad data and there's a
chance we can get better data).
Any reprojecting I will be doing will be on the fly, as the underlying
data has to remain in web mercator. Since we're talking a web app,
I'm a little concerned about reprojecting a whole lot of polygons on
the fly just to check distance, I'm concerned that performance will be
a problem (I.E. it won't be very responsive). Some of the polygons
follow county boundaries and stuff so they can have a lot of points
(although I could simplify them first if it were faster).
Paul, I would love to get your code for "Vicinity Distance". In the
interests of full disclosure however I must admit this is paid work
for a commercial customer, so I can understand if you do not wish to
give me a copy of the code.
Thanks,
Jeff
On Thu, Feb 5, 2009 at 1:08 PM, Martin Davis <[email protected]
<mailto:[email protected]>> wrote:
Another issue with ellipsoidal (geodetic) calculation is the whole
date line/poles wrapping issue. This is a major pain to deal
with. I guess local projections can be used to deal with this as
well, though.
Seems like it would be nice to have a library that would
automatically choose the best projection, do the transformation,
compute the result, and untransform...
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
<mailto:[email protected]>
http://lists.refractions.net/mailman/listinfo/jts-devel
------------------------------------------------------------------------
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
