So i have two layers and a script that uses arcpy.SpatialJoin_analysis to do a spatial join. Basically it spacial joins a zoning layer to parcels but upon further review it seems as i get weird results after the spatial join. In the "FZONE_CODE" field i get some that have 3 different zones. Which in some case can be the case not always and i find it through out spatial joined layer.
The 1st example(image1) i have is the parcel is joined with the zoning and it should just be Ind(blue) but if you look at it Yellow(Res) or Red(Com) doesn't go into the that parcel but the "FZONE_CODE" field states it's ComIndRes.
Second example (image2) after the spatial join has a parcel with ResResRes but Res(yellow) doesn't go into that parcel either but some how it has ResResRes in the "FZONE_CODE" field.
So i thought maybe i didn't snap to the end point or vertex correctly so i zoomed in as close as i can and i notice that vertex of the Zoning layer is not snapped to the vertex or end of the parcel so i try to move the zoning feature to the end/vertex of the parcel but it doesn't snap to it, it snaps off to the side(image3). So i am thinking this is why i get those weird results i am talking about. Ever time i try to move it just snaps the the side of the end or vertex, so my question is this normal?
snap is either end, vertex or edge whether you are in edit mode or otherwise, see the illustrations here
Snap—Help | ArcGIS for Desktop and here
About the editing classic snapping environment—Help | ArcGIS for Desktop
I have looked through the help docs and made sure i have the snapping correct, but what i don't understand is why it's truly not snapping to either end or vertex after zooming in super close. I think this is why i am getting weird results after the spatial join.
if works point by point, the whole feature doesn't snap at once, so if you want to ensure snap, then you will have to edit the feature by vertex, which is much slower than creating the feature with appropriate snapping in the first place, or in the case of polygons, appending the polygons to existing ones instead of retracing boundaries.
As per our phone interaction, a map scale past 1:1 is a known limitation of our software because at a scale of 1:1, the screen display is equal to the actual distance of objects on the earth's surface (i.e. an inch on your screen is equal to an inch on the ground). When you go past that scale, it may appear that features are overlapping (when in reality) what you are seeing is the actual software resolution tolerance pushed past it's maximum threshold. In essence, the entire screen is only one point (at a map scale of 1:0), which is why your work flow is producing inaccurate results.
Strangeness - gaps unintentionally created while editing
Chris Donohue, GISP
I figured that if i was to zoomed in the lines might look off but i wasn't sure but now i know thank for the info.
Since i now know that snapping is not the issue i still have the problem with parcel taking various zoning attributes when clearly the zoning doesn't over lap on to that parcel. I have check geometry and ran topology on the zoning and parcels and there is some topology errors on the taxparcels but none on where the zoning is spatial joined to the parcels.
I will try to post some data and see if anyone can take a look at it for me and help figure what's going on.