[postgis-devel] Adding Functions w/o Adding

[Paul Ramsey]

LRS needs to be done carefully, so as to not make it (a) more muddled
than it already is or (b) less useful. Right now we have two sets of
functions, some that work on measured geometries, and some that work
on unmeasured. And, as you note, we generally ignore the third
dimension in calculating the proportionality of things. There's some
ideas on the unification here:

http://opengeo.org/products/coredevelopment/postgis/lrs/

I think the simplest approach to the third dimension is to say "if
it's there, it's relevant" and include it in calculations of
proportional length. (That said, I just now ignored it in my
implementation, I'm such a flatlander.)

Paul

On Fri, Jan 22, 2010 at 4:45 PM, Nicklas Avén
<nicklas.aven at jordogskog.no> wrote:
> Hallo
>
> I have thought that I should raise some ideas about the line reference
> functions after this release. I mention it noe because it is a close
> subject.
>
> I would like to rewrite the linereferencing functions like ST_Line_Substring
> to do the measure in all 3 dimensions. I am not sure I suggest that there
> should be a different behaviour in that function but rather make a new that
> also handles the measure in units like meters instead of parts of the whole
> line.
>
>
>
> But the thing that was connected to this question was this about measuring
> in 2 or three dimensions. Does this customer wants it in 2D measuring or
> will he or she only work in 2 D so it doesn't matter.
>
> What I mean is that if we want to go against 3Dmeasuring at line referencing
> maybe that should be included in the bbeginning on this one?
>
> Just a thought.
>
> What is needed as I understands it is just another function like
> distance3d_pt_pt that uses 3 dimensions in pythagora theorem.
>
> In this function it would not matter that is only following the ground or a
> line that has the same angel to the ground all the way. But it would be a
> difference on a line following the ground and then suddenly continuing ut on
> a mountain or something like that.
> Just a thought
>
> /Nicklas
> 2010-01-22 Paul Ramsey wrote:
>
> All,
>>
>>I have a client who needs a custom function added. Since we're well into
>> release, obviously the SQL API can't change, or really any code in
>> underneath any existing SQL functions.
>>However, I can implement the function as a completely additive thing (and
>> in fact have), so it affects the stability of existing functions not at all.
>> And I can leave the SQL API alone, and simple ship the CREATE FUNCTION code
>> directly to the client.
>>
>>http://trac.osgeo.org/postgis/attachment/ticket/390/addmeasure.patch
>>
>>They get the benefit of a quick turnaround on a new feature, we maintain
>> our contract with respect to leaving the API unchanged through minor
>> releases.
>>I'd like to apply this patch into stable branches so folks who want it can
>> have it, by running the CREATE FUNCTION code themselves.
>>
>>Paul
>>
>>--
>>Paul Ramsey
>>OpenGeo - http://opengeo.org
>>The secret sauce is called... PostGIS.
>>
>>_______________________________________________
>>postgis-devel mailing list
>>postgis-devel at postgis.refractions.net
>>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>