[LandXML] March 4, 2005 working draft LandXML-1.1 posted

  • From: "Nathan Crews" <nathan.crews@xxxxxxxxxxx>
  • To: <landxml@xxxxxxxxxxxxx>
  • Date: Fri, 4 Mar 2005 18:33:10 -0700

A new working draft of LandXML-1.1, dated March 4, 2005, and the complete
change log have been posted to the LandXML.org web site. See
<http://www.landxml.org/schema/LandXML-1.1/LandXML-1.1.xsd>
http://www.landxml.org/schema/LandXML-1.1/LandXML-1.1.xsd and
<http://www.landxml.org/schema/LandXML-1.1/Cumulative%20LandXML-1.1%20Change
s.doc>
http://www.landxml.org/schema/LandXML-1.1/Cumulative%20LandXML-1.1%20Changes
.doc respectively.
 

From now on along with the schema version number a date field will occur at
the top of the LandXML-1.1.xsd schema file itself.


<?xml version="1.0"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by Nathan Crews
(Autodesk) 
Date Posted: 3/4/2005-->

 

As version 1.1 evolves this will allow tracking of specific versions of the
working drafts for discussion purposes. Now that LandXML.org has 369 members
from 270 organizations in 27 countries and can be used in 43 registered
software applications from all over the world, coordination of open
discussion is more important than ever. So please use landxml@xxxxxxxxxxxxx
for all discussions and questions.

 

Import version and software development note:

 

There will not be any drastic model changes that will cause significant work
to update the existing applications. Existing LandXML applications can
support LandXML-1.1 by simply changing the LandXML header to reflect the new
schema version. In fact, by changing the <LandXML> header to LandXML-1.1,
all LandXML-1.0 files will still validate. 

 

All LandXML-1.0 registered software applications will be able to import
LandXML-1.1 files without modification as long as the schema version of 1.1
does not stop program flow during import. It is suggested that if the
version attribute in the <LandXML> header element is newer than the software
expects to allow the user to choose to continue or not. This worked very
well for the software applications that made the 0.88 to 1.0 transition.

 

Software developers please review item #6, "Allow duplicate "name"
attributes across collections of same element type" for potential software
development impact. It may require a slight change in program logic to
understand the reduced scope of unique element names to collections of same
element types. See the change document for more details.

 

 

Scope of Proposed Changes for version 1.1

 

1.      Change <CoordinateSystem> to support common EPSG coordinate system
names shared by OpenGIS and GML schemas.

2.      Clarify what is meant by "zenithAngle" in the survey data.

3.      Add support for PI based alignment definitions.

4.      Add railway cant (superelevation) data to <Alignment>.

5.      Add data structure to support electronic Australian cadastral survey
system.

6.      Allow duplicate "name" attributes across collections of same element
type.

7.      Add road design cross section definitions to Alignments.

8.      Add support for non-linear road design cross section transitions.

9.      Adjust the PipeNetwork structure to better support modern hydraulic
materials such as curved pipe.

* Note - Italic text above indicates the proposed item IS NOT YET in the
current working draft of LandXML-1.1.

 

Items 1-6 above have been completed and are ready for review. For detailed
change notes please see the "Cumulative LandXML-1.1 Changes Since
LandXML-1.0" document at
http://www.landxml.org/schema/LandXML-1.1/Cumulative
<http://www.landxml.org/schema/LandXML-1.1/Cumulative LandXML-1.1
Changes.doc> LandXML-1.1 Changes.doc.

 

Important note about proposed <CoordinateSystem> Changes:

 

Lessons learned integrating LandXML-1.0 and GML or GIS/Geospatial
applications indicate we should not only provide units of measure, but also
the coordinate system. This will greatly extend the value of LandXML data
since it will be more readily imported into Geospatial software. This also
expands cross discipline data exchange potential for Architectural,
Civil/Survey and GIS. Buildings are built on civil engineering project sites
defined by survey boundaries that have a real location in the world. By
simplifying a working understanding of units of measure and coordinate
systems, ifcXML (Architectural/Building data), LandXML (Civil/Survey data)
and GML (GIS/Geospatial data) data can be easily brought together into a
single comprehensive 3D model; ready for a myriad of uses.

 

Rather than define our own global coordinate system dictionary, it is
proposed that we use the most comprehensive dictionary available and
actively maintained. This simplifies LandXML coordinate systems to reuse the
extensive coordinate systems dictionary work done by EPSG (European
Petroleum Survey Group, http://www.epsg.org). See
<http://www.ihsenergy.com/epsg/epsg21.html>
http://www.ihsenergy.com/epsg/epsg21.html for EPSG coordinate systems
details. LandXML can reference a simple numeric EPSC code to refer to
specific and complex coordinate system details of all know types (2D, 3D,
projected, etc.). For software developers a complete Microsoft Access .mdb
database and SQL script for creating the database tables for the coordinate
systems is provided by EPSG which will reduce development time (See the EPSG
web site for specific details regarding the use of these files).

 

New <CoordinateSystem>.epsgCode attribute represents the EPSG numeric code
for a specific coordinate system. EPSG has reserved the integer range 0 to
32767 for use as codes for coordinate systems.

 

Example: Represents Australian Map Grid Zone 52

name="AGD66 - AMG Zone 52" , epsgCode="20252" 

 

Example: Represents Colorado CS27 South Zone

name="NAD27-Colorado South" , epsgCode="26755"

 

 

 

Regards,

 

Nathan Crews

 <http://www.landxml.org> www.landxml.org

 




Other related posts: