From: P A Hill & E V Goodall (goodhill_at_xmission.com)
Date: Wed Jul 10 2002 - 17:25:29 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 01FFB157FE for <cavexml-outgoing_at_ethz.ch>; Fri, 12 Jul 2002 08:20:42 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id CCFD414BA0; Fri, 12 Jul 2002 08:20:39 +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 CB3CB157FE for <cavexml-loopcheck_at_ethz.ch>; Fri, 12 Jul 2002 08:20:38 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 9062214ADD; Fri, 12 Jul 2002 08:20:36 +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 4CCA5157FE for <cavexml_at_cartography.ch>; Fri, 12 Jul 2002 08:20:36 +0200 (CEST) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id A3C097D8C for <cavexml_at_cartography.ch>; Fri, 12 Jul 2002 08:20:33 +0200 (CEST) Received: from [198.60.22.200] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.35 #1) id 17SJGl-0003To-01 for cavexml_at_cartography.ch; Wed, 10 Jul 2002 09:20:43 -0600 Received: from goodhill.dsl.xmission.com ([198.60.114.17] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 17SJET-00022C-00 for cavexml_at_cartography.ch; Wed, 10 Jul 2002 09:18:22 -0600 Message-ID: <3D2C51E9.9040707@xmission.com> Date: Wed, 10 Jul 2002 09:25:29 -0600 From: P A Hill & E V Goodall <goodhill_at_xmission.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us To: cavexml_at_cartography.ch Subject: Re: comments on the data model References: <20020710135904.E9B6514ABB_at_karmail.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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
Richard Knapp wrote:
> Maybe the questions should be:
>
> Is this information that should be stored?
> Where should it be stored?
To me that sounds like the -- or one of the -- fundamental
questions to ask.
> However, with the processing speed of
> computers these days, should (compiled) coordinate data be stored at
> all? These are simple calculations and can be done very quickly and
> stored as a temp file or in memory.
For data like this a question I might ask is:
Is it reasonable to assume that there might be two different software
systems that might want to exchange the data and that these two
different systems might not completely understand or care to understand
what the the other is up to.
In the case of XYZs, I imagine that the program that generated
such values completely understands connectivity of the cave,
whether loops where closed, where the "fixed points" are located
what the known errors and weights are etc. which version of
the data is the right one to process (if there any re-surveys)
etc. Meanwhile I could picture another bit of software that trys
to generate SVG (a XML based 2D graphics format)
or VRML (a XML based 3D Graphics format) that knows just enough
CaveXML to find all the points and the lines between
them and generate some type of picture of them. Between these two pieces of
software I could imagine another specialized piece that works with
only connectivity (the graph of the points), the points, and various
cross sections and generates various interesting wall models (simple
boxes or fancy shapes, it would be up to this particular bit of software).
Given such a hypothetical scenerio which doesn't sound too unusual
to me, I'd think that absolute XYZs would definitely have their place
in the data.
>>If we want to add processed walls to the data, SVG is a good choice,
>>there is no need to reinvent the wheel.
>>
>
> Agreed. And it seems to be a better export format than DXF.
Since DXF is a proprietary, but well known standard (it is a format
used by AutoDesk) and SVG is XML and standardized I lean toward
the XML based one.
Actually SVG is really only slightly more standardized than DXF,
since I believe SVG was developed and promoted by Adobe over the
last few years while DXF has had a long life as an input/output format
for the industry standard AutoCAD software.
The page
http://www.escape.de/users/quincunx/dxfviewer/dxfviewer_intro.shtml
seems to describe it well:
"DXF is a widely used file format for exchanging 3D CAD data. It's not an open
format but owned by AutoDesk Inc. who used it for their program AutoCADŽ. With
every new version of AutoCADŽ the definition of DXF is changed but nevertheless
there are zillions of programs which are capable of reading and writing some
form of DXF."
Note that DXF is 3D while SVG is 2D. A format which is 3D and
XML is VRML.
-Paul
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST