<html>
<head>
        <title></title>
        
<meta name="GENERATOR" content="MSHTML 8.00.6001.18876"></meta>
        
<meta name="SKYPE_FRAMEID" content="UKSDOXEVME"></meta>
        
<meta id="skype_v3_tb_marker_id" name="SKYPE_PARSING_HAS_FINISHED" content="metacontent"></meta>
</head>

<body>
        
<div align="left">yes, there was a lot of good information. Also the topological part was very informative. The rest I haven't read yet</div>
        
<div align="left">Great</div>
        
<div align="left"> </div>
        
<div align="left">/Nicklas<br />
                <br />
                2010-01-23 Paul Ramsey wrote:<br />
                <br />
                LRS needs to be done carefully, so as to not make it (a) more muddled<br />
                >than it already is or (b) less useful. Right now we have two sets of<br />
                >functions, some that work on measured geometries, and some that work<br />
                >on unmeasured. And, as you note, we generally ignore the third<br />
                >dimension in calculating the proportionality of things. There's some<br />
                >ideas on the unification here:<br />
                ><br />
                >http://opengeo.org/products/coredevelopment/postgis/lrs/<br />
                ><br />
                >I think the simplest approach to the third dimension is to say "if<br />
                >it's there, it's relevant" and include it in calculations of<br />
                >proportional length. (That said, I just now ignored it in my<br />
                >implementation, I'm such a flatlander.)<br />
                ><br />
                >Paul<br />
                ><br />
                >On Fri, Jan 22, 2010 at 4:45 PM, Nicklas Avén<br />
                >
                <nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> wrote:<br />
                >> Hallo<br />
                >><br />
                >> I have thought that I should raise some ideas about the line reference<br />
                >> functions after this release. I mention it noe because it is a close<br />
                >> subject.<br />
                >><br />
                >> I would like to rewrite the linereferencing functions like ST_Line_Substring<br />
                >> to do the measure in all 3 dimensions. I am not sure I suggest that there<br />
                >> should be a different behaviour in that function but rather make a new that<br />
                >> also handles the measure in units like meters instead of parts of the whole<br />
                >> line.<br />
                >><br />
                >><br />
                >><br />
                >> But the thing that was connected to this question was this about measuring<br />
                >> in 2 or three dimensions. Does this customer wants it in 2D measuring or<br />
                >> will he or she only work in 2 D so it doesn't matter.<br />
                >><br />
                >> What I mean is that if we want to go against 3Dmeasuring at line referencing<br />
                >> maybe that should be included in the bbeginning on this one?<br />
                >><br />
                >> Just a thought.<br />
                >><br />
                >> What is needed as I understands it is just another function like<br />
                >> distance3d_pt_pt that uses 3 dimensions in pythagora theorem.<br />
                >><br />
                >> In this function it would not matter that is only following the ground or a<br />
                >> line that has the same angel to the ground all the way. But it would be a<br />
                >> difference on a line following the ground and then suddenly continuing ut on<br />
                >> a mountain or something like that.<br />
                >> Just a thought<br />
                >><br />
                >> /Nicklas<br />
                >> 2010-01-22 Paul Ramsey wrote:<br />
                >><br />
                >> All,<br />
                >>><br />
                >>>I have a client who needs a custom function added. Since we're well into<br />
                >>> release, obviously the SQL API can't change, or really any code in<br />
                >>> underneath any existing SQL functions.<br />
                >>>However, I can implement the function as a completely additive thing (and<br />
                >>> in fact have), so it affects the stability of existing functions not at all.<br />
                >>> And I can leave the SQL API alone, and simple ship the CREATE FUNCTION code<br />
                >>> directly to the client.<br />
                >>><br />
                >>>http://trac.osgeo.org/postgis/attachment/ticket/390/addmeasure.patch<br />
                >>><br />
                >>>They get the benefit of a quick turnaround on a new feature, we maintain<br />
                >>> our contract with respect to leaving the API unchanged through minor<br />
                >>> releases.<br />
                >>>I'd like to apply this patch into stable branches so folks who want it can<br />
                >>> have it, by running the CREATE FUNCTION code themselves.<br />
                >>><br />
                >>>Paul<br />
                >>><br />
                >>>--<br />
                >>>Paul Ramsey<br />
                >>>OpenGeo - http://opengeo.org<br />
                >>>The secret sauce is called... PostGIS.<br />
                >>><br />
                >>>_______________________________________________<br />
                >>>postgis-devel mailing list<br />
                >>>postgis-devel@postgis.refractions.net<br />
                >>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
                >>><br />
                >>><br />
                >> _______________________________________________<br />
                >> postgis-devel mailing list<br />
                >> postgis-devel@postgis.refractions.net<br />
                >> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
                >><br />
                >><br />
                >_______________________________________________<br />
                >postgis-devel mailing list<br />
                >postgis-devel@postgis.refractions.net<br />
                >http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
                ><br />
                ></div>
</body>
</html>