ok, here comes a document describing in general phrases what I have done and why. It is written in a strange form but is only meant for this discussion.
I have taken most of it directly from my head so there is no consistent in the deepness of the details.
Mark, if you want more I think you have to give me a direction.
Paul, as I have rearranged the whole measures.c as described in the end of this document you might be intrested to read that part, how I have grouped the functions.
I have written documentation for the new functions in the doc-part of the spike.
What need to be discussed is the definitions like what to return from shortestline when the geometries intersect. Now the first intersection-point found is returned as both first and second point in the returned line.
The reason is that I think it is very important that the length of the returned line should be the same as the result from st_distance. By doing it this way it might also be a useful way to find the intersection of two lines.
/Nicklas
Now I have moved the information about the distance calculation to the wiki:
>
>
>
and complemented with som word about the sub geometries handling.
>
>
I am also working on a small novell :-) of why the different changes is made.
>
>
Paul, I have done no more commenting in the code (the weekend is not long enough) so you have to just ask if something is too messy written so it makes no sense
>
>
/Nicklas
>
> 2009-11-07 Paul Ramsey wrote:
>
> My understanding is that the code is pretty modular and only activates
> >for the particular large geometry cases it performs well for. Perhaps
> >Niklas could put his .doc explanation, which is good, into the wiki
> >where it's more webbly accessed. I'll be looking for a number of CUnit
> >tests that run and compare both methods on a variety of inputs.
> >
> >p.
> >
> >On Sat, Nov 7, 2009 at 3:03 AM, Mark Cave-Ayland
> > .
cave-ayland@...> wrote:
> >> Paul Ramsey wrote:
> >>
> >>> Niklas,
> >>> I'm going to start reviewing your distance work on Monday, speak now
> >>> or forever hold your peace :)
> >>> P.
> >>
> >> I don't think reading the code will be a problem - my main concern is the
> >> lack of documentation for the algorithm changes. I'd like to see better
> >> documentation of the changes present in Niklas' spike (new algorithm
> >> descriptions and reason for change, clear evidence of testing) before
> >> agreeing to commit.
> >>
> >>
> >> ATB,
> >>
> >> Mark.
> >>
> >> --
> >> Mark Cave-Ayland - Senior Technical Architect
> >> PostgreSQL - PostGIS
> >> Sirius Corporation plc - control through freedom
> >> http://www.siriusit.co.uk
> >> t: +44 870 608 0063
> >>
> >> Sirius Labs: http://www.siriusit.co.uk/labs
> >> _______________________________________________
> >> postgis-devel mailing list
> >>
postgis-devel@...
> >> http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >>
> >_______________________________________________
> >postgis-devel mailing list
> >
postgis-devel@...
> >postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> >
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel
distdoc.odt (21K) 