On 2012/10/30 16:13, Burgstaller Stefan wrote:
@Zoltan:
I will explain my problem now in detail since I think that this
problem could be known to a lot of users:
In Germany we can order cadastre data in a proprietary format from our
land surveying offices. To be able to use this proprietary ASCII
format with common GIS software we convert the geometry objects with
corresponding data into point-, line- and polygon-shapes.
Unfortunately the source to convert contains different errors like
unclosed polygons (start and end coordinates are not the same), null
geometries, incorrect ring ordering, duplicate vertex or self
intersections, which are not repaired by the converting tool and
therefore lead to errors in the shape files. When I want to use these
shapefiles later for spatial functions like a select by location with
calculating intersections based on one of these error-shapes, the
results can be wrong due to the errors named above. Until now I did
not find any software function to solve these problems "smart" with a
few clicks except for the geometry repair functions provided by ArcGIS.
Even the GRASS v.clean function will not solve the problems listed above.
Greetings,
Stefan Burgstaller
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
Hi Stefan,
We have the same issues in South Africa with our Land Survey data.
I went a long way to cleaning the data by writing C code to check and
log, or repair and log the source data as I converted/cleaned it for a
client.
This was about 7 years ago.
I'm guessing when you get updates to the cadastre, you get the whole
data set again, so you have a repeat-cleaning cycle.
In my opinion the only way to handle this is with custom code.
Take each land parcel and if it seems clean, pass it through.
Then look at the left overs to see if you can find a common thread of
errors, program that, and re run to get a new set of leftovers.
Once that is done, you can start looking at the relative positions and
uses (road widening or land parcel) and start figuring out the slivers
and overlaps and other issues.
It is not as simple as I make it out to be, but it is the only way to
protect your data from being too unreliable, and to stop you having to
manually redo all the work again, for every update you get.
It's a big effort, but well worth it if you are the only one with a
clean data-set :-)
I am likely to be out of office quite a lot for the next 4-6 weeks,
otherwise I would ask you for a sample to see if I could offer better
guidance.
Let me know how you go - and how you end up solving it.
Good luck and kind regards,
Zoltan
--
===========================================
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
P.O. Box 7, Muizenberg 7950, South Africa.
65 Main Road, Muizenberg 7945
Western Cape, South Africa.
34° 6'16.35"S 18°28'5.62"E
Tel: +27-21-7884897 Mobile: +27-83-6004028
Fax: +27-86-6115323 www.geograph.co.za
===========================================
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
