From: Thrun Robert IHMD (ThrunR_at_ih.navy.mil)
Date: Sat Feb 10 2001 - 02:48:34 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA12318 for cavexml-outgoing; Sat, 10 Feb 2001 02:48:17 +0100 Received: from ih-router.ih.navy.mil (ih-router.ih.navy.mil [205.68.95.65]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA12314 for <cavexml_at_cartography.ch>; Sat, 10 Feb 2001 02:48:16 +0100 Received: from ih-router.ih.navy.mil (root_at_localhost) by ih-router.ih.navy.mil with ESMTP id UAA00481 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 20:48:10 -0500 (EST) Received: from ihmdex04.ih.navy.mil (ihmdex04.ih.navy.mil [206.39.129.72]) by ih-router.ih.navy.mil with ESMTP id UAA00477 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 20:48:10 -0500 (EST) Received: by ihmdex04.ih.navy.mil with Internet Mail Service (5.5.2650.21) id <1BC0SMTN>; Fri, 9 Feb 2001 20:48:35 -0500 Message-ID: <9718D3B1ED18D31180F000A0C99DE22301F7E94B@ihmdex03.ih.navy.mil> From: Thrun Robert IHMD <ThrunR_at_ih.navy.mil> To: "'cavexml_at_cartography.ch'" <cavexml_at_cartography.ch> Subject: Station names Date: Fri, 9 Feb 2001 20:48:34 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
On Wednesday, February 07, 2001 1:06 PM, Roger Schuster said:
> Do you see the difference? We will have serious problems with
> station names: Some software allows alphanumeric names, other
> allows only numeric values (CaveRender, Toporobot AFAIK). Some
> programs do support station names up to eight characters long,
> others even twelve or more. Some programs use combined names for
> stations (survey+station), others doesn't. And so on.
Although one of the supposed purposes of CaveXML is to facilitate
the exchange of data between programs, this is the first message on
the CaveXML mailing list that actually mentions one of the problems
in exchanging survey data.
Much of the discussion has been about issues that are of concern
for data archiving. Not that there is anything wrong with data
archiving. It's just that the desirable features for archiving
are not the same as the features for data exchange.
On Wednesday, February 07, 2001 4:34 PM, Devin Kouts said:
> "that's just not good software engineering practice".
>
> Before I get a bunch of flame mail let me just say that I
> understand why things get built the way they are, development
> envirnoment limitations, software efficiency considerations,
> user requirements, and even developer skill limitations. But
> none of these are an excuse for making outdated design the
> "status quo".
Roger discussed one of the problems that we encounter exchanging
data between the programs that are currently in use. Devin is
talking about a program that is not yet written.
Devin said:
> If an application doesn't understand what it is receiving then
> it must modify what it receives into something in can
> understand.
I am baffled by this remark. Say, for example, that a program
only takes distances in meters. If it does not understand feet
and inches, then it must modify the feet and inches into meters.
But if it can make the conversion, then it does understand feet.
Or, since this was said in the context of long station names, how
is the importing program supposed to convert a station name like
Llanfairpwllgwyngyllgogerychwyndrobwllllantysiliogogogoch to
something that it can understand? Use the first n characters?
The last n characters? Or take a chunk out of the middle?
On Thursday, February 08, 2001 11:41 AM, John Halleck said:
> Most survey programs I've seen have internally some unique
> number for a point. (If nothing else, an index into a table
> of names.)
>
> I think it would be nice if the point information had an
> (optional) tag that was a unique number. It would make some
> sorts of processing easier if there was already a number, and
> even easier if (in the case of N points) the numbers ran 1 .. N.
I think this is a great idea. I implemented it as part of
CMAP's export format two years ago. It puts the burden of
converting the data on the exporting program, which presumably
can understand its own data.
I tried to put a data export feature into the Survex code, but I
could not find a place to insert it. I asked Olly Betts about
it last August and he said it would be difficult.
Bob Thrun
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET