[postgis-devel] Geom/Geog Hack Plan

[nicklas.aven at jordogskog.no]

I think the expected often is very important. As a user you don't even know always what is right and what is wrong but you learn the behavior of a software.  often analyzes is based on changes more than the real numbers.Questions like Is it a decreasing or increasing number of households in the bufferzone of a river
Is it a decreasing or increasing areas affected of clearcuts in forestry (assuming a buffer around the clearcut is affected)
 
I don't find any better examples right know, but the point is that most analyzes based on changes over time is more sensitive to changed behavior than right or wrong behavior.
 
Isn't that the reason why we don't push out bugfixes the same day as the bug is fixed. To keep the expected behavior even if it is wrong.
 
The important thing then is to make people thinking over how the new behavior will affect their applications when the real functions gets released. Different function names would make it more obvious.
 
/Nicklas 2009-11-03 Paragon Corporation wrote:

>Nicklas,>Well actually we wouldn't change it in a micro release.  Yes I agree changing output in the micro release is probably a no no.> >We'd change it in a minor or major release (proably major in this case in 2.0).  As far as naming goes yes that is the basic argument.  That if we replace the function with a real one.  The real one will do "more the right thing" than the old.  So in essense it would be treated like a bug fix rather than a mere change of behavior.> >That does bring up the question of:>Is the right answer the one you are expecting or the one you expect.> >(are expecting meaning the one you are used to vs. you expect (without any prior expectations of behavior))> >For example in SQL 1/2 => 0 (both PostgreSQL and SQL Server and a lot of relational databases behave this way by the way)> >But if I change the behavior to suddenly return  0.5 (like MySQL does)> >Do people consider it wrong because it is no longer the expected answer of 0, but from a mathematical!
  point of view, it is the one you expect.> >Thanks,>Regina
>>From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of nicklas.aven at jordogskog.no
>Sent: Tuesday, November 03, 2009 6:07 AM
>To: PostGIS Development Discussion
>Subject: Re: [postgis-devel] Geom/Geog Hack Plan
>
>>
 >
Just a question for my understanding. >
What's the argument against a special prefix in function-name for those functions.>
If the argument is that we then can implement the "real" function in a micro-release, I don't think it is a good argument.>
Exchanging the hacked version with the real will cause a changed behavior of the function and is probably not what users expect from a micro-release, from the policy not to change functionality in micro-releases.>
 >
/Nicklas>
 
>
>2009-11-03 Paragon Corporation wrote:
>
>Paul and Kevin,
>>
>>I'm in agreement with Mark too. I suppose one or 2 of these functions is
>>not going to pollute our 1.5 that much.
>>
>>So how about this as a plan:
>>
>>Paul picks 1 or 2 more of these kind of functions. Note we already have
>>buffer -- which is now documented. Though not sure if the documentation is
>>clear enough -
>>http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I think
>>we need to revise our documentation template yet again -- though I'll put
>>that in a separate note).
>>
>>The rest of the functions get put in a wiki page and prominently linked from
>>the documentation
>>
>>
>> in geography index
>>http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_GeographyF
>>unctions
>>
>>as well as geography description page
>>
>> for easy access
>>http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geography
>>
>>Is everyone okay with that plan?
>>
>>Thanks,
>>Regina
>>
>>
>>_______________________________________________
>>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/20091103/33917204/attachment.html>