<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

Rick Zoolker schreef:

<blockquote

 cite="mid:3fcf5fb70708102100n77c4ae4aj8e4bf6e35968738b@mail.gmail.com"

 type="cite">

  <pre wrap="">Thanks for your help.  It's been very very very helpful.

I do have a few followup questions for you or the group.

I guess I understand all of what you said except for your #2 where you

state that all the functions work with lat/long except for distance

calculations.  As far as I can tell any perimeter calculation as well

as area calculations will almost certainly be wrong when dealing with

lat/long coordinates.  </pre>

</blockquote>

Wrong is a bit fuzzy, you will have distortions, but often these are

small enough to be neglected for the purpose. <br>

When you got a reference ellipsoid plus a well defined geographic

coordinate system there are mathematical functions available to do

distance and area calculations. For sure. <br>

How else would the great sailers of the 17th century get around? As I

said, there are faults in the calculations, but for the purpose one is

calculating them, the faults may well be acceptable.<br>

<br>

It's all about math!<br>

<br>

<blockquote

 cite="mid:3fcf5fb70708102100n77c4ae4aj8e4bf6e35968738b@mail.gmail.com"

 type="cite">

  <pre wrap="">Also, polygon operations (e.g. intersection,

union, etc) will certainly be wrong if they cross any "boundaries"

(i.e. +/- 180 deg).  I'd have to think about if they actually return

the correct result when you don't cross boundaries, but I'm thinking

that the fact that each degree of longitude is not a consistent length

(i.e. it varies by latitude), plus the fact that projected straight

lines become curves will mess things up in these operations.  You all

probably know this off the top of your heads, or perhaps the

distortions are not really enough that I should be concerned about

them.?

Thanks again for your help

  -Rick

On 8/10/07, Obe, Regina <a class="moz-txt-link-rfc2396E" href="mailto:robe.dnd@cityofboston.gov"><robe.dnd@cityofboston.gov></a> wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">Very good questions.  I may be wrong on some of my assumptions, but this is

my understanding

1) Everyone ships in lat long format because it covers the widest area of

space and can be easily transformed into other SRIDs or out of all SRIDs.

Its not even entirely true that everyone does.  Most state municipalities

for example often ship their data in a coordinate system specific to thier

area or state.

2) As far as I know most functions will work with lat long except distance

gives you funky results because it is measuring around circles for lat long.

3) Why do databases have this whole cartesian thingy and not work straight

with lat long?  Because screens are flat, printed maps are flat and when you

look at isolated areas you can make them look flat and not skew measurements

and layout.   So I guess its a hack to make your problem simpler.  If you

look at the upcoming SQL Server Katmai which is supposed to have Geography -

it will challenge that and try to deal with geodetic data as a "first class"

reference system.

4) Not everyone stores their data projected, but often will transform on the

fly if they do not project.  I do when I know I am only dealing with a very

isolated region like a single state or city municipality.

5) Its not true that tools like ArcView and MapInfo want lat long.  Actually

MapInfo is pretty sophisticated I think when it comes to projections so its

almost transparent to the user.  I'm not quite sure how it does it, but

encoded in each tab file is the projection info and you can lay on a bunch

of layers in different projections and it will magically pick the most

suitable one and reproject all the layers to that.  My knowledge of ArcView

is less, but I think ArcView tends to be more picky about projections so

requires more knowledge on the user's side to know how to deal with multiple

layers in different projections.

Hope that helps,

Regina

________________________________

From: <a class="moz-txt-link-abbreviated" href="mailto:postgis-users-bounces@postgis.refractions.net">postgis-users-bounces@postgis.refractions.net</a> on

behalf of Rick Zoolker

Sent: Fri 8/10/2007 1:34 PM

To: <a class="moz-txt-link-abbreviated" href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>

Subject: [postgis-users] Confusion about projections and Spatial Data

OK, I feel like I've got a fundamental block about how spatial data is

actually used in the real world and how spatially aware databases

actually make use of that data.  This is probably quite obvious for

everyone so please bear with me.

I've been playing with a bunch of spatial databases (Oracle, Postgis,

DB2) and from what I can tell, all tend to roughly follow the OGC SFA

spec (Oracle using different terminology).  Now it also seems that the

SFA spec deals EXCLUSIVELY with Cartesian coordinates.  Now here's my

first confusion.  If they only deal with Cartesian coordinates, why do

they allow you to specify SRIDs that are lat/long based.  Will any of

the SFA functions work with lat/long (other than ST_Transform(), which

is actually a SQL/MM and not even included in SFA)??

My next area of confusion is that I've looked at a bunch of data from

people such as Navteq, teleatlas, and a bunch of individual companies

databases, and it seems that every single one ships and stores their

data in lat/long.  So what the heck?  If the tools can't deal with

lat/long, why does everyone ship and store their data in lat/long?

Does everyone project this data before actually loading it into the

db?  Help!?

Now, it appears that Oracle in particular can do some functions with

lat/long directly (the distance calculation comes to mind), and I know

Postgis has some specialized distance functions for geodetic

coordinates, but I'm not sure if that extends to the whole function

set (i.e. can I do an Intersection of two polygons specified in

lat/long coordinates??).  Why doesn't the OGC SFA spec and libraries

support all the functions with geodetic coordinates directly rather

than require projected coordinates?

Finally, how do the analysis and visualization tools that people put

on top of these databases deal with these questions? (e.g. MapInfo,

ArcView, etc.)  They seem to want lat/long data as well, but if you

stored project coordinates in the database isn't there a problem??

HELP!

  -Rick

_______________________________________________

postgis-users mailing list

<a class="moz-txt-link-abbreviated" href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>

<a class="moz-txt-link-freetext" href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a>

OK, I feel like I've got a fundamental block about how spatial data is

actually used in the real world and how spatially aware databases

actually make use of that data.  This is probably quite obvious for