>> Hi Nicolas >> >> Thanks that helped me improve the validation queries, but the problem >> remains there. >> >> Given I want to validate that the building is inside a block and its >> totally contained, I came up with the following intersection matrix. >> >> SELECT ST_Relate(building, block, '2*F**F***') => false. >> >> The result tells me that it's not inside, but the difference still >> yields an empty geometry collection. >> >> I have attached the geometries now, so you can see if I'm missing >> something. >> >> PS: >> With the previous polygons in WKT format, results differed a little from >> what I told you, sorry, my fault. >> -- > > I think its a precision problem: > looking closely at your polygons, I can see this little overlapping > between buildings and blocks, leading to think a building is outside a > block (blocks in blue, buildings in brown on img1). > By moving the building vertex by hand, to force it to be inside its > block, the st_relate returns true as it should. > > Concerning st_difference, I guess that the overlapping is so tiny that > difference can't rebuild the polygon, though Postgis experts could > confirm this. > > Nicolas >
Yes it seems that there is a small overlapping caused by the digitalization process. I think that the snap tool used caused this. Even if It could be fixed using ST_SnapToGrid, these comes with 2 other problems: * I will be modifying data, that I should only validate, so i can't do that to solve the problem. * In some cases the SnapToGrid caused some self-intersections. Given that the area of a ST_Difference is always 0 in all this cases, i'll use it to check the geometries. I know it's not the best option, and doesn't feel right. -- Fabio R. Panettieri Software Architect http://www.xoomcode.com _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
