<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Paul, <div><br></div><div>Thanks for hearing me. Speaking for myself, an issue I have is something like this:</div><div><br></div><div>let's say I have a "report view" like:</div><div><br></div><div><div>leuschner=# select * from rpt_gmt_rufus;</div><div>-[ RECORD 1 ]--------+-------------------------------------------------------------------------</div><div>current_database | leuschner</div><div>current_user | hamannj</div><div>contact_email | <a href="mailto:jeff.hamann@forestinformatics.com">jeff.hamann@forestinformatics.com</a> </div><div>generated_when | 2009-10-12 09:38:19.35451-07</div><div>bdry_area | 3659040000.05859</div><div>n_srids | 3</div><div>srids | {2286,4326,26910}</div><div>activity_types | {}</div><div>activity_counts | {}</div><div>road_buffer_widths | {10,20,30,40,100}</div><div>stream_buffer_widths | {25,50,75,100,200}</div><div>n_streams | 0</div><div>total_stream_length | </div><div>n_roads | 0</div><div>total_road_length | </div><div>road_density | </div><div>lidar_density | 0</div><div>stream_crossings | -999</div><div>svnid | $Id: jobpak.sql 1709 2009-09-01 21:22:29Z hamannj $</div><div>optimizer | glpk-lp</div><div>gpx_desc | rufus database: leuschner</div><div><br></div><div>leuschner=# </div><div><br></div></div><div>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).</div><div><br></div><div>But, as soon as users something like:</div><div><br></div><div><div>bid | 1</div><div>bdry_area | 3659040000.05859</div><div>n_srids | 3</div><div>srids | {2286,4326,26910}</div><div>activity_types | {}</div><div><br></div><div>The first questions are:</div><div><br></div><div>1) what are the units, and </div><div>2) what is an srid and why are there three of them, and</div><div>3) How many acres/hectares, whatever is that.</div></div><div><br></div><div>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:</div><div><br></div><div>1) tabular results (e.g. financials ($/acre, $/hectare), acres/year, board feet/acre, etc.)</div><div>2) paper maps (maybe this plot locations) that are then used in field sampling, or wall maps, or </div><div>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 </div><div><br></div><div>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 </div><div><br></div><div>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 </div><div>2) "hear/see/ingest" the data in their original units, which I may not have a clue about, and </div><div>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</div><div><br></div><div>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 ;-)</div><div><br></div><div>having very familiarity with how this might be accomplished, I can envision the following examples:</div><div><br></div><div>st_area( boundary, 'hectares')</div><div><br></div><div>where boundary is from a google earth file (WGS84)</div><div><br></div><div>st_buffer( stream, stream_buffer[1], 'feet' )</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Thanks,</div><div>Jeff.</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Oct 11, 2009, at 2:07 PM, Paul Ramsey wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Glad to hear an opposing viewpoint, Jeff. Is this:<br><br> select st_distance(g1, g2, 'feet')<br><br>so much better than<br><br> select st_distance(g1, g2) / 0.3048<br><br>? I guess there's something to be said for transparency, when you look<br>at that, it's clear what's going on in the first one.<br><br>P.<br><br>On Sun, Oct 11, 2009 at 8:47 AM, Jeff Hamann<br><<a href="mailto:jeff.hamann@forestinformatics.com">jeff.hamann@forestinformatics.com</a>> wrote:<br><blockquote type="cite">Paul,<br></blockquote><blockquote type="cite">I just read the threads about having optional units in the geography<br></blockquote><blockquote type="cite">functions.<br></blockquote><blockquote type="cite">Should the geography functions have a (optional) units parameter? Are<br></blockquote><blockquote type="cite">the users that lazy? Do they need that? Oracle does it. Does<br></blockquote><blockquote type="cite">SQLServer?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">ST_Distance(a.geog, b.geog, 'miles')<br></blockquote><blockquote type="cite">ST_Area(a.geog, 'acres')<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">IMHO, I think "users" are that lazy, thus the need for server-side<br></blockquote><blockquote type="cite">applications. As for myself, I'm currently grappling with units in report<br></blockquote><blockquote type="cite">views, and having units would be absolutely awesome! I'm just not sure how<br></blockquote><blockquote type="cite">to implement them so that the value *and* the units are usable.<br></blockquote><blockquote type="cite">Jeff.<br></blockquote><blockquote type="cite">Jeff Hamann, PhD<br></blockquote><blockquote type="cite">PO Box 1421<br></blockquote><blockquote type="cite">Corvallis, Oregon 97339-1421<br></blockquote><blockquote type="cite">541-754-2457<br></blockquote><blockquote type="cite">jeff.hamann[at]forestinformatics[dot]com<br></blockquote><blockquote type="cite"><a href="http://www.forestinformatics.com">http://www.forestinformatics.com</a><br></blockquote><blockquote type="cite"><br></blockquote></div></blockquote></div><br><div>
<div>Jeff Hamann, PhD<br>PO Box 1421<br>Corvallis, Oregon 97339-1421<br>541-754-2457<br>jeff.hamann[at]forestinformatics[dot]com<br><a href="http://www.forestinformatics.com/">http://www.forestinformatics.com</a></div>
</div>
<br></div></body></html>