<br>
<div>The benefit of object oriented programming. </div>
<div>ESRI has the network analyst extension, schematics extension, which together allow the topology to be accurately described (network analyst) and the data to be simplified for cartographic (schematic) purposes. Along with full support for many RDBMS rules based triggers. I think this has your system described.<br>
<br>I hope this doesn't inflame anyone but simply gives a direction for future development.</div>
<div> </div>
<div> </div>
<div><br> </div>
<div class="gmail_quote">On Fri, Jul 22, 2011 at 8:26 AM, Zoltan Szecsei <span dir="ltr"><<a href="mailto:zoltans@geograph.co.za">zoltans@geograph.co.za</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><u></u>
<div bgcolor="#ffffff" text="#000000">Hi Darryl & list.<br>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.<br>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.<br>
<br>I know this sounds naively idealistic, but maybe I have been spoilt.<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>my 2c,<br>Zoltan<br>[and sorry about the history lesson]<br>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.<br>
At this point, luckily, I have run out of 2c coins :-)
<div>
<div></div>
<div class="h5"><br><br><br><br>On 2011/07/22 14:53, Darryl Bailey wrote: </div></div>
<blockquote type="cite">
<div>
<div></div>
<div class="h5">
<div>Hi,</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Here is a link to the SpatiaLite disscussion <a href="http://groups.google.com/group/spatialite-users/browse_thread/thread/39a355fab8202081/3883d30053e35d07#3883d30053e35d07" target="_blank">http://groups.google.com/group/spatialite-users/browse_thread/thread/39a355fab8202081/3883d30053e35d07#3883d30053e35d07</a></div>
<div> </div>
<div>Regards</div>
<div>Darryl Bailey </div></div></div><pre><fieldset></fieldset>
_______________________________________________
Qgis-user mailing list
<a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a>
</pre></blockquote><br><br><pre cols="72">--
===========================================
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: <a href="tel:%2B27-21-7884897" target="_blank" value="+27217884897">+27-21-7884897</a> Mobile: <a href="tel:%2B27-83-6004028" target="_blank" value="+27836004028">+27-83-6004028</a>
Fax: <a href="tel:%2B27-86-6115323" target="_blank" value="+27866115323">+27-86-6115323</a> <a href="http://www.geograph.co.za/" target="_blank">www.geograph.co.za</a>
===========================================</pre></div><br>_______________________________________________<br>Qgis-user mailing list<br><a href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
<br></blockquote></div><br>