[LandXML] Re: FW: Re: LandXML - Bentley/In Roads
- From: "Nathan Crews" <nathan.crews@xxxxxxxxxxx>
- To: <hugh.dixon@xxxxxxxxxxxxxx>, <landxml@xxxxxxxxxxxxx>
- Date: Thu, 22 Dec 2005 19:18:30 -0700
Good input Hugh.
There are some basic guidelines in the LandXML documentation to need to be
followed. Like point locations are Northing, Easting Elevation (or Y, X, Z).
I will be adding a number of other guidelines and clarifying definitions for
LandXML-1.1 (should cover 1.0 as well).
We have some good feedback from the Design/Survey TransXML team, who will be
using LandXML. I have the LINZ document, but not the one from Leica.
At the very least we can link to or post a copy of the vendor documents on
the web site.
cheers,
Nathan
-----Original Message-----
From: landxml-bounce@xxxxxxxxxxxxx [mailto:landxml-bounce@xxxxxxxxxxxxx] On
Behalf Of Hugh Dixon
Sent: Thursday, December 22, 2005 6:41 PM
To: Nathan Crews; landxml@xxxxxxxxxxxxx
Subject: [LandXML] Re: FW: Re: LandXML - Bentley/In Roads
Hi Nathan,
I don't have a lot of research to share, most of the stuff I have is how our
system interprets data from specific other systems.
I am however more than happy to share information about our system.
The comment was made that a basic XML format could be suitable.
In my spare time I dabble with Linux. There are current discussions about
open standards for documents. Word documents do not sit well with me. I
would therefore prefer XML, XHTML or maybe even PDF.
LINZ did a document (In Word, I think!) that seemed to us to be quite a good
description of how they interpret LandXML. Leica also did one. Do you have
copies of these?
My thoughts on a the actual format have (so far) been as follows:
"Application Name" and "Application Version Number" seem important to
identify the product.
We allow our end users to specify how a LandXML file is interpreted, so an
additional field such as "Options Selected" should, IMO be available.
Whether the LandXML file is being read or written may also be important.
(It is for us!)
These 4 fields should define the state of the software dealing with the
LandXML file.
Now I get confused :)
A plain table of "Element Name", "Attribute Name" and
"Interpretation/Description" seems reasonable, except I am unsure if the
"Element Name" can be/needs to be a 'full path' back to the root element.
(e.g. <PntList2D> may be interpreted differently depending on
context)
An alternative was to start with the LandXML schema, and prune it back to
only those elements and attributes that a particular software configuration
supports.
"Bigger than Ben Hur" is an expression that comes to mind!
It seems important to restrict this to a manageable level, and working out
exactly what people want or need.
I don't know what format the information Nathan has at the moment is in.
The Leica and Linz documents, although being in different formats, and not
compatible with each other, provided us with the information we required.
Perhaps just posting a number of documents like these on the LandXML web
site would be adequate. Each vendor could decide on a format most
appropriate to their needs and would require minimal supervision.
My view is that I am working on or with particular applications, and it is a
document on that application that I require.
I do not see the need to be able to generate, for example a list of
applications that support that support 3D Map Point elements.
My thoughts here are not at all clear, and I suspect that is reflected in
this e-mail.
Perhaps the last paragraph is the important one.
What do people actually want, and how do we see it being used. Is a text
document based on a particular application good enough?
Wishing those that celebrate over the Christmas season a joyful time,
Hugh
> -----Original Message-----
> From: Nathan Crews [mailto:nathan.crews@xxxxxxxxxxxx]
> Sent: Friday, 23 December 2005 7:00 AM
> To: Hugh Dixon; landxml@xxxxxxxxxxxxx
> Subject: RE: [LandXML] FW: Re: LandXML - Bentley/In Roads
>
> Michael / Hugh,
>
> If you are willing to share your research, I can help get the
> "application LandXML data support" information published on
> LandXML.org.
>
> I can dig up detailed LandXML data support for the Autodesk products
> and I understand Bentley may a similiar document or information for
> InRoads, GeoPak and MXRoads.
>
> Does anyone have a good idea on the format for this data? I started
> with a Word document with a table listing the elements in one column
> with a second column for details and notes for each, but I think it
> could look cleaner... Maybe a spread sheet or visio diagram?
>
> Regards (and Happy Holidays),
>
> Nathan
>
> -----Original Message-----
> From: landxml-bounce@xxxxxxxxxxxxx on behalf of Hugh Dixon
> Sent: Mon 12/19/2005 4:43 PM
> To: landxml@xxxxxxxxxxxxx
> Cc:
> Subject: [LandXML] FW: Re: LandXML - Bentley/In Roads
>
>
>
> Michael,
>
> It's that first sentence that gets me! (Although in that
> respect I am very much a "pot calling the kettle black") From
> a basic foundation it does seem that the conversion process
> is an iterative process.
> I guess I had best accept that, and get on with it.
>
> Thanks for your comments,
> Good luck with the new software!
>
>
> Hugh
>
>
>
> > > -----Original Message-----
> > > From: Ostertag, Michael [mailto:mostertag@xxxxxx]
> > > Sent: Tuesday, 20 December 2005 1:09 AM
> > > To: Hugh Dixon
> > > Subject: RE: [LandXML] Re: LandXML - Bentley/In Roads
> > >
> > > Hugh--
> > >
> > > First of all, I got the vendors to give me which elements they
> > > supported and in which way they intended to use the
> > elements (I wish
> > > they would post this to their websites).
> > > Secondly, by using VBA and style sheets, we would read the XML
> File
> > > and write it the database in question. Third, we would reverse
> the
> > > process.
> > >
> > > This would totally by pass the internal parsers and give us full
> > > control of the LandXML elements. I guess that we looked at the
> > > elements and data in the XML file and determined the
> > intent, changed
> > > it in VBA as necessary and then wrote it to the database. It
> took
> > > some time, but we finally wade through it. Clincher is, we
> > have to do
> > > it again...we changed software.
> > >
> > > I hope this helps some.
> > >
> > > michael
> > >
> > >
> > > -----Original Message-----
> > > From: Hugh Dixon [mailto:hugh.dixon@xxxxxxxxxxxxxx]
> > > Sent: Thursday, December 15, 2005 2:12 PM
> > > To: Ostertag, Michael
> > > Subject: RE: [LandXML] Re: LandXML - Bentley/In Roads
> > >
> > >
> > > Thanks Michael, you are confirming what I feel.
> > > You say you have used VBA, and changed your operating
> > procedures, to
> > > "massage" the data.
> > > Can you tell us how you found out in what way the data needed
> > > "massaging"?
> > > i.e. I'm guessing you have 'decoded' the way the software you
use
> > > interprets the LandXML file.
> > > It is how you got that information that interests me....
> > >
> > >
> > > Hugh Dixon
> > >
> > > > -----Original Message-----
> > > > From: Ostertag, Michael [mailto:mostertag@xxxxxx]
> > > > Sent: Friday, 16 December 2005 2:23 AM
> > > > To: Hugh Dixon
> > > > Subject: RE: [LandXML] Re: LandXML - Bentley/In Roads
> > > >
> > > > I have not used LandXML too much to exchange data between
> > different
> > > > programs, but believe that it may be necessary to develop
> > your own
> > > > style sheets to "massage" the data to desired results. I
> > > believe this
> > > > is due not necessarily to the to LandXML or the programs
> > being used
> > > > but to the slight variations in procedures by the
> > > individuals and what
> > > > data they find necessary to them.
> > > >
> > > > I have been able to exchange raw and processed data between
> > > programs,
> > > > but without some customization, we will not be able to
> > > exchange point
> > > > attribute information (TDS Attribute file).
> > > > Some of what we have done is through VBA and some to
> > > modifications of
> > > > procedures.
> > > >
> > > > Even if LandXML Standards are excepted by both programs, there
> is
> > > > still interpolation of the exact meaning of each element.
> > > >
> > > > Thanks,
> > > > Michael C Ostertag, CE IV
> > > > Montana Department of Transportation Missoula Construction PO
> Box
> > > > 7039 MISSOULA MT 59807-7039
> > > >
> > > > -----Original Message-----
> > > > From: landxml-bounce@xxxxxxxxxxxxx
> > > > [mailto:landxml-bounce@xxxxxxxxxxxxx]On Behalf Of Hugh Dixon
> > > > Sent: Monday, December 12, 2005 5:27 PM
> > > > To: landxml@xxxxxxxxxxxxx
> > > > Subject: [LandXML] Re: LandXML - Bentley/In Roads
> > > >
> > > >
> > > > Thankyou all for your assistance with this.
> > > > The core problem however remains. We are trying to map
> > > objects from
> > > > out data structures into LandXML elements/attributes, and
> > then into
> > > > another product.
> > > > How we do our mapping, naturally, makes perfect sense to us
> > > > :) There seems to be some confusion (on our and our users
> > > > part) when the second mapping is applied with data either
> > > not being as
> > > > expected, or disappearing totally.
> > > >
> > > > I believe that LINZ, a major LandXML user, provides a document
> > > > detailing what parts of LandXML they support, and how they
> > > interpret
> > > > it.
> > > > Has there been any move to encourage software
> > > providers/developers to
> > > > supply this sort of information to the wider community?
> > > > We do have this information available, although I suspect
> > it may be
> > > > difficult to find, and may not be particularly clear.
> > > > Does anyone else see a need for this information to be readily
> > > > available, and has anyone thought about a suitable format?
> > > >
> > > > Comments appreciated....
> > > >
> > > > --
> > > > Hugh Dixon
> > > > www.liscad.com
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
Other related posts:
