<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18812"></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">thanks</div>
<div align="left"> </div>
<div align="left">about the distance-calculations don't miss the dist.doc in ticket #231. </div>
<div align="left">That might save you some time to see the idea behind the new distance-calculation of polygons and linestrings that don't have intersecting bounding boxes.</div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left"> </div>
<div align="left"><br />
<br />
2009-09-09 Paul Ramsey wrote:<br />
<br />
Niklas,<br />
><br />
>There are at least three different implementations of line substring<br />
>hanging around, a couple that are bound to the old functions and one I<br />
>did for the elevationbetween functions. The whole conjunction calls<br />
>out for a cleaning and consolidation, frankly, but I've been leaving<br />
>it alone on the basis of not touching things that are working.<br />
><br />
>Attach your patch for 3D to a ticket so it doesn't get lost. I've got<br />
>reviewing your distance ticket on my list too so don't give up hope on<br />
>that.<br />
><br />
>P.<br />
><br />
>On Sun, Aug 30, 2009 at 1:17 PM,
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no>wrote:<br />
>> The function ST_Line_Substring is some mixture between 2D and 3D. It<br />
>> preserves the z-value but don't use it in calculation. The documentation<br />
>> describes this but the note that the function supports 3D I think is false.<br />
>><br />
>> Why not make it real 3D so it considers the third dimmension in the<br />
>> calculation.<br />
>><br />
>> Now this query:<br />
>> select st_asewkt(ST_Line_Substring(the_geom,0.2, 0.8))<br />
>> from<br />
>> (SELECT ST_GeomFromEWKT('SRID=4269;LINESTRING(1 1 1,1 1 3, 1 1 5, 1 1 8)')<br />
>> as the_geom ) a;<br />
>> gives the little bit strange result:<br />
>> "SRID=4269;LINESTRING(1 1 3,1 1 5)"<br />
>><br />
>> I think t would be much better to make it fully 3D-supportive. Then the<br />
>> result of this query is:<br />
>> "SRID=4269;LINESTRING(1 1 2.4,1 1 3,1 1 5,1 1 6.6)"<br />
>><br />
>> I have attached a patch that makes this.<br />
>><br />
>> The reason I started to look at this was that I wanted a function that takes<br />
>> distances instead of fraction of the total length.<br />
>> I hve a working finction that takes the startdistance and end-distance from<br />
>> the start of the line to pull out the substring-line. In some cases that is<br />
>> more straight on than going via the fractions. Should I post it or will<br />
>> there be to many functions too little difference?<br />
>> The question is if I should put effort in writing the documentation and<br />
>> regression-tests.<br />
>><br />
>> Greetings<br />
>> Nicklas<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>