select layer by location returns empty results

[davidzornosa]

Hi,

What i intend to do is to get all points from Table A that fall within some records of Table B.

- Table A: point geometry. Represents events that occur in certain spots

- Table B: polygon geometry. Represents geographic, non overlapping, areas

- I turn them into feature layers so they can be fed to "select layer by location".

- "Table A layer" is the input feature

- "Table B layer" contains the selecting features

I've checked visually that there indeed exist points in table A that fall within polygons present in Table B, however all i get, when i publish the service, is an empty collection in "results".

Any ideas,

thanks

[davidzornosa]

Hi Vandana, no its not a personal or file gdb, its oracle 11g -with SDE mounted-. If i try to use the tool you suggested, it throws an errror, besides, the following message seems to stablish that if data is in an sde database, it has to be right.

"SDE Geodatabases automatically check the validity of each geometry when they are uploaded; therefore the Check Geometry and Repair Geometry tools are not for use with SDE."

Thanks

[VandanaRaghunathan]

David,

That is correct, SDE automatically checks for validity. There might be more troubleshooting involved with the Oracle database to see why the select by location does not recognize the points. What happens when you import the shapefiles back to Oracle? Does Select by Location work on the imported oracle feature class?

Thanks,

Vandana

[davidzornosa]

Chad Kopplin‌, Dan Patterson‌, Todd Blanchette‌

this exercise worked. if i export the tables to shapefiles and those resulting shapefiles i export back to oracle tables, the new tables correctly work with the "select by location" tool.

This makes me think that the problem has something to do with the way table a and b are being populated: sql. The points and the polygons are not being generated via arcmap or such but by means of sde sql packages.

thank you

[DanPatterson_Retired]

ahhh... a GIS example of...work local, think global

[VandanaRaghunathan]

David,

That is great, glad is it is working now from Oracle.

Yes, most likely the way the original feature classes were created probably attributes to the issue.

Thanks,

Vandana

[davidzornosa]

Chad Kopplin, Dan Patterson, Todd Blanchette

One thing stills mystifies me: it seems to be common knowledge the fact that tables having a geometry column are somehow not valid, or not fully valid at least, geographic elements, not in the way a shapefile seems to be. Could you please suggest some article i can read to have this bothersome matter straightened out? thanks

[VandanaRaghunathan]

David,

Can you elaborate on the question with screenshots of the tables you are referring to?

Thanks,

Vandana

[davidzornosa]

Hi Vandana, the tables i'm using right now have:

A:

objectid      (double)

shape         (geometry [point])

B:

objectid        (double)

shape          (geometry [ polygon ])

shape.area  (double)

shape.len    (double)

If i understood what Chad Kopplin‌ and Dan Patterson‌ said, the actual geometry data is not stored in neither of the "shape" columns, but somewhere else.

So, along these lines, what might be causing the problem is some failure to comunicate between the table and the place where its geometry is actually stored.

That's what i want to clarify.

thanks

[VandanaRaghunathan]

Hello David,

It is hard to say what happened with the original oracle database feature class for it to fail in Select By Location without looking at the data. It could be due to several different factors. When you exported the data to shapefile and imported it back into Oracle, the inconsistencies were "fixed".

Yes, Shape* field indicates geometry and the feature needs to have geometry (feature layer) to be a valid input for Select by Location. You cannot add tables to the tool.

Hope this helps.

-

Vandana

[ChadKopplin]

That is right; so, you could change your model to access the actual feature

class or shapefile that the table is associated with, then you have the

actual geometry and you will not have to convert the table to a shapefile,

feature class, or layer. Then your model should work because you are using

the actual layer that contains the geometry.