[postgis-devel] Adding Functions w/o Adding

[Nicklas Avén]

yes, there was a lot of good information. Also the topological part was very informative. The rest I haven't read yetGreat /Nicklas

2010-01-23 Paul Ramsey wrote:

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
> 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
>>
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100123/50da2cec/attachment.html>