<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Brent,<div><br></div><div>I think I misunderstood what you were doing, but it sounds like you are storing two separate pieces of information (start and end point), not the same information in two separate columns. Is this right? I certainly agree that storing a line is inappropriate in that case, in the same way that storing zero is an inappropriate solution to represent no (null) data.</div><div><br></div><div>This certainly proves that no one solution fits all - good news for those of us making a living from data solutions development I guess!</div><div><br></div><div>cheers</div><div><br></div><div>Ben</div><div><br></div><div><br><div><div>On 04/09/2009, at 3:05 , <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>Hi Chris,<br><br>I accept that some of the extra geometries could be construed as denormalising, where the geometries are in fact the same, and we physically store more than one projection.<br><br>However I disagree that storing a start & finish point of an event such as these is denormalised, any more than storing separate start & finish times for the event is.<br><br>While you may use a trackline between these points to to represent such an <br>event in a fully denormalised database, I don't believe this is actually a normalising process, as the actual path traversed is often unlikely to have been a straight line, so the line is an estimated path derived from known measurements. Storing the measurements in separate columns as 2 point geometries does not imply any level of denormalisation. <br><br>Sure, it is possible to have a single timestamp column, which can store start & finish times, & be joined to the event, just like it is possible to have a single varchar() column to store all string fields such as name, street address, suburb, city, county, state & country, each of which is appropriately flagged & then joined in a self relation to retrieve an address, but this is not generally considered as normalisation, nor is storing strings representing different attributes in different columns regarded as denormalised.<br><br>I don't see why a geometry is any different from timestamps or strings in the relational model, such that only one geometry column is possible in a normalised model, but other datatypes can have more than one, when the entity being modelled (in this case an event in time & space) in fact has more than one geometry attribute to store.<br><br>I accept this is different from multiple SRIDS, & about multiple geometries... <br><br><br>Regards,<br><br> Brent Wood<br><br><br>--- On Fri, 9/4/09, Chris Hermansen <<a href="mailto:chris.hermansen@timberline.ca">chris.hermansen@timberline.ca</a>> wrote:<br><br><blockquote type="cite">From: Chris Hermansen <<a href="mailto:chris.hermansen@timberline.ca">chris.hermansen@timberline.ca</a>><br></blockquote><blockquote type="cite">Subject: Re: [postgis-users] several SRID on one table<br></blockquote><blockquote type="cite">To: <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a>, "PostGIS Users Discussion" <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote><blockquote type="cite">Date: Friday, September 4, 2009, 2:43 AM<br></blockquote><blockquote type="cite">Hi Brent;<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What you are in effect doing is denormalizing your database<br></blockquote><blockquote type="cite">for performance reasons.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In a perfect world, you would only store the initial<br></blockquote><blockquote type="cite">information, and use geometric functions to generate the<br></blockquote><blockquote type="cite">derived info on the fly. Of course it's not yet a perfect<br></blockquote><blockquote type="cite">world... And so it's reasonable to denormalize to improve<br></blockquote><blockquote type="cite">performance.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Therefore the objective being to improve performance, the<br></blockquote><blockquote type="cite">denormalizations must be done to ensure that.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In some cases, all will be well with everything on one<br></blockquote><blockquote type="cite">table; like for instance when the application re-uses more<br></blockquote><blockquote type="cite">than one of the stored computed geometries at the same time,<br></blockquote><blockquote type="cite">and the cost of "use" is greater than the additional I/O<br></blockquote><blockquote type="cite">overhead created by joining multiple separate - perhaps<br></blockquote><blockquote type="cite">clustered - tables together as needed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This would likely depend mostly on the width of the rows in<br></blockquote><blockquote type="cite">the single-table approach.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The opposite would be the case if the application only used<br></blockquote><blockquote type="cite">one geometry at a time, for example storing the same<br></blockquote><blockquote type="cite">geometry in two different projections. In this case, the<br></blockquote><blockquote type="cite">performance is better with a separate table for each<br></blockquote><blockquote type="cite">geometry (more rows retrieved per physical read).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As Ben points out, this separate table approach, in this<br></blockquote><blockquote type="cite">second type of application, adds some clarity as well.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This isn't an issue of whether or not it's good or bad<br></blockquote><blockquote type="cite">design to have multiple geometries per row; it's bad design,<br></blockquote><blockquote type="cite">but nevertheless acceptable and common practice to<br></blockquote><blockquote type="cite">denormalize for performance.<br></blockquote><blockquote type="cite">Chris Hermansen <a href="mailto:chris.hermansen@timberline.ca">chris.hermansen@timberline.ca</a><br></blockquote><blockquote type="cite">tel+1.604.714.2878 · fax+1.604.733.0631 ·<br></blockquote><blockquote type="cite">mob+1.778.840.4625<br></blockquote><blockquote type="cite">Timberline Natural Resource Group · <a href="http://www.timberline.ca">www.timberline.ca</a><br></blockquote><blockquote type="cite">401 · 958 West 8th Avenue · Vancouver BC · Canada<br></blockquote><blockquote type="cite">· V5Z 1E5<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Date: Thu, 3 Sep 2009 00:20:02 <br></blockquote><blockquote type="cite">To: Ben Madin<<a href="mailto:ben@remoteinformation.com.au">ben@remoteinformation.com.au</a>><br></blockquote><blockquote type="cite">Cc: <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote><blockquote type="cite">Subject: Re: [postgis-users] several SRID on one table<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi Ben,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I use mutiple geometries in a table not just to have<br></blockquote><blockquote type="cite">multiple projections of the same geometry, but in one<br></blockquote><blockquote type="cite">example, dealing with fishing trawler paths, the dataset has<br></blockquote><blockquote type="cite">(supposedly) a start & finish position (but as lat/lon<br></blockquote><blockquote type="cite">numbers- the source database is not spatially enabled), just<br></blockquote><blockquote type="cite">as it does a start & finish time. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">To say only one position can be stored is as reasonable as<br></blockquote><blockquote type="cite">saying only one timestamp can be stored. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I can also generate a trackline between these as an<br></blockquote><blockquote type="cite">estimated line traversed, and buffer this by a gear width<br></blockquote><blockquote type="cite">(/2) to get an estimated swept area. So with only one<br></blockquote><blockquote type="cite">projection, I can have 4 geometries representing the same<br></blockquote><blockquote type="cite">entity.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I store the buffer in both lat/lon & a custom equal<br></blockquote><blockquote type="cite">area projection. I typically map the lat/lon one, along with<br></blockquote><blockquote type="cite">all the other relevant layers, but use the equal area one<br></blockquote><blockquote type="cite">for area calculations/spatial analyses.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I agree that the user needs to ensure the two versions are<br></blockquote><blockquote type="cite">kept synchronous. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A view with a transform()ed geometry can provide this<br></blockquote><blockquote type="cite">capability pretty well, but loses the spatial index<br></blockquote><blockquote type="cite">(although I guess you could create an index on the<br></blockquote><blockquote type="cite">transformed version - I haven't tried), & transform()<br></blockquote><blockquote type="cite">does add noticeable overhead when you have 10s of millions<br></blockquote><blockquote type="cite">of polygon geometries.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Brent Wood<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--- On Thu, 9/3/09, Ben Madin <<a href="mailto:ben@remoteinformation.com.au">ben@remoteinformation.com.au</a>><br></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">From: Ben Madin <<a href="mailto:ben@remoteinformation.com.au">ben@remoteinformation.com.au</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [postgis-users] several SRID on one<br></blockquote></blockquote><blockquote type="cite">table<br></blockquote><blockquote type="cite"><blockquote type="cite">To: <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a>,<br></blockquote></blockquote><blockquote type="cite">"PostGIS Users Discussion" <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote><blockquote type="cite"><blockquote type="cite">Date: Thursday, September 3, 2009, 3:40 PM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Arguably the relational<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">database concept is meant to avoid storing the same<br></blockquote></blockquote><blockquote type="cite">data<br></blockquote><blockquote type="cite"><blockquote type="cite">more than once, but I have also done this to reduce<br></blockquote></blockquote><blockquote type="cite">overhead<br></blockquote><blockquote type="cite"><blockquote type="cite">during complex output queries (ie storing a point on<br></blockquote></blockquote><blockquote type="cite">surface<br></blockquote><blockquote type="cite"><blockquote type="cite">of a polygon instead of calculating it each time).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ultimately, it worked out slightly faster to have<br></blockquote></blockquote><blockquote type="cite">multiple<br></blockquote><blockquote type="cite"><blockquote type="cite">smaller tables, as we only wanted one aspect of the<br></blockquote></blockquote><blockquote type="cite">geometry<br></blockquote><blockquote type="cite"><blockquote type="cite">at any one time. When it came for time for others to<br></blockquote></blockquote><blockquote type="cite">use the<br></blockquote><blockquote type="cite"><blockquote type="cite">same data, it was also much clearer to them what was<br></blockquote></blockquote><blockquote type="cite">going<br></blockquote><blockquote type="cite"><blockquote type="cite">on.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It might be a good time to add that storing the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">same data in multiple formats requires some method to<br></blockquote></blockquote><blockquote type="cite">ensure<br></blockquote><blockquote type="cite"><blockquote type="cite">concurrency - if someone updates the column that is<br></blockquote></blockquote><blockquote type="cite">in<br></blockquote><blockquote type="cite"><blockquote type="cite">WGS84, a trigger to update the other columns would be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">essential to avoid returning mixed version<br></blockquote></blockquote><blockquote type="cite">information. This<br></blockquote><blockquote type="cite"><blockquote type="cite">obviously holds true whether you have multiple columns<br></blockquote></blockquote><blockquote type="cite">in<br></blockquote><blockquote type="cite"><blockquote type="cite">one table or multiple tables with one column<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">each.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cheers<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ben<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 02/09/2009, at 3:13 , <a href="mailto:pcreso@pcreso.com">pcreso@pcreso.com</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">H Steve,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I have had recommendations that this is not good<br></blockquote></blockquote><blockquote type="cite">practice,<br></blockquote><blockquote type="cite"><blockquote type="cite">but I have done this often myself for various reasons,<br></blockquote></blockquote><blockquote type="cite">with<br></blockquote><blockquote type="cite"><blockquote type="cite">good success.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">As far as I'm concerned, a very useful ability of a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">spatially enabled RDBMS is to realise that a geometry<br></blockquote></blockquote><blockquote type="cite">is<br></blockquote><blockquote type="cite"><blockquote type="cite">only an attribute of an entity, like a date, time,<br></blockquote></blockquote><blockquote type="cite">numeric<br></blockquote><blockquote type="cite"><blockquote type="cite">or string type. Real world entities can be represented<br></blockquote></blockquote><blockquote type="cite">by<br></blockquote><blockquote type="cite"><blockquote type="cite">multiple geometries, and have multiple dates, etc,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> associated with them, so this is a perfectly good<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">model, and offers substantial benefits over the<br></blockquote></blockquote><blockquote type="cite">(dated) GIS<br></blockquote><blockquote type="cite"><blockquote type="cite">model where the geometry is somehow more special than<br></blockquote></blockquote><blockquote type="cite">other<br></blockquote><blockquote type="cite"><blockquote type="cite">attributes of a feature/entity. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cheers,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> Brent Wood<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--- On Wed, 9/2/09, <a href="mailto:Steve.Toutant@inspq.qc.ca">Steve.Toutant@inspq.qc.ca</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="mailto:Steve.Toutant@inspq.qc.ca">Steve.Toutant@inspq.qc.ca</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: <a href="mailto:Steve.Toutant@inspq.qc.ca">Steve.Toutant@inspq.qc.ca</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="mailto:Steve.Toutant@inspq.qc.ca">Steve.Toutant@inspq.qc.ca</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">[postgis-users] several SRID on one table<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To: "PostGIS<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Users Discussion" <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Wednesday,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">September 2, 2009, 2:46 AM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hello,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">We need to use a table<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">several purposes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with different SRID.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is it a good practice<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">have several<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">geometry columns on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">one table or should we create one table<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">per SRID?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What are the pros and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cons<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of using<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">several geometry<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">columns on one table? <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">thanks<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Steve<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Steve Toutant, M.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sc.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Analyste en<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">géomatique<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Secteur environnement<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Direction des risques<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">biologiques, environnementaux et<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">occupationnels<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Institut national de<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">santé publique du Québec<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">945, avenue Wolfe<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Québec, Qc G1V 5B3 <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tél.: (418) 650-5115<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#5281<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fax.: (418) 654-3144<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:steve.toutant@inspq.qc.ca">steve.toutant@inspq.qc.ca</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://www.inspq.qc.ca">http://www.inspq.qc.ca</a><br></blockquote></blockquote><br><blockquote type="cite"><blockquote type="cite"> <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-----Inline Attachment<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Follows-----<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">postgis-users mailing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote></blockquote><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">postgis-users mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote></blockquote><br><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Ben Madin<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">REMOTE INFORMATION<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">t : +61 8 9192 5455<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">f : +61 8 9192 5535<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">m : 0448 887 220<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Broome WA 6725<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:ben@remoteinformation.com.au">ben@remoteinformation.com.au</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> <br></blockquote></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Out<br></blockquote><blockquote type="cite"><blockquote type="cite">here, it pays to know...<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">postgis-users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br></blockquote><blockquote type="cite"><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote><br><blockquote type="cite"><br></blockquote>_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>http://postgis.refractions.net/mailman/listinfo/postgis-users<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><br class="Apple-interchange-newline">-- </div><div><br>Ben Madin<br>REMOTE INFORMATION<br><br>t : +61 8 9192 5455<br>f : +61 8 9192 5535<br>m : 0448 887 220<br>Broome WA 6725<br><br><a href="mailto:ben@remoteinformation.com.au">ben@remoteinformation.com.au</a><br><br><br><br><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span><span class="Apple-tab-span" style="white-space: pre; "> </span>Out here, it pays to know...<br><br></div></span>
</div>
<br></div></body></html>