2024 年 5 月 31 日

都市計画データ標準製品仕様書

第 1.2 版

解説書

内容
1.

2.

3.

はじめに ................................................................................................................................................ 1
1.1.

本書の目的 ..................................................................................................................................... 1

1.2.

本書の構成 ..................................................................................................................................... 1

1.3.

引用文献......................................................................................................................................... 2

都市計画データ標準製品仕様書の概要 ................................................................................................ 3
2.1.

製品仕様書とは .............................................................................................................................. 32.2.

都市計画データ標準製品仕様書とは ............................................................................................. 3

2.2.1.

標準製品仕様書の特徴 ........................................................................................................... 4

2.2.2.

標準製品仕様書と拡張製品仕様書 ......................................................................................... 6

2.2.3.

標準製品仕様書の運用 ........................................................................................................... 7

都市計画データ標準製品仕様書の解説 ................................................................................................ 8
3.1.

応用スキーマ ................................................................................................................................. 8

3.1.1.

都市計画データの全体像 ........................................................................................................ 8

3.1.2.

対象とする LOD .................................................................................................................... 9

3.1.3.

都市計画基本図モデル ......................................................................................................... 10

3.1.4.

都市計画基礎調査情報モデル .............................................................................................. 15

3.1.5.

都市計画決定情報モデル ...................................................................................................... 18

3.1.6.

空間スキーマ ........................................................................................................................ 25

3.2.

参照系 .......................................................................................................................................... 32

3.2.1.

空間参照系 ............................................................................................................................ 32

3.2.2.

時間参照系 ............................................................................................................................ 34

3.2.3.

地理空間データにおける参照系の指定 ................................................................................ 343.3.

品質要求及び評価手順 ................................................................................................................. 36

3.3.1.

標準製品仕様書の品質要求 .................................................................................................. 36

3.3.2.

標準製品仕様書の品質評価手順 ........................................................................................... 37

3.3.3.

部分更新を行う場合の品質評価 ........................................................................................... 38

3.4.

データ製品配布 ............................................................................................................................ 38

3.4.1.

CityGML による符号化........................................................................................................ 38

3.4.2.

CSV による符号化 ................................................................................................................ 40

3.4.3.

成果品の構成 ........................................................................................................................ 41
解

i

3.5.

4.

メタデータ ................................................................................................................................... 44

3.5.1.

JMP2.0 に基づくメタデータ ................................................................................................ 44

3.5.2.

原典資料一覧 ........................................................................................................................ 44

都市計画データ拡張製品仕様書の作成 .............................................................................................. 45
4.1.

概要 .............................................................................................................................................. 45

4.2.

応用スキーマの作成 .................................................................................................................... 45

4.2.1.

基本的なルール .................................................................................................................... 45

4.2.2.

都市計画基本図のための拡張 .............................................................................................. 45

4.2.3.

都市計画基礎調査情報のための拡張.................................................................................... 47

4.2.4.

都市計画決定情報のための拡張 ........................................................................................... 494.3.

品質要求及び品質評価手順の決定 .............................................................................................. 50

4.4.

拡張製品仕様書の作成 ................................................................................................................. 50

付属資料 1

用語及び略語 ..................................................................................................................... 52

付属資料 2CityGML/i-UR 解説 .......................................................................................................... 53

付属資料 3

秘匿処理方法 ..................................................................................................................... 64

付属資料 4

改訂概要 ............................................................................................................................ 68

参考文献.................................................................................................................................................. 77

解ii

1. はじめに1.1. 本書の目的「都市計画データ標準製品仕様書」（以下、「標準製品仕様書」と呼ぶ）は、都市計画データ（都市計画
情報（都市計画行政に必要となる都市計画基本図、都市計画基礎調査情報及び都市計画決定情報）の地理
空間データ）に対する要求事項（製品仕様）をまとめた文書である。標準製品仕様書は、各地方公共団体
において、都市計画データを整備する際に、その製品仕様を適切に決定でき、かつ、各地方公共団体の製品仕様に従って整備された都市計画データが、標準化されたものになることを目的としている。
各地方公共団体では、都市計画データを整備する際には、整備する対象や範囲を明確にするため、標準製品仕様書を参考として、それぞれの製品仕様書（以下、「拡張製品仕様書」と呼ぶ）を作成しなければならない。
そこで、本書は、標準製品仕様書の内容を解説するとともに、標準製品仕様書に従い、各地方公共団体
が拡張製品仕様書を作成する手順を示す。
なお、本書はデータ作成方法を規定するものではない。データ作成方法については、各地方公共団体の公共測量作業規程や都市計画基礎調査実施要領、個人情報保護法及び著作権法、その他関係する法令・規則・マニュアルを確認・遵守すること。

1.2. 本書の構成
本書の構成を表 1-1 に示す。
第 1 章では、本書の目的や構成を示す。
第 2 章では、標準製品仕様書の概要を説明する。主として地方公共団体職員を対象としている。
第 3 章では、標準製品仕様書を解説する。各地方公共団体において、都市計画データの作成に従事する技術者を対象とする。
第 4 章は、拡張製品仕様書を作成する手順を示す。各地方公共団体において、都市計画データを作成する際に、その製品仕様を検討する技術者を対象とする。
また、付属資料には、標準製品仕様書や都市計画データへの理解を深めるための補助的な資料を示す。
表 1-1 本書の構成
章

タイトル

内容

1章

はじめに

本書の目的及び構成。

2章

都市計画データ標準製品仕様書の標準製品仕様書の考え方や特徴などの概要。

概要
3章
4章

都市計画データ標準製品仕様書の標準製品仕様書に定義されたデータ構造、品質、解説

符号化仕様等、主たる内容の技術解説。

都市計画データ拡張製品仕様書の地方公共団体ごとの拡張製品仕様書の作成方法の

作成

解説。
解

1

付属資料 1

用語及び略語

標準製品仕様書で使用する用語及び略語の説明。

付属資料 2CityGML 解説

標準製品仕様書が引用する CityGML 及び i-UR の解説。

付属資料 3

秘匿化処理

都市計画基礎調査データを秘匿化する場合の処理方法の解説。

付属資料 4

改訂履歴

標準製品仕様書の改定内容を解説。

1.3. 引用文献
本書が引用する規格・仕様・マニュアルを以下に示す。
表 1-2 引用文献
文書名

URL

都市計画データ標準製品仕様書

https://www.mlit.go.jp/toshi/
city_plan/toshi_city_plan_tk_
000049.html

Data Encoding Specification of i-Urban Revitalization -Urban

https://www.chisou.go.jp/tiik

Planning ADE- ver.3.1 （内閣府地方創生推進事務局）

i/toshisaisei/itoshisaisei/iur/
index.html

OpenGIS® OGC City Geography Markup Language (CityGML)

https://www.ogc.org/standar

Encoding Standard, Version 2.0, OGC document 12-019 （Opends/citygml

Geospatial Consortium）
地理情報標準プロファイル（JPGIS）2014 （国土交通省国土地理院） https://www.gsi.go.jp/GIS/jp
gis-downloads.html

JMP2.0 仕様書（国土交通省国土地理院）
品質の要求，評価及び報告のための規則（国土交通省国土地理院）
作業規程の準則（国土交通省国土地理院）

https://psgsv2.gsi.go.jp/kouk
you/jyunsoku/

都市計画基礎調査実施要領（国土交通省都市局）

https://www.mlit.go.jp/toshi/
tosiko/kisotyousa001.html

引用文献のうちで、版の記載があるものは、その版を適用し、その後の改正版（追補を含む）は適用しない。版の記載がないものは、その最新版（追補を含む）を適用する。
また本書において、「i-UR」は、特段の指定がない限り、Data Encoding Specification of i-Urban
Revitalization -Urban Planning ADE- ver.3.1 を指す。また、「CityGML」についても同様に OpenGIS®
OGC City Geography Markup Language (CityGML) Encoding Standard, Version 2.0, OGC document 12019 を指す。

解2

2. 都市計画データ標準製品仕様書の概要
2.1. 製品仕様書とは製品仕様書とは、地理空間データを作成する際に、作成すべき地理空間データの使用目的、内容及び品
質など、作成されるべき地理空間データに対する要求事項をまとめた文書である。製品仕様書は、地理空間データへの要求事項を明確にするため、作成者は要求事項に見合った効率的な作成手法を選定でき、作成された地理空間データは本来の利用目的に適したものとなる。
また、作成された地理空間データを使用する際には、地理空間データだけではその内容や品質などを詳細に把握することが困難であり、再利用の支障になる場合がある。そこで、地理空間データと製品仕様書を対として利用者に提供することで、利用者は地理空間データの内容、構造、データ形式及び品質などを、製品仕様書により知ることができ、地理空間データをより有効に活用できるようになる。
つまり製品仕様書は、地理空間データが作成される場面では、設計書として使用され、地理空間データ
が流通・交換される場面では、詳細な取扱説明書として使用される。
地理空間データの製品仕様書の構成を表 2-1 に示す。
表 2-1 地理空間データの製品仕様書の構成
1

構成

概要

概覧

製品仕様書の作成に関する情報、製品（地理空間データ）の目的、引用規格等。

2

適用範囲

この製品仕様書が適用される範囲。

3

データ製品識別製品の名称、日付、問合せ先等。

4

データ内容及び構造

データ構造（UML クラス図）と定義。

5

参照系

製品に適用される座標参照系及び時間参照系。

6

データ品質

製品に対する品質要求、また、任意で品質評価手順。

7

データ製品配布

製品の符号化仕様と媒体情報。

8

メタデータ

製品のメタデータに適用される仕様

9

その他（任意記載項目）

1～8 以外の項目で示したい事項。例えば、データ取得やメンテナ
ンスに関する事項。

製品仕様書の詳細：地理空間データ製品仕様書作成マニュアル[1]2.2. 都市計画データ標準製品仕様書とは「都市計画データ標準製品仕様書」は、「都市計画データ」への要求事項をまとめた製品仕様書である。
標準製品仕様書は、都市計画情報に関する製品仕様書である「都市計画 GIS データの共通仕様（案）」（国土交通省都市局, 2005 年 3 月）及び「地図情報レベル 2500 数値地形図データ作成のための標準製品
解

3

仕様書」
（国土交通省国土地理院, 2014 年 4 月）の内容を統合している。統合により、これまで独立して存在していた都市計画基本図、都市計画基礎調査及び都市計画図書の各データを一体的に取り扱えるようにすることを目的としている。さらに、3D 都市モデルとの整合を図ることにより、3D 都市モデルと一体的な整備によるコストの削減・省力化、都市計画の高度化、民間での活用を同時に目指している。
都市計画情報と3D都市モデルの相互連携イメージ
都市計画情報（2D）

都市計画基本図

都市計画
基礎調査情報建物、道路等の共通利用

都市計画
都市計画
決定情報
基礎調査情報都市計画区域、区域区分の共通利用

図 2-1 都市計画データと 3D 都市モデルとの一体的整備

3D 都市モデルの詳細：3D 都市モデルの導入ガイダンス[2]2.2.1. 標準製品仕様書の特徴
標準製品仕様書の特徴を示す。標準製品仕様書の詳細は、2 章に示す。
(1) データの内容及び構造
標準製品仕様書が定義するデータの内容は、都市計画基本図（数値地形図）、都市計画基礎調査及び都
市計画図書を網羅し、データ構造は CityGML 及びその拡張である i-UR のデータ構造に準拠している。
CityGML は、地理空間データに関する国際標準化団体である Open Geospatial Consortium（OGC）
が策定した、都市空間を記述することを目的としたデータ構造とフォーマットの国際標準である。また、
i-UR は CityGML の拡張ルールに準拠し内閣府地方創生推進事務局が策定した技術仕様であり、都市計
画や都市再生に必要となる情報のデータ構造とフォーマットを定めている。CityGML 及び i-UR については、付属資料 2

CityGML/i-UR 解説に示す。

3D 都市モデルではデータの相互流通性を高めるために CityGML 及び i-UR が採用されていることから、都市計画データにおいてもこれを採用することで、データの相互流通性と 3D 都市モデルとの整合性を高めている。つまり、3D 都市モデルの製品仕様を定める 3D 都市モデル標準製品仕様書では、独自にデータ構造を定義せず、CityGML 及び i-UR から必要なデータ構造を抽出して利用している。都市計画
データにおいても、独自にデータ構造を定義せず、必要なデータ構造を CityGML 及び i-UR から抽出している。結果として、同じ情報は同じデータ構造でデータ化されることになる。
例えば、建築物の記述には CityGML で定義された bldg:Building を使用し、建築物に付与する属性（都解4

市計画基礎調査で得た建物利用現況）の記述には、i-UR に定義された uro:BuildingDetailAttribute を使用する。これは、3D 都市モデルも都市計画データも共通である。一方、3D 都市モデルでは、建築物の形状として、CityGML に定義された LOD1（箱モデル）を含むが、都市計画データには、2 次元の形状（LOD0）を含む。また、都市計画決定情報の記述には、i-UR に定義された uro:UrbanPlanningArea などの都市計画の各種区域を使用する。これは、3D 都市モデルと都市計画データと完全に共通となる。一方、都市計画データには、都市計画基礎調査で収集する人口規模などの統計情報があるが、これは 3D 都市モデル標準製品仕様書には含まれていない。

都市計画データ
標準製品仕様書

都市計画データにのみ含まれるi-UR
CityGML

3D都市モデルにのみ含まれる

3D都市モデル
標準製品仕様書

都市計画データ、3D都市モデルに共通

図 2-2 都市計画データと 3D 都市モデルとの整合
このように、都市計画データと 3D 都市モデルとは、同じデータ構造で記述される。そのため、将来的に都市計画データと 3D 都市モデルとを統合し、一体管理することも可能である。
(2) 参照系
標準製品仕様書が採用する参照系のうち、空間参照系は、「日本測地系 2011 における平面直角座標系」を採用する。平面直角座標系は、都市計画基本図にも採用されている空間参照系であり、地球を平面に投影した面上における原点からの距離で位置を示すことから、距離や面積の計算が容易になるという特徴がある。
なお、3D 都市モデルでは、「日本測地系 2011 における経緯度座標系と東京湾平均海面を基準とする
標高の複合座標参照系」を採用している。これは 3D 都市モデルが全国を対象としているからである。一方、都市計画データは都市単位での利用を想定しているため、平面直角座標系を採用している。
また、時間参照系は、「グレゴリオ暦及び日本標準時」とする。グレゴリオ暦とは西暦である。日本では、日付の記述として西暦と和暦が併用されているが、混在がデータ利用上の支障となるため、標準製品
仕様書では日付の表記を西暦に統一する。
(3) 品質要求及び評価手順
標準製品仕様書の品質要求のうち、位置正確度（位置の正しさ）は、都市計画法により都市計画の計画図に要求される縮尺 1/2500 に対応する地図情報レベル 2500（水平の標準偏差 1.75m、高さの標準偏差0.66m）を基本とする。標準製品仕様書では、位置正確度以外に、データに漏れや過剰が無いかを示す「完全性」、データ構造やデータフォーマット、属性の定義域等の適合度を示す「論理一貫性」、属性の値の正解

5しさ等を示す「主題正確度」の観点から品質要求を行っている。また、データが品質要求を満たしているか否かを評価する手法（品質評価手順）を併せて提示している。
(4) フォーマット（符号化仕様）
製品仕様書では、「データの内容及び構造」に従い、データを記述するフォーマットを指定する。標準
製品仕様書が採用するフォーマットは、CityGML 形式を基本とする。CityGML は、タグによりデータを意味づけする XML の一種である。ただし、都市計画基礎調査の調書及び集計表に該当するデータは、図形（幾何オブジェクト）を含まないデータであることから、調書及び集計表のデータにはフォーマットとして CSV 形式を採用する。CSV 形式とはカンマ区切りのテキストファイル形式である。その他、ファイル命名規則やフォルダ構成等も定めている。
(5) メタデータ
メタデータは、地理空間データの説明情報である。メタデータにはデータの作成日、データ作成者等の情報や、品質評価結果が記述され、データを再利用する際にデータの概要を把握する有益な情報となる。
製品仕様書では、メタデータの仕様を指定している。標準製品仕様書が採用するメタデータの仕様は、JMP2.0 を基本とする。JMP2.0 は、地理情報標準である ISO19115 Metadata に従い、国土地理院において定めた日本における地理空間データのメタデータの実装仕様である。ただし、JMP2.0 では、データ作成に使用した資料（原典資料）の詳細を記述できない。そこで標準製品仕様書では、JMP2.0 により記述
するメタデータとは別に、原典資料の諸元を示す一覧を CSV 形式で作成することを定めている。
(6) その他「その他」には、製品仕様書を構成する前述の各項目に含まれていないものの、製品仕様書に基づき地理空間データ製品を作成する際や、作成された地理空間データ製品を使用する際に、製品仕様書に記載しておいたほうがよいと思われる追加情報を記述する。標準製品仕様書では、以下を示す。


標準製品仕様書の拡張規則及び制限規則


標準製品仕様書に基づき、地方公共団体ごとの都市計画データ製品仕様書（「拡張製品仕様書」と呼ぶ）を作成するために、標準製品仕様書に定義する地物や属性を取捨選択、又は追加するための規則である。



取得方法


都市計画データを作成する際に従うべき、データ取得方法に関する指定である。各地方公共団
体の公共測量作業規程や都市計画基礎調査実施要領がこれに該当する。

2.2.2. 標準製品仕様書と拡張製品仕様書
都市計画データに含むべき情報は、都市の規模や環境によって差異がある。ただし、地方公共団体ごとに独自に製品仕様書を作成すると、それに従った都市計画データも様々なものとなってしまい、データとしての再利用性が低くなってしまう。
解6そこで、標準製品仕様書は、都市計画データの標準的な製品仕様を定めている。これを各地方公共団体の都市計画データの製品仕様書のベースとすることで、地方公共団体ごとの製品仕様書作成の利便性を向上しつつ、全体として標準化された都市計画データとすることができるようになる。標準製品仕様書
はいわばカタログであり、各地方公共団体はここに定義された地物や属性を必要に応じて取捨選択又は追加し、それぞれの製品仕様書（拡張製品仕様書※）を作成できる。このとき、標準製品仕様書の拡張規則及び制限規則に準拠することで、拡張製品仕様書も国際標準に準拠した製品仕様書となり、各都市の都市計画データの再利用性を高めることができる。拡張製品仕様書の作成方法は、本書の第 4 章にて解説する。
なお、製品仕様書には、作成する都市計画データの空間範囲等を記述する必要がある。これらの情報は各地方公共団体によって異なることから、地物の取捨選択・追加の有無によらず、地方公共団体ごとに拡張製品仕様書を作成する必要がある。
※標準製品仕様書に従い、各地方公共団体において作成された製品仕様書はすべて「拡張製品仕様書」となる。（例：〇〇市都市計画データ拡張製品仕様書）

2.2.3. 標準製品仕様書の運用
都市計画情報のデジタル化推進には、①標準製品仕様書の策定データの標準化と、これに準拠した②データ整備・更新の推進策の両軸が必要である。しかしながら、地方公共団体のデジタル化の現状により異なることから、地方公共団体によっては一挙に標準製品仕様書に基づくデータ整備・更新を行うことが困難な場合がある。
よって、都市計画データの整備・更新では、地方公共団体のデジタル化の現状に応じた段階を設定する
ことが考えられる。

解7

3. 都市計画データ標準製品仕様書の解説
3.1. 応用スキーマ
本項では、標準製品仕様書第 4 章に示す都市計画データの応用スキーマを解説する。
応用スキーマには、都市計画データとして必要となるデータ構造とその内容が記述されている。データ
構造の記述には、UML クラス図を使用する。UML クラス図の記法は、付属資料 2 に解説する。

3.1.1. 都市計画データの全体像
都市計画データの応用スキーマ（「都市計画データ応用スキーマ」と呼ぶ）は、CityGML 及び i-UR から、都市計画データに必要な地物等を抽出している。都市計画データ応用スキーマと、CityGML 及び iUR の関係を示した図が、図 3-1 に示すパッケージ図である。

«ApplicationSchema»
都市計画データ«import»«import»«ApplicationSchema»
CityGML«ApplicationSchema»
i-UR«import»«import»«import»GML

図 3-1 都市計画データ応用スキーマの構成
都市計画データ応用スキーマは、CityGML と i-UR を引用している。また、CityGML や i-UR は、応用スキーマに共通して利用可能な基本的な要素（例：点、線、面）を定義する GML を引用している。
都市計画データ応用スキーマは、都市計画基本図モデル、都市計画基礎調査情報モデル、都市計画決定
情報モデルから構成する（図 3-2）。

解8

都市計画基本図モデル

都市計画基礎調査情報モデル

都市計画決定情報モデル(from 3D都市モデル)

図 3-2 都市計画データ応用スキーマのパッケージ
都市計画基本図モデルは、都市計画基本図に必要となる地物等を CityGML 及び i-UR から引用する。
同様にして、都市計画基礎調査モデルには、都市計画基礎調査情報に必要となる地物等、都市計画決定情報モデルには、都市計画決定情報に必要な地物等が CityGML 及び i-UR から引用されている。
なお、都市計画決定情報モデルは、既に 3D 都市モデルの応用スキーマで定義されているため、都市計
画データ応用スキーマではこれを利用している。
3 つのパッケージが引用する CityGML 及び i-UR の地物等を表 3-1 に示す。
表 3-1 都市計画データが引用する CityGML 及び i-UR のパッケージ
GML

CityFurniture

CityObjectGroup

Generics

LandUseReliefTransportation

TunnelVegetation

WaterBody

Urban Object

Urban Function

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

基本図
都市計画

※
✓

✓

✓

✓

基礎調査情報都市計画

Statistical Grid

Building✓

Bridge✓Appearance

Core

都市計画

i-UR

CityGML

✓

✓

✓

✓

✓

※
✓

✓

✓

決定情報

✓

✓

※

※各地方公共団体において、CityGML 及び i-UR に無い地物等を拡張したい場合に使用する。

3.1.2. 対象とする LOD
LOD（Level Of Detail）は、「詳細さの度合い（詳細度）」であり、一つのオブジェクトの幾何をその利用や可視化の目的に応じて、複数の段階に抽象化することを可能とする、マルチスケールなモデリングの仕組みである。
CityGML の LOD には、LOD0 から LOD4 までの 5 段階があり、LOD0 が最も粗く、LOD4 が最も細かいデータとなる。
LOD0 は、地物を 2 次元平面に投影した形状であり、点、線又は面として表現する。
LOD1 は、LOD0 の形状を加工した形状であり、立体又は面として表現する。LOD0 で点又は線とし
解9

て表現された地物は、LOD1 では面又は立体として表現される。また、LOD0 で面として表現された地
物は、LOD1 では高さをもつ面又は立体として表現される。LOD1 で面として表現される地物や道路や水面あるいは土地利用や都市計画区域のように、厚みをもたず、2 次元的な広がりをもつ地物である。
都市計画データでは、LOD0 を 2 次元の数値地形図データと位置付ける。また、数値地形図データを加工し、構造化（線を閉じて面とする等）したデータを LOD1 と位置づける。表 3-2 に都市計画データ
応用スキーマが対象とする LOD を示す。
さらに、i-UR では、LOD の概念を拡張し、LOD-1（マイナス 1）を定義している。これは個々の地物ではなく、地物を集計した統計データを用いて簡易に都市を表現する概念である。都市計画基礎調査情報のうち、統計メッシュによる表現はこれに該当するため、LOD-1 となる。
表 3-2 都市計画データ応用スキーマが対象とする LOD
LOD-1
都市計画基本図
都市計画基礎調査情報

LOD0

LOD1

LOD2

LOD3

LOD4

〇
〇

〇

〇※1

都市計画決定情報〇※2

土地利用は、数値地形図では記号と区域界等で表現される。一方、都市計画基礎調査の土地利用現況で使用する土地利用は面として必要となる。そこで、都市計画基礎調査の土地利用現況は LOD1 としている（※1）。また、都市計画決定情報は、地形地物や行政界等の線を利用し、区域を作成するため LOD1としている（※２）。

3.1.3. 都市計画基本図モデル(1) モデルの概要
都市計画基本図モデルは、都市計画基本図に含まれる情報のデータモデルである。都市計画基本図は、
国土地理院が定める「地図情報レベル 2500 数値地形図データ作成のための標準製品仕様書（案）」に基
づき、地図情報レベル 2500 の数値地形図（DM）データとして作成されている。
DM は地図として地物の形状を記述する観点からは効率的なデータ構造となっている一方で、記述可
能なデータ項目が固定されているため、地物に都市計画基礎調査等で得た情報を属性として追加することが困難である。
そこで、都市計画基本図モデルでは CityGML 及びこれを拡張した i-UR をデータ構造として採用している。この時、DM との対応付けを明確にするため、「公共測量標準図式 数値地形図データ取得分類基準表」（以下、「標準図式」と呼ぶ）を CityGML 及び i-UR のクラスに対応付けている。対応付けは、標準図式の分類コード（レイヤとデータ項目を識別する 4 桁の半角数字）ごとに行っている。表 3-3 に対応付けの概要を示す。分類コードごとの対応は、標準製品仕様書 4.2.1 に示す。各地方公共団体において、独自の分類コードを追加している場合は、表 3-3 及び標準製品仕様書 4.2.1 を参考にして、対応付ける
CityGML 又は i-UR のクラスを選定するとよい。CityGML は建物や道路、トンネルといった都市を構成する様々な地物をクラスとして定義しているため、分類コードの多くは CityGML のクラスに対応づく。
一方、CityGML では行政界のような概念的な地物のクラスは定義されていないが、これらは i-UR に定解10

義されているため、i-UR のクラスに対応付く。
表 3-3 都市計画基本図モデルの対応付け
DM のレイヤ

対応付ける CityGML/ i-UR のクラス※

説明

道路

tran::Road、tran::Track

道路は tran::Road に対応付け、徒歩道及び庭園
路は、tran::Track に対応付ける。

境界、所属界

urf::Administration

道路施設

brid::Bridge、tun::Tunnel、
frn::CityFurniture 、 tran::Road 、
veg::SolitaryVegetationObject

鉄道

tran::Railway

建物

bldg::Building

鉄道施設

建物に付属する構造物

brid::Bridge、tun::Tunnel、
frn::CityFurniture

uro::DmGeometricAttribute

水部

wtr::WaterBody

水部に関する構造物

frn::CityFurniture

brid::Bridge、frn::CityFurniture、
wtr::WaterBody
uro::OtherConstruction
uro::DmGeometricAttribute

法面

uro::OtherConstruction

諸地、場地

urf::Boundary、luse::LandUse

構囲

veg::PlantCover

変形地

dem::BreaklineRelief、
dem::MassPointRelief

基準点

指示点
注記

、

frn::CityFurniture

植生

等高線

施設の種類に応じて、対応付ける地物を選定。

frn::CityFurniture

建物記号

その他小物体施設の種類に応じて、対応付ける。
brid::Bridge（橋梁、横断歩道橋）、tun::Tunnel（トンネル）の他、その他の道路付属物は
frn::CityFurniture、道路面を構成する地物は、
tran::Road （ 歩 道 、 分 離 帯 ）、 並 木 は
veg::SolitaryVegetationObject とする。

施設の種類に応じて、対応付ける。
wtr::WaterBody（水涯線、湖沼等）、brid::Bridge（桟橋）の他、渡船発着所は、frn::CityFurniture 、
そ の 他 の 水 部 に 関 す る 構 造 物 は
uro::OtherConstruction とする。流水方向は、
uro::DmGeometricAttribute とする。

区域界は urf::Boundary とし、その他の諸地・場
地は luse::LandUse とする。

dem::BreaklineRelief、
uro::DmGeometricAttribute

等高線は、dem::BreaklineRelief とし、矢印は、
uro::DmGeometricAttribute とする。

frn::CityFurniture、
dem::MassPointRelief

標石がある基準点は、frn::CityFurniture に対応
付 け 、 図 化 に よ る 標 高 点 は 、
dem::MassPointRelief に対応付ける。

線での表現は、dem::BreaklineRelief とし、点での表現は dem::MassPointRelief とする。

uro::DmGeometricAttributeuro::Annotation※接頭辞に urf 又は uro が付くクラスは i-UR、それ以外は CityGML で定義されたクラスである。

解11

(2) モデルの構造
都市計画基本図モデルは、CityGML 又は i-UR に定義されているクラスに、DM データとして必要な情報（例：分類コード）を属性として付与する構造となっている。

図 3-3 は、DM データの「建物」の UML クラス図である。
「建物」は、CityGML の bldg::Building に対応付けている。この bldg::Building に数値地形図データとして必要な情報として追加しているのが、

uro::DmAttribute である。

図 3-3 Building の UML クラス図

uro::DmAttribute は、抽象クラスであり、図式を表現する uro::DmGeometricAttribute と注記を示す

uro::DmAnnotation の二つの下位クラスがある。さらに、これらのクラスは、数値地形図データと互換性を保つための要素情報（uro::DmElement）をもつことができる（図 3-4）。

解12図 3-4 数値地形図との変換に必要なデータのための UML クラス図

uro::DmGeometricAttribute は、数値地形図データの図式表現に係る情報を属性としてもつ（表 3-4）。
表 3-4 uro::DmGeometricAttribute の属性
属性名

属性の内容

dmCode（uro::DmAttribute から継承）

DM 分類コード。

meshCode（uro::DmAttribute から継承） 当該図形が含まれる図郭番号。
geometryType

線や面などの図形の種類（DM のレコードタイプ）。

mapLevel

地図情報レベル（都市計画基本図の場合は 2500 となる）。

shapeType

中庭線や棟割線などの図形の区分（DM の図形タイプ）。

visibility

上空から見えているかの区分。

is3d

地物の座標値が 3 次元か否か（2 次元の場合は false）。

isInstallation

当該図形が付属図形か否かの区分。

isEdited

編集処理が行われたか否かの区分。

angle

当該図形が方向をもつ場合の角度。

elevation

当該図形に標高値が与えられている場合の標高。

また、uro::DmGeometricAttribute は関連役割 lod0Geometry により図形（gml::_Geometry）をもつ。

gml::_Geometry は、点、線、面などを汎化した抽象クラスであり、点、線、又は面のいずれでも記述できる。

1 つの bldg::Building は、複数の uro::DmAttribute をもつことができる（関連役割 bldgDmAttributeの多重度が[0..*]）。これは、DM では、1 棟の建物を表現する際に、複数の図形区分が用意され、これに基づく複数の図形を組み合わせることがあるためである（図 3-5）。
解

13

外形

棟割線

中庭線

階層線

図 3-5 堅ろう建物に使用する図式（太線）
例えば、ある 1 棟の建物の DM データが、外形と中庭線から構成されていた場合、当該建物を表す

bldg::Building のインスタンス（データ）には、外形の図形をもつ uro::DmGeometricAttribute のインス
タ ンス と中庭 線の 図形を も つ uro::DmGeometricAttribute の イン スタン スと が含ま れる 。 前 者 はshapeType（図形タイプ）の値が 0（非区分）となり、後者は 31（中庭線）となる。

なお、1 棟の建物を表現する複数の図形を構造化（例：外形と中庭線を組合せ、内空有のポリゴンを作成する）し、面として表現する場合は、bldg::Building の lod0RoofEdge（屋根外形）及び lod0FootPrint(接地外形)を使用し、その構造化した面を記述する。都市計画基本図の場合は、建物の形状を上からの正射
影による外周で表示することが原則となるため、lod0RoofEdge を採用することが原則となる。
数値地形図との互換性を保つための情報は、uro::DmElement に格納する（表 3-5）。
表 3-5 uro::DmElement の属性
属性名

属性の内容

属性名

属性の内容

locationType

地域分類。

breakType

間断区分。

infoType

情報分類。

attributeValue

属性区分。

elementKey

要素識別番号。

attributeType

属性数値。

hierarchyLevel

階層レベル。

attributeValue

属性データ書式。

dataType

実データ区分。

cretionDate

取得年月。

annotationType

精度区分。

updateDate

更新の取得年月。

precisionType

注記区分。

terminationDate

消去年月。

dislocationType

転位区分。

freeSpace

空き領域。

このように、都市計画基本図モデルは DM 分類コードごとに CityGML 又は i-UR に定義されているクラスに対応付け、DM データとして必要な情報を、取得した図形と共に属性として付与する構造となっ
ている。

解

14

3.1.4. 都市計画基礎調査情報モデル(1) モデルの概要
都市計画基礎調査情報モデルは、「都市計画基礎調査実施要領」に基づき作成する位置図、調書及び集計表のデータモデルである。
都市計画基礎調査情報モデルは、位置図に記載する内容を地物とし、CityGML 及び i-UR のクラスと対応付けている。また、調書は地物がもつ属性として定義している。集計表についても、小地域や行政区
域など、集計する単位となる地物の属性として定義している。
都市計画基礎調査の地物と CityGML 及び i-UR のクラスとの対応は、標準製品仕様書 4.3.1 に示す。
(2) モデルの構造
都市計画基礎調査実施要領では、各データ項目について、作成すべき位置図、調書及び集計表を指定している。データ項目によって使用するクラスは異なるが、データ構造の考え方は同じであるため、ここでは「土地利用現況」及び「人口規模」を用いて解説する。

位置図に表現する地物は、CityGML 又は i-UR に定義する地物を示すクラスに対応付ける。そのクラスがもつ幾何オブジェクトや属性を用いて、位置図に地物の位置を表示したり、属性値で色分けしたりできる。例えば、土地利用現況では、位置図として用途別分布図を作成する。土地利用は luse::LandUseに対応付ける（図 3-6）。

位置図で示す土地利用の図形（面）

位置図のイメージ図
位置図上で色分け表示
する場合に使用する属性（用途、面積等）。
いずれの属性を取得対象とするかは、各自治体の製品仕様書（拡張製品仕様書）で指定する。

土地利用の図形（LOD1）の作成に使用した原典資料と、主題属性の作成に資料下原典資料を、品質情報として記述する。

図 3-6 土地利用現況の UML クラス図と位置図との対応

luse::LandUse は LOD1 の幾何オブジェクトとして面（lod1MultiSurface）をもち、これが位置図に示
解

15

す図形となる。また、luse::LandUse の属性 usage（用途）の値を用いて色分けができる。

uro::LanduseDetailAttribute は、土地利用現況で収集・整理する様々な情報を土地利用の属性として格納するための箱として用意されたデータ型のクラスである。uro::LanduseDetailAttribute に定義された各属性は任意であり、土地利用現況で収集・整理する場合に使用する。いずれの属性を採用するかは、拡張製品仕様書において指定する（4.2.3）。また、uro::DataQualityAttribute は、原典資料を記録するためのデータ型である。土地利用現況で作成する土地利用の図形は、建築確認の申請データや地番図から境界線を取得する場合や、航空写真から判読する場合など、地方公共団体により取得方法や原典資料が様々である。そこで、属性 geomertySrcDesc により、その土地利用の境界を取得した方法や原典資料を記録する。
また、位置図には、地物の外形線や代表的な位置を示したものだけではなく、メッシュにより表現する
場合がある。メッシュは、あるエリアを隙間なく網の目に分けた区画である。各メッシュはほぼ同一の大きさ・形状となることから、各メッシュに統計データを属性として与えてそのエリアを表現することで、地域事象を計量的に比較することが容易になる。このメッシュの表現には、i-UR で定義された

urg::_StatisticalGrid を用いる。urg::_StatisticalGrid は抽象クラスであり、インスタンス化されるのはこれを継承する具象クラスとなる。
例えば、図 3-7 は、人口分布図を表す場合の UML クラス図である。人口分布図では、メッシュ単位（4 分の 1 地域メッシュ）で表現する。この人口分布図のメッシュを表すクラスは、urg::_StatisticalGridを継承した urg::Population である。urg::Population は、性別・年齢別人口（urg::populationByAgeAndSex）

や昼間人口（urg::daytimePopulation）などの属性をもつ。属性の値を用いて色分けすることで、人口分
布図を表現できる。

位置図上で色分け表示
する場合に使用する属性（年齢別人口、昼間人口）

1つ1つのメッシュと対応づく

いずれの属性を取得対象とするかは、各自治体の製品仕様書（拡張製品仕様書）で指定

図 3-7 人口規模

位置図のイメージ図

位置図（人口分布図）の UML クラス図

調書は、図形と属性とが一体化した GIS データから、属性を出力した表である。そこで、調書は地物の一部（属性の集まり）として、i-UR に定義されたデータ型のクラスに対応づけている。
解16

調書は、urf::UrbanPlanningBasicSurveyTable と、urf::ItemRecordType により構成する。

urf::UrbanPlanningBasicSurveyTable は、調書の表全体を指し、urf::ItemRecordType は、表に含まれる個々のレコードを指す。

urf::UrbanPlanningBasicSurveyTable には調書を管理するために必要な情報が属性として定義されている。例えば、調書の名称（tableName）や基準日（referenceDate）である。また、urf::ItemRecordType

は、調書に必要となる項目として、id と item をもつ。これらのデータ型は汎用的なデータ型として定義されており、都市計画基礎調査の全ての調書に適用する。属性 id は各レコードを識別するための属性である。これは位置図上に示した地物を識別する参照番号として用いる。属性 item は、調書を構成する調査項目（列見出し）と値との対であり、urf::ValueByCodes を用いて記述する。urf::ValueByCodes は、追加する属性の名称（class）と、これに対応する属性の値を、整数型（intValue）、実数型（doubleValue）、
単位付き計測値型（measureValue）、文字列型（stringValue）のいずれかから 1 つ選び、属性の名称と値とをセットで記述するためのデータ型である。都市計画基礎調査実施要領に示される各調書については、追加する属性の名称が標準製品仕様書（B.3）に示されているため、これに従う。各地方公共団体で独自の項目を設定している場合には、列見出しの名称とこれに対応する値の型を拡張製品仕様書で指定することで、任意に追加できる。

レコードの識別子
レコードごとの属性データ

調書のレコード

図 3-8 調書の UML クラス図と土地利用現況調書との対応

集計表は、調書に含まれる情報を、集計した結果である。集計表も調書と同様に表形式であるため、調解

17

書と同じく i-UR に定義されたデータ型のクラスを使用する。
図 3-9 に土地利用現況の集計表の UML クラス図と集計表との対応を示す。

urf::UrbanPlanningBasicSurveyTable は、集計表の表全体を指す。また集計表の各レコードは、

urf::SummaryRecordType を用いて記述する。urf::SummaryRecordType の属性 classCode 及び classLabel

は、集計の単位を指す。classCode の型は gml::CodeType である。gml::CodeType は、指定したコードリ
ストの中から選択するできるデータ型である。classLabel の型は xs::string であり、任意の文字列型である。土地利用現況調査の場合は、集計表の Common_UrbanAreaClass.xml から都市計画の区域区分に該当するコードを指定し、classLabel により、コードに対応する説明を記述する。コードとするか、任意の文字列とするかは、標準製品仕様書（B.3）に示している。属性 item は、項目と値の対であり、土地利用現況調査の集計表の場合は、用途別の土地利用面積である。この属性の型は urf::ValueByCodes であり、属性 class に土地利用の用途（例：田、畑）を格納し、単位付き計測値型となる measureValue を使って合計面積を格納する。item の多重度は、[1..*]であり複数回記述できるようになっている。つまり、土地利用の用途ごとに合計面積を列挙できる。
このように、都市計画基礎調査データはデータ項目ごとに、位置図に記載するものは地物として、調書及び集計表は、表全体とこれを構成するレコードとを分け、それぞれ CityGML 又は i-UR のクラスと対応付けている。

属性classCode（コード）又はclassLabel（コードに対応する説明）により集計する単位を指定する。
（例の場合は、classLabelにより、区域区分を文字列で記述）
集計単位

集計結果

集計表のレコード
属性itemで土地利用の用途ごとの合計面積を列記する。

図 3-9 集計表の UML クラス図と土地利用現況集計表との対応

3.1.5. 都市計画決定情報モデル
解18

(1) モデルの概要
都市計画決定情報モデルは、都市計画図書である計画図及び計画書のデータモデルである。
計画図は、都市計画法施行規則第 9 条第 2 項において縮尺 2500 分の 1 以上の平面図と定められており、縮尺 2500 分の 1 で整備される都市計画基本図を基に作成される。すなわち、計画図の位置正確度も都市計画基本図と同等の位置正確度となる。紙地図では都市計画区域のような 1 図郭に収まらない広範な区域を都市計画基本図に図示ができなかったが、デジタルデータとして記述することで図郭の境界を考慮する必要がなくなる。
なお、都市計画の総括図は、都市計画を可能な限り 1 葉の図面に表示することを目的として作成されていることから、本標準製品仕様書の対象外とする。
標準製品仕様書では、法令に基づき都市計画で決定される各区域（表 3-6）を地物として定義している。
また、都市計画において定めるべき事項や定めるよう努める事項、また、都市計画を告示する際に必要となる事項を、区域の属性とし、i-UR のクラスと対応付けている。さらに「都市再生特別措置法」に基づき市町村が作成する立地適正化計画において定められる居住誘導区域及び都市機能誘導区域についても、
立地適正化計画が都市計画法に基づく市町村マスタープランの一部とみなされるその性格を考慮し、都市計画決定情報に含めている。
都市計画の各区域と、i-UR のクラスとの対応は、標準製品仕様書の 4.4.3 に示す。
表 3-6 都市計画決定情報モデルの対象
都市計画の種類

都市計画法

都市計画区域、準都市計画区域

法六条の二

区域区分

七条

地域地区及び用途地域

八条

促進区域

十条の二

遊休土地転換利用促進地区

十条の三

被災市街地復興推進地域

十条の四

都市施設

十一条第 1 項（以下で細分していない都市施設）

八号～十五号
交通施設

一号

公共空地

二号

供給施設及び処理施設

三号

水路

四号

教育文化施設五号

医療施設及び社会福祉施設

六号

市場、と畜場、火葬場

七号

市街地開発事業十二条

市街地開発事業等予定区域

十二条の二

地区計画等

十二条の四

立地適正化計画（都市機能誘導区域、居住誘導区域）

―

解

19

(2) モデルの構造標準製品仕様書では、表 3-6 に示す都市計画の種類ごとに UML クラス図を示している。ここでは全体像と特徴的な点を解説する。

都市計画決定情報モデルに含まれる各種区域は、i-UR の urf::_UrbanFunction を継承する（図 3-10）。

urf::_UrbanFunction は、CityGML には定義されていない、目には見えない概念的な地物のクラスである。この、urf::_UrbanFunction は、lod1MultiSurface という関連役割により面（gml::MultiSurface）と関連をもつ。つまり、面として表現することができる。urf::_UrbanFunction を継承し、区切られた一定の範 囲 を 意 味 す る 区 域 （ urf::Zone ） が 定 義 さ れ て い る 。 こ の 区 域 を さ ら に 継 承 し 、 都 市 計 画 区 域（urf::UrbanPlanningArea）や地域地区（urf::DistrictsAndZones）などの各種区域がクラスとして定義されている。これらの各種区域は、urf::_UrbanFunction を間接的に継承しているため、面として表現できる。都市計画決定データの LOD や形状は、2)で説明する。

_Feature

区域の図形（面）«FeatureType»core::_CityObject«FeatureType»+lod1MultiSurface«DataType»
urf::Boundary«Type»
gml::MultiSurface

0..1

urf::_UrbanFunction

区域の境界_AbstractGeometricAggregate

立体的な範囲+boundary0..*«FeatureType»
urf::ThreeDimensionalExtent«FeatureType»
urf::Zone+threeDimensionalExtent
0..*

地域地区
区域区分
«FeatureType»
urf::DistrictsAndZones（市街化区域、市街化調整区域）
促進区域«FeatureType»
urf::AreaClassification«FeatureType»
urf::QuasiUrbanPlanningArea

準都市計画区域«FeatureType»
urf::UrbanPlanningArea«FeatureType»
urf::ProjectPromotionArea

市街地開発事業等
予定区域

市街地
開発事業

«FeatureType»
urf::UrbanDevelopmentProject«FeatureType»
urf::ScheduledAreaForUrbanDevelopmentProject

被災市街地復興推進地域

図 3-10

都市施設

地区計画等

«FeatureType»urf::
UnusedLandUsePromotionArea

遊休土地転換利用促進地区

都市計画区域«FeatureType»

urf::_AbstractDistrictPlan«FeatureType»urf::
UrbanDisasterRecoveryPromotionArea«FeatureType»
urf::UrbanFacility«FeatureType»
urf::ResidenceAttractionArea

居住誘導区域«FeatureType»
urf::UrbanFunctionAttractionArea

都市機能誘導区域

都市計画決定情報モデルの UML クラス図（全体像）

また、都市計画決定情報モデルには、urf::_Zone を継承する都市計画の区域以外に、urf::Boundary と解20urf::ThreeDimensionalExtent の 2 つのクラスが定義されている。urf::Boundary は、区域の境界である。
urf::Boundary は 、 区 域 の 境 界 に 属 性 を 付 与 し た い 場 合 に 使 用 す る 。 詳 細 は 6) で 説 明 す る 。
urf::ThreeDimensionalExtent は、道路、都市高速鉄道、河川その他の政令で定める都市施設について定めることができる立体的な範囲である。
なお、地域地区を特化して用途地域、都市施設を特化して交通施設というように、さらに特化して詳細なクラスが定義されている場合がある。また、図 3-10 は全体像のみを示しており属性の表示を省略しているが、標準製品仕様書では個々の区域の UML クラス図の中で、都市計画において定めるべき事項や定めるよう努める事項が属性として定義されている。

標準製品仕様書において、都市計画決定データに適用する LOD は LOD1 である。
都市計画決定データとして定義される、全ての都市計画の区域は、「面」で表現する。
3.1.2 で述べたように、LOD1 では、土地利用や道路、そして都市計画の区域のような面的な広がりをもつ都市オブジェクトは、高さをもたない面として表現される。これらの面は、3 次元の地形に重畳することで 3 次元的に可視化できる。

都 市 計 画 の 各 区 域 の 形 状 は 、 上 位 の 抽 象 ク ラ ス で あ る urf::_UrbanFunction か ら 継 承 す る

lod1MultiSurface（面）を使用して記述する。この lod1MultiSurface により記述された区域は、計画図の平面図に示す区域の範囲と一致する。都市施設の立体的な範囲である urf::ThreeDimensionalExtent もurf::_UrbanFunction を継承しており、その形状は lod1MultiSurface（面）を使用して記述する。この時、lod1MultiSurface により記述する幾何オブジェクトは、計画図の平面図で示される範囲（平面）となる。

都 市 計 画 の 各 区 域 を 表 す ク ラ ス は 、 i-UR の urf::_UrbanFunction （ 図 3-11 ） を 継 承 す る 。

urf::_UrbanFunction は i-UR の Urban Function モジュールの最上位の汎用的なクラスであり、これを継承するクラスで使用可能な様々な属性が定義されているが、全てオプション（多重度が[0..1]又は[0..*]）となっている。

_CityObject«FeatureType»

urf::_UrbanFunction
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

class: gml::CodeType [0..1]
function: gml::CodeType [0..*]usage: gml::CodeType [0..*]validFrom: xs::date [0..1]
validFromType: gml::CodeType [0..1]
enactmentFiscalYear: xs::gYear [0..1]
validTo: xs::date [0..1]
validToType: gml::CodeType [0..1]
expirationFiscalYear: xs::gYear [0..1]
legalGrounds: xs::string [0..1]
custodian: xs::string [0..1]
notificationNumber: xs::string [0..1]
urbanPlanType: gml::CodeType [0..1]
areaClassificationType: gml::CodeType [0..1]
nominalArea: gml::MeasureType [0..1]
prefecture: gml::CodeType [0..1]
city: gml::CodeType [0..1]
reference: xs::anyURI [0..1]
reason: gml:StringOrRefType [0..1]
note: gml:StringOrRefType [0..1]
surveyYear: xs::gYear [0..1]

図 3-11

属性の多重度[0..1] 省略可能。最大記述回数は1回。
[0..*] 省略可能。複数回記述することができる。

_UrbanFunction の UML クラス図

解21

都市計画の各区域は urf::_UrbanFunction を継承するため、これらすべての属性をオプションとしてもつことができる。都市計画の区域の場合には、例えば、いつ決定されたのか、また、都道府県で決定されたのか、市町村で決定されたのか等の情報を必須としたい場合がある。しかしながら、応用スキーマのUML クラス図の記法には、上位のクラスで指定された多重度を変更する仕組みがない。そこで、オプシ
ョンとなっている属性を必須としたい場合には、応用スキーマ文書において、属性の定義に「運用上必須とする」という記載をしている。応用スキーマクラス図において属性の多重度がオプションとなっている場合においても、応用スキーマ文書において運用上必須とする旨が記載されている場合には、必ず属性を作成しなければならない。

「運用上必須とする」属性として、例えば、当初の告示番号（urf::notificationNumber）や当初の告示日（urf::validFrom）などがある。ただし、これらの情報を過去に遡ってデータ化することが困難な場合がある。運用上必須となる属性のデータ化が難しい場合は、属性に「不明」を意味する値を入れることができる。告示日などの日付が不明な場合は、「0001-01-01」、告示番号などの文字列が不明な場合は「Null」
を入力する。

都市計画決定には、新規に決定される場合や、決定された都市計画が変更される場合、また、廃止される場合がある。このような時系列の変遷を、urf::_UrbanFunction から継承する属性 validFrom と validTo
により記述できる。

属性 validFrom は、都市計画が効力を生じる日付（xs:date）である。属性 validTo は、都市計画が効力を失う日付（xs:date）である。属性 validFrom の日付から validTo の日付までが、その都市計画が有効となる期間である。属性 validFrom 及び属性 validTo には、その種類（属性 validFromType 及び属性

validToType）を記述できる。これは、それぞれの日付が「決定」、「変更」又は「廃止」のいずれであるかを区別するために用いる。
例えば、用途地域が新規に決定され、その後、都市計画の変更により区域が拡大されたり、縮小された
りし、最後に用途が変更されたとする（図 3-12）。

解222025年度のデータセット

データ①

区分 function

都市計画の決定2025-10-01

第2種住居地域が指定された6 （第2種住居地域)

始期 validFrom

2025-10-01

始期の区分 validFromType

データ①

1 （新規）

終期 validTo-

終期の区分 validToType

第2種住居地域

当初の告示番号 notificationNumber
最終の告示日 finalNotificationNumber
最終の告示番号 finalNotificationNumber

第2種住居地域の区域が拡大されたデータ②

6 （第2種住居地域)

2025-10-01

2027-10-01

1 （新規）

3 （変更）----○○市告示第140号○○市告示第150号

2027-10-01

2027-10-01○○市告示第150号○○市告示第150号

データ①

データ①-2

データ②

6 （第2種住居地域)

6 （第2種住居地域)

6 （第2種住居地域)

2025-10-01

2025-10-01

2027-10-01

1 （新規）

終期 validTo

1 （新規）

3 （変更）

2030-10-01

終期の区分 validToType

-

-

3（変更）

当初の告示番号 notificationNumber--○○市告示第140号

最終の告示日 finalNotificationNumber○○市告示第140号○○市告示第150号

ー2030-10-01

2030-10-01

最終の告示番号 finalNotificationNumber

ー○○市告示第160号○○市告示第160号

2035年度のデータセット

データ①

データ①-2

データ②

データ③

6 （第2種住居地域)

始期 validFrom

6 （第2種住居地域)

6 （第2種住居地域)

9（近隣商業地域）

2025-10-01

始期の区分 validFromType

2025-10-01

2027-10-01

2035-10-01

1 （新規）

終期 validTo

1 （新規）

3 （変更）

3 （変更）

2020-10-01

終期の区分 validToType

2035-10-01

2035-10-01

-

3（変更）

当初の告示番号 notificationNumber

3 （変更）

3 （変更）-○○市告示第140号

最終の告示日 finalNotificationNumber○○市告示第140号○○市告示第150号○○市告示170号

ーーー

2035-10-01

ー

ー

ー

○○市告示第170号

始期の区分 validFromType
終期 validTo
当初の告示番号 notificationNumber
最終の告示日 finalNotificationNumber
最終の告示番号 finalNotificationNumber

2030年度のデータセット

2030-10-01

区分 function

縮小

第2種住居地域の区域が縮小された

始期 validFrom
データ データ①-2 ②

近隣商業地域に変更された始期の区分 validFromType

区分 function

都市計画の変更

2035-10-01

データ③

近隣商業地域最終の告示番号 finalNotificationNumber

区分 function
始期 validFrom
始期の区分 validFromType
終期 validTo
終期の区分 validToType
当初の告示番号 notificationNumber
最終の告示日 finalNotificationNumber
最終の告示番号 finalNotificationNumber○○市告示第140号
データ②

始期 validFrom

終期の区分 validToType

都市計画の変更

データセットに含まれるデータの変遷2025-10-01

6 （第2種住居地域)

区分 function
データ①○○市告示第140号

データ①

2027年度のデータセット

都市計画の変更

2027-10-01-

都市計画の区分
都市計画の効力を生じる日
都市計画の効力を生じる日の区分（新規・変更）
都市計画の効力を失う日
都市計画の効力を失う日の区分（廃止・変更）
都市計画の当初の告示番号
当該都市計画を含む最終（最新）の都市計画決定・変更の告示日
当該都市計画を含む最終（最新）の都市計画決定・変更の告示番号

図 3-12

当該年度に整備する
3D都市モデルに格納すべきデータ（必須）
経年変化の把握（無効となった区域も把握）したい
場合に格納すべきデータ（オプション）

都市計画の変遷

この例では、2025 年 10 月 1 日にある区域が「第 2 種住居地域」として指定され、2027 年 10 月 1 日に都市計画の変更により区域が拡大された。また、2030 年 10 月 1 日に再度都市計画が変更され区域が縮小された。このとき、縮小された区域は 2025 年に指定された区域の一部であった。続いて 2035 年 10
月 1 日の都市計画の変更では「第 2 種住居地域」として指定されていた全ての区域は「近隣商業地域」に変更された。このような場合、各年に整備した都市計画決定情報のデータセットには次のようなデータが含まれる。
2025 年のデータセットには、この年に決定された「第 2 種住居地域」のデータ（データ①）が含まれる。urf:validFrom の値は 2025-10-01 となり、urf:validFromType の値は 1（新規）となる。

2027 年のデータセットには、この年に拡大された「第 2 種住居地域」のデータ（データ②）が追加される。データ②は都市計画の変更により生じた区域であるため、urf:validFromType の値は 3（変更）となる。また、最新の告示番号が更新されるため、データ①の属性 urf:note は更新され、値は 2027-10-01○○市告示第 150 号となる。
2030 年のデータセットには、2025 年に決定された区域が縮小された区域のデータ（データ①－2）と、
解23

2027 年に決定された区域のデータ（データ②）が含まれる。ともに、最新の告示番号である urf:note が更新される（値は 2030-10-01-○○市告示第 160 号）。このとき、都市計画が変更される前まで存在していた区域（データ①）の消失を把握したい場合には、urf:validTo 及び urf:validToType を使用する。

urf:validTo の値は 2030-10-01 となり、urf:validToType の値は 3（変更）となる。2030 年のデータセッ

トとして必須となるデータはデータ①－2 及びデータ②であり、データ①はオプションである。
2035 年のデータセットには、新たに決定された「近隣商業地域」を示す区域のデータ（データ③）が含まれる。また、消失した区域の把握を行う場合には、第 2 種住居地域の区域を示すデータ①－2 及びデータ②の urf:validTo 及び urf:validToType を記述したものをデータセットに含める。2035 年度のデータセットとして必須となるのはデータ③であり、データ①、データ①－2 及びデータ②はオプションである。
また、オプションとなるデータは、各年の必須のデータ（有効な都市計画のデータ）の差分により生成可能である。
なお、既に都市計画が決定されてから長い時間が経ち、複数の変更が加えられ、それらの記録が紙でしか残されていない場合も多い。このような場合、過去の都市計画の変遷を管理することは現実的でない

ため、urf:notificationNumber（告示番号）を Null とするなどとし、本標準製品仕様書に基づいてデータ整備が可能な時点から時系列に整備することも考えられる。

都市計画において定めるべき項目あるいは定めることができる項目には、定型化されていないものや図表が含まれるものがある。このような情報に対応する属性には、型として gml:StringOrRefType を設定している。

gml:StringOrRefType は、文字列（xs:string）又は参照（xlink:href）のいずれかを選択可能な型である。

文字列で記述することが難しい場合は、xlink:href を用いて外部ファイルを参照することができる。外部ファイルとは、地方公共団体のウェブサイト等から公開されている都市計画決定に関わる計画書や計画図の HTML や PDF 等であり、xlink:href の値としてその URL を記載する。

«FeatureType»
urf::UrbanPlanningArea
+
+
+
+
+
+
+
+

図 3-13areaClassification: gml::CodeTypereasonForAreaClassification: gml:StringOrRefType [0..1]
policyForAreaClassification: gml:StringOrRefType [0..1]
purposeForUrbanPlan: gml:StringOrRefType [0..1]
policyForUrbanPlanDecision: gml:StringOrRefType [0..1]
population: xs::integer [0..1]
cityArea: gml::MeasureType [0..1]
cityPopulation: xs::integer [0..1]

都市計画区域（urf::UrbanPlanningArea）の UML クラス図

例 え ば 、 都 市 計 画 区 域 （ urf::UrbanPlanningArea ） の 場 合 は 、 区 域 区 分 を 定 め る と き の 方 針（policyForAreaClassification）や都市計画の目標（purposeForUrbanPlan）などの属性がこれに該当する（図 3-13）。これらの情報は長文であったり、図表が入っていたりする場合もあり、構造化したデータと解24

して記述することが難しい場合がある。この場合、各地方公共団体のウェブサイトから PDF 等の文書として公開されている「都市計画区域の整備、開発及び保全の方針」の URL を値として記述する。

都市計画区域や用途区域等の区域は、境界線により区切られる。区域の形状は gml::MultiSurface（面）により表現され、面の境界は、gml::LineString（折れ線）で表現される。

都市計画では、区域の境界を「地番界」や「道路中心線」などの地物を用いて指定したり、あるいは「道路中心線から 2m のセットバック」のように地物からの距離で指定したりする場合がある。しかしながら、幾何オブジェクトである gml::LineString にはこのような情報を属性として付加できない。

そこで、区域の境界が何であるのかを属性としてもたせるために定義された地物が、urf::Boundary である。urf::Boundary は、区域（urf::Zone）を区切る境界である（図 3-10）。urf::Boundary は、属性 function
により、その境界線が行政界なのか、道路中心線なのか等の種類を指定できる。

ただし、urf::Boundary の幾何オブジェクトは、これにより区切られる都市計画区域や用途地域等の区域を示す面の境界と一致しなければならない。例えば、ある地区計画の境界が地番界と道路区域界により指定されていたとする（図 3-14）。この時、地区計画の区域は、この地区計画の境界の線（linestring1～linestring5）を外周とする面となる。

境界線b（道路区域界）linestring5

linestring4
polygon1

地区計画A

linestring1

境界線a
（地番界）

linestring2
地物

lod1MultiSurface

地区計画A

polygon1

地物

lod1MultiCurve

境界線alinestring1

境界線blinestring2, linstring3, linestring4, linestring5

図 3-14linestring3

Polygonexterior（外周）polygon1

linestring1, linestring2, linstring3, linestring4,
linestring5

区域と境界線との関係

なお、区域の境界線に属性をもたせる必要が無い場合は、urf::Boundary を作成しなくてよい。

3.1.6. 空間スキーマ
空間スキーマとは、点、線及び面などの座標をもつ幾何的な要素（幾何オブジェクト）を定義するスキ
解25

ーマであり、地理情報標準の一つである。
地理情報標準では、地物の位置や形状も地物の特性として捉えており、これを空間属性と呼ぶ。空間ス
キーマでは、この地物の空間属性を記述するための幾何オブジェクトやその構造を定義している。
空間スキーマには様々な幾何オブジェクトが定義されているが、都市計画データでは 2 次元で位置や形状を記述するために必要となる幾何オブジェクトのみを抽出している。これを空間スキーマプロファ
イルと呼ぶ。
本項では、空間スキーマプロファイルに含まれる幾何オブジェクトについて、GML により符号化した場合のインスタンスと合わせて解説する。
(1) 基本的な幾何オブジェクト
空間スキーマプロファイルは、基本的な幾何オブジェクトとこれらの集まりで構成する。
図 3-15 は基本的な幾何オブジェクトである。
基本的な幾何オブジェクトとは、点、線及び面である。基本的な要素の上位クラスである

gml::_GeometricPrimitive を継承し、点（gml::Point）、線（gml::_Curve）、面（gml::_Surface）が定義される。gml::_Curve は、さらにこれを継承し折れ線（gml::LineString）が、また、gml::_Surface は、これを継承し多角形（gml::Polygon）がそれぞれ定義される。

_Geometry

凡例«Type»
gml::_GeometricPrimitive

GMLに定義されたクラス

CityGMLに定義されたクラス

点i-URに定義されたクラス«Type»
gml::_Surface«Type»«Type»
gml::Point

gml::_Curve+0..*+interior

1+exterior«type»
gml::_Ring«Type»
gml::Polygon

position: gml::DirectPosition«Type»
gml::LineString+

position: gml::DirectPosition [2..*]線

面«Type»
gml::LinearRing+

position: gml::DirectPosition [4..*]

図 3-15

空間スキーマプロファイル（１）gml::Point は、座標（gml::DirectPosition）をもつ。gml::LineString は、始点及び終点を含む 2 点以上の座標から構成される。さらに、gml::Polygon は、1 つの外周（exterior）をもち、また、内周（interior）をもつこともできる。内周や外周は、輪（gml::_Ring）により定義される。輪を継承する gml::LinearRing

は 、 平 面 の 輪 で あ る 。 gml::Polygon の 外 周 及 び 内 周 に は 、 こ の gml::LinearRing を 使 用 す る 。
解26

gml::LinearRing の輪は、4 点以上の座標の列により記述する。この時、始点と終点は一致し、これは輪が「閉じている」ことを意味する。
(2) 点（gml::Point）

gml::Point は、点を記述するための幾何オブジェクトであり、その位置を示す座標値をもつ。
座標値の記述には、<gml:pos>を使用する。

記述例：<gml:Point gml:id=”pos001”><gml:pos>-17833.33 -40388.62 0.0</gml:pos></gml:Point>

座標値は X、Y、Z の順列とし、それぞれを半角スペースで区切る。この時、X 及び Y は、
「日本測地系
2011 における平面直角座標系」に従う。X 及び Y の座標値は、小数点第 2 位（センチメートル）とする。
また、都市計画データの場合は、2 次元データであるため、高さを示す座標値は 0.0 とする。
平面直角座標系では、X は真北に向かう値を正し、Y は真東に向かう値を正とすることに注意すること。また、3D 都市モデルでは経緯度座標系が採用されていることにも注意すること。
(3) 線（gml::_Curve, gml::LineString）

gml::_Curve は線を記述するために使用される幾何オブジェクトである。gml::_Curve は抽象クラスであり、インスタンスはこれを継承する具象クラスを用いて作成する。gml::_Curve を継承する具象クラス
は複数あるが、都市計画データでは、gml::LineString のみを使用する。gml::LineString は、折れ線である。

gml::LineString は、以下の事項を守らなければならない。

1) gml::LineString を構成する点を、以下の方法により記述する。
 gml:posList を用いて記述する。この時、gml:posList には 2 点以上の座標値が含まれてなければならず、すべての座標値には同じ空間参照系が適用されなければならない。
