From: Richard Knapp (richfk_at_attglobal.net)
Date: Thu Jul 18 2002 - 12:32:57 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 977E415915 for <cavexml-outgoing_at_ethz.ch>; Thu, 18 Jul 2002 13:57:03 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id C9EA3157C0; Thu, 18 Jul 2002 13:57:00 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id CC91F15904 for <cavexml-loopcheck_at_ethz.ch>; Thu, 18 Jul 2002 13:56:58 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 95CA415876; Thu, 18 Jul 2002 13:56:55 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 4671C15912 for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 13:56:54 +0200 (CEST) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 37F1214BA0 for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 13:56:51 +0200 (CEST) Received: from Muphin (slip-12-65-79-156.mis.prserv.net[12.65.79.156]) by prserv.net (out4) with SMTP id <2002071811405920403p4ccre>; Thu, 18 Jul 2002 11:40:59 +0000 From: "Richard Knapp" <richfk_at_attglobal.net> To: "cavexml_at_cartography.ch" <cavexml_at_cartography.ch> Date: Thu, 18 Jul 2002 06:32:57 -0400 (EDT) X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 In-Reply-To: <5.1.0.14.1.20020718110200.01d45cf0_at_popa.melbpc.org.au> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: comments on the data model Message-Id: <20020718115651.37F1214BA0@karmail.ethz.ch> X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
On Thu, 18 Jul 2002 17:46:41 +1000, Peter MATTHEWS wrote:
> >While browsing some more through the elements, there doesn't seem to
> >be a way to cover brunton on tripod (or other instrument on tripod)
> >surveys. For those, an Instrument Height, Target Height, and a Method
> >for measuring (station to station, instrument to target, station to
> >target, and instrument to station) are needed.
>
> A good example. Without going into fine or exact detail at this stage (we
> can make sure we do that when we come to it when working through the
> diagram), here is an approximate way it would work (entities in Caps):
>
> * a Shot would record all the various Measurements taken. (The fields
> available in a Shot would cover all possible Measurements which a Shot
> might need; any unused fields would be null in a db or maybe omitted in XML.)
So there would be entries here for Instrument Height and Target
Height as well as Azimuth, Distance, and Inclination?
> * the Segment would record that one of the Instruments used during that
> Segment was a brunton on a tripod, and what particular surveying Technique
> the Segment used, e.g. traverse.
>
> * the Technique for traverse would indicate that the Measurements needed
> are distance, azimuth and inclination.
...and Instrument and Target Height.
> * the Instrument used would indicate what Method(s) were needed for that
> type of Instrument to obtain the required Measurements.
Not necessarily. Suuntos could be used on tripod and a bruton could
be hand-held. Where will this information be in an empty data file?
In the editor?
> * a program which was processing the above data would note the
> Instrument(s) and surveying Technique, and then select the appropriate
> "business rule" ("survey rule"?) for that combination, which would
> ultimately tell it what Measurements to go looking for in the Shot data,
> and what to do with them, in order to calculate the set of co-ordinates for
> the Position of the next Station.
Interesting linkage between the elements. However, I have found when
there is so too required and too much linkage, things fail. Users
regularly change the way things are done when the data is compiled
("Do azimuths get averaged? Is there one that should be used instead
of others? Let's try both ways and see what happens"). Certainly
there will be some rules to be followed. Numbers will need to be in a
certain format, attributes will need to picked from a certain list in
cases.
But is it up to the data structure to impose rules or store the data?
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST