LandXMLのというのは、XML形式の土木CIM様に規格されたオープンフォーマットです。
で、そのLandXMLについてですが、これはその名の通りLand版（土地？）のXML形式のデータフォーマットだと理解しますが、Landのなかでも自然の地形（現況地形等）に関しては、ちょっとXMLのフォーマットいうのはそぐわないのではないか？と、かねがねより私はそのような疑念を抱いてきました。
その第一の理由が、地形を表現するデータと言うものがデータ量がすこぶる多い性質のものである点です。
第二には、人工での建築物や土木構造物とは違って、自然界の地形データというものは付帯する属性が極めて少ないという点。
この2点です。
以下にその辺の詳しい説明をしたいと思いますが、そのためLandXMLの地形データはすこぶる扱いにくいものになっている気がしてなりません。
以下は、私のような根っからのシステム屋の考え方で言えばですが、
やはり、データのフォーマットいうものは、とにかく使う側の（ユーザーの）使い勝手をまず第一に考えて作るべきでありますから、けっして、作る側本位に（拡張性だの再利用だのを優先して）決めたらいけませんね。今風で言うと、とにかくユーザーファーストで行かないと、オープンフォーマット（オープンデータ）いうのは、広く使ってもらってなんぼの世界だと思います。とにかく、考えるべき（最も優先するべき）はユーザー本位の使い勝手の良さ、それに尽きるだろうと思うわけです。
そのためには、まずもってシンプルさ、それが重要です。作る側の理屈で、拡張性だの再利用だのの方を優先して作ってしまうと、どうしても複雑化してしまう。それが著しく利用促進の妨げになるいうのは事実（世の常ではないか）と思います。世の中に広く普及させる唯一無二の方法は、とにかくシンプルで使い勝手が良く手軽さがあること。
世界的な流れなのかもしれないですが、作り手の拡張性や自由度やらを重視したXMLの規格いいますものは、その根本的な原理原則に反するのではなかろうか・・・と。
それで、話し戻しますが、
Landの上には人工の構造物と自然の地形が乗っているわけであけですが、この2つ、フォーマットは別々に分けてもいいんじゃないかと思う次第です。
先ほども書きました様に、とにかく地形のデータはデータ量が多く、ファイルもバカでかくなる場合が多いわけですから、しかも、地形に属性はすこぶる少なく、ツリー構造も必要はない。にもかかわらず、無理にXML化するとどうなるか？と言えば、国土地理院基盤地図情報の数値標高モデルのXMLデータを見ればわかる通り、無駄な情報が多いわりに、本質的な標高データの部分はただの羅列になってしまうに過ぎません。無駄が多く、即ち、どうにもユーザーの使い勝手が悪いと言わざるを得ない思います。
それで思い出しますのが、国土地理院の地形データと言えばその昔の数値地図のＣＤ、1枚7500円（税抜き）で販売されていたやつです。
このパッケージは懐かし～～～！
それが、ある時世界的な流れで（たぶん、世界測地系移行の関係で？）突如XML形式に変わったんです。そしたら、私も含めて誰も周りでこのＣＤ使わなくなって話し聞かなくなってしまったわけです。その流れを汲んで今、国土地理院のホームページから無料でダウンロードができる基盤地図情報の数値標高モデルのデータの中身を見たら、明らかに我々古い人間のユーザーが誰しも思うように、「地形データにタグは要らないよな。(笑)」
<gml:tupleList>タグのデータを見れば、肝心な標高はどうせ延々とＣＳＶ（カンマ区切り）のデータの羅列でしかありませんし、その前のごちゃごちゃした前置き部分のタグデータの数々が邪魔をして中々本題に辿り着けない感が、前置きが長くて誰にも読まれない文章に似ている感じがします。。。各タグの意味も直感的には中々わかりずらいですし、、、
昔のこのＣＤのデータフォーマットは、こんな感じだったですので、特に私みたいなFORTRANエンジニアには、すこぶる使い勝手が良かったわけです。（出典：国土地理院数値地図50ｍメッシュ標高ＣＤより）
やっぱ、工学系の大量データはこうでないと・・・。MEMデータは良かったな～(笑)
（要するに、昔は国土地理院も我々ユーザーのことを考えたフォーマットにしてくれていたんですね。）
で、今はFORTRANっていう時代ではないですから、やっぱデータは皆が使ってるExcelで扱い易い「CSV形式でしょ！」と言うことで、当システムでは、データの受渡しにはあえて今でもCSVを採用しています。
でも、世界の潮流や国の方針に逆らうような反逆児(!?)になるつもりではないですから(笑)、あくまでこれはいづれはLandXMLにも対応せねばならんだろう言うことで、今は未だその気乗りがしないというだけの話であります。