[postgis-users] Snapped polygon

fpanettieri at xoomcode.com fpanettieri at xoomcode.com
Thu Jul 22 17:58:45 PDT 2010


>> 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




More information about the postgis-users mailing list