[postgis-devel] optional units parameter...

[Jeff Hamann]

Paul,

Thanks for hearing me. Speaking for myself, an issue I have is  
something like this:

let's say I have a "report view" like:

leuschner=# select * from rpt_gmt_rufus;
-[ RECORD 1 ]-------- 
+ 
-------------------------------------------------------------------------
current_database     | leuschner
current_user         | hamannj
contact_email        | jeff.hamann at forestinformatics.com
generated_when       | 2009-10-12 09:38:19.35451-07
bdry_area            | 3659040000.05859
n_srids              | 3
srids                | {2286,4326,26910}
activity_types       | {}
activity_counts      | {}
road_buffer_widths   | {10,20,30,40,100}
stream_buffer_widths | {25,50,75,100,200}
n_streams            | 0
total_stream_length  |
n_roads              | 0
total_road_length    |
road_density         |
lidar_density        | 0
stream_crossings     | -999
svnid                | $Id: jobpak.sql 1709 2009-09-01 21:22:29Z  
hamannj $
optimizer            | glpk-lp
gpx_desc             | rufus database: leuschner

leuschner=#

where the inputs come from a wide variety of sources (users, web,  
etc.) and currently, there is no standard way to even communicate  
metrics (trees/acre, road density (miles/acre)). It's used as a  
"scope" for the database. It tells me very basic information about the  
collection of data and allows me to converse with users (consumers of  
output) in the language they speak (e.g. "We have xxx acres, yyy miles  
of road, and zzz million board feet).

But, as soon as users something like:

bid                  | 1
bdry_area            | 3659040000.05859
n_srids              | 3
srids                | {2286,4326,26910}
activity_types       | {}

The first questions are:

1) what are the units, and
2) what is an srid and why are there three of them, and
3) How many acres/hectares, whatever is that.

This tells me that most "users" aren't aware of how coordinate system  
and projection information is stored. In fact, they don't care, and  
are more interested one of the following:

1) tabular results (e.g.  financials ($/acre, $/hectare), acres/year,  
board feet/acre, etc.)
2) paper maps (maybe this plot locations) that are then used in field  
sampling, or wall maps, or
3) google earth files for visualization, gps files to get them to the  
site, or some other set of machine readable files they then plug into  
some other machine

So the main issue for myself is this: How do I store raw data from a  
variety of sources (field personnel, analysts, and managers) that

1) maintains the integrity of the original data regardless of where it  
came from and who provided it, so that users (i.e. consumers of  
outputs) can
2) "hear/see/ingest" the data in their original units, which I may not  
have a clue about, and
3) provides a level of "translation" that generates credibility so  
that the issue of unit conversion, coordinate transformation,  
projection, no longer becomes a stumbling block to accepting the results

In forestry, we have data from all over space and time and many users  
maintain NAD27, NAD83, WGS84, Oregon North, UTM, blah, blah, blah, and  
units are a big deal. I use chains for field sampling ;-)

having very familiarity with how this might be accomplished, I can  
envision the following examples:

st_area( boundary, 'hectares')

where boundary is from a google earth file (WGS84)

st_buffer( stream, stream_buffer[1], 'feet' )

where stream is in UTM (meters), stream buffer vector is in feet, and  
the resulting buffer area needs to be reported in acres or hectares.


Thanks,
Jeff.




On Oct 11, 2009, at 2:07 PM, Paul Ramsey wrote:

> 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
>>

Jeff Hamann, PhD
PO Box 1421
Corvallis, Oregon 97339-1421
541-754-2457
jeff.hamann[at]forestinformatics[dot]com
http://www.forestinformatics.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091012/8cf670c0/attachment.html>