[postgis-devel] optional units parameter...

[Paragon Corporation]

In short.  While I understand this is an optional parameter and I don't have
to use it and I'm not completely against it, I just think it will open up a
whole can of worms we don't want to open this early in the game.  Not a bad
thought for PostGIS 2.0 but I think it will slow down our PostGIS 1.5
release.

By can of worms I mean

1) Which units will you support? And when someone complains about how their
favorite unit is not in there -- are we going to release a patch?
2) what level of precision will your rounding be 
3) Should we use a postgis_distance_enum for better clarity
4) How are you going to spell said units so we don't have to write stupid
FAQs like
5) Lots of dumb FAQ questions
a) What is wrong with this stupid distance function 

Why is it erroring out on me with 

SELECT ST_Distance(g1,g2, 'ft')

b) I see all spatial refs proj4 refer to u=ft, u=m why is this distance
function different

etc.
c) I see there are 2 distance type functions -- one that takes units and one
that doesn't which one should I use?

Just my 2 crazy cents.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paragon
Corporation
Sent: Sunday, October 11, 2009 7:25 PM
To: 'PostGIS Development Discussion'; 'Jeff Hamann'
Subject: Re: [postgis-devel] optional units parameter...

Jeff,
That's the problem I have with the below.  We were grappling with this too
and for example for one of the flash apps we are doing the user has the
choice to toggle which unit to display in on the fly.
Running back to the server for a unit conversion is costly so the webservice
always pass units in meters and the flash app converts to the units the user
requests on the fly.  Even for a caching webservice -- converting on the fly
is always less costly than going back to the server for that.

This solution doesn't help on the fly and what about good old geometry users
-- you think everyone is happy with the native units of their spatial ref?
For reports I need the numbers formatted differently depending on units so
there is always additional formatting etc that needs to be done depending on
the units.  If its  feet I don't need as many decimal places as for meters
etc.

Thanks,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Sunday, October 11, 2009 5:08 PM
To: Jeff Hamann
Cc: PostGIS Development Discussion
Subject: Re: [postgis-devel] optional units parameter...

Glad to hear an opposing viewpoint, Jeff. Is this:

  select st_distance(g1, g2, 'feet')

so much better than

  select st_distance(g1, g2) / 0.3048

? I guess there's something to be said for transparency, when you look at
that, it's clear what's going on in the first one.

P.

On Sun, Oct 11, 2009 at 8:47 AM, Jeff Hamann
<jeff.hamann at forestinformatics.com> wrote:
> Paul,
> I just read the threads about having optional units in the geography 
> functions.
> Should the geography functions have a (optional) units parameter? Are 
> the users that lazy? Do they need that? Oracle does it. Does 
> SQLServer?
>
> ST_Distance(a.geog, b.geog, 'miles')
> ST_Area(a.geog, 'acres')
>
> IMHO, I think "users" are that lazy, thus the need for server-side 
> applications. As for myself, I'm currently grappling with units in 
> report views, and having units would be absolutely awesome! I'm just 
> not sure how to implement them so that the value *and* the units are
usable.
> Jeff.
> Jeff Hamann, PhD
> PO Box 1421
> Corvallis, Oregon 97339-1421
> 541-754-2457
> jeff.hamann[at]forestinformatics[dot]com
> http://www.forestinformatics.com
>
_______________________________________________
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