Kedar Deshpande wrote:
Thanks David, it is now clear to me why do we get multiple
features.
So, for example, if we have a small zipcode which is kind of
embedded in a large zipcode of 'L' shape, for any point inside the
inner zipcode, it will return both zipcodes since the envelope of the L
zipcode always overlaps the inner one. (real example : zipcodes 98367
and 98359)
So, instead of comparing only the envelope overlap, is it not
possible to check the overlap of that specific polygon shape? so that
the result would be more accurate. The feature should have the polygon
information, right ? .. Is there a way to filter it out based on its
shape (not just rectangular envelope), in this library?
As Frank mentioned before not without linking in the geos library.
Otherwise what you can do is test to see if your point is in any of the
polygons returned by OGR. So let OGR do the initial checks then grab
the vertices yourself and run a point in polygon test. There are
multiple examples of the crossings test available on the web search for
code point in polygon to see a bunch in google. Just pick the one
that's appropriate for whatever language you're using.
On Tue, Jun 12, 2012 at 11:34 AM, David J.
Bakeman <[email protected]>
wrote:
I think a picture is needed
here so here is one with zip code boundary
polygons I emphasized the envelopes of the polygons near the purple
point and you can see that 3 of the envelopes (in yellow) are
intersected by the purple point and would all be returned by an
overlapped envelope test.
Here I zoomed in
kedardeshpande87 wrote:
Frank,
Thank you very much for the reply.
I am still really curious about what could be the reason that it returns
multiple features for a single point.
The code for filtering which I have written is like this :
...
OGRDataSource *ds = OGRSFDriverRegistrar::Open("shapefile_path", FALSE);
OGRLayer *layer = ds->GetLayer(0);
OGRGeometry *g = new OGRPoint(longitude, latitude);
layer->SetSpatialFilter(g);
OGRFeature *feature = NULL;
while((feature = layer->GetNextFeature()) != NULL) {
// do something with feature ...
}
As per the API doc, it says : "it is guaranteed that all features who's
envelope (as returned by OGRGeometry::getEnvelope()) overlaps the envelope
of the spatial filter will be returned."
I checked the envelope the OGRPoint geometry I have created. This envelope
is also a single point (minX, maxX are same and minY, maxY are same). So,
how is it possible that multiple features overlap on the same point ?
For the same shapefile, I checked results by using some other libraries as
well. Those libraries return a single zipcode. So I am guessing the
shapefile which I am using does not have overlapping data.
Could it be that the vector math done while calculating the intersection of
filter-geometry and features has some limitations?
Could you please give me some idea about this ?
Thanks,
Kedar
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Re-Accuracy-of-OGRLayer-SetSpatialFilter-API-tp4980063p4980907.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
|
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