2) gml::LineString を構成する点の座標値は、始点と終点が一致する場合を除き、一意とする。
3) gml::LineString は交差したり、重なったりしてはならない。

gml::LineString は、2 点以上の点から構成され、それらの点の順序は始点から終点までの順列になっていなければならない。始点と終点以外の点の座標が、他の点の座標と一致していてはならず、また、一つの折れ線に自己交差や重なりがあってはならない（図 3-16）。

解

27

P0

P1

P0

P1

P4

P4

P2

P2

P3

L2=（P0 ,P1 ,P2 ,P3 ,P4）
自己交差

図 3-16

P3

L3=（P0 ,P1 ,P4,P2,P3,P4 ）始終点以外の点重複

エラーとなる gml:LineString の例

gml::LinearString を CityGML で記述する場合、複数の記述方法があるが、標準製品仕様書では、<gml:posList>を使用する方法を採用する。これは、gml::LineString を構成する座標値を 1 つの要素の値として列挙する方法である。
<gml:posList>-178333.3 -40388.62 0.0 -17832.25 -40389.91 0.0</gml:posList>(4) 面（gml::_Surface, gml::Polygon）

gml::_Surface は面を記述するために使用される幾何オブジェクトである。gml::_Surface は抽象クラス

であり、インスタンスはこれを継承する具象クラスを用いて作成する。gml::_Surface を継承する具象ク
ラスは複数あるが、都市計画データでは、gml::Polygon のみを使用する。gml::Polygon は、多角形である。

gml::Polygon は 1 個の外周（exterior）を必ずもち、また、0 個以上複数個の内周（interior）をもってもよい。内周がある場合は、外周と内周とは同じ平面上に存在しなければなければならない。つまり、

gml::Polygon を構成する全ての点は同じ平面上に存在しなければならない。ただし、都市計画データの場合は、2 次元（高さを示す座標値が 0）のデータとなるため、全ての点は高さ=0 の平面上に存在するため、内周は必ず外周と同じ平面上に存在する。gml::Polygon の外周及び内周は gml::LinearRing（輪）を使って記述する。

また、gml::Polygon の外周の頂点の順列が gml::Polygon の向き（法線）を決める。都市計画データの場合、gml::Polygon の向きは全て「正」となる。また、向きが「正」となる gml:Polygon は、頂点の順列が面の内部を左側に見る順序でなければならない。よって、外周は、常に左回り（反時計回り）となり、内周が存在する場合は、内周の頂点の順列は、右回り（時計まわり）となる（図 3-17）。
P2

P2
Q1

P1
P3

Q3

P3
P0

Q2

P1

Q0
P0

外周=（P0 ,P1 ,P2 ,P3 ,P０）

外周=（P0 ,P1 ,P2 ,P3 ,P０）
内周＝（ Q０,Q3,Q2,Q1 ,Q０ ）図 3-17 gml::Polygon の向きと外周及び内周の頂点の順列
妥当な gml::Polygon は、以下を満たさなければならない。

解281) 内周が、外周に完全に含まれている。
2) 内周が他の内周と重なっておらず、他の内周に包含されてもいない。
3) 内周が外周に接していてもよいが、gml::Polygon の内部を分断しない。
4) 内周と外周が線分で重ならない。
5) 外周及び内周に自己交差がなく、始終点以外の点で一致する点がない。

gml::Polygon は、1 個の外周をもたなければならず、また、0 個以上の内周をもつことができる。

一つの gml::Polygon の内周は必ず外周に含まれていなければならない（図 3-18①）。内周が外周に含まれていない gml::Polygon（図 3-18 ②）は誤りである。

gml::Polygon の内周が外周に接していてもよい（図 3-17 ③）が外周の 2 ヵ所以上に接し、gml::Polygonの内部を分断してしまう（図 3-18 ④）場合は、誤りである。

一つの gml::Polygon に二つ以上の内周が存在していてもよい（図 3-18 ⑤）が、一つの内周が、他の内周と重なっていたり、包含されていたりしてはならない（図 3-18 ⑥）。
内周及び外周は、自己交差してはならない（図 3-18 ⑦）。また、始終点以外で一致する頂点が存在してはならない（図 3-18 ⑧）。内空が存在するドーナツ状の幾何オブジェクトを作成したい場合は内周により内空を表現する（図 3-18①）ことが正しく、一筆書きで内空を表現する（図 3-18 ⑧）ことは誤り
である。

外周

①

正

②

外周

誤

外周

③

正

内周

内周がポリ ゴ ン を 分断

内周が外周に含ま れていない

外周

誤

内周

内周

内周

④

外周

⑤

正

外周

⑥

⑦

誤

⑧

誤

誤

内周
内周

内周

内周
自己交差

他の内周に包含

図 3-18

始終点以外で一致

正しい gml::Polygon と誤った gml::Polygon の例

図 3-18④⑥⑦⑧のような事例は、1 つの gml::Polygon として記述するとエラーとなる。一方で、このような幾何形状を表現したい場合には、それぞれを gml::Polygon に分割し、これらの集まりである

gml::MultiSurface を使用することで 1 つの幾何オブジェクトとして扱うことができる。
解29

(5) 輪（gml::_Ring, gml::LinearRing）

gml::_Ring は輪を記述するために使用される幾何オブジェクトである。gml::_Ring は抽象クラスであり、インスタンスはこれを継承する具象クラスを用いて作成する。gml::_Ring を継承する具象クラスは複数あるが、都市計画データでは、gml::LinearRing のみを使用する。gml::LinearRing は、平面の輪である。gml::LinearRing は、gml::Polygon の外周及び内周を記述するために使用する。

gml::LinearRing は、以下の事項を守らなければならない。

1) 4 点以上の順列から構成され、始点と終点が一致する。
2) gml::LinearRing を構成する全ての点は、始点と終点を除き、一致しない。
3) 自己交差しない。

gml::LinearRing は、閉じた「輪」、すなわち、始終点が一致していなければならず、また、自己交差や始終点以外での一致は許さない（図 3-19）。

P0

P1

P0

P1

P0

P1
P4

P3

P2

R1=（P0 ,P1 ,P2 ,P3）
閉じてない

P2

P3

R2=（P0 ,P1 ,P2 ,P3 ,P0）
自己交差
図 3-19P2P3

R3=（P0 ,P4 ,P2 ,P3 ,P4 ,P1 ,P0）
始終点以外の点重複

エラーとなる gml::LinearRing の例

gml::LinearRing の座標列の記述には、<gml:posList>を使用する。UML クラス図では、gml::LinearRingの属性 position の多重度が 4 以上（[4..*]）となっている。これは、面を構成するには始点と終点以外に2 点以上の中間点が必要であることを意味する。よって、<gml:posList>にも 4 点以上の座標列が記述され、始点と終点の座標値は必ず一致する。4 点で記述される場合は、三角形となる。
<gml:posList>0.0 0.0 0.0 -1.0 0.0 0.0 -1.0 -1.0 0.0 0.0 -1.0 0.0 0.0 0.0 0.0</gml:posList>(6) 集まりとなる幾何オブジェクト
幾何オブジェクトには、基本的な幾何オブジェクトの集まりとして記述されるものがある（図 3-20）。

gml::_AbstractGeometricAggregate は、幾何オブジェクトの集まりであり、これを継承するクラスは、

集める幾何オブジェクトの種類が異なる。点（gml::Point）の集まりは gml::MultiPoint、線の集まりは

gml::MultiCurve、面の集まりは gml::MultiSurface である。集まりに含まれる幾何オブジェクト同士が、重なっていたり、離れていたりしてもよい。
解30

gml::GeometricComplex も基本的な幾何オブジェクトの集まりである。この時、個々の幾何オブジェ
クト同士は離れていてもよいが、重なったり、交差したりしてはならない。
なお、基本的な幾何オブジェクト（点、線、面）は、集まりとなる幾何オブジェクトの構成要素になってもよいし、ならなくてもよい。また、同じの基本的な幾何オブジェクトが、複数の幾何オブジェクトの集まりの構成要素となってもよい。

«Type»
gml::_Geometry«Type»
gml::_GeometricPrimitive«Type»
gml::GeometricComplex+element«Type»
gml::_AbstractGeometricAggregate1..*

基本的な要素の集まり«Type»
gml::Point++pointMember

position: gml::DirectPosition 0..*«Type»
gml::_Curve

点の集まり«Type»
gml::MultiPoint

線の集まり«Type»
gml::MultiCurve+curveMember
0..*

面の集まり
«Type»
gml::_Surface«Type»
gml::MultiSurface+surfaceMember0..*

図 3-20

空間スキーマプロファイル（２）(7) 点の集まり（gml::MultiPoint）

点の集まり は、 gml::MultiPoint を用いて記述 する。関連 役割 pointMember により構成す る点（gml::Point）を直接記述又は参照する。gml::MultiPoint には、1 つ以上の点が含まれていなくてはならない。

直接記述とは、gml::Point のインスタンスを記述することである。一方、参照とは、gml::Point のイン

スタンスの識別子を参照することである。この場合、別の場所に、その識別子が付与された gml::Point のインスタンスが存在していなければならない。以下に示す記述例は、2 点からなる gml::MultiPoint のイ
ンスタンスである。1 点目は直接記述されており、2 点目は参照されている。この時、“gml:id=pos01”となるような gml::Point が、存在しなければならない。

記述例：
解

31

<gml:MultiPoint><gml:pointMember><gml:Point><gml:pos>-17833.33 -40388.62 0.0</gml:pos></gml:Point></gml:pointMember><gml:pointMember xlink:idref=”#pos01”/></gml:MultiPoint>(8) 線の集まり（gml::MultiCurve）

線の集まりは、 gml::MultiCurve を用いて記述する。関連役割 curveMember により構成する線（gml::_Curve）を直接記述又は参照する。gml:MultiCurve には、1 つ以上の gml::_Curve が含まれていなくてはならない。CityGML では、線として gml::LineString のみが使用可能であるため、gml::MultiCurveは gml::LineString（折れ線）の集まりとなる。構成要素となる gml::LineString は、重なっていたり、離れていたりしてもよい。また、構成要素となる線の向きに制約はない。
(9) 面の集まり（gml::MultiSurface）

面の集まりは、 gml::MultiSurface を用いて記述する。関連役割 surfaceMember により構成する面（gml::_Surface）を直接記述又は参照する。gml:MultiSurface には、1 つ以上の gml::_Surface が含まれて い な く て は な ら な い 。 CityGML で は 、 面 と し て gml::Polygon の み が 使 用 可 能 で あ る た め 、

gml::MultiSurface は gml::Polygon（多角形）の集まりとなる。構成要素となる gml::Polygon は、重なっていたり、離れていたりしてもよい。また、構成要素となる曲面の向きに制約はない。
(10) ネットワーク（gml::GeometricComplex）

gml::GeometricComplex は基本的な幾何オブジェクトの集まりである。このとき、構成要素同士の交差が許されない。

CityGML では、線形ネットワークを記述する場合に、gml::GeometricComplex を使用する。この時、

gml::GeometricComplex は gml::LineString の集まりとなる。

gml::GeometricComplex の構成要素となる線は、互いに離れていてもよいが、交わってはならない。すな わ ち 、 道 路 の 中 心 線 を gml::GeometricComplex で 表 現 す る 場 合 、 道 路 同 士 の 交 差 点 で は 必 ず

gml::LineString を区切り、gml::LineString 同士の端点が同じ座標を共有しなければならない。この交わってはならない点が、gml::MultiCurve とは異なる。

3.2. 参照系
参照系とは、空間及び時間の位置を定める基準である。

3.2.1. 空間参照系
都市計画データの水平方向の空間参照系は、平成 14 年国土交通省告示第 9 号で定義される平面直角座標系とする。平面直角座標系とは、座標値が次の条件に従ってガウス・クリューゲルの等角投影法によっ
解32

て表示されるように、全国を 19 の座標系に区分する座標参照系である（表 3-7）。


座標系の X 軸は、座標系原点において子午線に一致する軸とし、真北に向かう値を正とする。



座標系の Y 軸は、座標系原点において座標系の X 軸に直交する軸とし、真東に向かう値を正とする。



座標系の X 軸上における縮尺係数は、0.9999 とする。



座標系原点の座標値は、次のとおりとする。


X=0.000 メートル Y＝0.000 メートル
表 3-7 平面直角座標系

系
I

座標系原点の経緯度
東経

北緯129°30ʼ0”33°0ʼ0”

適用区域

EPSG コード

長崎県 鹿児島県のうち北方北緯 32 度南方北緯 27 度西方

6669

東経 128 度 18 分東方東経 130 度を境界線とする区域内（奄美群島は東経 130 度 13 分までを含む。)にあるすべての島、小島、環礁及び岩礁
II131°0ʼ0”33°0ʼ0”

福岡県

佐賀県

熊本県

大分県

宮崎県

鹿児島県（I

6670

系に規定する区域を除く。)
III

132°10ʼ0”36°0ʼ0”山口県 島根県

広島県

6671

IV

133°30ʼ0”33°0ʼ0”香川県 愛媛県

徳島県 高知県

6672

V134°20ʼ0”36°0ʼ0”

兵庫県 鳥取県

岡山県

6673

VI

136°0ʼ0”36°0ʼ0”

京都府

福井県

大阪府

滋賀県

三重県

奈良県 和歌

6674

山県
VII

137°10ʼ0”36°0ʼ0”石川県 富山県

岐阜県 愛知県

6675

VIII

138°30ʼ0”36°0ʼ0”新潟県 長野県

山梨県 静岡県

6676

IX

139°50ʼ0”36°0ʼ0”

東京都（XIV 系、XVIII 系及び XIX 系に規定する区域を除く。) 福島県6677

栃木県 茨城県 埼玉県 千葉県 群馬県

神奈川県
X

140°50ʼ0”40°0ʼ0”青森県 秋田県山形県 岩手県 宮城県

6678

XI

140°15ʼ0”44°0ʼ0”

小樽市

伊達市

6679

函館市

局の所管区域北斗市

北海道後志総合振興北海道胆振総合振興局の所管区域のうち

豊浦町、壮瞥町及び洞爺湖町 北海道渡島総合振興局の所
管区域 北海道檜山振興局の所管区域
XII

142°15ʼ0”44°0ʼ0”

北海道（XI 系及び XIII 系に規定する区域を除く。）

6680

XIII

144°15ʼ0”44°0ʼ0”

北見市

6681

帯広市

釧路市

網走市

根室市

北海道オホ

ーツク総合振興局の所管区域のうち美幌町、津別町、斜里町、清里町、小清水町、訓子府町、置戸町、佐呂間町及び大空町

北海道十勝総合振興局の所管区域

北海道釧路総合振興局の所管区域 北海道根室振興局の所管区域
XIV

142°0ʼ0”26°0ʼ0”

東京都のうち北緯 28 度から南であり、かつ東経 140 度 30

解

33

6682

分から東であり東経 143 度から西である区域
XV

127°30ʼ0”26°0ʼ0”沖縄県のうち東経 126 度から東であり、かつ東経 130 度

6683

から西である区域
XVI

124°0ʼ0”26°0ʼ0”沖縄県のうち東経 126 度から西である区域

6684

XVII

131°0ʼ0”26°0ʼ0”沖縄県のうち東経 130 度から東である区域

6685

XVIII

136°0ʼ0”20°0ʼ0”

東京都のうち北緯 28 度から南であり、かつ東経 140 度 30

6686

分から西である区域
XIX

154°0ʼ0”26°0ʼ0”

東京都のうち北緯 28 度から南であり、かつ東経 143 度か

6687

ら東である区域

ガウス・クリューゲルの等角投影法により、座標原点を通る子午線は等長に、図形は等角の相似形に投影される。しかし、原点から東西に離れるに従って平面距離が増大する。そこで、平面直角座標系では、投影距離の誤差を相対的に 1/10000 以内に収めるよう座標原点を通る子午線上の縮尺係数を 0.9999 に設定し、かつ、座標原点から東西約 130km 以内を適用範囲としている（図 3-21）。平面直角座標系を用
いて、地物を平面上に投影し、位置・方向・距離等を計算することは、曲面上の処理に比べ非常に簡単になり便利である。また、都市計画基本図のように、測量範囲が狭い場合には、十分正確に表すことが可能
である。
北（ X）

約130km

約130km
約90km

約90km

西
1.00011.00000.99991.00001.0001

東（ Y）
縮尺係数

南

図 3-21

平面直角座標系の軸の方向と縮尺係数

なお、都市計画データは、高さをもたない 2 次元のデータである。ただし、等高線のように、属性として高さをもたせる場合がある。この場合には、測量法施行令（昭和２４年政令第 322 号）第２条第２項に規定する日本水準原点を基準とする高さ（以下「標高」という。）を採用する。

3.2.2. 時間参照系
都市計画データの時間参照系は、「グレゴリオ暦及び日本標準時」とする。標準製品仕様書において、
日付型（xs:date）や年型（xs:gYear）で指定された属性の値は、グレゴリオ暦（西暦）で記述する。

3.2.3. 地理空間データにおける参照系の指定
解34

都市計画データに適用する参照系のうち、時間参照系は「グレゴリオ暦及び日本標準時」により一律固定されているため、地理空間データに含まれる座標に適用する参照系は、空間参照系のみを指定する。
空間参照系の指定は、データ集合の範囲を示す gml::Envelope の srsName 属性に記述する。

データ集合に記述する空間参照系は、これの定義を取得可能な URI により指定する。URI は OGC による座標参照系の定義を使用することを原則とし、以下のように記載する。
http://www.opengis.net/def/crs/EPSG/0/[epsg]
ここで、[epsg]は、空間参照系ごとに割り当てられた識別子（EPSG コード）であり、表 3-7 に示す 4桁の半角数字が該当する。例えば、平面直角座標系第 9 系の場合は、以下となる。
URI の例：http://www.opengis.net/def/crs/EPSG/0/6677
記述例：<gml:boundedBy><gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/6677" srsDimension="3"><gml:lowerCorner>-38089.22 -16905.43 0.0</gml:lowerCorner><gml:upperCorner>-33148.56 -10185.34 0.0</gml:upperCorner></gml:Envelope></gml:boundedBy>

gml:Envelope の属性 srsName に空間参照系の URI を記述する。属性 srsDimension には次元数を入れる。gml:lowerCorner には、X 座標、Y 座標及び標高の最小値を記載し、gml:upperCorner には最大値を記載する。ただし、標高は最大値、最小値ともに 0.0 となる。

解35

3.3. 品質要求及び評価手順
3.3.1. 標準製品仕様書の品質要求
地理空間データの品質とは、製品仕様（地理空間データへの要求事項）と、作成された地理空間データとの差異である。地理情報標準では、地理空間データの定量的な品質として、表 3-8 に示す 5 つの区分を行い、15 の品質要素を定義している。
表 3-8 定量的な品質の区分
品質の区分

内容

品質要素

完全性

地理空間データに含まれるべき地物、地物

過剰、漏れ

属性、地物関連のインスタンスの過不足。
論理一貫性

データの論理的な規則に対する適合度。

書式一貫性、論理一貫性、定義域一貫性、
位相一貫性

位置正確度

地物の位置の正確さ。

絶対位置正確度、相対位置正確度、グリッ
ド位置正確度

主題正確度

地物の分類や定量・非定量的属性の正確さ。 分類の正しさ、非定量的属性の正しさ、定量的属性の正確度

時間品質

地物の時間属性の正確さ。

時間測定正確度、時間一貫性、時間妥当性

標準製品仕様書では、都市計画基本図モデル、都市計画基礎調査情報モデル、都市計画決定情報モデルのそれぞれの特徴を踏まえ、それぞれに品質要求を設定している。
なお、標準製品仕様書では、位置正確度は、絶対位置正確度のみを使用し、相対位置正確度及びグリッ
ド位置正確度は使用していない。また、時間に係る属性への品質要求は、時間品質ではなく、主題正確度を用いている。これは、CityGML 及び i-UR が時間品質の対象である時間スキーマを採用していないためである。
品質要求では、表 3-8 に示す品質要素に対して、その品質要素を適用する範囲（データ品質適用範囲）、評価に使う尺度（データ品質評価尺度）、合否の判定基準（適合品質水準）を指定する。
データ品質適用範囲は、データ集合全体を指定してもよいし、特定の地物型や地物属性・地物関連を指定してもよい。また、いくつかの地物型のようにグループでもよい。通常は、同じ品質要求を適用する対象をまとめて指定する。データ品質評価尺度は、測定できる（数値で表される）品質の意味である。エラ
ーの数や割合、あるいは誤差の量などが該当する。良否の判定が必要な場合は、誤りの基準を記述する。
適合品質水準は品質評価尺度に基づき計測された値の合否の判定基準である。例えば、エラーの数の場
合は、エラーが 0 個の場合には合格、1 個以上の場合は不合格というように、合否を分けるエラーの数を記述する。
(1) 都市計画基本図の品質
都市計画基本図への品質要求は、「地図情報レベル 2500 数値地形図データ作成のための標準製品仕様
解36

書（案）」に準じている。
完全性については、地物の重要度に応じたエラーの数又は割合を許容している。
論理一貫性については、エラーを許容しない。
位置正確度は、作業規程の準則に示された「地図情報レベル 2500」における標準偏差（水平位置の標
準偏差 1.75m 以内、標高点の標準偏差 0.66m 以内、等高線の標準偏差 1.0m 以内）を適合品質水準として採用している。
主題正確度は、地物の重要度に応じたエラーの数又は割合を許容している。
(2) 都市計画基礎調査情報の品質
都市計画基礎調査情報への品質要求は、「都市計画 GIS データの共通仕様（案）」を参考に設定している。都市計画基礎調査情報には、地方公共団体自らが調査をするデータ項目だけではなく、他機関で整備されている GIS データ等を収集・加工し作成するデータが存在する。
前者の場合は、「地図情報レベル 2500 数値地形図データ作成のための標準製品仕様書（案）」に準じた品質要求とし、後者については参照データとなる原典資料との一致を品質要求として設定している。
(3) 都市計画決定情報の品質
都市計画決定情報への品質要求は、「都市計画 GIS データの共通仕様（案）」を参考に設定している。
都市計画決定情報は、都市計画図書をベースに作成されるデータであり、都市計画図書との差異は許容されない。そこで、完全性や主題正確度は、参照データ（都市計画図書）との一致を品質要求として設定している。
なお、位置正確度は、参照データの取り扱いにより、以下の 2 つの品質要求を設定している。位置正確
度の品質要求においては、いずれかを選択できる。


紙で印刷された計画図上の区域の境界線をデジタイズする場合は、デジタイズによる誤差が許容値内であることを品質要求とする。


このときの許容誤差は、図上 0.3 ㎜とする。これは、公共測量において既成図数値化を行う場
合の許容誤差に一致する。



都市計画基本図の地物（道路縁、道路縁から生成した道路中心線、行政界等）を使用して区域の境界線を作成している場合は、使用している地物（道路縁、行政界等）との相対的な距離が 0、すな
わち、一致していることを品質要求とする。

3.3.2. 標準製品仕様書の品質評価手順
品質評価手順は、品質情報を求める過程の記述である。地理情報標準では、品質評価手順は製品仕様書の必須の記載項目ではなく、品質要求に応じてデータ作成者が品質評価手順を設定できるとされている。
一方で、様々な事業者がデータ作成に関わる可能性がある場合、事業者ごとに品質評価手順を検討する
ことも、発注者が事業者ごとに品質評価手順の妥当性を評価することも作業の重複となる。そこで、標準
製品仕様書では、品質評価手順も定めている。
品質評価手順は、具体的な品質評価手法とその手順を示す。標準製品仕様書で示す品質評価手法は、
解37

「地図情報レベル 2500 数値地形図データ作成のための標準製品仕様書（案）」に準じている。標準製品
仕様書では、品質評価手法として「全数・自動検査」と「全数・目視検査」、「抜取・目視検査」「抜取検
査（目視又は自動を規定しない）」を設定している。また、抜取検査については、抜取方法を設定している。特に、都市計画基礎調査データと都市計画決定データについては、参照データとなる原典資料がデジ
タルデータであるか否か等の形態により採用可能な検査手法が異なることから、「抜取検査」を採用している。

3.3.3. 部分更新を行う場合の品質評価
都市計画データのデータ集合は、「都市計画基本図」「都市計画基礎調査情報」「都市計画決定情報」の3 つから構成し、これら 3 つのデータを一体的に整備・管理・利用していくことを目指している。一方
で、都市計画データの整備又は更新では、全てのデータを同時に整備・更新することよりも、例えば、都市計画基本図の一部の図郭を更新する、都市計画基礎調査をエリアやデータ項目を分けて複数年にかけて実施する等、一部の地物や一部のエリアを対象とすることが多い。
このような部分的に整備・更新する場合の品質評価は、基本的には、更新又は追加した地物等のみが対象となる。ただし、完全性のうち、以下についてはデータ集合全体を品質評価する必要がある。


gml:id の一意性（更新していないファイル、更新後のファイルを含めデータ集合全体での一意性の確認）



データの漏れ・過剰（更新をしていないファイルの統合漏れや重複が無いかの確認。この場合、比較対象とする参照データは、更新前のデータ集合となる。
）

なお、一部の図郭を対象とした整備・更新を行う場合、当該図郭だけではなく、隣接する図郭についても品質評価の対象とし、図郭境界線上の地物の漏れや過剰が無いことを確認する必要がある。

3.4. データ製品配布
データ製品配布では、都市計画データのフォーマットや、成果品のフォルダ構成や命名規則を定めている。

3.4.1. CityGML による符号化
都市計画基本図、調書及び集計表を除く都市計画基礎調査情報、都市計画決定情報の符号化仕様として、標準製品仕様書では CityGML を採用している。
CityGML では、使用可能なタグやタグの出現順序及び出現回数が、XMLSchema で指定されている。
GIS や CAD の内部形式で作成されたデータを CityGML 形式に変換する際には、XMLSchema に従わなければならない。以下では、CityGML 形式への変換時に留意すべき事項を解説する。XMLSchema の構
造は、付属資料 2 に解説する。

解38

(1) 接頭辞
CityGML 及び i-UR には、複数の XMLSchema が存在し、標準製品仕様書ではこれらを引用している。
どの XMLSchema から引用している要素であるのかを明確にするため、全ての要素には接頭辞を付与しなければならない。
(2) schemaLocation の指定

CityGML 形式に出力したファイルの schemaLocation の指定は、i-UR の符号化仕様（urbanObject.xsd

及び urbanFunction.xsd）は、成果物に含める符号化仕様のファイルへの相対パスとすること。
地物型又はモジュールごとに分けられた成果物を格納するフォルダ（例：bldg, tran）の直下に CityGML
データを格納した場合、schemaLocation として記述すべき符号化仕様への相対パスは以下となる。
urbanObject.xsd への相対パス：../../schemas/iur/uro/3.0/urbanObject.xsd
urbanFunction.xsd への相対パス：../../schemas/iur/urf/3.0/urbanFunction.xsd
statostocalGrid.xsd への相対パス：：../../schemas/iur/urg/3.0/statisticalGrid.xsd(3) gml:id

標準製品仕様書では、データ集合内で都市オブジェクトを識別するための ID である gml:id の付与ルールを定めている。データ集合内に含まれる全ての都市オブジェクトには、標準製品仕様書の付与ルールに従い、gml:id を付与する必要がある。

gml:id はデータ集合内で重複があってはならない。また、gml:id の開始文字は数字であってはならない。
(4) タグの出現順序
CityGML データに出現するタグは、あらかじめ XMLSchema によりその順序が決まっている。具体的には以下の順序で出現する。これらの順序を守らない場合、論理一貫性に不適合となる。
1. gml:*2. core:*3. gen:*4. bldg:*、tran:*等 CityGML クラスで定義された属性・関連役割
5. uro:*、urf:*、urg:*の i-UR で定義された属性・関連役割
なお、データを作成しない属性は、空タグ（値を入れないタグ）を作成しない。
(5) 単位付き計測値型（gml:MeasureType）

単位付き計測値型の属性には、かならず uom 属性により、単位を指定しなければならない。

標準製品仕様書では原則として、長さの単位は“メートル”、面積の単位は“平方メートル” 又は“ヘクタール”、時間の単位は“時間”を採用している。この場合、uom 属性にはそれぞれ"m"、"m2"、"ha"、"hour"を記述する。これら以外の単位については、それぞれの応用スキーマ文書の属性の定義に従うこと。

解39

(6) コード型（gml:CodeType）
コード型の属性には、あらかじめ用意されたコードリストに列記されたコードから一つを選択し、値として記述する。この時、用意されたコードリストの所在を codeSpace 属性に記述する。コードリストは、成果物フォルダに格納するため、codeSpace 属性は CityGML ファイルからコードリストファイルへの相対パスにより記述する。

なお、codeSpace 属性によりコードリストが指定されていない場合、値は文字列として扱われる。

(7) 部分更新した場合の漏れや重複
都市計画データ等の一部を更新する場合は、成果物は更新した都市計画データと更新していない都市
計画データとを統合し、一式とする必要がある。そのため、統合した際にデータの漏れや重複が無いことを確認する必要がある。

3.4.2. CSV による符号化
都市計画基礎調査データの調書及び集計表の符号化仕様として、標準製品仕様書では CSV を採用している。以下では、GIS や表計算ツールで作成されたデータを CSV 形式に変換する際に留意すべき事項を解説する。
なお、標準製品仕様書の Annex B には、CSV 形式で出力した場合のサンプルデータを示す。ヘッダー
やレコードの記述はこれを参考にするとよい。
(1) ヘッダーの作成
CSV には必ずヘッダーを設ける。ヘッダーは 3 行で構成する。1 行目には都道府県コード、市区町村
コード、データ項目、表名称及び基準日を記述する。2 行目は、出力する応用スキーマの UML クラス図の各属性の日本語名を記述する。3 行目には UML クラス図の各属性名を記述する。
また、標準製品仕様書に定義する属性は、UML クラス図に記載された順序で記述し、拡張製品仕様書で追加する属性は、標準製品仕様書で定義された属性の後とする。
(2) 区切り文字
属性値と属性値との区切り文字には、“,”（カンマ）を使用する。使用しない属性もしくは出力しない属性がある場合には、区切り文字の連続により省略する。
なお、属性値の中で区切り文字を使用したい場合は、“;”（セミコロン）を使用する。
(3) 属性値の記述方法
属性値の表記は、標準製品仕様書に示す属性の型に従うこと。
なお、属性値が文字列（xs::string）の場合は、ダブルクォーテーションで囲む。メッシュコードのように開始文字が“0”となる場合は、この 0 も値に含めなければならない。
属性値の順序は、ヘッダーの 2 行目に出力する属性名の順序に従う。

解40

3.4.3. 成果品の構成
成果品には、都市計画データだけではなく、拡張製品仕様書やメタデータなどが含まれる（表 3-9）。
表 3-9 成果品
成果品

数量

都市計画データ 成果品

単位

備考

都市計画データ

1

式

CityGML 形式と CSV 形式が存在する。

メタデータ

1

式

JMP2.0 に基づく XML 形式のメタデータと、CSV 形式の原典資料リストが存在する。

XMLSchema

1

式

i-UR 3.0 の XMLSchema ファイル。都市計画データは相対パスによりこの XMLSchema を参照する。

拡張製品仕様1

式

各都市で作成された拡張製品仕様書。

コードリスト1式

データ製品より参照されるコードリスト。

(1) ファイル単位
CityGML 形式の都市計画データのファイル単位を表 3-10 に示す。
表 3-10
都市計画データ

ファイル単位地物の種類

ファイル単位都市計画基本図情報

i-UR 及び CityGML に定義されたモジュール

都市計画基礎調査情報

都市計画基礎調査のデータ項目

都市計画決定情報

空間範囲

地図情報レベル 2500 の都市計画の種類
国土基本図の図郭単位（都市計画区域及び準都市計画区域、区域区分、地域地
区、促進区域、遊休土地転換利用促進地区、被災市街地復興推進地域、都市施設、市街地開発事業、市街地開発事業
等の予定区域、地区計画等）

ただし、図郭の境界線で地物を分割することは行わず、図郭に跨って存在する地物は、それぞれの図郭に含まれる面積の割合を算出し、この割合が最も大きい図郭のファイルに含む。面積は、小数点 2 桁（3桁目で四捨五入、単位は m2）で比較する。面積が同じ場合は図郭番号の小さい方（北側を優先する。次に西側を優先する）とする。
CSV 形式の都市計画データ（調書及び集計表）のファイル単位は、調書又は集計表とする。
(2) ファイルサイズ
ファイルサイズの上限は、50MB とする。
ファイルサイズが 50MB を越える場合は、ファイルを分割する。
CityGML 形式ファイルの場合は、地図情報レベル 1000 の国土基本図の図郭に分割する（図 3-22）。
この時、図郭番号の上 6 桁が等しい周辺図郭（地図情報レベル 5000 の図郭に該当）も同様に地図情報レ
解41

ベル 1000 の図郭に分割する必要がある。

３４
図 3-22CityGML 形式ファイルの分割

CSV 形式ファイルを分割する場合は、ヘッダーを含むファイルは 1 つのみとし、残りのファイルには
ヘッダーは含まず、レコードのみを含める。
(3) ファイル名称
CityGML 形式ファイル及び CSV 形式ファイルのファイル名称は、標準製品仕様書 7.2.3 に示す。これ
らのファイル以外の成果品のファイル名を以下に示す。
表 3-11

成果品

コードリスト

ファイル名称

ファイル名称
命名規則
標準製品仕様書に定義されたコードリストの名称は変更しない。
標準製品仕様書の対象としていないコード型の属性を追加した場合は、以下とす
る。

拡張子

.xml

[クラス名]_[属性名]
JMP 形式のメタデータの名称は以下とする。
udx2d_[市区町村コード]_[整備年度]_[オプション]
CSV 形式のメタデータの名称は、以下とする。
udx2d_[市区町村コード]_[整備年度]_sorceList-[オプション]
メタデータ

XMLSchema

JMP2.0
形式.xml[市区町村コード]は、2 桁の都道府県コードと 3 桁の市区町村コードからなる 5 桁のCSV 形式
コードとする。
.csv[整備年度]は作成した西暦年度（4 桁）を記述する。
[市区町村コード]及び[整備年度]は、いずれも半角数字とする。
[オプション]は、成果品が複数種類作成される場合に、これらを識別するために使用する任意の文字列とする。半角英数字のみを使用可とする。成果品を格納するルー
トフォルダに使用する[オプション]の文字列に一致させること。成果品が 1 種類の場合は省略する。
成 果 品 に 格 納 す る XMLSchema フ ァ イ ル の 名 称 は 変 更 せ ず 、 i-UR 3.0 のXMLSchema をダウンロードし、格納する。
.xsd

解

42

urbanObject
urbanFunction
statisticalGrid
拡張製品仕様書のファイル名称は、以下とする。
[市区町村コード]_[整備年度]_specification2d

拡張製品仕様書

また、拡張製品仕様書に付する表を含む様式（Annex A）のファイル名称は以下と 拡 張 製
品 仕 様
する。
書
.pdf
[市区町村コード]_[整備年度]_objectlist2d[市区町村コード]は、2 桁の都道府県コードと 3 桁の市区町村コードからなる 5 桁のコードとする。
[整備年度]は作成した西暦年度（4 桁）を記述する。
[市区町村コード]及び[整備年度]は、いずれも半角数字とする。

様式
.xlsx

(4) フォルダ構成とフォルダ名称
成果品のフォルダ構成及びフォルダの名称は、標準製品仕様書 7.2.4 に示す。
成果品のフォルダ（サブフォルダを含む）の名称には半角英数字及び半角記号（アンダースコア及びハイフン）のみを使用すること。
フォルダ構成は、3D 都市モデルと同一（ただし、CSV を格納するフォルダなどを追加）である。
(5) データの圧縮
都市計画データの成果品フォルダは、各々を ZIP 形式（拡張子 zip）に圧縮する。
ファイルの圧縮は、成果品フォルダのルートフォルダを圧縮することとし、その内部のいかなるサブフ
ォルダにも圧縮形式のファイルを含んではならない。
圧縮後のファイル名称は、以下とする。
[市区町村コード]_[市区町村名英名]_[整備年度]_citygml2d_[更新回数]_[オプション]
ルートフォルダの名称は、3D 都市モデルと同一であるが、圧縮後のファイル名は citygml2d の文字列のみが異なることに注意すること。
[市区町村コード]は、都市計画データを作成する範囲となる都道府県コード（2 桁）と市区町村コード（3 桁）の組み合わせからなる 5 桁の数字とする。
[市区町村名英名]は、デジタル庁が定める「行政基本情報データ連携モデル_住所」に従う。すなわち、市区町村名称を国土地理院が定める「地名等の英語表記規程」（平成 28 年国地達第 10 号）に準拠しつ
つ、市区町村の種別は city や ward ではなく-shi や-ku で表す。
[整備年度]は、都市計画データを整備した年度（半角数字 4 桁の西暦）とする。
[更新回数]は、履歴管理用に半角数字を付す。初回に作成した成果物は 1 とする。以降、修正等を行った場合はバージョンアップごとに数字を加算していく。
[更新回数]は[整備年度]ごとに加算する。[整備年度]が変わった場合は、1 から開始する。
[オプション]は、成果品が複数種類作成される場合に、これらを識別する任意の文字列とする。半角英解43数字のみ使用可とする。成果品が 1 種類の場合は、_[オプション]は省略する。
なお、圧縮後の成果品フォルダのファイルサイズは、上限を 2GB とする。
2GB を超える場合は分割する。分割は、成果品と同じフォルダ構成を複数作成し、成果品のファイルを作成したフォルダに振り分けることにより行う。この時、それぞれの成果品フォルダ内に、同じファイルが重複して存在してはならない。
ファイルを振り分けたのち、成果品のフォルダごとに圧縮する。
圧縮後のファイル名称は、 [市区町村コード] _[市区町村名英名]_[整備年度]_citygml2d_[更新回数]_[オプション]_[分割番号]とする。

3.5. メタデータ
3.5.1. JMP2.0 に基づくメタデータ
都市計画データ全体として 1 つのメタデータを作成することを基本とする。ただし、以下の場合には統合したメタデータとは別に、メタデータファイルを分けて作成する。
都市計画データの一部を整備・更新する場合•



整備・更新したデータについてのメタデータを作成する。

データ作成事業者が異なる場合•



事業者ごとに作成したデータについてのメタデータを作成する。

メタデータの作成には、国土地理院が提供するメタデータエディタを使用できる。

メタデータエディタの詳細：メタデータの作成について[4]3.5.2. 原典資料一覧
原典資料一覧は、都市計画基本図と都市計画基礎調査情報について、それぞれ標準製品仕様書に基づき
CSV 形式で作成する。
都市計画基本図と都市計画基礎調査情報は、国土基本図郭ごとに記述することを基本とするが、地方公共団体全域で同じ原典資料が使用されている場合には、まとめて記載してもよい。例えば、都市計画基本図について、一部の図郭で新たに撮影した航空写真を用いて更新された場合など、複数の原典資料が使用される場合には、図郭ごとに記載する。
原典資料一覧の CSV ファイルを作成する場合は、標準製品仕様書 Annex C のテンプレートに従うこ
と。

解

44

4. 都市計画データ拡張製品仕様書の作成
4.1. 概要
拡張製品仕様書は、標準製品仕様書に基づき作成された、各地方公共団体の都市計画データ製品仕様書である。拡張製品仕様書は、地方公共団体ごとに作成する必要がある。また、拡張製品仕様書では、標準
製品仕様書に定義された地物や属性を、必要に応じて取捨選択又は追加してもよい。
本章では、拡張製品仕様書を作成する手順を示す。

4.2. 応用スキーマの作成
本項では、標準製品仕様書の応用スキーマを拡張し、作成対象とする地物や属性を限定、又は不足する
地物や属性を追加したりする方法を示す。
標準製品仕様書の拡張が必要な場面を表 4-1 に示す。
表 4-1 標準製品仕様書の拡張が必要となる場面
都市計画データ

拡張が必要となる主な場面

都市計画基本図•

DM 分類コードの追加•

図形タイプの変更•

独自属性の追加•

実施しない調査の設定•

地方公共団体独自の属性追加又は作成しない属性の設定•

地方公共団体独自の調査の追加•

当該地方公共団体に存在する都市計画の区域の抽出•

標準製品仕様書にはない都市計画の区域の追加•

地方公共団体独自の属性の追加又は作成しない属性の設定

都市計画基礎調査情報

都市計画決定情報

4.2.1. 基本的なルール
拡張製品仕様書の範囲（＝都市計画データとして作成対象とする地物及び属性・関連役割）を明確にするため、拡張製品仕様書には、標準製品仕様書 Annex A の地物一覧（template_objectlist2d.xlsx, シート
名：A.3.1_取得項目一覧）を用いて、作成対象とするものに○（必須で作成するものには●）を付けた一
覧を付ける。作成対象としない地物等の応用スキーマクラス図や文書を削除する必要はない。

4.2.2. 都市計画基本図のための拡張(1) DM 分類コードの追加
地方公共団体独自の DM 分類コードを設定している場合は、コードリストを以下の方法により拡張
解

45

する。
①

拡張製品仕様書 4.2.1 に示す「都市計画基本図の地物とクラスとの対応」に、追加したいコード、その説明及びこれに対応する CityGML 又は i-UR のクラスを記載する。
CityGML 又は i-UR に定義されたいずれの地物に対応させるかは、3.1.3 を参考にする。

②

拡張製品仕様書 4.2.4 に示すコードリスト（Common_dmCode.xml）のコード一覧に、①で追加した
コードとその説明を追加する。

③

コードリストファイル（Common_dmCode.xml）に追加したいコードと説明を追加する。
コ ー ド の 追 加 は 、 以 下 に 示 す XML の フ ラ グ メ ン ト を 、 コ ー ド リ ス ト フ ァ イ ル 末 尾 に あ る</gml:Dictionary>タグの直前に挿入すればよい。
<gml:dictionaryEntry><gml:Definition gml:id="Common_dmCode_1"><gml:description>[追加したいコードに対応する説明]</gml:description><gml:name>[DM 分類コード]</gml:name></gml:Definition></gml:dictionaryEntry>

gml:id は、他と重複しない識別子とする。

<gml:name>タグにはコードを記述する。

<gml:description>タグにはコードの説明を記述する。

追加するコードは、同じファイルに既に定義されている他のコードと重複してはならない。

(2) 図形タイプの変更
標準図式と地方公共団体の公共測量作業規程で、図形タイプ（点、線又は面）が異なる場合がある。標準製品仕様書に示された図形タイプとは異なる図形タイプを使用する場合は、以下を実施する。
•

拡張製品仕様書 4.2.3 の応用スキーマ文書（関連役割の型が uro:DmAttribute となる関連役割の定義
文において、図形タイプを変更したい DM 分類コードと変更したい内容を反映する。


反映する内容は、各地方公共団体の公共測量作業規程において示される、追加したい分類コードの取得方法である。



図式情報を格納する uro:DmGeometricAttribute は、点、線、面のいずれの形状でも保持することが可能な空間属性をもっているため、図形タイプが変更となっても応用スキーマクラス図を変更する必要はない。

(3) 独自属性の追加
都市計画基本図は、地図表現に必要な属性のみを保持するため、独自の属性追加は想定していない。
ただし、必要な場合は、次項に示す都市計画基礎調査情報のための拡張に独自属性の追加方法を示しているため、この方法と同様にして追加できる。
解46

4.2.3. 都市計画基礎調査情報のための拡張(1) 実施しない調査の設定
実施しない調査がある場合、4.2.1 に示す通り、当該調査に対応する地物に○又は●を付けず、対象外であることを示す。
(2) 地方公共団体独自の属性追加又は収集しない属性の設定
収集しない属性がある場合、4.2.1 に示す通り、当該属性に○又は●を付けず、対象外であることを示す。
各地物には様々な属性が箱として用意され、多くの属性は任意である。これらは必要に応じて拡張製品
仕様書で取捨選択してよい。例えば、他の地物との空間演算により算出可能な情報は利用頻度が高ければ属性として格納し、利用頻度が低ければ属性として格納せず、GIS 上で必要に応じて演算することでもよい。ただし、必須又は運用上必須となる属性は必ず作成する必要がある。例えば、調査年（surveyYear）
が該当する。都市計画基礎調査が複数年に分けて実施される場合なども想定され、地物ごとに情報の鮮度を把握することを可能とするため、標準製品仕様書では必須としている。

地方公共団体独自の属性追加がある場合、汎用属性（gen::genericAttribute）又はコード型拡張属性（uro::KeyValuePairAttribute）を用いて、以下の方法により追加する。
①

追加したい属性の型に合わせて、汎用属性又はコード型拡張属性のいずれかを選択する。

汎 用 属 性 の 型 は 文 字 列 型 （ gen::stringAttribute ）、 整 数 型 （ gen::intAttribute ）、 実 数 型

（gen::doubleAttribute）、日付型（gen::dateAttribute）、URI 型（gen::uriAttribute）、単位付き計

測値型（gen::measureAttribute）から選択できる。また、コード型の属性を追加したい場合には、コード型拡張属性（uro::KeyValuePairAttribute）を使用する。

②

選択した属性の型に応じて、属性の定義表を作成する。
汎用属性を使用する場合は、地物型ごとに汎用属性の一覧表（template_objectlist2d.xlsx, シート



名：A.3.2_汎用属性）を作成する。


追加したい属性ごとに、「属性の型」、「名称」、「定義」及び「定義域」を記述する。また、必要に応じて「単位」及び「注釈」を記述する。

「 属 性 の 型 」 は 、 文 字 列 型 （ gen::stringAttribute ）、 整 数 型 （ gen::intAttribute ）、 実 数 型（gen::doubleAttribute）、日付型（gen::dateAttribute）、URI 型（gen::uriAttribute）、単位付き計測値型（gen::measureAttribute）からする。

「名称」は、拡張属性の内容が分かる、簡潔な語句を記述する。

「定義」は、汎用属性の詳細な内容を示す。

「多重度」は、その汎用属性が一つの地物インスタンスに出現しうる回数を示す。

「定義域」には、その汎用属性が取りうる値の範囲を記述する。

「単位」は、汎用属性とした単位付き計測値型を選択した場合は、必ず指定する。それ以外の整数型や実数型を選択した場合も必要に応じて指定できる。
解

47



他に特筆すべき事項があれば、「注釈」に記述する。
コード型拡張属性を使用する場合は、コード型拡張属性の一覧表（template_objectlist2d.xlsx, シ

ート名：A.3.3_コード型拡張属性）を作成する。


一覧表は応用スキーマで一つ作成する。



追加したコード型拡張属性ごとに、
「説明」
「定義」
「多重度」
「型」
「定義域」
「注釈」を記述する。

「説明」は、拡張属性の内容が分かる、簡潔な語句（名称）を記述する。

「定義」は、拡張属性の詳細な内容を示す。

「多重度」は、その拡張属性が一つの地物インスタンスに出現しうる回数を示す。

「型」は、コード型を示す「gml:CodeType」とする。この値は固定値である。

「定義域」には、次項で示す、コード型拡張属性が取りうる値を格納するコードリストのファイル名を記述する。

③「注釈」には、対象となる地物型を示す。

コード型拡張属性を使用する場合は、追加する属性の名称のコードリストと、追加した属性の値として取りうるコードリストを作成する。
追加する属性の名称のコードリストの名称は、KeyValuePairAttribute_key.xml とする。②で一覧

に記入した key とその説明との対を記述する。
<gml:dictionaryEntry><gml:Definition gml:id="key_100"><gml:description>[追加したいコード型属性の説明]</gml:description><gml:name>[コード型属性に割り振った番号]</gml:name></gml:Definition></gml:dictionaryEntry>
各 key に対応するコードリストの名称は、KeyValuePairAttribute_key[key].xml とする。このとき、

[key]は、②で追加する属性に割り振った 100 以上の整数である。
なお、属性を追加したい地物の地物定義文書の汎用属性又はコード型拡張属性の定義に、追加したい属
性の名称及び定義を記載する。このとき、標準製品仕様書は汎用属性及びコード型拡張属性を対象外としているため、括弧書きを外すなどの編集を行うこと。（template_specification2d.docx）

さらに、追加した属性を調書や集計表として出力する場合、各データ型の orgItem 属性を使用して追加する。この属性は、汎用属性と同様に、任意の属性を追加するための仕組みである。orgItem の使用方
法は以下の通りである。
•

属性を追加したい地物の応用スキーマ文書の orgItem の定義に、追加したい属性の名称（class）及び属性の型を記述する。属性の型は、整数型（intValue）、実数型（doubleValue）、単位付き計測値型（measureValue）、属性の型は文字列型（stringValue）から選択できる。また、追加したい属性の定義も記載すること。


標準製品仕様書は orgItem 属性を対象外としているため、括弧書きを外すなどの編集を行うこ
解

48

と。


属性の型として単位付き計測値型を選択した場合は、単位も指定すること。

(3) 地方公共団体独自の調査の追加
標準製品仕様書に定義されていない調査がある場合は、以下の手順で拡張できる。
•

位置図を作成する場合は、汎用都市オブジェクト（gen::GenericCityObject）を使用して記述する。

①

汎用都市オブジェクトの定義表（template_objectlist2d.xlsx、シート名：A.3.6_汎用都市オブジェク
ト）を作成する。
汎用都市オブジェクトには、これを識別するコードを付与する。



このコードが、汎用都市オブジェクトの属性 name の値となる。

コードを付与した汎用都市オブジェクト毎に、「name の値」、
「説明」
「定義」及び「属性一覧」を一覧にする。
「name の値」は、汎用都市オブジェクトを識別するコードである。

「説明」は、汎用都市オブジェクトの内容が分かる簡潔な語句（名称）である。

「定義」は、汎用都市オブジェクトの詳細な説明である。

「属性一覧」は、独自属性の追加と同様に、「汎用属性の型」、
「名称」、
「定義」
「多重度」及び「定義域」を記述する。また、必要に応じて「単位」及び「注釈」を記述する。



汎用都市オブジェクトは、コード型拡張属性（uro::KeyValuePairAttribute）を使用することができないため、コードを使用したい場合には文字列型の汎用属性等で代替すること。

②

汎用都市オブジェクトの属性 name のコードリスト（GenericCityObject_name.xml）を作成する。
コードに対応する説明は、①で作成した汎用都市オブジェクトの内容が分かる簡潔な語句（名称）をとする。

調書及び集計表を追加する場合は、汎用的なデータ型である urf::ItemRecordType、

urf::SummaryRecordType 及び urf::UrbanPlanningBasicSurveyTable を使用する。調書の場合は

urf::ItemRecordType、集計表の場合は urf::SummaryRecordType を使用する。これらのデータ型の構造に従って拡張製品仕様書 Annex B に示す、都市計画基礎調査調書及び集計表の定義を追加する。B.2 に示す調書及び集計表の一覧に追加するとともに、B.3 に示すそれぞれのテーブル定義に、属性ごとにその定義を記載する。

4.2.4. 都市計画決定情報のための拡張(1) 当該地方公共団体に存在する都市計画の区域の抽出
当該地方公共団体に存在する都市計画の区域を抽出する場合は、4.2.1 に示す通り、作成対象とする都市計画の区域に該当する地物に○又は●を付け、作成対象であることを示す。
(2) 標準製品仕様書にはない都市計画の区域の追加
標準製品仕様書に定義されていない都市計画の区域がある場合は、以下の手順で拡張できる。
解

49

•

「都市施設」、「市街地開発事業」、「地区計画」等には含まれるが、これを継承するクラスとして存在しない場合、「市街地開発事業（urf::UrbanDevelopmentProject）」、「都市施設（urf::UrbanFacility）」、「地区計画（urf::DistrictPlan）」などの上位の概念を示すクラスを使用して記述することができる。
•

上位の概念を示すクラスが存在しない場合は、区域（urf::Zone）を使用して記述する。



urf::Zone を使用する場合は、使用したい名称や追加したい属性をそれぞれ応用スキーマ文書に記載しなければならない。


urf::Zone は法的な区域を示す地物型であり、定義文書は、拡張製品仕様書のテンプレート（template_specification.docx）に含めている。

(3) 地方公共団体独自の属性の追加又は作成しない属性の設定作成しない属性がある場合は、4.2.1 と同様に、当該属性に○又は●を付けず、対象外であることを示す。
地方公共団体独自の属性追加がある場合、都市計画基本図や都市計画基礎調査情報と同様、汎用属性を用いて追加する。

4.3. 品質要求及び品質評価手順の決定
新たに追加したすべての地物型等についても、品質要求を追加する必要がある。
基本的には、追加した地物型等の内容に応じて、標準製品仕様書で定める品質要求の「データ品質適用範囲」に、追加した地物型等を追加すればよい。
標準製品仕様書で定める品質要求以外の品質要求が必要な場合には、品質評価手順と合わせて追加すること。品質評価手法の決定に当たっては、「品質の要求、評価及び報告のための規則」6．品質評価のための規則に従い、データ品質評価尺度を適用するための手順（規定された方法）を記述、又はその記述を含む文書（例えば，認定済の日本産業規格など）を引用する。また、参照データの名称も示すこと。
なお、都市計画基本図の位置正確度として地図情報レベル 2500 を採用しているが、他のデータセットとの整合をはかり、地図情報レベル 1000 や地図情報レベル 500 を採用している場合には、対象となる地物型や適合品質水準を更新すること。

4.4. 拡張製品仕様書の作成
地方公共団体ごとの都市計画データの製品仕様をとりまとめ、拡張製品仕様書を作成する。拡張製品仕様書を作成する際のテンプレートとして、標準製品仕様書 Annex A に示すテンプレートを用いる。
拡張製品仕様書には、作成すべき地物等の一覧や、追加した地物等がある場合にはその製品仕様や品質要求等が含まれなければならない。また、製品仕様書が対象とする範囲や作成した都市計画データの問
合せ先等、地方公共団体ごとに異なる内容をそれぞれ反映する必要がある。
表 4-2 に、拡張製品仕様書に反映すべき内容を示す。
なお、拡張製品仕様書の作成においては、国土交通省国土地理院が作成した「地理空間データ製品仕様
解50

書作成マニュアル」が参考となる。
表 4-2 拡張製品仕様書に反映すべき内容
1

構成

拡張製品仕様書に反映すべき内容

概覧

拡張製品仕様書の題名、版、日付、作成者を各地方公共団体において記載する。
また、拡張製品仕様書が適用される空間範囲（基本的には各地方公共団体の行政区域となる）を指定する。また、必要に応じて時間範囲を指定する。
引用規格等には、各地方公共団体の公共測量作業規程や都市計画
基礎調査実施要領を記載する。

2

適用範囲

適用範囲の名称を記載する。

3

データ製品識別製品の名称、日付、問合せ先を記載する。

4

データ内容及び構造作成対象とする地物等の一覧を付する。
追加する地物や属性がある場合にはその内容が地物定義文書に反映されていなければならない。
数値型の属性について、原典資料との一致が必要な場合には、拡張製品仕様書の応用スキーマ文書において、属性の定義にその旨記載すること。

5

参照系

平面直角座標系の系を指定すること。

6

データ品質

追加する地物や属性がある場合には、品質要求に反映する。
必要に応じて、新たな品質要求及び評価手順を追加してもよい。

7

データ製品配布

標準製品仕様書に従うこととし、拡張製品仕様書で変更しない。

8

メタデータ

標準製品仕様書に従うこととし、拡張製品仕様書で変更しない。

9

その他（任意記載項目）

データ取得において従うべき各都市の公共測量作業規程及び都市
計画基礎調査実施要領の名称を記載する。

製品仕様書作成の詳細：地理空間データ製品仕様書作成マニュアル JPGIS 2014 版[5]解51

付属資料 1
3D 都市モデル

用語及び略語都市空間の地物及び属性を都市スケールで 3 次元的に再現した CityGML 形式の
データ。

ADE

Application Domain Extensions。
CityGML の拡張規則に則り拡張されたモジュール。

CityGML

City Geography Markup Language。
都市空間を記述することを目的に作成されたデータ構造とフォーマットの標準
仕様。

GML

Geography Markup Language。
地理空間データを記述するための XML ベースのマークアップ言語。

i-UR

CityGML に都市計画及び都市再生に必要な地物や属性を追加した ADE。

JMP2.0Japan Metadata Profile 2.0。
国土地理院により策定された、ISO19115 メタデータのプロファイル。

LOD

Level Of Detail。詳細さの度合い（詳細度）であり、CityGML において定義されている、一つのオブジェクトの幾何をその利用や可視化の目的に応じて、複数の段階に抽象化することを可能とする、マルチスケールなモデリングの仕組みである。

UML

Unified Modeling Language。
オブジェクト指向モデリング言語の一つ。

インスタンス「クラス」に含まれる「もの（オブジェクト）」の実体。

応用スキーマ

一つ又は複数の応用システムによって要求されるデータのための概念スキーマ。

幾何オブジェクト

点、線、面、立体などの幾何形状。

クラス

共通の性質をもつ「もの（オブジェクト）」を抽象化した概念（型）。

スキーマ

モデルを一定の書式に基づき記述したもの。

地物

現実世界の現象の抽象概念。

地物属性

地物の特性。

地物関連

地物間の関係。

地理情報標準地理空間データを異なるシステム間で相互利用する際の互換性の確保を主な目
的に、データの設計、品質、記述方法、仕様の書き方等のルールを定めたもの。
ISO19100 シリーズ（JIS X7100 シリーズ）。

都市計画情報都市計画行政に必要となる都市計画基本図、都市計画基礎調査及び都市計画図書に含まれる情報。

都市計画データ

都市計画情報の 2 次元のデジタルデータ。

概念スキーマ

必要な情報をデータモデルによって抽象化し、その抽象化した概念と概念間の関係を定義した記述。

解52

付属資料 2 CityGML/i-UR 解説
1

概要
本付属資料は、「都市計画データ標準製品仕様書」（以下、「標準製品仕様書」と呼ぶ）の応用スキーマ及び符号化仕様として採用する CityGML 及び i-UR を解説する。また、CityGML 及び i-UR への理解を助けるため、UML クラス図及び XMLSchema の読み方についても併せて解説する。
なお、本付属資料は標準製品仕様書の応用スキーマ及び符号化仕様を理解する一助となることを目的としており、解説の内容も基本的な範囲に留まることに留意されたい。

2

CityGML
CityGML（City Geography Markup Language）は、地理空間情報に関する国際的な標準化団体である OGC（ Open Geospatial Consortium）によって策定された、3 次元で都市空間を記述することを目的に、基本的な地物と属性を定義したデータ標準仕様である。データの概念構造を示す UML ク
ラス図と、UML クラス図に基づき XML 形式で符号化するための仕様である XMLSchema から構成される。CityGML は、地理情報標準（ISO19100 シリーズ）に従って作成された応用スキーマの一つである。
(1) CityGML の特徴
CityGML の特徴として、「LOD（Level Of Detail）」と「拡張性」がある。
LOD は、詳細さの度合い（詳細度）であり、一つのオブジェクトの幾何をその利用や可視化の目的に応じて、複数の段階に抽象化することを可能とする、マルチスケールなモデリングの仕組みである。LOD には、LOD0 から LOD4 までの 5 段階があり、LOD0 が最も粗く、LOD4 が最も細かい
データとなる。従来、地理空間データは地図の縮尺ごとに整備・利用され、縮尺を超えたデータ管理は困難であった。LOD は、一つのオブジェクトについて複数の異なる形状表現を統合的に管理することを可能とする仕組みである。
CityGML では、様々な用途に利用できる汎用的な応用スキーマとするため、基本的な地物・属性
しか定義されていない。ただし、応用分野や目的に応じて地物や属性を追加（拡張）する仕組みが用意されている。拡張方法には 3 つある：①

コードリストによる拡張：分類（class）や機能（function）等のコード型属性について、コードリストを拡張できる。例えば、標準製品仕様書には DM 分類コードをコードリストとして用意しているが、これに地方公共団体独自の分類コードを追加することができる。

②

Generic モジュールによる拡張：汎用的な Generic オブジェクトや Generic 属性を使用して、CityGML に定義されていない地物や属性を追加できる。都市計画基礎調査において、地方公
共団体独自の位置図を作成しており、CityGML に対応する地物が存在しない場合に使用できる。

③ ADE（Application Domain Extensions）による拡張：CityGML のルールに従い、応用スキーマとして新たに地物や属性を追加定義する方法である。UML クラス図と XMLSchema を作成するため、データ構造の厳密性を担保できる。次項で説明する i-UR は、CityGML の ADE の解53

一つである。
(2) CityGML のモジュール
CityGML には地物の内容に応じた 13 のモジュールが用意されている。例えば、Building モジュ

ー ル に は 、 建 築 物 （ bldg::Building ） や 、 こ の 構 成 要 素 と な る 壁 面 （ bldg::WallSurface ） や 窓（bldg::Window）などが地物として定義されている。また、Bridge には、橋梁（brid::Bridge）が地物として定義されている。標準製品仕様書では、これらのモジュールから、都市計画基本図等に必要となる地物を引用している。
なお、CityGML は様々な分野での利用を想定していることから、分野や用途別に地物を定義するのではなく、「もの」に着目して定義している。例えば、鉄道施設や道路施設というように、分野や用途別に地物を定義すると、鉄道施設にも橋梁（鉄道橋）、道路施設にも橋梁（鉄道橋）を定義しなければならない。CityGML ではこのような分野や用途に着目した地物定義ではなく、地物として「橋梁」を定義し、属性で用途（道路橋や鉄道橋等）を区分するという設計方針となっている。
グループ（他の地物をまとめるために使用）

都市設備

地物に貼るテクスチャ

橋梁

建築物

土地利用

地形

交通（道路、鉄道等）トンネル

植生

汎用地物・属性（暫定的に地物と属性を追加するために使用）

水部（川、海等）

地物に共通の基本要素
テクスチャが貼られた面（廃止予定なので非推奨）
図形など

住所

付 2-図 1 CityGML のモジュール構成
3

i-UR「i-UR」は、内閣府地方創生推進事務局において作成された技術仕様であり、CityGML の ADEとして開発された。
(1) i-UR の背景
まちづくりの現場における関係者の合意形成と、都市再生の生産性と投資の質の向上の促進を図るためには、都市再生における空間的・数値的理解を得るためのデータの一体的活用を容易とする基盤整備と、作成したデータが都市のストックとして蓄積されていく枠組みの構築が重要である。その解54

ためには、仕様の異なるデータを統合し、各機関が基準として適用する標準データ交換フォーマット
が必要であることから、内閣府地方創生推進事務局において、平成 30 年度より、「都市再生の見える化情報基盤」として「i-都市再生」を推進しており、その中で標準データの技術仕様案の「i-UR」が策定された。
「i-UR」は、既に国際的に利用されている実績があり、データの意味を交換できる厳密性と不足する情報を拡張可能な柔軟性を兼ね備えた国際標準である CityGML をベースとし、ADE の仕組みを使って策定された。
なお、「i-都市再生」は社会状況の変化を踏まえ、令和 2 年度よりその範囲を「社会の最適化を図る都市情報基盤」として拡大し、「社会活動の高度化や日常生活における質の向上を実現させるため、都市を構成する情報と都市活動に関連する静的・動的な情報を連携させることで様々な課題の分析、検討、解決を図る取組」としてその定義を改めている。

i-都市再生の詳細：i-都市再生ガイダンス[6](2) i-UR のモジュール
i-UR は、データの特性に応じた 4 つのモジュールから構成されている（付 2-図 2）。

都市オブジェクト

都市機能«ApplicationSchema»
Urban Object

統計メッシュ
«ApplicationSchema»
Statistical Grid

«ApplicationSchema»
Urban Function

公共交通«ApplicationSchema»
Public Transit

標準製品仕様書で使用するモジュール付 2-図 2 i-UR のモジュール構成と標準製品仕様書との関係
Urban Object モジュールは、CityGML に定義済みの地物（例：bldg::Building）に詳細な属性を追加 し た り 、 こ れ を 拡 張 し て 新 た な 地 物 を 定 義 （ 例 ： bldg::Building を 拡 張 し 、 地 下 街 と し てUndergroundBuilding を定義する）したりするためのモジュールである。標準製品仕様書では、数値
地形図を表現するために必要となる属性や都市計画基礎調査の建物利用現況として建物に付加する属性に使用するデータ型として、Urban Object モジュールで拡張されたデータ型を使用している。
Urban Function モジュールは、CityGML には定義されていない、概念的な地物を定義するモジュールである。CityGML には、橋梁（brid::Bridge）や地形（dem::ReliefFeature）のような物理的な地物は定義されているが、行政区域や行政界といった目には見えない制約条件のような地物は定義されていない。しかしながら、都市計画では都市計画区域や用途地域といったゾーニングの情報は非常に重要な地物となる。そこで、都市計画の各区域等は Urban Function モジュールで定義された地物型を使用している。
解55

Statistical Grid モジュールは、統計メッシュを定義するモジュールである。地域メッシュのような
統計メッシュは、各メッシュが等面積かつスケーラビリティをもって設計されており、位置も固定されていることから、比較や統合、時系列変化の把握が容易となり、地域の傾向分析等に有用である。標準製品仕様書では、都市計画基礎調査の分布図に必要な地物を Statistical Grid モジュールから引用している。
Public Transit は公共交通の運行情報を定義するモジュールであり、公共交通機関の時刻表とその地理的情報に使用される共通形式を定義した GTFS(General Transit Feed Specification)を CityGMLにマッピングしたものである。
なお、標準製品仕様書ではこのモジュールは使用していない。

i-都市再生の詳細：i-都市再生技術仕様案[7]4UML クラス図の概要
UML クラス図とは、Unified Modeling Language（統一モデル化言語）の記法の 1 つであり、「もの（オブジェクト）」の静的な構造を表現することができる。地理情報標準では、地理空間データの概念的な構造（どのような地物があり、どのような属性をもち、地物間がどのような関係性にあるかの記述。データフォーマットには依存しない。
）を記述する記法として採用されている。
以下で UML クラス図の記法を解説する。
付 2-表 1 UML クラス図の記法
表記

意味
クラス。クラスは 3 段の箱により記述する。
1 段目の箱には、ステレオタイプ（クラスの種類。付 2-表 2 参照）とクラスの名前を記述する。クラスの名前には、それぞれのクラスがどのモジュールで定義されているかを明示するため、接頭辞を付ける。
2 段目の箱には、クラスの属性を記述する。
3 段目の箱はクラスの操作であり、地理空間データの応用スキーマでは使用しない。
クラスの属性は、属性の名前、属性の型、属性の多重度から構成する。
属性の型は、属性が取る値の種類を指定する。xs::string（文字列型）のような基本的な型や gml::MultiSurface のような幾何形状を示すクラ
ス、あるいは、応用スキーマで定義した別のクラスを指定できる。
属性の多重度は、その属性が繰り返し出現可能な回数を指定する。
[a..b]のように指定し、a 及び b は、a<=j<=b となる任意の整数 j を意味する。[a..a]は、[a]と同じとみなす。以下のような記載方法がある。
[0..1] ：0 又は１[0..*] ：0 以上[1..*] ：1 以上
解

56

表記

意味
[m] ：m[m..n] ：m 以上 n[m,n] ：m 又は n
なお、属性の多重度を省略することもできる。省略された場合は、1 となる。
継承。
元となるクラス（上位クラス）の特性を受け継ぐ新しいクラス（下位クラス）との関係である。
クラス図では三角（△）と線とで表現し、△が付く側（Class1）が元となるクラスである。
継承する下位クラスのインスタンスは、自分自身に定義された属性や関連役割だけではなく、上位クラスに定義された属性や関連役割をもつ。
すなわち、Class1 に属性「名称」が定義されていた場合、Class2 も属性として「名称」をもつ。
関連。
二つのクラス間に関係性があることを意味する。
関連役割名は、この関連における役割を示す。
関連には多重度を指定できる。多重度は、相手クラスのインスタンスが1 つ存在した場合に、関連しうる自身のインスタンスの数を記載する。
多重度の記法は、属性の多重度と同じである。また、多重度が省略された場合は 1 となる。
関連には向きをつけることができる。向きは矢印により記述する。関連
に向きが付けられた場合、関連は片方向となる。
標準製品仕様書では、関連は地物と幾何オブジェクトとの関係に使用される。この関連は、地物から幾何オブジェクトへの片方向となる。例えば、bldg::Building と LOD0 の幾何形状となる gml::MultiSurface との間には片方向の関連が定義されている。

インスタンスにする場合、 bldg::Building のインスタンスの中には
gml::MultiSurface のインスタンスそのもの又は gml::MultiSurface のインスタンスへの参照が含まれる。一方、gml::MultiSurface のインスタンスの中には、bldg::Building のインスタンスへの参照が含まれるこ
とはない。

解

57

表記

意味
集成関連。
二つのクラス間に全体と部分という関係がある関連である。全体となる
クラス側に白いひし形を記述する。
関連役割名は、この集成関連における役割を示す。また、集成関連には多重度を指定できる。多重度や向きの記法は関連と同様である。
標準製品仕様書では、地物間に全体と部品の関係が成り立つ場合に、集成が使用され、かつ、全体から部品への片方向の向きとなっている。例
えば、地区計画と地区計画において定められる地区整備計画との間に集成が定義されている。

インスタンスにする場合は関連と同様となり、地区計画のインスタンスの中には地区整備計画のインスタンスそのもの又は地区整備計画のイ
ンスタンスへの参照が含まれる。一方、地区整備計画のインスタンスの中に、地区計画のインスタンスへの参照が含まれることはない。
合成。
二つのクラス間に全体と部分という関係がさらに強固な関連である。全体となるクラス側に黒いひし形を記述する。合成は、全体となるクラスが無くなった場合に、部分となるクラスも無くなる関係に用いる。
関連役割名や多重度の表記は、集成と同様である。
標準製品仕様書では、地物とデータ型あるいはデータ型とデータ型との間に合成が使用され、かつ、全体から部品への片方向の向きとなっている。例えば、調書と調書のレコードとの間に、合成が定義されている。

インスタンスにする場合、部品となるクラスのインスタンスを、全体となるクラスのインスタンスの内部に記述する。つまり、調書のインスタ
ンスの中にレコードのインスタンスが直接記述される。

解58

クラスの 1 段目に記載されるステレオタイプの解説を付 2-表 2 に示す。
付 2-表 2 ステレオタイプ
ステレオタイプ

説明<<FeatureType>>

地物に適用するステレオタイプ。地物型と呼ぶ。

<<DataType>>

地物の属性の型に適用するステレオタイプであり、複数の属性をまとめたい場
合に使用する。データ型と呼ぶ。

<<Type>>GML や CityGML で定義された地物以外の型のうち、gml::MultiSurface のような幾何オブジェクトなど、識別子をもつ型に適用するステレオタイプ。

<<Enumeration>>

地物属性の定義域が固定となる場合に、定義域に含まれる値を列挙した型に<<Enumeration>>を使用する。列挙型と呼ぶ。属性の型として使用される。
なお、列挙型は定義域が固定されるため、拡張製品仕様書において定義域が拡張される可能性のある場合には、属性の型にはコードリスト（gml::CodeType）
を使用する。

<<Union>>

地物の属性の型に適用するステレオタイプであり、複数の属性のうち、いずれか一つを選択して値を記述させたい場合に使用する。
標準製品仕様書では、都市計画基礎調査の集計表を作成する際に、集計の単位を選択するための型に適用している。

5

XMLSchema の概要
XML（eXtensible Markup Language：拡張可能なマーク付け言語）は、テキスト形式のデータフォーマ

ットである。タグで値を囲むことにより、その値に意味づけをする。XML は、開始タグと終了タグとそれに囲まれた値の組が基本の単位（「要素」と呼ぶ）となり、タグで囲われた「要素」と、「要素」とタグの内部に記載される「属性」から構成される。

要素
タグ（開始タグ）

タグ（終了タグ）<uro:totalFloorArea uom="m2">1471.66</uro:totalFloorArea>
属性

XML で記述された文書を XML 文書と呼ぶ。一方、XMLSchema は、XML 文書の書式を規定する文書であり、XML 文書に出現する要素や属性、またそれらの値の型、さらに、要素の出現順序や出現回数などを規定する。つまり、XMLSchema は、XML 文書の設計図に該当する。
この XML は任意に拡張することができるが、地理空間データを記述するために拡張されたのが、GML（Geography Markup Language）である。GML は OGC により策定された国際標準であり、
解59

UML クラス図で記述された応用スキーマを、XML 形式に符号化するために UML クラス図と
XMLSchema のマッピングルールを定めている。また、点、線、面などの基本的な要素やコード型などの属性のデータ型については XMLSchema を定めており、各応用スキーマを XMLSchema にマッピング
する際には、これらを利用できる。
CityGML は、この GML に従い、CityGML の応用スキーマに対応する XMLSchema を定めている。
同様にして、i-UR についても、拡張された応用スキーマに対応する XMLSchema が定められている。
以降では、CityGML 及び i-UR の XMLSchema について解説する。
(1) 要素（element）宣言要素（element）は、XML 文書の中で「タグ」として出現する。要素宣言は、XML 文書で使用可能なタグを宣言するものである。name 属性は要素の名称であり、XML 文書で使用するタグとなる。また、type 属性は要素のデータ型であり、XML 文書でタグ（開始タグ）とタグ（終了タグ）との間に挟まれる値の種類を指定する。
<element name=“totalFloorArea” type=“gml:MeasureAttribute”/>
タグ

開始タグと終了タグとの間に記述される値の種類

type 属性で指定する値の種類は、文字列（xs:string）や整数（xs:integer）のような単純な型（「単純型」と呼ぶ）だけではなく、複数の要素のかたまりを指定することもできる。これを「複合型」と呼ぶ。
(2) 複合型（complexType）宣言
複合型（complexType）とは、複数の要素や属性から構成される「要素や属性のかたまり」である。
name 属性は複合型の名称である。複合型の開始タグと終了タグとの間に、かたまりにしたい要素や属性を列挙する。
例えば、以下の例では、要素として要素名が prefecture と city という 2 つの要素をかたまりにしている。
<xs:complexType name=“locationType"><xs:sequence><xs:element name=“prefecture" type="xs:string“ /><xs:element name=“city" type="xs:string“ minOccurs=“0” maxOccurs=“unbounded”/></xs:sequence></xs:complexType>

複合型に含める要素には、多重度（繰り返し出現可能な回数）を指定できる。最小の出現回数を
minOccurs 属性で指定し、最大の出現回数を maxOccurs 属性で指定する。多重度は省略でき、省略された場合は 1 となる。また、unbounded は制限がないことを意味する。前述の例では、prefecture 要素
解60

は多重度が省略されているため必ず 1 回出現するが、city 要素は、出現しなくてもよく、また何度でも出現してもよい。さらに出現順序は、宣言された順序と一致する。この例の場合では、最初にprefecture 要素、その次に city 要素が出現する。
複合型は要素の type 属性として指定する。

<xs:element name=“Location” type=“locationType”/>

type 属性に複合型が指定された場合、要素宣言されたタグとタグとの間に出現する内容は、複合型で宣言された要素や属性のかたまりとなる。

<Location><prefecture>東京都</prefecture><city>文京区</city><city>台東区</city></Location>

例えば、Location 要素を宣言し、この型として LocationType を指定したとする。この場合、Location タグの間には、LocationType でかたまりにされた prefecture 要素と city 要素としてそれぞれ宣言された、prefecture と city のタグが出現する。これらのタグが出現可能な回数は、LocationType で指定された多重度に従う。
複合型を構成する属性の型には単純型しか指定することはできないが、要素の型に複合型を指定することができる。これにより、XML 文書のツリー構造を表現できる。
(3) 応用スキーマと XMLSchema
応用スキーマの UML クラス図で記述された概念的なデータ構造を、XML 形式に符号化するため、UML クラス図と XMLSchema のマッピングルールが定められている（付 2-表 3）。
付 2-表 3 UML クラス図と XMLSchema の対応付け
UML クラス図

XMLSchema

パッケージ

原則として 1 つのパッケージに 1 つの XMLSchema を作成する。

クラス

element と complexType となる。列挙型の場合は simpleType（単純型）となる。

属性

complexType の中の element

関連・集成・合成

complexType の中の element

継承element の substitutionGroup 属性及び complexType の中の extension を使用する。substitutionGroup 属性では、継承するクラスの要素名を指定し、extension では、継承するクラスの複合型名を指定する。
解61

例として、公共空地（urf::OpenSpaceForPublicUse）の UML クラス図と XMLSchema を比較してみる。

付 2-図 3 公共空地（urf::OpenSpaceForPublicUse）の UML クラス図
付 2-図 3 は公共空地の UML クラス図である。urf::OpenSpaceForPublicUse は、urf::UrbanFacility（都市施設）を継承している。また、自身に属性は定義されていないが、データ型である

urf::ParkAttribute を合成（関連役割 parkAttribute）により保持している。
以下に、この urf::OpenSpaceForPublicUse の XMLSchema を示す。

<xs:element name="OpenSpaceForPublicUse" type="urf:OpenSpaceForPublicUseType" substitutionGroup="urf:UrbanFacility“/><xs:complexType name="OpenSpaceForPublicUseType"><xs:complexContent><xs:extension base="urf:UrbanFacilityType"><xs:sequence><xs:element name="parkAttribute" type="urf:ParkAttributePropertyType" minOccurs="0"/></xs:sequence></xs:extension></xs:complexContent></xs:complexType>

urf::OpenSpaceForPublicUse は、クラスであるため、要素宣言と複合型宣言が行われる。クラス名は、要素の名称に一致する。urf::OpenSpaceForPublicUse は、urf::UrbanFacility を継承しているため、要素解62

の substitutionGroup 属性では、継承するクラスに対応する要素（urf:UrbanFacility）が指定され、また、複 合 型 宣 言 で は 、 xs:extention の base 属 性 に お い て 、 継 承 す る ク ラ ス に 対 応 す る 複 合 型（urf:UrbanFacilityType）が指定されている。また、複合型である OpenSpaceForPublicUseType では、
公共空地の関連役割である parkAttribute が要素として宣言されている。UML クラス図では多重度が[0..1] と な っ て い る た め 、 XMLSchema で も minOccurs=”0” が 指 定 さ れ て い る （ 最 大 出 現 回 数
maxOccurs=”1”は省略）。
このように、UML クラス図と XMLSchema は 1 対 1 に対応づく。XML 文書は XMLSchema に従った構造で作成されることから、結果として、UML クラス図に従った XML 形式のデータとなる。
【補足 1：PropertyType 複合型について】関連役割 parkAttribute に対応する要素宣言において type 属性で指定されている ParkAttributePropertyType は、UML クラス図でデータ型として定義されている

ParkAttribute を子要素として呼び出し、記述するための複合型である。
<xs:complexType name="ParkAttributePropertyType"><xs:sequence><xs:element ref="urf:ParkAttribute"/></xs:sequence></xs:complexType><xs:element name="ParkAttribute" type="urf:ParkAttributeType“/><xs:complexType name="ParkAttributeType"><xs:sequence><xs:element name="parkTypeNumber" type="gml:CodeType" minOccurs="0“/><xs:element name="parkSizeNumber" type="gml:CodeType" minOccurs="0“/><xs:element name="parkSerialNumber" type="xs:integer" minOccurs="0"/></xs:sequence></xs:complexType>

GML では、UML クラス図に記述されたクラス、属性、関連役割の各名称が XML 文書においてタグとして出現されるよう、マッピングルールが定められており、属性の型として他のクラスを指定する場
合、あるいは関連・集成・合成でほかのクラスと関連付ける場合には、必ずそのクラスに対応する要素を出現させるための複合型が宣言される。この複合型の名称は、○○PropertyType（○○にはクラスに対応する要素名が入る）と CityGML 及び i-UR では統一されている。
【補足 2：substitutionGroup 及び extension について】UML クラス図の継承に相当する XMLSchemaの仕組みとして、要素には substitutionGroup、複合型には extension を使用する。
substitionGroup は代替グループと呼ばれ、指定した要素の代わりに出現することが可能となる。例
えば、OpenSpaceForPublicUse は、UrbanFacility の代わりとして出現できる。これは UML クラス図
上で他の地物が UrbanFacility と関連している場合、この地物は関連先として UrbanFacility を継承するOpenSpaceForPublicUse も選択できることと同じ意味となる。
extension は、複合型の拡張の仕組みである。extension で指定した複合型に、新たな要素や属性を追加することができる。これは、UML クラス図において、クラス間に継承関係が定義されている場合、上位のクラスの属性及び関連役割を、下位のクラスが受け継ぎ、さらに、自身に独自の属性や関連役割を定義できることと同じ意味となる。

解63

付属資料 3
1

秘匿処理方法概要
本付属資料は、「利用・提供の観点を踏まえた都市計画基礎調査実施要領及び都市計画基礎調査情報の利用・提供ガイドラインに係る技術資料（第２版）」（令和 3 年 5 月、国土交通省都市局）の内容に基づき、都市計画基礎調査の「建物利用現況」及び「土地利用現況」の集計データを秘匿化してオープンデータとして公開する場合の、秘匿処理を行った都市計画基礎調査データの製品仕様を示すものである。
本付属資料は、秘匿処理が必要な場合の参考資料であり、「都市計画データ標準製品仕様書」（以下、「標準製品仕様書」と呼ぶ）に示す製品仕様の一部ではない。また、秘匿処理の詳細は、「利用・提供の観点を踏まえた都市計画基礎調査実施要領及び都市計画基礎調査情報の利用・提供ガイドラインに係る技術資料（第２版）」を参照すること。

秘匿処理方法の詳細：利用・提供の観点を踏まえた都市計画基礎調査実施要領及び都市計
画基礎調査情報の利用・提供ガイドラインに係る技術資料（第２版）[8]2

秘匿処理の方法
秘匿処理の方法には、「非表示による方法」、「合算集計による方法」及び「集計区分の集約化による方法」がある。以下でその方法を説明する。
(1) 非表示による方法
秘匿が必要な数値等のみを表示しない方法である。
データを秘匿する箇所（元データが 0（ゼロ）の箇所を含む）には”X”（エックス（半角大文字））を入力する。ただし、秘匿しない箇所の元データが 0（ゼロ）の場合には“-（ハイフン（半角文字））”を入力する。
合計値を算出している範囲内で非表示を行う場合は、合計値からの差引きによって秘匿している数値を算出できないよう、その範囲内でもう一箇所非表示を行う。非表示とする対象は、秘匿する箇所の次に小さい数値とする。
(2) 合算集計による方法
一定の小地域において区分の該当数が少数で秘匿処理が必要な場合、隣接する小地域や同一区域に属ずる小地域等との合算集計により対応する。その際、合算先の小地域コードを採用し、各集計区分の該当数を合算する。なお、合算元が合算されたことが判読できるよう調査結果として取りまとめる。
例えば、付属 3 図 1 に示す小地域 A において秘匿処理が必要とする。このとき、小地域 A の集計値
は、隣接する小地域 B の集計値と合算する。小地域 A には、合算先（小地域 B）を識別できるようにしておき、小地域 B には、合算元（小地域 A）が識別できるようにしておく。
解64

付属 3 図 1 合算集計のイメージ(3) 集計区分の集約化による方法
秘匿処理が必要な小地域の集計区分を集約する方法である。 例えば、建物用途区分の集計区分（全18 区分）について、秘匿処理が必要と判断された場合には、用途が比較的近い複数の区分を集約化する（例：「店舗等併用住宅」、「店舗等併用共同住宅」及び「作業所併用住宅」を集約し「併用住宅」とする）。この場合、集計区分の方法を事前に設定すれば、自動処理が可能となる。
3

秘匿処理された都市計画基礎調査の製品仕様(1) データの内容及び構造秘匿処理を行う場合には、秘匿処理に必要な情報を属性として、応用スキーマ UML クラス図に追加する。
都 市 計 画 基 礎 調 査 の 集 計 表 で あ る UrbanPlanningBasicSurveyTable に は 、 秘 匿 化 の 有 無（isAnonymized）を属性として付与する。また、2(2)で示した「合算集計による方法」では各レコー
ドに秘匿処理又は合算された値が格納されていることを明確にするための属性を、各レコードの上位の地物型である urf::UrbanPlanningBasicSurveyRecord に付与する。これにより、継承する全てのデータ型（集計表の各レコードに相当）は、秘匿処理にかかる属性をもつことができるようになる。

«DataType»
UrbanPlanningBasicSurveyTable
+
+
+
+
+
+
+

prefecture: gml::CodeTypecity: gml::CodeType [0..1]
dataItemNumber: gml::CodeTypetableName: xs::string
unit: xs::stringreferenceDate: xs::dateisAnonymized: xs::string+record1..*«DataType»
UrbanPlanningBasicSurveyRecord++++

orgItem: ValueByCodes [0..*]secrecyProcessing: xs::string [0..1]
destination: gml::CodeType [0..1]
target: gml::CodeType [0..*]

付属 3 図 2 秘匿処理属性を追加したＵＭＬクラス図
属性 securecyProcessing は、当該レコードが秘匿処理されたものであるのか、合算されたものであ解65

るのかを示す。また、属性 destination は当該レコードが秘匿処理されている場合に、合算先のレコードを識別する属性である。属性 destination は、
当該レコードが合算された値となっている場合に、合算元となるレコードを識別する属性である。
また、これらの秘匿処理にかかる属性を、応用スキーマ文書にも追加する。
集計表には属性 isAnonymized の定義を追加する（付属 3 表 1）。

付属 3 表 1 集計表に追加すべき属性
都市計画基礎調査のデータ項目ごとに定められた調書又は集計表を示すデ

型の定義

ータ型。
上位の型

―

ステレオタイプ<<DataType>>自身に定義された属性
属性名

属性の型及び多重度

定義

urf::isAnonymized

xs::boolean

秘匿処理を行ったか否かの別。
true：秘匿処理が行われている
false：秘匿処理が行われていない

また、「合算集計による方法」により秘匿処理を行う場合には、属性 securecyProcessing、destination

及び destination の定義を、集計表の各レコードのデータ型に追加する。

付属 3 表 2 レコードのデータ型に追加すべき属性（土地利用現況の例）
型の定義

土地利用の現況。
都市計画基礎調査 C0302 に示される土地利用現況の調書の作成に使用する。

上位の型

urf::UrbanPlanningSurveyRecord

ステレオタイプ<<DataType>>自身に定義された属性
属性名

属性の型及び多重度

定義

urf::secrecyProcessing

xs::string [0..1]

秘匿処理を行う場合に以下を入力する。
秘匿されている他の地域を当該地域に合算する
場合は、「合算地域あり」とする。非開示情報に相当する情報の場合は、「秘匿地域」とする。
「合算地域あり」の場合、urf::target には、合算された地域のコードを記載する。また、「秘匿地域」の場合、urf::destination には、合算先の地域のコードを記載する。

urf::destination

gml::CodeType [0..1]

合算先の地域を識別するコード。

urf::target

gml::CodeType [0..*]

合算された地域を識別するコード。

解66

(2) 配布書式情報
符号化仕様には、標準製品仕様書に示す CSV による符号化仕様に従う。
なお、秘匿処理にかかる属性を追加しているため、CSV 形式で符号化されたデータには追加された属性も出力する。
配布媒体情報は、標準製品仕様書に示すオープンデータのための配布媒体情報に従う。
4

秘匿処理が必要な事例
小地域・区域で集計したデータを公開する際には、個人又は事業者等の権利利益を保護するため、集計データの秘匿処理が必要となる場合がある。
都市計画基礎調査において、秘匿処理が必要となる可能性のある状況の例を以下に示す。
【例 1】

建物利用現況 用途別棟数の集計表

・建物が 1 棟のみや 2 棟のみの小地域【例 2】

建物利用現況

階数別棟数の集計表

・建物が 1 棟のみや 2 棟のみの小地域

解67

付属資料 4
1

改訂概要

概要
本付属資料は、「都市計画データ標準製品仕様書」（以下、「標準製品仕様書」と呼ぶ）の改定内容を解説する。

2

標準製品仕様書第 1.2 版の改訂概要

3D 都市モデル標準製品仕様書第 4.0 版と整合を図るため、以下の改訂を行った。

対象

改訂概要

1

全体

引用するi-URの版を3.1に更新した。

2

都市計画決定情報

立地適正化計画（都市機能誘導区域、居住誘導区域）を含めた。

3

都市計画決定情報

容積率、建ぺい率など、割合で記述する属性の値を、百分率に修正し、データ型をdoubleからintegerに
変更した。

４

都市計画決定情報

全ての区域について、品質に関する属性を必須とした。

5

都市計画基礎調査

土地利用現況調査及び建物利用現況については、品質に関する属性を必須とした。

6

都市計画基本図全ての地物について、品質に関する情報（公共測量成果の種類を含む）を必須とした。

7

都市計画基本図

交通施設（歩道、分離帯）は、tran:Roadを使用して記述するよう変更した。

8

全体

主題属性が不明な場合の不明値の取り扱いを、基本的なデータ型ごとに追記した。

９

都市計画決定情報、都市計画基礎調査コード型の属性を追加できるコード型拡張属性を追加した。

10

全体

誤記の修正。

対象モデル

全体

番号

対象地物

ー

対象属性・関連ー

改定概要

3D都市モデル標準製品仕様書の改訂に伴い、引用するi-URのXMlSchemaの版がi-UR 3.1に更新されたため、都市計画データ標準製品仕様書も更新した。

対象ドキュメント
標準製品仕様書

第１．１版

１．４

第1.2版

i-UR 3.0

その他

1i-UR 3.1

XMLSchemaのURL：
https://www.geospatial.jp/iur/schemas/uro/3.1/urbanObject.xsd
https://www.geospatial.jp/iur/schemas/urf/3.1/urbanFunction.xsd
https://www.geospatial.jp/iur/schemas/urg/3.1/statisticalGrid.xsd

解68対象モデル

都市計画決定情報

番号

２

対象地物

都市機能誘導区域、居住誘導区域

対象属性・関連ー

改定概要

3D都市モデル標準製品仕様書の改訂に伴い、立地適正化計画に関する地物型が都市計画決定情報モデルに追加されたため、都市計画データ標準製品仕様書においても、都市計画決定情報モデルに移動する。

対象ドキュメント
標準製品仕様書４．４．２（２０）、４．４．３（１３）

第１．１版

第1.2版

都市計画基礎調査情報モデルに定義

都市計画決定情報モデルに定義_Feature«FeatureType»core::_CityObject«FeatureType»+lod1MultiSurface

urf::_UrbanFunction«DataType»
urf::Boundary+boundary0..*«FeatureType»
urf::Zone_AbstractGeometricAggregate

0..1«Type»
gml::MultiSurface«FeatureType»
urf::ThreeDimensionalExtent+threeDimensionalExtent
0..*«FeatureType»
urf::DistrictsAndZones«FeatureType»

urf::_AbstractDistrictPlan«FeatureType»
urf::AreaClassification«FeatureType»
urf::QuasiUrbanPlanningArea«FeatureType»
urf::ProjectPromotionArea«FeatureType»
urf::UrbanFacility«FeatureType»urf::
UnusedLandUsePromotionArea«FeatureType»
urf::UrbanPlanningArea«FeatureType»
urf::ResidenceAttractionArea«FeatureType»
urf::UrbanDevelopmentProject«FeatureType»
urf::UrbanFunctionAttractionArea«FeatureType»
urf::ScheduledAreaForUrbanDevelopmentProject«FeatureType»urf::
UrbanDisasterRecoveryPromotionArea

その他

都市機能誘導区域：urf:UrbanFunctionAttractionArea
居住誘導区域：urf:ResidenceAttractionArea

対象モデル

都市計画決定情報モデル

対象地物

ー

対象属性・関連割合を表す属性（建蔽率、容積率、緑化率）

改定概要

建ぺい率等、割合を表す属性の値は、標準製品仕様では全体を1とした場合の値として定義していた。
一方、都市計画図書では百分率で表現されており、自治体が保有するGISデータの属性も、百分率で作成されている。
原典資料と一致しているほうが分かりやすいため、百分率に変更する。

番号3

対象ドキュメント
標準製品仕様書

4.４.２

第１．１版

第1.2版

属性の型 xs:double （実数）

属性の型 xs:integer （整数）

属性の定義（建ぺい率の例）

属性の定義（建ぺい率の例）

建蔽率（敷地面積に対する建築面積の割合）。全体を「1」とする割合で記述する。

建蔽率（敷地面積に対する建築面積の割合）。全体を「100」とする割合（百分率）で記述する。単位は％。

その他

対象となる属性
建ぺい率、容積率、緑化率、間口率
対象となる地物
用途地域、高層住居誘導地区、高度利用地区、特定街区、都市再生特別地区、居住環境向上用途誘導地区、特定用途誘導
地区、特定防災街区整備地区、風致地区、臨港地区、緑化地域、一団地の住宅施設、一団地の官公庁施設、流通業務団地、一団地の津波防災拠点市街地形成施設、一団地の復興再生拠点市街地形成施設、一団地の復興拠点市街地形成施設、一団地の都市安全確保拠点施設、市街地改造事業、地区整備計画に定められる地区
ただし、都市計画調査の「地価の状況（urf:LandPrice）は、原典資料となる国土数値情報が実数型のため、変更しない。

解69

対象モデル

都市計画決定情報モデル

番号

4

対象地物

全て

対象属性・関連

dataQualityAttribute

改定概要

都市計画決定情報モデルの各区域については、品質管理のための属性（uro:DataQualityAttribute）を運用上必須とする。

対象ドキュメント
標準製品仕様書

第１.１版

4.４．２（19）、４．４．３

改定後

記載なし

その他

都市計画決定情報モデルは全てLOD1であるため、geometrySrcDescLod1を用いて使用した原典資料の種類を記述する。

補足図

データ品質属性（uro:DataQualityAttribute）

番号

geometrySrcDescLod0, geometrySrcDescLod1,
geometrySrcDescLod2, geometrySrcDescLod3,
geometrySrcDescLod4,• LOD別に、幾何オブジェクトの作成に使用した原典資料を記載するための属性。
• 都市計画決定情報モデルは全てLOD1であるため、geometrySrcDescLod1を用いて使用した原典資料の種類を記述する。
※ geometrySrcDescLod1は必須となっているため、作成しないモデルの場合は、未作成を表す“999”を選択する。
• geometrySrcDescLod2-4は使用しない。
• 主題属性の作成に使用した原典資料の種類を選択する。
• 都市計画決定情報モデルの場合は、都市計画図書が基本となる。
• 主題属性を作成しない場合は、省略する。
• 都市計画データの場合は、テクスチャの付与及びLOD２以上のデータ作成や箱モデルのLOD1作成は行わないた
め、以下の属性は省略する。

解

70

４

対象モデル

都市計画基礎調査情報モデル

番号

５

対象地物

bldg:Building、luse:LandUse

対象属性・関連[接頭辞]DataQualityAttribute

改定概要

建物利用現況及び土地利用現況については、品質管理のための属性（uro:DataQualityAttribute）を運用上必須とする。
建物利用現況については、公共測量成果（例：基本図）を使用している場合は、公共測量成果の種類を示す“uro:PublicSurveyDataQualityAttribute）も作成する。

対象ドキュメント
標準製品仕様書4.３.２（１） ６）、１４）

第１.１版

改定後

記載なし

その他

各データ型の解説は、４の補足図及び５の補足図を参照。
建物利用現況及び土地利用現況は、3D都市モデルの作成の原典資料として使用する場合があるため、品質属性を必須とする。
建物利用現況の場合は、geometrySrcDescLod0、土地利用現況の場合は、geometrySrcDescLod1を用いて使用した原典資料の種類を記述する。

補足図

公共測量データ品質属性（uro:PublicSurveyDataQualityAttribute）

番号５

公共測量成果を使用しない場合は、作成しない。

srcScaleLod0,
srcScaleLod1, sｒｃScaleLod2,
srcScaleLod3, srcScaleLod4
原典資料の地図情報レベルを、LOD別に記載するための属性。
都市計画基本図の場合は、“１”（地図情報レベル2500）が基本となる。
ハイブリッドで数値地形図を作成している場合は、道路縁は“3”（地図情報レベル500）や建物外形は“2”（地図情報レベル
1000）のように、地物によって変わる。
publicSurveyDescLod０,
publicSurveyDescLod1,publicSurveyDescLod２,
publicSurveyDescLod３,publicSurveyDescLod4• 公共測量成果の具体的な種類を選択する。
• 例：空中写真測量の場合は、“003”

解71対象モデル

都市計画基本図モデル

番号

６

対象地物

全て

対象属性・関連[接頭辞]DataQualityAttribute

改定概要

品質管理のための属性（uro:DataQualityAttribute）を必須とする。
都市計画基本図は公共測量成果となるため、公共測量成果の種類を示す“uro:PublicSurveyDataQualityAttribute）
も作成する。

対象ドキュメント
標準製品仕様書

第１.１版

4.４.２

改定後

記載なし

その他

都市計画基本図モデルは、LOD0となるが、geometrySrcDescLod1は必須となっているため、未作成を表す“999”を選択する。

対象モデル

都市計画基本図モデル

対象地物

tran:Road

対象属性・関連ー

改定概要

交通施設の歩道（分類コード：2213）及び分離帯（分類コード：２２２６）に対応するCityGML又はi-URの地物を、
tran:Roadに修正

番号
対象ドキュメント
標準製品仕様書

第１.１版

その他

７

4.２．１(2)

改定後

都市計画基本図はLOD0に対応するため、3D都市モデルにおいてLOD2以上で登場するtran:TrafficAreaやtran:AuxiliaryTrafficAreaを使用しないよう、修正。

解72

対象モデル

すべて

番号

対象地物

すべて

対象属性・関連

すべての主題属性

改定概要

主題属性が不明な場合の不明値の取り扱いを、基本的なデータ型ごとに追記した。
作成対象とする主題属性の値が不明な場合は、不明値を入力する。

８

対象ドキュメント
標準製品仕様書

第3.５版

４．１．６

改定後

日付型及び年型のみ記載

属性の型
xs:string
gml:CodeType

不明な場合の対応
Nullと入力する。（半角英文字）
不明を示すコードを入力する。

xs:boolean→不明なコードがない場合は、データを作成しない。
データを作成しない。

xs:integer
xs:double
xs:date-9999と入力する。
-9999と入力する。
年月日が分からない場合は、0001-01-01と入力する。
年のみ分かる場合はYYYY-01-01とし、年月のみ分かる場合
はYYYY-MM-01とする。

xs:gYear
xs:nonNegativeInteger

0001と入力する。
9999と入力する。

gml:MeasureType,
gml:LengthType

値は-9999とし、単位は属性ごとに指定された単位を入力する。

gml:MeatureOrNullListType

Null値の定義域にunknownを指定する。

xs:anyURI

Nullと入力する。（半角英文字）

その他

データがない場合に、作成対象ではないのか、不明なのか、あるいはエラーで欠落しているのかが分からないため、不明な場
合には不明値を入力することを原則とする。（作成対象ではない場合には、不明値の入力は不要）

対象モデル

都市計画基礎調査情報モデル、都市計画決定情報モデル

対象地物

全て

対象属性・関連

uro:KeyValuePairAttribute

改定概要

コード型の属性を追加できるよう、uro:KeyValuePairAttributeへの関連を追加した。

番号
対象ドキュメント
標準製品仕様書

第１.１版

その他

4.3, 4.4

改定後

コード型の属性を追加したい場合にのみ使用するデータ型である。
また、コード型の属性を追加する方法を、解説書の拡張製品仕様書の作成手順において追記した。

解

73

９

対象モデル

都市計画基礎調査情報モデル

対象地物

urf:Zone

対象属性・関連ー

改定概要

標準製品仕様書に定義されていない都市計画の区域を記述したい場合に使用するクラスを、gen:GenericCityObjectからurf:Zoneに変更した。

番号10

対象ドキュメント
標準製品仕様書4．4.3（１５） １） （解説書 4.2.4）

第１.１版

改定後
_CityObject«FeatureType»

urf::_UrbanFunction
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

class: gml::CodeType [0..1]
function: gml::CodeType [0..*]usage: gml::CodeType [0..*]validFrom: xs::date [0..1]
validFromType: gml::CodeType [0..1]
enactmentFiscalYear: xs::gYear [0..1]
validTo: xs::date [0..1]
validToType: gml::CodeType [0..1]
expirationFiscalYear: xs::gYear [0..1]
legalGrounds: xs::string [0..1]
custodian: xs::string [0..1]
notificationNumber: xs::string [0..1]
finalNotificationNumber: xs::string [0..1]
finalNotificationDate: xs::date [0..1]
urbanPlanType: gml::CodeType [0..1]
areaClassificationType: gml::CodeType [0..1]
nominalArea: gml::MeasureType [0..1]
prefecture: gml::CodeType [0..1]
city: gml::CodeType [0..1]
reference: xs::anyURI [0..1]
reason: gml:StringOrRefType [0..1]
note: gml:StringOrRefType [0..1]
surveyYear: xs::gYear [0..1]«FeatureType»
urf::Zone+

その他

location: xs::string [0..1]

urf:Zoneは、「法律で定められた区域」を記述するための地物型であり、告示日や告示番号などの属性をもっている。

解74

誤記の修正のうち、データ構造に関わるものを以下に示す。
対象モデル

都市計画基礎調査モデル

番号

1１－①

対象地物

urf:LandUseConversion

対象属性・関連

lod0MultiPoint

改定概要

都市計画基礎調査実施要領では、点で取得することとなっているが、UMLクラス図では面を参照していたため、点を参照す
るよう修正。

対象ドキュメント
標準製品仕様書4.3．2(1) 9), 10)

第１.１版

改定後

lod1MultiSurface
lod0MultiPoint

その他

C0305 農地転用状況、C0306 林地転用状況

対象モデル

都市計画基礎調査モデル

対象地物

urf:LandUseConversion

対象属性・関連

lod0MultiPoint

改定概要

都市計画基礎調査実施要領では、点で取得することとなっているが、UMLクラス図では面を参照していたため、点を参照す
るよう修正。

番号
対象ドキュメント
標準製品仕様書4.3．2(1) 9), 10)

第１.１版

改定後

lod1MultiSurface
lod0MultiPoint

その他

1１－①

C0305 農地転用状況、C0306 林地転用状況

解75

対象モデル

都市計画基礎調査モデル

番号

対象地物

ー

対象属性・関連ー

改定概要

UMLクラス図とXML Schemaに不整合があったため、修正した。

１1－②

対象ドキュメント
標準製品仕様書ー（XMLSchemaの修正）

改定後
1

urf:LandPrice及びurf:UrbanFacilityStatusは、UMLクラス図ではurf:UrbanFunctionを継承しているが、XMLSchemaでは継承する記述となっていなかったため、XML Schemaを修正した。

2

UMLクラス図urf:EconomicActivityTypeTypeの属性（事業所数）numberOfOfficesの記述が、XMLSchemaでは
numberOfOfficersとなっていたが、UMLクラス図を正としてXML Schemaを修正した。

3

UMLクラス図のurf:AgriculturalDevelopmentType（農林漁業関連施策）の記述が、 XMLSchemaでは
urf:AgriculturalDevelopmentProjectTypeとなっていたが、XML Schemaを正として、UMLクラス図を修正した。

4

UMLクラス図のurf:PublicTransitFacility の属性urf:companyType及びurf:facilityTypeのデータ型はgml:CodeTypeであるが、XML Schemaでは、xs:stringになっていたため、XML Schemaを修正した。

5

UMLクラス図のurf:NewHousingの属性urf:mainPurposeはXML Schemaでは、urf:purposeとなっていたため、XML Schema
を正として、UMLクラス図を修正した。

６

UMLクラス図のurf:LandPriceの属性urf:storeysAboveGround及びurf:storeysBelowGroundのデータ型はxs:integerとなっていたが、XML Schemaでは、ｘｓ：nonNegativeIntegerとなっていたため、XML Schemaを正として、UMLクラス図を修正した。

７

UMLクラス図のurg:StatusOfSightseeingのクラス名が、XML Schemaではurg:StatusOfSiteseeingになっていたため、XML Schemaを修正した。

その他

解

76

参考文献
1.

国土交通省国土地理院, 地理空間データ製品仕様書作成マニュアル, 2019 年 11 月,
https://psgsv2.gsi.go.jp/koukyou/download/ps_manual.pdf

2.

国土交通省都市局, 3D 都市モデルの導入ガイダンス, 2024 年 3 月,
https://www.mlit.go.jp/plateau/libraries/handbooks/

3.

国土交通省都市局, 都市計画情報のデジタル化・オープン化ガイダンス, 2023 年 6 月,
https://www.mlit.go.jp/toshi/tosiko/toshi_tosiko_tk_000187.html

4.

国土交通省国土地理院, メタデータの作成について,
https://psgsv.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_meta.html

5.

国土交通省国土地理院,

地理空間データ製品仕様書作成マニュアル JPGIS 2014 版, 2020 年 1 月,

https://psgsv2.gsi.go.jp/koukyou/public/seihinsiyou/seihinsiyou_index.html
6.

内閣府地方創生推進事務局, i-都市再生ガイダンス,
https://www.chisou.go.jp/tiiki/toshisaisei/itoshisaisei/guidance.html

7.

内閣府地方創生推進事務局, i-都市再生技術仕様案,
https://www.chisou.go.jp/tiiki/toshisaisei/itoshisaisei/iur/index.html

8.

国土交通省都市局,利用・提供の観点を踏まえた都市計画基礎調査実施要領及び都市計画基礎調査情報の利用・提供ガイドラインに係る技術資料（第２版）,

2021 年 5 月,

https://www.mlit.go.jp/toshi/city_plan/toshi_city_plan_tk_000049.html

解77