[Qgis-user] Re: Multiple geometries in an import file (Darryl Bailey)

[Zoltan Szecsei]

Hi Darryl & list.
I have not looked at the Spatialite discussion, and may not have time to 
do so right now - so yes, there may be a viewpoint that I have missed.
But my comment is quite simply that it is the programmers duty to write 
code that does the job correctly, without the user hitting problematic 
caveats.

I know this sounds naively idealistic, but maybe I have been spoilt.

My first exposure to GIS was the mainframe based SICAD - which had both 
full topology, and a scripting language. At user level you could simply 
walk through the data structue, and ask questions like "what area 
features lie on each side of my current line feature that I am 
querying?" The rendering was pretty good, even though we are talking 
mainframe based technology during the period 1984 to 1989.

I then went on to Genamap which is/was UNIX/Linux based and has exactly 
the same, and more, capabilities (than SICAD had). I have used Genamap 
since 1990 (yep, >21 years), and enjoyed full freedom from having to 
split geometries etc. It renders with its own java based methods, and 
also SVG.

So no, I can't agree with the point of view that speed comes before data 
integrity, and sit and wonder why the old programmers got it right, and 
the new ones find reason not to do it the (programmatic) difficult way.

my 2c,
Zoltan
[and sorry about the history lesson]
PS: Property survey data is notoriously "wrong" [ie: full of slivers, 
overlaps etc] and is a prime candidate for exactly the opposite of 
Darryls example: Put the documented surveyed coordinates as attributes, 
and then create a "best possible" topologically correct map, so that the 
user is able to make queries on adjoining properties through the 
topology rather than through spatial mechanisms.
At this point, luckily, I have run out of 2c coins :-)



On 2011/07/22 14:53, Darryl Bailey wrote:
> Hi,
> I've been thinking along simialir lines with property survey data.  I 
> figured that its not really the GIS program's task to do this, but the 
> underlying file or data structure.  The way i see it is that instead 
> of having the coords "hard coded" for the sewer lines, it would be 
> preferable that the sewer lines coords reference those coords as 
> defined by the manholes.  So if you change the manholes' coords then 
> the sewer line is automatically updated.
> I thought this may be catered for by SpatiaLite and put the query to 
> their user list and got quite a good response.  Basically this sort of 
> setup (strict topology) hampers processing speed(and viewing speed for 
> that matter), which is what the majority of the end product of a GIS 
> is used for.  This got me thinking - keep the topological data as 
> attribute data and then create the spatial data as and when required 
> so that the coords are hard coded into the actual spatial 
> file/dataset.  Maybe a QGis plugin could be created to do this.
> Here is a link to the SpatiaLite disscussion 
> http://groups.google.com/group/spatialite-users/browse_thread/thread/39a355fab8202081/3883d30053e35d07#3883d30053e35d07
> Regards
> Darryl Bailey
>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user


-- 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20110722/5ef871cb/attachment.html>