[postgis-users] postgis, postgresql and geological data

[Gerry Creager N5JXS]

Dennis Veatch wrote:
> On Thursday 18 December 2003 10:43 pm, Gerry Creager N5JXS wrote:
> 
>>Dennis,
>>
>>I'm responding off-list for the time being, although generally we try to
>>keep all the responses on-list...
>>
>>A couple of points to consider.
>>
>>DEMs, DOQQs, etc are different data presentations.  Once you snag them,
>>you have to consider the metadata, especially the geodetic datum and
>>ellipsoid of the information, as well as the projection.
> 
> 
> Well sounds like I need to keep this simple as a beginning. So I'll just deal 
> with DLG's for now. Of those things mentioned above how do they apply to 
> DLG's (metadata, ellipsoid, etc)?

What's metadata?  Well, if you take a "map" but fail to include, say, a 
North Arrow, a scale, and information on datum and map projection, it's 
really _NOT_ a map, but a picture.  Its data do not well represent 
anything, and without the aforementioned information, one might 
successfully infer spatial nuance and similarities, but there's no way 
to make a measurement that's meaningful.

A Datum provides information on the coordinate system and the effective 
shape of the smooth earth model in use, as well as any local distortion 
incorporated in a planar model of the area you might be working in.  The 
ellipsoid is the smooth earth mathematical model we work with that 
usually describes the earth as an oblate shperoid, with an equatorial 
radius of about 6378138 meters.

The Projection information tells, in sometimes cryptic form, how a model 
of the earth, a roughly spherical structure, can be presented on a flat 
page with limitations in distortion appropriate (we hope) for the 
purpose one might be presenting.

>>Mapserver will reproject data, but if you try to mix geodetic datums
>>(NAD27 vs NAD83, for instance) things will get confusing very quickly.
>>
> 
> 
> How does NAD27/83 relate to DLG?

Depends on the origins of the DLG basemap.  That's part of the research 
YOU get to do.

>>In the database you created for your brother, how do you log lat/lon?
>>Are data acquired by GPS, or SWAG'd off a quad-sheet?  What's the level
>>of accuracy you want for the data, and how precisely are they recorded
>>now in the database?
> 
> 
> The database was created before the state requirements for lat/long/altitude 
> and I never bothered to update it as I knew it was a cheesy affair and had 
> plans to move him to open source. He does use a GPS handheld (Magellan 
> SportTrakMAP) and thats really the only function The lat/long/altitude will 
> be input manually.
> 
> Well I would like the accuracy to be the best that can acquired.

Consider that you're getting about 10 meter accuracy horizontally, and 
20-30 m accuracy vertically.  If you're lucky.  Vertical accuracy with a 
hand-held, in an autonomous more, is tricky at best, and usually more a 
product of luck than skill.

Barring other input, we will assume the default datum for the GPS from 
the factory is WGS-84 and has not been changed.  For YOUR purposes, you 
can assume this is identical to NAD83 for a horizontal datum.

>>Essentially, what you're looking at is a full-blown GIS application, and
>>while MapServer can render the data, and MySQL or PostGreSQL can handle
>>any and all of the database chores, the user interface might still be a
>>pretty problem.
> 
> 
> Hmmm a full-blown GIS app. I don't suppose you or anyone here might know of 
> such that already exists? 
> 
> Yeah, I'm sure the user interface will be ummm interesting. Bear in mind he 
> drills wells and is not computer literate. Though I don't want it dumbed down 
> where there is little to no flexability.

It's not impossible to craft something with a web interface to enter the 
well data, and store it in a PostGres/PostGIS database.

>>I'll try to answer geodetic questions if you have any. Please refer
>>general Mapserver questions to the main list, so the larger public can
>>gain from the discussion.
> 
> 
> At this point I am still in a research phase trying to figure out what kind of 
> map data to use (still open to suggestions even though I did say DLG), getting 
> the postgresql side setup with some of the existing data. 
> 
> Oh and sort of waiting to hear from the Mandrake cooker folks about postgis. 
> They already have grass, gdal, g3DGMV and geotiff. I've reqeusted they add a 
> postgis rpm to round things out. Otherwise I'll have to compile it myself.
> 
> Yeah I know it is probably a knuckleheaded thing to do on a beta.

Not a Mandrake hacker, so I can't help there.

gerry
-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843