[LandXML] Re: LandXML attribute consistency
- From: nathan.crews@xxxxxxxxxxxx
- To: KMURPHY@xxxxxxxxxxxxxx
- Date: Tue, 8 Oct 2002 12:03:34 -0700
You can differentiate the existance of design data by using the optional
'state' attribute on most LandXML elements.
For example:
<CgPoints name="Existing Topo" state="existing">
<CgPoint name="1" desc="CP 1" code="70">10000 10000 1000</CgPoint>
<CgPoint name="2" desc="CP 2" code="70">9928.16 8425.81
1027.423</CgPoint>
</CgPoints>
<CgPoints name="Existing Topo" state="proposed">
<CgPoint name="10" desc="CL 1" code="70">10000 10000 1000</CgPoint>
<CgPoint name="12" desc="CL 2" code="70">9928.16 8425.81 1027.423</CgPoint>
</CgPoints>
or
<Surface name="existing" desc="existing ground" state="existing">
<SourceData>
<Breaklines>
<Breakline brkType="standard" name="Breakline Feature1" desc="">
<...>
</SourceData>
</Surface>
Where the two CgPoints collection contain existing or proposed data. Almost all
LandXML elements support the state attribute.
Also for incorporating external file reference use the <Feature> element. It
contains a file reference scheme.
External File References Provided by the LandXML Schema:
A simple alternative to external file linking has been provided in the LandXML
schema for specific elements. These optional LandXML elements refer to larger
source data files used to create the LandXML data elements.
Example:
<.>
<Surfaces>
<Surface name="EG" desc="Existing Ground">
<.>
<SourceData>
<PointFiles>
<PointFile>d:\\projects\\cityofmoosehead\\1020Points.xml</PointFile>
<PointFile>http://data.rosecounty.st.me.us/planning/50gridtopopoint.asp?city=moosehead
</PointFile>
</PointFiles>
</SourceData>
<.>
</Surface>
</Surfaces>
This example shows two types of external references, one is a XML document
located on the local file system and the second is a XML stream generated by
the specified URL. Both types of reference return LandXML data containing
surface point <P> elements.
The <Feature>.<DocFileRef> element is contained within the common <Feature>
element. Using this element, it is easy to associate external data, such as
raw data files, drawing files, project files, legal documents or even web data
references such as links to DEM and other surface data, to specific elements.
Hope this helps...
Nathan Crews
www.landmxl.org
-----Original Message-----
From: Kevin Murphy [mailto:KMURPHY@xxxxxxxxxxxxxx]
Sent: Tuesday, October 08, 2002 2:09 PM
To: Nathan Crews
Subject: Re: [LandXML] LandXML attribute consistency
Nathan,
perhaps this is not the correct place to ask such questions but I will
anyways...
1) How can we differentiate between existing cogo points ( surveyed)
and design cogo points ( proposed)
2) Is there a way we could incorporate source information such as data
from digital mapping
versus points from a conventional survey...versus points from an RTK
survey..versus information
taken from a set of "as built" plans ??
just my 2 cents worth...
thanks
K.Murphy
Kevin J Murphy, PE,LS
Michael Baker Jr Inc
307 College Road East
Princeton, NJ, 08540
phone...609-734-7927
pager....732-836-5601
fax........609-734-7950
email: kmurphy@xxxxxxxxxxxxxx
>>> <nathan.crews@xxxxxxxxxxxx> 10/08/02 02:02PM >>>
There is a suggestion that we clarify the use of the common attributes
name, desc, and code. The issue comes from real-world data exchange
customer issues and I think there is a simple solution.
Here is a suggested and consistant use of the attributes in the data
types most common in LandXML data:
Cogo Points seems to be a simple item however there are at least 3
vendors
are placing feature coding in different attributes. We use Feature >
Style,
LDD uses code and Moss uses desc. I suggest for discussion that beside
the
actual geometry, we have a minimum of:
name - point name (we all seem to get this one.)
desc - a note on the point that adds information to the feature code
code - feature code. we use this to control displays and classify
points
Alignments are an area where I have not had a lot of comments back from
the
public but besides the required geometry I suggest the same information
as
the cogo points.
name - alignment name
desc - a note on the point that adds information to the feature code
code - feature code. we use this to control displays and classify
points
Parcels are the same as alignments to InRoads except they are closed.
name - parcel name
desc - a note on the point that adds information to the feature code
code - feature code. we use this to control displays and classify
points
This really suggests that we use 'desc' for a simple note and use the
'code' attribute to mean feature code, classification or category.
What do you think?
Nathan Crews
www.landmxl.org
Other related posts:
