Intergovernmental Committee on Surveying and Mapping

Submission Date: 18/03/2022

Approval Date: <yyyy-mm-dd>

Publication Date: <yyyy-mm-dd>

External identifier of this document: https://linked.data.gov.au/def/csdm/2022

Internal reference number of this document: 21-CAD

Version: 1.0

Category: ICSM Implementation Specification

Editors: Rob Atkinson

Contributors: Andrew Hunter, Byron Cochrane, Jeff Needham, Adrian White, Murray Dolling, Roger Fraser, Nicholas J. Car, Matthew Purss & Simon Opper

ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions

Copyright notice

[TBD]

Warning

This document is a candidate for an Australia/New Zealand standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

This model will undergo implementation testing and may be submitted for consideration as a candidate international standard. It is presented in the form of an OGC specification in order to facilitate this option.

Document type:

Document subtype: Conceptual Model

Document stage: Submitted to ICSM for consideration

Document language: English

License Agreement

This specification is released under the Creative Commons Attribution 4.0 International (CC BY 4.0) as per other Land Information New Zealand data policy.

Full details for this license are available at https://creativecommons.org/licenses/by/4.0/

1. Preamble

1.1. Standard Overview

1.1.1. Goal

This the first complete draft of ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions

Because the underlying approach is based on an analysis of current and emerging standards in the geospatial and broader online technology sectors, this document will introduce a series of key "patterns" that have known and demonstrable implementation pathways. The model provides a formal conceptual model and linked logical model to meet requirements gathered during the analysis phase, using these key patterns.

The next steps will include development of candidate encodings and implementation testing. It is intended the approach and the specific patterns used will provide a basis for a clear, future-proof and internationally viable implementation pathway in a vendor-neutral form.

This specification also includes some early examples of a range of information intended to support application of this model in specific jurisdictions:

  • examples based on current practices in different encodings used by differed jurisdictions

  • cross-referencing requirements with text clauses in jurisdictional regulations

  • cross-referencing model concepts and terminology with terminology used within different jurisdictions.

1.1.2. Audience

{statuswarning}

The audience for this specification includes:

  • surveying software (client) application vendors, including business, architecture and developer roles.

  • cadastral system implementers

  • standards developers and reviewers

  • data modellers in related domains (e.g. Digital Twins, BIM etc)

  • jurisdictions seeking to evaluate and if necessary define updates to establish the regulatory foundation for implementation of a 3D Cadastre.

Different sections of this document will apply to different audiences. The specification will provide hyper-links between different viewpoints where applicable.

It is expected that different audiences can focus on different aspects. Feedback on ease of navigation to areas of relevance is welcome

1.1.3. Standard’s Parts

The ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions is made of multiple parts which are:

  • a specification document

    • this document

  • data models

    • expressed using a canonical language (ontologies) for not just Cadastral elements but Use Cases and other things too

  • data validators

    • to validate instance data against the data models

  • examples

    • examples of data model elements. Both in the Specification and stand-alone

This document has the role of specification and documents the normative, machine-readable data models.

1.2. Submitting organizations

The following organizations have submitted this Implementation Specification to ICSM:

  1. Land Information New Zealand on behalf of the ICSM Cadastral Working Group

1.3. Submission contact points

All questions regarding this submission should be directed to the submitters:

Organisation/Company

Contact

email

Land Information New Zealand

Jeff Needham

JNeedham@linz.govt.nz

1.4. Revision history

Date

Release

Author

Paragraph modified

Description

24 Nov. 2021

Discussion Draft

Rob Atkinson

All

Preparation of contextual material for review with potential implementing stakeholders

1 March 2022

Draft for review

Rob Atkinson

All

Project team review

18 March 2022

Final draft submitted

Rob Atkinson

1.5. Relation to the OGC® Abstract Specification

This document structure aligns with the OGC® Abstract Specification [MODSPEC].

Where appropriate the key patterns used to define the model are based on ISO19100 series and equivalent OGC® Abstract Specifications.

Implementation patterns are based on OGC standards where relevant, which in turn have documented relationships with OGC® Abstract Specifications.

2. Scope

This document is the specification part of an implementation standard issued by the Australia and New Zealand Intergovernmental Committee on Surveying and Mapping (ICSM). It is authored by the ICSM jurisdictions (States & Territories of Australia and New Zealand).

The ICSM 3D Cadastral Survey Data Model and Exchange Project (3DCSDMP) developed a new standard to be available across Australia and New Zealand for exchanging digital cadastral survey information between the survey industry and government land administration agencies/land registries. The project was established by ICSM with support from the Spatial Information Council (ANZLIC).

Combined with complementary and concurrent developments in 3D capability for modelling the built and natural environments, cadastral surveyors will be increasingly challenged to provide 3D models of land boundaries, and this standard allows them to meet this challenge.

Also, the Cadastre 2034 strategy developed by ICSM plans a digital future for the cadastre in Australia. That future recognises the role of the cadastre in enabling spatial digital twins, smart 3D cities, integrated planning, and utility management.

These drivers are pushing the modernisation of cadastral systems, and this standard will enable the fully digital exchange of cadastral information, and particularly enable surveyors to transition from lodging paper or PDF plans to fully digital data, including 3D elements.

ICSM will seek Open Geospatial Consortium adoption of this standard to facilitate widespread adoption within software used by cadastral surveyors for preparing the survey plans and datasets required by ICSM jurisdictions.

3. Related Domains

Analysis suggests the scope of this model to lie in the intersection of Surveying, Infrastructure and Land Administration domains. This can be illustrated thus:

Domain Context
Figure 1. Cadastral Domain in context

The key point here is that it is expected that Survey concerns are a superset of the survey concerns related to infrastructure. At this stage further engagement with these standards is proposed on the basis of establishing common spatial requirements across a wider set of related domains (key Patterns) - which would provide opportunities to better align these different models.

Note that neither LADM (ISO 19152 - Land Administration Data Model) nor LandInfra Conceptual Model explicitly identify how they relate to the Topology aspects of ISO 19107 - Geometry in a way which provides useful guidance on implementation.

The key conformance class "Geometry Primitives" in this specification is a candidate for a common implementation pattern for 3D Features and topology requirements that may be factored out into a stand-alone specification to assist in future alignment and specification evolution.

Table 1. Comparison Matrix
Standard Name BSi IFC (IFC4 ISO10303) ISO LADM (ISO19152:2012) - OGC LandInfra (OGC 15-111r1) LandXML (landxml.org) - ICSM ePlan (ICSM ePlan v10) ISO GML (ISO19136:2020) OGC CityGML (OGC 20-010) GeoJSON (IETF RFC 7946) GeoPackage (OGC 12-128r18) Geographic Information Spatial Schema (ISO19107:2019)

Primary Users

BIM & AEC

Land Admins

Asset Mgrs, Engineers, Surveyors

Survey Engineering

Cadastral Surveyors

Geographic information modellers

3D City modellers

Web developers

GIS

Geographic information modellers

Project Gov’

Strong

Strong

Strong

Weak

Medium

Strong

Strong

Strong

Strong

Strong

CadastreFeatures

Partial

Yes

Yes

Yes

Yes

Yes*

No

No

Yes?

No

Cad. FeatSupport

No

?

Yes

Yes

Yes

Yes*

No

?

No

N/A

Cad.Evidence

No

No

Yes

Yes

Yes

Yes*

No

No

Yes

No

Evid. Support

No

?

Yes

Yes

Yes

Yes*

No

No

Yes

N/A

Features (ISO 19109)

No

?

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Features Tool Support

N/A

?

Yes (Leica, FME, etc)

?

?

Simple Features only (FME, GDAL)

?

Yes (Various web tools)

Yes (SQLite)

N/A

Simple Geom

Yes(ISO10303)

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Complex Geom

Yes(ISO10303)

Yes

Yes

Partial

Partial

Yes

Yes

No

Yes

Yes

Simple Geom Tool Support

Yes

Yes (PostGIS, etc.)

Yes (Leica)

Yes (12d, FME, etc.)

Yes (12d, FME, etc.)

Yes

Yes

Yes

Yes (Most GIS)

N/A

Complex Geom Sup

Yes (ISO10303)

?

Yes (Leica)

?

?

Yes (FME, GDAL)

?

No

?

N/A

2D Topology

Yes(ISO10303)

?

Yes

Yes?

Yes?

Yes

Yes

No

Yes

Yes

3D Topology

Yes(ISO10303)

?

No

No?

No?

Yes

No

No

No

Yes

2D TopoSupport

Yes

?

Yes (Leica)

YesLimited

YesLimited

Yes (FME)

Yes (FME)

N/A

Yes

N/A

3D TopoSupport

Yes

?

?

No

?

?

?

No

No

N/A

Code Lists

Enums

Yes *

Yes *

Yes

Yes

Yes *

Yes *

Yes

Yes *

Yes

CRS

Many

Many

Many

Many

Many

Many

Many

1

Many

Many

Metadata

Extensive, inconsistent

ISO 19115

ISO 19115

Basic

Basic

ISO 19115

Basic

STAC, OAPIRec

ISO 19115

N/A

Extensionsallowed

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

N/A

Extension Support

Medium

Low

Low

Medium

Low

Medium

Medium

Broad

Low

N/A

4. Conformance

The Domain Model of this specification is composed of a number of Packages which represent Conformance Classes according to the OGC Modular Specification.

This allows for implementers of this specification to describe which particular modules they implement - i.e. that their implementation conforms to.

This specification is primarily a Conceptual Model - meaning that the conformance target of this model is an implementation specification , which is implicitly based on a logical model . These implementation specifications use well known patterns to implement abstract models - which may be viewed as the best options for reusable components of conceptual models , notwithstanding the potential imposition of logical modelling concerns such as metadata aspects of classes.

Thus for example, the key abstract model ISO-19107 (Geometry) may be partially implemented by multiple encodings (e.g. GML and GeoSPARQL). Each encoding using the metamodels of its underlying technology with a logical model of the form imposed be that technology. Thus GML is based on XML schema, which imposes attribute ordering, assumptions that properties are scoped to classes, rigid monomorphic class inheritance and the complexity of either ad-hoc approaches or use of another specification to handle relationships (Xlink) etc. GeoSPARQL uses OWL (Web Ontology Language) with its inherent polymorphism and assumptions. Other encoding technologies such JSON impose their own approaches.

Logical models such as BIM IFC [ref] also illustrate this principle, with the notable example of ifcOWL.

Various modelling languages exist with different advantages and disadvantages. The split between conceptual and logical models in UML is, however, not easily expressed within UML, and inconsistently implemented in practice. On the other hand, the RDF (Resource Descriptor Framework) underpinnings of OWL allow relationships to be readily modelled across different layers of abstraction. In general it is possible to convert models expressed in most other languages into a combination of OWL and other RDF axioms. It then becomes possible to map between related models irrespective of the original modelling language (e.g. ISO using UML, IFC using EXPRESS, LandXML using XSD. )

Another RDF language, SHACL (the Shapes Constraint Language), allows imposition of a logical model naturally onto a largely unconstrained conceptual model. The biggest advantage, however, of using the semantic class model as the modelling paradigm is that it is expressed in a form that allows direct implementation within RDF, in a form that can be validated using SHACL, with a canonical logical model based on the implementation patterns available for components based on established conceptual models. Thus the model can be effectively illustrated and tested by the use of canonical examples . Conversion of these to different implementation models can be undertaken to test aspects of the model, and can be used as conformance test cases for future implementation models based on this model.

The conceptual model is defined as a semantic model using OWL, however UML may be used view this model.

For each logical model implementing this specification one or more implementation encodings may be defined. These encodings are out of scope for this specification, however examples are provided showing how different encodings might realise each of the elements of the conceptual model. Each Conformance Classes in this specification has a SHACL validator for instance data encoded using the canonical logical model , om any valid RDF serialisation encoding option.

Conformance to this specification may therefore be determined by mapping and implementation encodings to the canonical logical model and validating the results using the SHACL validators for instance data.

Profiles of these implementation models may be defined to meet the needs of specific jurisdictions and interoperability with specific systems. Profiles may be described as constraints against specific encodings using the technologies most suitable for the encoding platform.

5. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  • This section to be completed before submission as OGC standard . Refer to section 9 "Key Patterns" for discussion of the standard models upon which this model is based.

6. Terms and Definitions

The terms and definitions given in the above references apply in this document, as well as those reproduced or created in this section.

6.1. Conceptual Model

The model that defines the basis for identifying objects and their inherent relationships with other objects.

c.f. "model that defines concepts of a universe of discourse" [ISO 19101]

6.2. Logical Model

Establishing a definition of a logical model , and the tendency of conceptual models to be too closely coupled to logical models is a currently an active area of discussion within the OGC - so this definition is used in the interim for the purposes of this specification

The expression of the sets of properties (attributes and relationships) required to describe features in a conceptual model for the purposes of a specific application. Logical models will typical be constrained around different implementation patterns supported by the meta-models for target encodings.

For example a logical model intended to be encoded as a CSV file will be constrained to a vector of scalar valued attributes (with the potential for constraints around datatype encoding using micro-formats - such as string formats for geometries.)

6.3. Canonical Logical Model

The expression of the conceptual model using well known ("canonical") forms of the underlying abstractions that form the basis of a conceptual model. The canonical logical model is assumed to be "lossless" - that is expressive of the conceptual model within the limitations of the underlying component models. Thus the canonical logical model can act as a proxy for the conceptual model itself in the case where the conceptual schema language is not consistent across the normative definitions of the conceptual model components.

This is a form of conceptual schema ("formal description of a conceptual model [ISO 19101]), however this definition takes into account the possibility that this form is directly implementable as an application schema ("conceptual schema for data required by one or more applications [ISO 19101")

6.4. Profile

A specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications.

See description of profiles in the Patterns section.

7. Conventions

This document provides a automatically generated view of the normative ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions specification.

It introduces a number of explanatory mechanisms, notably:

  • Canonical Examples - "well formed" snippets of code that can be directly validated using the canonical logical model SHACL components.

  • Implementation Examples - snippets of code or diagrams that illustrate implementations in some format. These formats may be legacy, alternative standards or potentially future options.

7.1. Identifiers

The normative provisions in this standard are denoted by the IRI [TBD]

All requirements and conformance tests that appear in this document are denoted by partial IRIs which are relative to this base.

8. Introduction

The 3D Cadastral survey conceptual model specification describes the concepts and fundamental relationships between information elements required to exchange 3D survey data between surveyors and cadastral database systems.

The domain of Cadastral Survey overlaps with other key related domains which have their own special needs and approaches. This model is intended to be reusable by any related domain as part of a more extensive application-specific composite model. As such it defines reusable modules to support partial integration and clearly specifies its dependencies on underlying standards.

Implementations of this conceptual model (i.e. the conformance target ) will be logical models which describe structural implementation patterns and encoding specifications which define exactly how these may be implemented.

The model itself is described using a canonical logical model in a form that best supports modularity as well integration of different levels of abstraction from meta-models through to implementation examples. Please see Annex D for the details and rationale for the specific form of expression. This form of model is not expected to limit implementation options, but does provide an easily-testable "out of the box" encoding option. There is no intention to impose a specific encoding implicit in this choice of modelling expression.

8.1. Model Requirements

The details of the ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions are driven by an extensive co-design process within the ICSM jurisdictions to define requirements - in the forms of Use Cases and specific pre-conditions (expectations about the data model content) for data exchange for different aspects of cadastral survey data. This work was supported by analysis of available and emerging standards. The separate Use Cases can be combined into an overarching set of requirements, but help reflect the potential for modularity in the model - the potential to implement a subset of total requirements for a given application.

There are a few additional "meta requirements" that dictate the form of the model however:

  • It should be possible to define and express the compatibility of 3D constructs with related application domains

  • 3D geom

  • It should be possible to extend the model to support observation of additional aspects of features required for specific applications

  • It should be possible include additional observation methods and result forms in future *

8.2. Standard structure

This specification document provides a series of sections designed to aid in interpreting the form of the model documentation, which is derived directly and automatically from the normative model components.

{statuswarning}

The key sections necessary in order understand to the model itself are:

Implementers may wish first to focus on

Annexes provide details of the established requirements, how these are known to relate to jurisdictional terminology and in detail examples and discussions on methodology.

8.3. Modelling framework

This specification document follows a modular design (based on the OGC Modular Specification policy [MODSPEC]). It comprises several different components in the form of conformance classes , whose requirements are expressed as formal models.

The [MODSPEC] provides for identification of a conformance target that can be tested via an abstract test suite . For a conceptual model the conformance target is an implementation - i.e. a logical model with or without a specific encoding .

It is described using a combination of standard conceptual models for common patterns and the ontology representations of key ISO standards for spatial concepts. This allows for a common and flexible representation of the concepts in a single environment and does not preclude an equivalent UML version of the model.

The Ontology representation provides more natural environment for mapping between conceptual, logical and implementation models, and crucially provides a canonical logical model for a "lossless" data representation that can be used to test implementations of the data model. It is notable that BuildingSmart International BIM/IFC provide ifcOWL with "the same status as the EXPRESS and XSD schemas of IFC".

There is nevertheless potential for a ISO19103 compliant UML model for one or more application schema , each describing a logical model for implementation. Such schemas could be developed in conjunction with a GML schema encoding option if this is deemed to be a viable implementation strategy. Past experience in ISO and OGC in developing such models is that developing a UML model without a testing strategy that includes generation of GM schemas automatically is unlikely to result in a high quality machine-readable version of a model.

Using the canonical logical model approach based on OWL, each conformance class of the model provides a concrete test suite using the SHACL (Shapes Constraint Language) that can be used to validate instance data encoded in RDF. This form of data is used to create illustrative canonical examples and linked to each model elements. These examples however may be expressed in multiple encodings - these, and other examples of current practice are linked as implementation examples , documented with the underlying implementation standard used.

Implementation examples are not normative - they are there to provide illustration of how the model concepts have been implemented in existing or related systems, in order to provide additional clarity of the semantics of the model element for those familiar with these implementations.

In future it would be relatively easy to extend the modelling approach to define one or more normative implementations and mappings to support migration from legacy or related data formats to a normative encoding. This could also be used to define translations between aspects of the model and other platforms - such as BIM/IFC.

8.4. Testing

Testing a conceptual model has traditionally been difficult, and abstract test suites typically make a general statement about implementations including the conceptual elements.

The methodology used to generate this specification has introduced a testing framework with a range of additional testing opportunities:

  • collaborative (co-design with subject matter experts) and formal documentation of requirements as annotations in the modelling language.

  • use of a canonical logical model that can directly express implementation via canonical examples .

  • conversion of model to validation tools to test canonical examples for completeness and correctness (testing the testing…​)

  • mapping key concepts to existing and potential future implementation examples.

  • review and mapping of the model to existing regulatory frameworks.

  • cross-referencing terminology to existing usages of similar terminology.

  • assessment of testing coverage of the model against different testing strategies.

8.5. Relationship to other models

This is an informal overview of the relationships between ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions and related models.

model context
Figure 2. Package organisation and relationships to external standards

8.5.1. ISO 16739-1:2018 (BIM/IFC)

"IFC is a standardized, digital description of the built asset industry."

The compatibility of the 3D Cadastre model with the extensively used IFC standard has been a prime consideration. The testing framework for the 3D Cadastre includes translation of canonical examples into IFC and CityGML equivalent forms.

Although the scope and requirements for IFC and Cadastre are very different (see Annex ) there are a number of key areas where compatibility can be supported:

  • testing translation of 3D solid geometry elements into IFC "Spaces"

  • use of IFC models to describe Occupation details of surveyed boundaries

  • visualisation of 3D cadastral concepts with the aid of IFC scenes

IFC does not readily support the identified cadastre domain requirements for wider range of observations about survey points and vectors and metadata around survey processes, but this compatibility provides for ready integration of data between design and survey spaces.

Testing will be undertaken over the final stages of the ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions development project to validate that 3D geometry and topology concepts can be represented in both the proposed profile of ISO 19107 (GeoSPARQL 1.2) as well as IFC through automated translations. A full analysis of the degree of overlap between IFC and this document will be provided after this testing is complete.

8.5.2. CityGML

To be completed. It is noted CityGML does not support survey observation nor explicit topological concerns, however it is expected that the proposed 3D Solid Geometry profile would support the implicit profile of ISO19107 used in CityGML.

More work is required to determine the potential capability, future pathway and relevance of CityJSON.

8.5.3. ISO 19152: "Land Administration Data Model" (LADM)

LADM is an ISO model for Land Administration. LADM encompasses the objects in a Cadastral System - but not the process of survey or the attributes of those objects.

As "LandInfra Standard addresses a subset of LADM", so the cadastral survey domain will overlap through a specific type of land unit. This overlap is best expressed as an equivalence mapping in the conceptual model, since LADM is at a high level of abstraction. The 3D Cadastral logical model and encodings become potential implementations of LADM. [Byron to comment on conformance target of LADM]

8.5.4. LandInfra

Note that the relationship between the 3D Cadastre Model and LandInfra in Figure 2 is highlighted as an area for further exploration and negotiation.

The Land and Infrastructure Conceptual Model is an OGC specification with the declared scope: "land and civil engineering infrastructure facilities".

Currently the Survey component of LandInfra is described as a subset of LandInfra, however it is probably more logical to think of LandInfra using a relevant subset of a Cadastral Model, since the infrastructure is just one application of survey and cadastre.

A discussion with the LandInfra authors regarding possible optimal refactoring of the LandInfra standard in a new version is proposed. Such a revision would hopefully adopt a more flexible, extensible and convenient approach to the implementation of ISO 19156 Observations and Measurements as proposed in this standard, and simplify its structure by removing much of the comparison with other approaches from the main specification.

A corollary of this is the relationship of LandInfra to specific domain models such as Pipeline ML, MUDDI etc - ideally a refactor of LandInfra to support linkages to specific domain models can be achieved at the same time as abstracting cadastral and survey elements into more easily reusable component models.

9. Key Patterns

We based this conceptual model for the ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions on a set of well-known conceptual models for which implementation patterns are available. The abstractions of these patterns provide a basis for consistency of approach across a range of similar requirements with the assurance of a direct pathway to at least one available implementation approach (and often several alternatives). They also establish patterns to extend the model and address specific implementation requirements.

Each pattern is described below to aid in interpreting the details of the model in the normative sections.

9.1. Pattern - Modular Components

Context - Consistent use of loosely coupled modular components creates a system that is easy to implement, use, maintain and extend.

Consider - A well-governed model should include reusable mechanisms that simplify and extend functionality across a wide range of implementations. Vocabularies and Codelist is one example of shared components.

Problem - The lack of shared components can lead to diverse and incompatible solutions. A component is just a generic term for any predefined object used across multiple applications. For components to be reusable, they must be standardised. This standardisation ensures that each component reliably delivers regardless of the context in which it is used. Think of modular components as Legos: interchangeable building blocks you can assemble into pages.

Loose coupling and high cohesion Monolithic design with high dependency between components often produces heavyweight solutions suited to a few environments. Cohesion often refers to how the elements of a module belong together. High cohesion prevents the propagation of errors distributed across the model.

Solution - Provide Modular components to create a flexible design with reusable components across many environments. Apply loose coupling and high cohesion to ensure the components are reusable by minimising the number of connections and dependencies between components.

Good modular design requires a sound governance regime. Many models fail over time due to the lack of proper governance of the model and its modules. Many Standards Development Organisations (SDOs) exist with the express purpose to maintain such standards, e.g. OGC, ISO, BSI. Other organisations exist that participate at a different level, such as maintaining localised code lists. These may be cross-government organisations such as ICSM or professional bodies such as FIG. Some organisations fill multiple roles. Standards maintenance is not an optional task - it will fall on someone. By default, it is the creator of the standard. Ignoring governance issues creates significant risks to a standard’s sustainability and its ability to provide the desired interoperability benefits.

To make components modular:

  • Standardised design: Structure and interface is predetermined and doesn’t vary by implementation.

  • Standardised, centralised code: Unique code should not be needed each time you reuse the component.

  • Controlled via system logic: Predefined behaviour should occur based on system rules, not content author discretion.

  • Customisable options: Localised rules can provide for functional options controllable via metadata or other configuration settings.

Use this pattern to achieve interoperability of components across the related applications in the domains. Make components available through reusable software libraries to ease model implementation across multiple solutions. Make available tools to validate that solutions developed produce conformant results.

Ensure that a stable body exists to govern each and any solution component. Where such a body does not exist, account for the cost and overhead of creating one. The rules of governance and methods by which one can participate should be clear and accessible to those using the standard.

9.2. Pattern - Conceptual Model

Context - A robust conceptual model, based on real-world use cases, is required to identify objects and their inherent relationships with other objects within a universe of discourse.

Consider - While Modular components is essential across all whole a data model, the whole must be expressed as a Conceptual Model

Problem - Within any business process, there are many ways to conceptualise the entities and relationships that comprise a process. The absence of a common conceptual model leads to a proliferation of ad-hoc approaches to common problems.

Solution - Develop a conceptual model through a collaborative and iterative process based on use cases derived from domain experts. Iteratively test, validate and improve the developing model with stakeholders. Through this robust process, determine the model parts and their relationships.

The resulting Conceptual Data Model is a diagram identifying the business concepts (entities) and the relationships between these concepts to gain, reflect, and document understanding of the organisation’s business, from a data perspective.

"It shows how the business world sees information. It suppresses non-critical details in order to emphasise business rules and user objects. It typically includes only significant entities which have business meaning, along with their relationships."

Entrust governance of this model to a Standards Development Organisation at as high a level as possible.

Consider next -

  • Ontological Modelling to formalise the structure of the model.

  • Vocabularies and Code-list to standardise teminologies.

  • Canonical Logical Model

  • Domain Compatibility

9.3. Pattern - Ontological Modelling

Context - Communicating the nature of a conceptual model in a precise manner requires the use of formal language. Of the available standard approaches, an Ontological approach provides the most flexibility.

Consider - This pattern provides a useful method of formally describing a Conceptual Model

Problem - When building a conceptual data model where the choice of implementation schemas and encodings is undecided, the modelling language needs to provide as much flexibility as possible to support multiple options while preserving commonality.

Many languages exist to describe data models. The Unified Modeling Language (UML) is one common language used by OGC and ISO TC211. EXPRESS is another commonly used in the BIM community. However, we have chosen an Ontological approach using the Web Ontology Language (OWL) for this project. An Ontology representation provides a more natural environment for mapping between conceptual, logical and implementation models and crucially provides a canonical logical model for a "lossless" data representation to test implementations of the data model. OWL provides a higher level of abstraction and openness than other options. Thus, it is easier to derive other models like UML and EXPRESS from OWL than the reverse. Furthermore, the native output of OWL being RDF (a linked data format) provides additional advantages. (See https://www.w3.org/RDF/advantages.html).

Solution - Use the ontological modelling language Web Ontology Language (OWL) to build the data model. OWL provides a high level of abstraction and openness, allowing for the derivation of implementation models.

Consider next -

  • Linked data Support

  • Flexible Domains of interoperability

Links -

9.4. Pattern - Feature / Geometry Distinction

Context - In a cadastral dataset, a feature, such as a parcel, may be spatially described in many ways. It may have point descriptions, 2D descriptions, volumetric descriptions, and others.

Problem - The distinction between a Feature and its geometry attribute(s) is a key pattern for describing the "real world" flexibly. Whilst early GIS applications may have tended to attach attributes to a geometry object this leads to ad-hoc approaches to unambiguously identifying the real-world features. Each application chose a different name and form for the feature identifier - illustrating the problems with modelling via logical models without an underlying conceptual model.

Solution - Using the General Feature Model defined in ISO 19109, Feature Type models are used to classify the representations of real-world things. Inherent in this is the identification of such features, which implicitly enables the declaration of relationships between instances of these types. Under this model, features may have an arbitrary number of attributes describing spatial aspects (geometries) or topologies. In practice, implementations are often optimised to support a specific form of spatial representation within the context of the application. Thus in 2D GIS systems, sets of cadastral parcels may be described by a series of polygons with a common set of business rules regarding the assumed vertical datum, coordinate systems, level of precisions etc. This doesn’t preclude other forms of representation, but logical data models are constrained and simplified by these assumptions of homogeneity.

When features are indistinct from their geometry in the data model, it is difficult to record more than one spatial definition for that feature. Therefore, neither the conceptual nor canonical logic constrain the range or number of possible geometry representations of any given feature in this specification.

However, any logical model for implementation may choose to implement different sets provided they conform to cardinality constraints defined in the conceptual model.

9.5. Pattern - Observations Model

Context - A core element required by this data model is to attach metadata about Observations to attributes of features.

Problem - A common challenge in data modelling is the attachment of observation metadata to attributes of features. A range of different logical models are often used, including definitions of complex datatypes or multiple related attributes. Specification notes may define the conceptual relationship between attributes. Alternative methods use naming conventions (area, area_units, area_measurement_process, area_previous etc ad infinitum ).

Solution - The Observations pattern is a well established conceptual model (c.f. ISO 19156) for describing metadata about the process of observation of the value of a property of a feature.

The benefit of this pattern is that it provides great flexibility to:

  • add observations about any aspect of any feature type using the same encoding syntax

  • provide explicit information about the time of observations in a standard way

  • be extended to provide richer information models about processes and equipment as required by localised implementations.

Observation model (ISO 19156)
Figure 3. Observation Conceptual Model

A Canonical Logical Model for ISO 19156 is available in the OWL language: SOSA (Sensor, Observation, Sample and Actuator). This forms part of a larger model that supports description of observation equipment, sampling strategies etc.

SOSA model
Figure 4. SOSA (Sensor, Observation, Sample and Actuator)

Note that the SOSA logical model includes some additional conceptual elements such as the "Sensor" and provides standardised ways of describing what is observed, when (of observation and the phenomenon being observed). Also, note that the Procedure is modelled in the abstract only - and each implementation will need to determine an appropriate logical model for this component.

Using the Observations pattern allows metadata to be attached to changes in the state of any feature’s property. Furthermore, this specification supports the inclusion of additional observation types not defined without the need to change underlying logical models (where the meta-model for the logical model does not define an inflexible schema). Thus, this pattern accommodates other details such as the addition of point-cloud observations, photographs of survey monuments, the locus of mobile sensor platforms, by new types of observations and the specification of encoding for different observation result data types. There are multiple ways of specifying properties, however the most powerful and unambiguous option is to specify the logical properties of the FeatureOfInterest . A profile of SOSA to make this choice of implementation pattern is proposed and included as a module.

Feature Attributes as Observed Property
Figure 5. Specification of observed property

The ObservationsCollections sub-pattern introduced in updates to SOSA and Observations and Measurements Version 3 working draft provides for common metadata to be shared across multiple Observations in a Collection.

SOSA Observation Collections
Figure 6. Survey Observations sharing common instrument and method metadata

9.6. Pattern - Provenance Model

Context - The nature of this data model requires a well-structured way to capture information about processes and associated times and dates

Consider - One aspect of implementing the Flexible Domains of interoperability pattern includes the need to support various ways organisations and jurisdictions may capture process and date information. The Vocabularies and Codelist pattern covers aspects of this issue but does not address the need for a standard data model for this information.

Problem - The data model must address complex chains of activities. Many of these may vary in polymorphic ways across jurisdictions. A robust model that accommodates this is required.

Solution - The PROV-O Ontology provides a common pattern related to process and times. This standard provides metadata about processes and provenance of information and is formally aligned to the Observation pattern. Together, these patterns form the basis of both the conceptual and canonical logical models.

PROV concepts
Figure 7. PROV - the provenance ontology - core concepts

The provenance pattern provides a well-known pattern for capturing metadata for relatively complex chains of events. For example, implementations can choose the types of activities, entities and agents, then include any business rules and apply a single logical model to these chains. Or choose a restricted profile based on a fixed set of activities as a custom logical model (i.e. a pre-defined set of date elements in a simplified schema.)

Consider next -

  • The Observations pattern is formally aligned to a more general provenance model using the PROV-O Ontology.

9.7. Pattern - Canonical Logical Model

Context - To implement a Conceptual Model in a consistent interoperable fashion, one needs standardised descriptions of the attributes and relationships of the objects described in the model.

Consider - This pattern expresses and builds upon the Conceptual Model using Ontological Modelling to provide a consistent approach to implementations.

Problem - The proliferation of ad-hoc approaches to implementing a conceptual model leads to incompatible non-interoperable implementations.

Solution - Express the conceptual model using well known ("canonical") forms of the underlying abstractions that form the basis of a conceptual model. The canonical logical model is assumed to be "lossless" - expressive of the conceptual model within the limitations of the underlying component models. Thus the Canonical Logical Model can act as a proxy for the Conceptual Model itself in the case where the conceptual schema language is not consistent across the normative definitions of the conceptual model components. The Canonical Logical Model is a form of conceptual schema ("formal description of a conceptual model [ISO 19101]). However, this definition takes into account the possibility that this form is directly implementable as an application schema ("conceptual schema for data required by one or more applications [ISO 19101]")

9.8. Pattern - Flexible Domains of interoperability

Context - Within a domain community, different local requirements may lead to variations of implementation of a data model. To provide the desired interoperability between organisations within a knowledge domain, a data model needs to offer enough flexibility and extensibility to support subtle differing organisational requirements.

Consider - Use of this pattern allows for the adaptation of the Conceptual Model and Canonical Logical Model to fit a particular implementor community’s unique business requirements.

Problem - Subtle differences always exist between different organisations' data and processes in performing the same service. Too rigid a data model leads to localised workarounds that undermine desired interoperability

Rigid data models provide interoperability between the organisations that use them. But workarounds are commonly implemented when an organisation’s unique business requirements do not fully fit the data model. These workarounds may inhibit the desired interoperability. Therefore, provision of some flexibility and extensibility to the data model is often required. However, too much flexibility may lead to unmanageable diversity of implementation that also inhibits interoperability.

Solution - Designed the data model with enough flexibility to support the differences in requirements that various organisations in the domain may have. Ensure the existence of governance regimes to maintain and oversee these modifications. Carefully considered each variation to keep these limited in number and the model as simple as possible. The proliferation of customisations inhibits interoperability and vendors' ability to implement and support the model.

Consider next -

  • Profiles

  • Vocabularies and Codelist

9.9. Pattern - Vocabularies and Codelist

Context - As standards are built upon agreed understandings of terminology, standardised vocabularies are necessary for creating an effective data model. However, some local vocabularies will likely persist and need to be managed and supported.

Problem - The lack of common understanding of terminologies is the first problem encountered when creating a standardised data model. This may not be apparent until late in the process. Misunderstandings can badly affect the utility of chosen standards. Furthermore, due to internal business reasons, different localities and organisations will still wish to refer to some objects, attributes, and relations using other terms and possible definitions.

Solution - The foundation of effective data modelling is to establish common vocabularies to ensure participants agree upon the usage of terms used in the model. This vocabulary will grow as work progresses and will require good governance. To be most effective, store this common vocabulary in a web-accessible registry.

In addition, localised terminologies may be required to support localised business requirements. A key implementation pattern to this purpose is using a code list specific to a specific application domain, such as the regulatory environment of any particular jurisdiction. This pattern could be described as either a simple scalar value or a meta-model such as a CodeList (ISO 19103) or ConceptScheme (SKOS). Declaring distinct conceptual types for each code list, as a subtype of a common meta-model (a SKOS Concept Scheme in the canonical logical model), allows implementations of these lists to declare the type of value they represent and (some types of) implementation models to self-document the specific type of value required in properties that references whilst allowing for simple implementation using standard patterns for values from such lists. It also clearly identifies the use of a consistent pattern each time required, for example, the set of code lists needed to configure an implementation for a given jurisdiction.

Consider next -

  • Linked Data

  • Domains of interoperability

  • Modular Components

9.10. Pattern - Profiles

Context - To ease the ability of implementors to support the data model, a data model should support the customisations of the model to suit a community’s variation of required model objects.

Problem - A particular group of implementors may find a data model challenging to use because the choice of model objects is more extensive than their needs. Or they may discover missing from the otherwise well-suited model some things they need. Inconsistent, incompatible implementations may result.

To provide for the needs of various organisations and support the greatest interoperability, a data model may need to include for a particular implementation more objects, attributes and relations than required by a specific group of implementors. Conversely, another group may wish to extend the model with some objects, attributes, and relations not present. Profiles provide a mechanism to limit and/or extend a data model to support local requirements.

Solution - Profiles are a well-established pattern to constrain the usage of a specification within a narrower scope and with greater consistency where the original specification does not mandate specific implementations. Conformance to a profile implies conformance to the profiled specification. Profiles provide a key mechanism to define a "domain of interoperability" encompassing as many aspects as required. For example, in the case of data models, profiles allow ready identification and declaration of conformance to areas of commonality and interoperability between complex specifications.

Geometry profiles - An example of the profile pattern that will be familiar to the geospatial standards community is the definition of a profile of the complex and broadly scoped abstract model of geometry and topology defined by ISO 19107. In typical GIS applications, the Simple Features Profile limits data types to simple points, lines and polygons widely supported by such systems and encoding formats. Thus, the extensive and theoretical scope of ISO 19107 (see Figure 1 from ISO 19107) is significantly reduced in a consistent way that can easily be implemented and tested. Furthermore, it provides interoperability within the applicable scope, ensuring that implementations can also interoperate with more complete implementations of the abstract model since the underlying abstract specification defines the common elements.

Many informal profiles - i.e. text in specifications, identify the additional constraints imposed - such as GeoJSON and CityGML, state (without direct reference to ISO19107) the subset of ISO19107 geometry types supported. Other profiles are formalised but may be constrained to specific implementations like the Simple Features SQL standard.

The formalised profile approach is taken for the ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions, with the definition of a candidate profile of ISO 19107 for the minimal set of geometric and topological elements required for cadastral applications. This profile is a superset of an equivalent profile that could be abstracted from the implementation patterns supported in CityGML and IFC and the Simple Features Profile.

Logical profiles - In addition to restrictions on conceptual scope, profiles may also determine specific sets of attributes to be attached to a given conceptual class - such as expressed in UML Application Schema class models, XML-, or JSON- schema, SHACL "Shapes".

SHACL is used to describe the canonical logical model for the ICSM Conceptual Model for 3D Cadastral Survey Dataset Submissions using constraints against general-purpose conceptual models. These can be further extended using the same mechanisms to define localised profiles to meet implementation requirements.

9.11. Pattern - Quality Model

Context - In most any information system, data quality is an important dimension to record. When recording Cadastral Survey data, it is a central concern.

Consider - Provenance and Observations require the support of a model to record the qualitative dimensions of the data. The use of Vocabularies and Codelist with this pattern supports Flexible Domains of interoperability

Problem - The value of a survey rests on understanding the accuracy of the measurements. Different jurisdictions will have different rules and methods regarding recording the quality of the measurements and observations.

Solution - Inclusion of the Quality Model provided by ISO19157 allows for a standardised approach to record quality measures such as precision and accuracy. This data quality model accommodates the differing existing quality metrics and rules implemented by the jurisdictions.

Links - ISO 19157:2013 Geographic information — Data quality - https://www.iso.org/standard/32575.html

9.12. Pattern - 3D Solid Geometry

Context - To support the capture of 3D cadastral objects, the data model must support the definition of 3D solid geometries.

Problem - Without the ability to describe cadastral information as volumetric solids, the ability to submit 3D cadastral information is limited as it is impossible to test whether the solids are watertight or validate spatial relationships between cadastral parcels.

2D cadastre parcels only require definition in two directions, East (X) and North (Y). Whereas in the 3D space, spatial units defining the extent of a cadastral parcel require definition in all directions, X, Y and height. Within the computer modelling domain, the main representations used for the representation of solids, spatial units constrained in all directions, include:

  • Cell decomposition - division of space, or a cadastral feature, into a set of elements, typically voxels;

  • General sweeping - the representation of objects in terms of 2D shapes extruded along general curves, i.e., constructive solid geometry;

  • Set theoretic - a set of primitive shapes or (parametric) surfaces (more correctly half planes) that when combined using Boolean operators form a solid; and

  • Boundary Representation - a collection of surface elements that form the skin of a solid.

ISO 19107:2019 adopted the Boundary Representation (B-Rep) to describe vector data. The skin is composed of a set of adjacent bounded elements called faces; cadastral boundary faces in this context, which defines the object’s shell. Faces are bounded by a set of edges, or boundary lines, which are curves lying on the surfaces of the faces intersecting the edges. The points where several faces meet are called vertices and represent survey points generally. When physical markers are placed on the ground as part of a cadastral survey, they represent Boundary Marks. The data structure can be divided into two primary groups: one responsible for defining the object’s structure (the topology) and the form or shape of the object (the geometry).

Solution - Represent spatial properties of all 3D CSDM feature types using the geometry classes defined in ISO 19107. Depending on the feature type, spatial representations can have 0-, 1-, 2-, or 3-dimensional extents. All new 3D CSDM geometries are expected to use 3D coordinate values. However, it is expected the 3D CSDM will also manage that legacy 2D data.

Besides the primitive geometries, points, curves, surfaces, and solids, the 3D CSDM allows aggregations of geometries like spatial aggregates (MultiPoint, MultiCurve, MultiSurface, MultiSolid) and composites (CompositeCurve, CompositeSurface, CompositeSolid).

The 3D CSDM Conceptual Model does not restrict the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS). However, an encoding or a jurisdictional profile may restrict the usage of geometry types. For example, curved lines like B-splines or clothoids, or curved surfaces like NURBS could be disallowed by explicitly defining null encodings for these concepts in the encoding specification.

Require non-2-manifold geometry (unbounded volumes) to represent conventional 2D parcels that are unbounded in the Z-axis (height). ISO 19152 refers to these representations as Liminal Spatial Units and represents them using a 2D boundary face string (on the map datum) and vertical boundary faces. In effect, fake edges are required at some arbitrary elevation to allow various spatial operations to be performed, for example, it is not possible to determine the orientation of a face extending to +/- infinity in the Z axis.

face truncated
Figure 8. Truncated face

In many instances, a cadastral parcel’s upper and lower height limits with respect to a specific datum are known. The upper and lower height limits slice the vertical faces of the unbounded cadastral parcel to create a polygonal slice. Alternatively, a polygonal slice can be considered a type of extrusion of the 2D cadastral parcel along the Z (height) axis with specified limits.

9.13. Pattern - Topology of 3D Solids

Context - The recording and testing of the spatial relationships between features in the cadastre (topology) is an essential aspect of the cadastre.

Problem - The value of the cadastre diminishes if the spatial relationships between cadastral objects cannot be retrieved and tested.

Solution - Record geometry and features once, when required elsewhere, reference them via unique identifiers. Favour encodings that support the inclusion of as many rules as possible.

From a cadastral survey perspective, topology provides two main functions. First is validating the data according to specific rules, e.g., no overlaps or gaps between primary parcels. Second is the ability to identify and manage shared boundaries and other geometric relationships, e.g., in New Zealand, a Unit Title represents a stratum estate that lies within the base land (subdivided parcel) and is disjoint from the Common Property held by the Body Corporate. Satisfaction of this second requirement assists the implementation of the first because topological models allow geometries to be captured once and referenced many times, significantly reducing data volumes and enhancing dataset integrity results.

Adopting the principles of topology also enables rapid spatial data retrieval, enhanced spatial analysis, and enforcement of data integrity rules.

Delegation of the enforcement of some topological rules to the application domain may be necessary. Indeed, it is possible, and even common, to delegate all topological concerns to the application. However, embedding topology in the data increases the interoperability of the data by reducing the reliance on particular software components, and also preserves the benefits of dataset integrity and reduced file size.

Ideally, the topological graph should be bidirectional, i.e., capable of being navigated up and down the graph. It is common to from higher dimension geometries from sets of lower geometries, a boundary line (a 1D geometry) is defined by a set of 2 or more survey points (0D geometries). Construction of geometries in this manner implicitly informs the topology of a spatial unit. However, topology in this sense only allows one-way navigation of the topology graph. Therefore, functions may be required to generate the necessary topology to address specific spatial queries, i.e., which survey points define the solid(s) describing this/these cadastral parcel(s).

This approach reflects the general approach taken by cadastral surveyors when defining cadastral parcel boundaries. Original, reliable monumentation (survey points) defines a cadastral boundary’s location. A closed set of cadastral boundary lines defines the cadastral parcel, or a cadastral parcel face in the 3D space, …​

Topological relations between geometries can be established by sharing geometries (typically parts of the boundary) between different geometric objects. For example, the face between two adjacent 3D cadastral parcels should only be represented by a single geometry (a face ) and referenced by all features or more complex geometries defined or bounded by the face. Thus, redundancy can be avoided, and explicit topological relations between parts, maintained.

An ideal representation geometry and topology are kept separate, allowing greater flexibility but at the risk of ambiguity when created with conflicting information.

If cadastral spatial unit geometric representation implements a Boundary Representation approach strictly, then in instances where two or more spatial units intersect, e.g., an easement passing through a cadastral parcel. Each spatial unit is split into discrete solids. (The cadastral unit would split - the portion of the cadastral unit outside the easement and the portion inside the easement. The easement would be split at the cadastral parcel boundaries.) These would then aggregate to form each specific spatial unit. The easement portion inside the cadastral parcel, being common to the cadastral parcel and the easement, is only created once but referenced in the definition of each spatial unit. All intersections between the cadastral unit and the easement are explicitly defined in this approach. A simplified approach might model the cadastral parcel and the easement independently of each other. There is no explicit definition of the relationship between the two spatial units in this instance. If such an approach is adopted, it is recommended that an intersection curve be defined to describe where the two solids meet explicitly.

IntersectionCurve
Figure 9. Intersection Curve

Consider next -

  • Including Linked Data support in the implementation model and encodings can reduce duplication of features and their geometry .

9.14. Pattern - Domain Compatibility

Context - To ease implementation and uptake, new systems should be as compatible with existing practices within a domain and jurisdiction as possible. Include contributions from existing solutions providers in design.

Consider - Reusable Modular components should consider the ability of existing solution providers and practitioners to implement and use the model designed.

Problem - New systems often engender unfamiliar ways of doing things, making the solution hard to implement and use. Solutions that are alien to the business of the existing software providers are unlikely to be implemented and supported. If the current technical support community finds a model challenging to implement is unlikely to gain traction.

Sometimes change is necessary to overcome poorly designed and implemented previous solutions. Other changes may offer benefits when modelling the data, but they are not worth the pain incurred in implementation. Getting the balance right is critical to a good model. Relational database designers call this process "denormalisation".

Solution - Use cases derived from the existing community of professionals should provide the foundation for creating a solution as familiar as possible to potential implementors and users. When vocabularies need to be standardised in the model, ensure that local terms may be substituted. Allow polymorphic objects to address situations where particular rules and types apply to entities only in certain jurisdictions.

Engagement with the relevant software vendor community is an essential part of this process. Through this engagement, the supporting software community gains confidence that they can implement the model cost-effectively and usable. We demonstrate the ability to implement this model through good documentation and provide candidate encodings for the most complex concepts expressed in familiar standard encodings. Parts of this model will be difficult, or even impossible, to implement in much of the current traditional software and systems.

Consider next -

  • Use Vocabularies and Codelist to preserve the terminologies used by a community.

  • Apply the Flexible Domains of interoperability pattern to address object type variations and rules.

9.15. Pattern - Linked Data Support

Context - To unambiguously share information across and between systems, it is helpful that the model allows the expression of the data according to linked data principles.

Consider - The natural output of an Ontological model is

Problem - There is a great need to share cadastral survey data across many disciplines. Siloed systems where clear identity is hard to determine and maintain reduce the usability and utility of these data.

Solution - Follow the four principles of Linked Data in the model design and implementation -

  • Use URIs as names for things.

  • Use HTTP URIs so that people can look up these names

  • When someone looks up a URI, provide useful information using the standards (RDF, SPARQL)

  • Include links to other URIs so that they can discover more things

To sum it up, Linked Data breaks down the information silos between various organisations and brings down the fences between multiple formats. Furthermore, the Linked Data principles facilitate the extension of the data models and allow easy updates. As a result, data integration and browsing through complex data become more manageable and efficient.

The use of OWL in creating this model provides a native ability to leverage the benefits of Linked Data and create implementations encodings such as TTL and JSON-LD, using the Resource Descriptor Framework (RDF) model. The use of such encodings, while not currently common for cadastre, is growing in multiple related fields. RDF encodes multiple OGC and ISO TC 211 standards and the notable example of ifcOWL.

Furthermore, the language of Linked Data, RDF, relies on a triple store model of subject, object, predicate. The unambiguous recording of the predicate provides the most distinctive feature of RDF and Linked Data. The predicate allows the meaning of the relationship between objects to be explicitly recorded and transmitted in the data, greatly enhancing interoperability.

Consider next -

  • Implement Vocabularies and Codelist using these Linked Data principles.

Links -

10. Domain Model

10.1. Conformance Classes

  1. 3D Geometry and Topology Basic Profile

  2. Cadastral Parcel

  3. Container

  4. Provenance Profile

  5. Survey Features

  6. Survey Observations

10.2. Class Hierarchy

+ expand all, click '+' to expand individually

10.3. Conformance Class: 3D Geometry and Topology Basic Profile

https://linked.data.gov.au/def/csdm/geometry

10.3.1. Class: 3D Spatial Unit

A general 3D spatial unit is an abstract represented a closed solid or multi-solid or other valid geometry from which a solid can be derived.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from 3D Spatial Unit

overlaps

[0..*]

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:boundedBy

from 3D Spatial Unit

boundedBy

[0..*]

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

Images
3DSpatialUnit
Figure 10. Diagram for 3D Spatial Unit

Format

image/png

10.3.2. Class: Boundary Edge

A Boundary Line is a feature whose geometry is a connected set of lines representing the common part of two polygons share this set of oriented lines. As a feature it can participate in topological relationships between features that may, or may not, have planar geometry representations, and observations about the nature of the boundary can be made. The inner and outer features may be swapped by inverting the orientation of the geometry primitive, thus a single orientable boundary line may be used to partially define boundaries of both touching features. An oriented linear ring geometry representation for the planar extend of a bounded feature may be calculated from the geometries of the set of boundary features, using the inward or outward topology to adjust orientation accoridingly.

Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

geo:hasGeometry

from Feature

hasGeometry property inherited from geo:Feature

[0..*]

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:nodeFrom

from Boundary Edge

nodeFrom

[1]

geometry:Node

geometry:nodeTo

from Boundary Edge

equivalent to a GML directedNode with orientation "-"

[1]

geometry:Node

10.3.3. Class: Boundary Face

A Boundary Face is a feature whose geometry is the orientable (possibly composite) surface where two solids touch. As a feature it can participate in topological relationships between features that may, or may not, have solid geometry representations, and observations about the nature of the face can be made. The inner and outer features may be swapped by inverting the orientation of the geometry primitive, thus a single orientable boundary face may be used to define boundary faces of both touching features. The shell of a feature may be computed from the set of faces defining boundaries.

Subclass of
Images
boundary face
Figure 11. Diagram for Boundary Face

Format

image/png

face
Figure 12. Diagram for Boundary Face

Format

image/png

face2
Figure 13. Diagram for Boundary Face

Format

image/png

Canonical Examples 

surveyobs_examples:blue_top_boundary
  a geometry:BoundaryFace ;
  geo:hasGeometry surveyobs_examples:blue_top ;
  geo:touchesInward examples:cp1 ;
  rdfs:label "blue_top boundary" ;
  skos:editorialNote "Example of a vertically unbounded boundary with a nominal solid geometry." ;
  geometry:isTruncated true ;
.
face 

examples:blue_yellow_boundary
  a geometry:BoundaryFace ;
  geo:hasGeometry examples:blue_yellow_face ;
  geo:touchesInward examples:cp1 ;
  geo:touchesOutward examples:cp2 ;
  rdfs:label "blue_yellow_boundary" ;
  foaf:depiction <https://surroundbitbucket.bitbucket.io/3d-cadastre/spec/face.png> ;
.

10.3.4. Class: Boundary Node

A Boundary Node is a feature whose geometry is a single Point representing the touching of two or more features at a single node. As a feature it can participate in topological relationships between features that may, or may not, have planar geometry representations.

Note
Statement required regarding the topology here - are we interest in the touching features or the edges of those features - those edges may not be separately represented so it should be the bounded features. If so - how does one identify the edges when building a topology?
Subclass of

10.3.5. Class: BoundaryFeature

A Boundary Feature is a topological concept - an object relates to a specific geometry type and adds information about the orientation of the geometry relative to topologically connected features. Note that a Featuredefined without specifiying the underlying geometry if required, allowing for example the geometry to be measured or calculated by operations on the geometries of related features.

Subclass of
Requirements

10.3.6. Class: AbstractSolidGeometry

An Abstract Solid Geometry is...

Subclass of

10.4. Conformance Class: Cadastral Parcel

https://linked.data.gov.au/def/csdm/parcel

10.4.1. Class: Estate

A set of real property rights that can be held by a legal entity.

Subclass of
Canonical Examples

Description

An estate is not modelled explicitly - it is simply a reference to an external system - for example a persistent IRI or local system identifier. Implementing profiles may define addtional metadata for such references if needed. 

examples:Estate-Lot1
  a parcel:Estate ;
  rdfs:comment "An estate is not modelled explicitly - it is simply a reference to an external system - for example a persistent IRI or local system identifier. Implementing profiles may define addtional metadata for such references if needed." ;
  rdfs:label "Estate - Ownership of Lot1" ;
.

10.4.2. Class: Estate Parcel

The spatial extent of an Estate. It may consist of one or more cadastral parcels.

Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from 3D Spatial Unit

overlaps

[0..*]

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:boundedBy

from 3D Spatial Unit

boundedBy

[0..*]

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

parcel:interest

from Estate Parcel

[1..*]

Specify Covenant Information

Specify Title Reference

parcel:parcel

from Estate Parcel

[0..*]

Canonical Examples 

examples:DP_333333
  a parcel:EstateParcel ;
  rdfs:label "Yellow And Blue Units" ;
  parcel:interest examples:Estate-Lot1 ;
  parcel:parcel examples:cp1 ;
  parcel:parcel examples:cp2 ;
.

10.4.3. Class: Interest In Land

An Interest In Land is ownership or security towards real property.

Note
This is from LandInfra - Easement is just one example here but it may be worth making explicit as it is the touch point with the LandInfra scope.
Subclass of

10.4.4. Class: Appellation

The legal description for a specific piece of land.

Subclass of
Requirements
Canonical Examples 

examples:Lot1_Appellation
  a parcel:Appellation ;
  dct:hasPart examples:NamePart_Lot ;
  rdfs:label "Lot 1 DP 333333" ;
.

10.4.5. Class: Cadastral Parcel

A single or multi area, or solid, above, or below the surface of the earth as specified through legislated process. The extent of a cadastral parcel can be described by a surface or solid and topological relationships with other parcels.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from 3D Spatial Unit

overlaps

[0..*]

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:boundedBy

from 3D Spatial Unit

boundedBy

[0..*]

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

parcel:appellation

from Cadastral Parcel

appellation

[1]

Appellation

Specify Unique Parcel ID

Specify Parcel Appellation

parcel:interest

from Cadastral Parcel

[0..*]

Interest In Land

Specify Covenant Information

Specify Title Reference

parcel:qualityClass

from Cadastral Parcel

parcel quality

[0..1]

Quality Classification for Parcel

Specify Parcel Quality

parcel:surfaceArea

from Cadastral Parcel

The surface area of the parcel (in the units defined by the given implementation profile of this standard).

[0..1]

Specify Surface Area

parcel:terrainIntersectionCurve

from Cadastral Parcel

parcel-terrainIntersectionCurve

[0..1]

Linear Ring

Requires a Terrain Intersection Curve

parcel:type

from Cadastral Parcel

parcel type

[1]

Parcel Type

Specify non-primary parcel purpose

Specify Cadastral Parcel Type

Images
CadastralParcel
Figure 14. Diagram for Cadastral Parcel

Format

image/png

cadastralparcelexample
Figure 15. Diagram for Cadastral Parcel

Format

image/png

Canonical Examples
blue box 

examples:cp1
  a parcel:Parcel ;
  geo:hasGeometry examples:s1 ;
  geo:sfWithin examples:lot1 ;
  rdfs:label "Blue spatial unit" ;
  foaf:depiction <https://surroundbitbucket.bitbucket.io/3d-cadastre/spec/blue_box.png> ;
  geometry:boundedBy examples:blue_yellow_boundary ;
  geometry:hasGeometryPart surveyfeatures_examples:g_p1 ;
  geometry:hasGeometryPart surveyfeatures_examples:g_p10 ;
  parcel:appellation examples:Appellation_Blue_unit ;
  parcel:interest examples:Strata_Title_1 ;
  parcel:surfaceArea 56643.4 ;
  parcel:terrainIntersectionCurve examples:blue_box_terrain ;
  parcel:type examples:Strata ;
.

ISO-10303-21;
HEADER;
FILE_SCHEMA(('IFC4'));
ENDSEC;

DATA;
/* site / project level information - mostly boilerplate*/
#11=IFCPROJECT('1Pv7U_QXf86vJbLHc6LgdI',$,'Project',$,$,$,$,(#20,#27),#15);
#12=IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#13=IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#14=IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#15=IFCUNITASSIGNMENT((#12,#13,#14));
#16=IFCCARTESIANPOINT((0.,0.,0.));
#17=IFCDIRECTION((0.,0.,1.));
#18=IFCDIRECTION((1.,0.,0.));
#19=IFCAXIS2PLACEMENT3D(#16,#17,#18);
#20=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#19,$);
#21=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model',*,*,*,*,#20,$,.MODEL_VIEW.,$);
#22=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Box','Model',*,*,*,*,#20,$,.MODEL_VIEW.,$);
#23=IFCCARTESIANPOINT((0.,0.,0.));
#24=IFCDIRECTION((0.,0.,1.));
#25=IFCDIRECTION((1.,0.,0.));
#26=IFCAXIS2PLACEMENT3D(#23,#24,#25);
#27=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Plan',2,1.E-05,#26,$);
#32=IFCSITE('1KBmulBMf7MgB4kkr2pyT$',$,'Site',$,$,#47,$,$,$,$,$,$,$,$);
#34=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',$,$,$,#11,(#32));
#36=IFCBUILDING('23JhBYRQDDjws2fDYl7eZ5',$,'Building',$,$,#52,$,$,$,$,$,$);
#38=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',#37,$,$,#32,(#36));
#40=IFCBUILDINGSTOREY('23JhBYRQDDjws2fDYl7eZ5',$,'Building Storey',$,$,#52,$,$,$,$,$,$);
#42=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',$,$,$,#36,(#40));
#43=IFCCARTESIANPOINT((0.,0.,0.));
#44=IFCDIRECTION((0.,0.,1.));
#45=IFCDIRECTION((1.,0.,0.));
#46=IFCAXIS2PLACEMENT3D(#43,#44,#45);
#47=IFCLOCALPLACEMENT($,#46);
#48=IFCCARTESIANPOINT((0.,0.,0.));
#49=IFCDIRECTION((0.,0.,1.));
#50=IFCDIRECTION((1.,0.,0.));
#51=IFCAXIS2PLACEMENT3D(#48,#49,#50);
#52=IFCLOCALPLACEMENT(#47,#51);


/* IFC object definitions */

/* Traverse Points */
/* survey marker style material definition */
#809=IFCCOLOURRGB($,0.,0.,0.);
#810=IFCCOLOURRGB($,0.,0.,0.);
#811=IFCSURFACESTYLERENDERING(#809 ,0.,#810,$,$,$,$,$,.NOTDEFINED.);
#812=IFCSURFACESTYLE('Survey Marker Black',.BOTH.,(#811));

/* survey marker style material definition */
#813=IFCCOLOURRGB($,0.,0.,1.);
#814=IFCCOLOURRGB($,0.,0.,1.);
#815=IFCSURFACESTYLERENDERING(#813 ,0.,#814,$,$,$,$,$,.NOTDEFINED.);
#816=IFCSURFACESTYLE('Survey Marker Blue',.BOTH.,(#815));

/* style material - Gloss paint blue */
#59=IFCCOLOURRGB($,0.392156863,0.584313725,0.929411765);
#60=IFCCOLOURRGB($,0.392156863,0.584313725,0.929411765);
#61=IFCSURFACESTYLERENDERING(#59,0.,#60,$,$,$,$,$,.NOTDEFINED.);
#62=IFCSURFACESTYLE('Gloss paint blue',.BOTH.,(#61));


/* survey/traverse/occupation marker object - this is a cube */
#825=IFCINDEXEDPOLYGONALFACE((2,4,1));
#826=IFCINDEXEDPOLYGONALFACE((6,8,5));
#827=IFCINDEXEDPOLYGONALFACE((2,7,3));
#828=IFCINDEXEDPOLYGONALFACE((4,5,1));
#829=IFCINDEXEDPOLYGONALFACE((3,6,4));
#830=IFCINDEXEDPOLYGONALFACE((1,8,2));
#831=IFCINDEXEDPOLYGONALFACE((2,3,4));
#832=IFCINDEXEDPOLYGONALFACE((6,7,8));
#833=IFCINDEXEDPOLYGONALFACE((2,8,7));
#834=IFCINDEXEDPOLYGONALFACE((4,6,5));
#835=IFCINDEXEDPOLYGONALFACE((3,7,6));
#836=IFCINDEXEDPOLYGONALFACE((1,5,8));
#837=IFCCARTESIANPOINTLIST3D(((-0.1,0.1,0.1),(-0.1,-0.1,0.1),(0.1,-0.1,0.1),(0.1,0.1,0.1),(-0.1,0.1,-0.1),(0.1,0.1,-0.1),(0.1,-0.1,-0.1),(-0.1,-0.1,-0.1)));
#838=IFCPOLYGONALFACESET(#837,$,(#825,#826,#827,#828,#829,#830,#831,#832,#833,#834,#835,#836),$);
#839=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#838));



#1104=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1105=IFCGEOGRAPHICELEMENT('0000000000P26',#1104,'P1','Survey Point P1 ShowLabel',$,#1110,#1114,$,.USERDEFINED.);
#1106=IFCCARTESIANPOINT((38.089, -31.596, 5.));
#1107=IFCDIRECTION((0.,0.,1.));
#1108=IFCDIRECTION((1.,0.,0.));
#1109=IFCAXIS2PLACEMENT3D(#1106,#1107,#1108);
#1110=IFCLOCALPLACEMENT($,#1109);
#1111=IFCCARTESIANPOINT((38.889, -31.396, 5.));
#1112=IFCBOUNDINGBOX(#1111 ,0.2,0.2,0.2);
#1113=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1112));
#1114=IFCPRODUCTDEFINITIONSHAPE($,$,(#1113,#839));
#6003=IFCSTYLEDITEM(#1105,(#812),'Survey Marker Black');


#840=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#841=IFCGEOGRAPHICELEMENT('0000000000P2',#840,'P2','Survey Point P2 ',$,#846,#850,$,.USERDEFINED.);
#842=IFCCARTESIANPOINT((43.089, -31.596, 5.000));
#843=IFCDIRECTION((0.,0.,1.));
#844=IFCDIRECTION((1.,0.,0.));
#845=IFCAXIS2PLACEMENT3D(#842,#843,#844);
#846=IFCLOCALPLACEMENT($,#845);
#847=IFCCARTESIANPOINT((43.889, -31.396, 5.));
#848=IFCBOUNDINGBOX(#847 ,0.2,0.2,0.2);
#849=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#848));
#850=IFCPRODUCTDEFINITIONSHAPE($,$,(#849,#839));
#6004=IFCSTYLEDITEM(#841,(#816),'Survey Marker Black');

#851=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#852=IFCGEOGRAPHICELEMENT('0000000000P3',#851,'P3','Survey Point P3 ',$,#857,#861,$,.USERDEFINED.);
#853=IFCCARTESIANPOINT((43.089, -36.596, 5.000));
#854=IFCDIRECTION((0.,0.,1.));
#855=IFCDIRECTION((1.,0.,0.));
#856=IFCAXIS2PLACEMENT3D(#853,#854,#855);
#857=IFCLOCALPLACEMENT($,#856);
#858=IFCCARTESIANPOINT((43.889, -36.396, 4.8));
#859=IFCBOUNDINGBOX(#858 ,0.2,0.2,0.2);
#860=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#859));
#861=IFCPRODUCTDEFINITIONSHAPE($,$,(#860,#839));
#6005=IFCSTYLEDITEM(#852,(#816),'Survey Marker Black');

#862=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#863=IFCGEOGRAPHICELEMENT('0000000000P4',#862,'P4','Survey Point P4 ',$,#868,#872,$,.USERDEFINED.);
#864=IFCCARTESIANPOINT((38.089, -36.596, 5.000));
#865=IFCDIRECTION((0.,0.,1.));
#866=IFCDIRECTION((1.,0.,0.));
#867=IFCAXIS2PLACEMENT3D(#864,#865,#866);
#868=IFCLOCALPLACEMENT($,#867);
#869=IFCCARTESIANPOINT((38.889, -36.396, 4.8));
#870=IFCBOUNDINGBOX(#869 ,0.2,0.2,0.2);
#871=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#870));
#872=IFCPRODUCTDEFINITIONSHAPE($,$,(#871,#839));
#6006=IFCSTYLEDITEM(#863,(#816),'Survey Marker Black');


#961=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#962=IFCGEOGRAPHICELEMENT('0000000000P13',#961,'P13','Survey Point P13',$,#967,#971,$,.USERDEFINED.);
#963=IFCCARTESIANPOINT((43.089, -36.596, 0.000));
#964=IFCDIRECTION((0.,0.,1.));
#965=IFCDIRECTION((1.,0.,0.));
#966=IFCAXIS2PLACEMENT3D(#963,#964,#965);
#967=IFCLOCALPLACEMENT($,#966);
#968=IFCCARTESIANPOINT((43.889, -36.396, -0.200));
#969=IFCBOUNDINGBOX(#968 ,0.2,0.2,0.2);
#970=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#969));
#971=IFCPRODUCTDEFINITIONSHAPE($,$,(#970,#839));
#6007=IFCSTYLEDITEM(#962,(#816),'Survey Marker Black');

#972=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#973=IFCGEOGRAPHICELEMENT('0000000000P14',#972,'P14','Survey Point P14',$,#978,#982,$,.USERDEFINED.);
#974=IFCCARTESIANPOINT((38.089, -36.596, 0.000));
#975=IFCDIRECTION((0.,0.,1.));
#976=IFCDIRECTION((1.,0.,0.));
#977=IFCAXIS2PLACEMENT3D(#974,#975,#976);
#978=IFCLOCALPLACEMENT($,#977);
#979=IFCCARTESIANPOINT((38.889, -36.396, -0.200));
#980=IFCBOUNDINGBOX(#979 ,0.2,0.2,0.2);
#981=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#980));
#982=IFCPRODUCTDEFINITIONSHAPE($,$,(#981,#839));
#6008=IFCSTYLEDITEM(#973,(#816),'Survey Marker Black');

#983=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#984=IFCGEOGRAPHICELEMENT('0000000000P15',#983,'P15','Survey Point P15',$,#989,#993,$,.USERDEFINED.);
#985=IFCCARTESIANPOINT((38.089, -31.596, 0.000));
#986=IFCDIRECTION((0.,0.,1.));
#987=IFCDIRECTION((1.,0.,0.));
#988=IFCAXIS2PLACEMENT3D(#985,#986,#987);
#989=IFCLOCALPLACEMENT($,#988);
#990=IFCCARTESIANPOINT((38.889, -31.396, -0.200));
#991=IFCBOUNDINGBOX(#990 ,0.2,0.2,0.2);
#992=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#991));
#993=IFCPRODUCTDEFINITIONSHAPE($,$,(#992,#839));
#6009=IFCSTYLEDITEM(#984,(#816),'Survey Marker Black');

#994=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#995=IFCGEOGRAPHICELEMENT('0000000000P16',#994,'P16','Survey Point P16',$,#1000,#1004,$,.USERDEFINED.);
#996=IFCCARTESIANPOINT((43.089, -31.596, 0.000));
#997=IFCDIRECTION((0.,0.,1.));
#998=IFCDIRECTION((1.,0.,0.));
#999=IFCAXIS2PLACEMENT3D(#996,#997,#998);
#1000=IFCLOCALPLACEMENT($,#999);
#1001=IFCCARTESIANPOINT((43.889, -31.396, -0.200));
#1002=IFCBOUNDINGBOX(#1001 ,0.2,0.2,0.2);
#1003=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1002));
#1004=IFCPRODUCTDEFINITIONSHAPE($,$,(#1003,#839));
#6010=IFCSTYLEDITEM(#995,(#816),'Survey Marker Black');


#1005=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1006=IFCGEOGRAPHICELEMENT('0000000000P17',#1005,'P17','Survey Point P17',$,#1011,#1015,$,.USERDEFINED.);
#1007=IFCCARTESIANPOINT((42.252, -35.717, 2.530));
#1008=IFCDIRECTION((0.,0.,1.));
#1009=IFCDIRECTION((1.,0.,0.));
#1010=IFCAXIS2PLACEMENT3D(#1007,#1008,#1009);
#1011=IFCLOCALPLACEMENT($,#1010);
#1012=IFCCARTESIANPOINT((42.052, -35.517, 2.330));
#1013=IFCBOUNDINGBOX(#1012 ,0.2,0.2,0.2);
#1014=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1013));
#1015=IFCPRODUCTDEFINITIONSHAPE($,$,(#1014,#839));
#6011=IFCSTYLEDITEM(#1006,(#816),'Survey Marker Black');

#1016=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1017=IFCGEOGRAPHICELEMENT('0000000000P18',#1016,'P18','Survey Point P18',$,#1022,#1026,$,.USERDEFINED.);
#1018=IFCCARTESIANPOINT((42.252, -35.717, 4.550));
#1019=IFCDIRECTION((0.,0.,1.));
#1020=IFCDIRECTION((1.,0.,0.));
#1021=IFCAXIS2PLACEMENT3D(#1018,#1019,#1020);
#1022=IFCLOCALPLACEMENT($,#1021);
#1023=IFCCARTESIANPOINT((42.052, -35.517, 4.350));
#1024=IFCBOUNDINGBOX(#1023 ,0.2,0.2,0.2);
#1025=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1024));
#1026=IFCPRODUCTDEFINITIONSHAPE($,$,(#1025,#839));
#6012=IFCSTYLEDITEM(#1017,(#816),'Survey Marker Black');

#1027=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1028=IFCGEOGRAPHICELEMENT('0000000000P19',#1027,'P19','Survey Point P19',$,#1033,#1037,$,.USERDEFINED.);
#1029=IFCCARTESIANPOINT((42.252, -33.717, 4.550));
#1030=IFCDIRECTION((0.,0.,1.));
#1031=IFCDIRECTION((1.,0.,0.));
#1032=IFCAXIS2PLACEMENT3D(#1029,#1030,#1031);
#1033=IFCLOCALPLACEMENT($,#1032);
#1034=IFCCARTESIANPOINT((42.152, -33.517, 4.350));
#1035=IFCBOUNDINGBOX(#1034 ,0.2,0.2,0.2);
#1036=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1035));
#1037=IFCPRODUCTDEFINITIONSHAPE($,$,(#1036,#839));
#6013=IFCSTYLEDITEM(#1028,(#816),'Survey Marker Black');

#1038=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1039=IFCGEOGRAPHICELEMENT('0000000000P20',#1038,'P20','Survey Point P20',$,#1044,#1048,$,.USERDEFINED.);
#1040=IFCCARTESIANPOINT((42.252, -33.717, 2.530));
#1041=IFCDIRECTION((0.,0.,1.));
#1042=IFCDIRECTION((1.,0.,0.));
#1043=IFCAXIS2PLACEMENT3D(#1040,#1041,#1042);
#1044=IFCLOCALPLACEMENT($,#1043);
#1045=IFCCARTESIANPOINT((42.052, -33.517, 2.330));
#1046=IFCBOUNDINGBOX(#1045 ,0.2,0.2,0.2);
#1047=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1046));
#1048=IFCPRODUCTDEFINITIONSHAPE($,$,(#1047,#839));
#6014=IFCSTYLEDITEM(#1039,(#816),'Survey Marker Black');

#917=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#918=IFCGEOGRAPHICELEMENT('0000000000P9',#917,'P9','Survey Point P9',$,#923,#927,$,.USERDEFINED.);
#919=IFCCARTESIANPOINT((43.089, -35.717, 4.550));
#920=IFCDIRECTION((0.,0.,1.));
#921=IFCDIRECTION((1.,0.,0.));
#922=IFCAXIS2PLACEMENT3D(#919,#920,#921);
#923=IFCLOCALPLACEMENT($,#922);
#924=IFCCARTESIANPOINT((43.889, -35.517, 4.350));
#925=IFCBOUNDINGBOX(#924 ,0.2,0.2,0.2);
#926=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#925));
#927=IFCPRODUCTDEFINITIONSHAPE($,$,(#926,#839));
#6015=IFCSTYLEDITEM(#918,(#816),'Survey Marker Black');

#928=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#929=IFCGEOGRAPHICELEMENT('0000000000P10',#928,'P10','Survey Point P10 ShowLabel',$,#934,#938,$,.USERDEFINED.);
#930=IFCCARTESIANPOINT((43.089, -33.717, 4.550));
#931=IFCDIRECTION((0.,0.,1.));
#932=IFCDIRECTION((1.,0.,0.));
#933=IFCAXIS2PLACEMENT3D(#930,#931,#932);
#934=IFCLOCALPLACEMENT($,#933);
#935=IFCCARTESIANPOINT((43.889, -33.517, 4.350));
#936=IFCBOUNDINGBOX(#935 ,0.2,0.2,0.2);
#937=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#936));
#938=IFCPRODUCTDEFINITIONSHAPE($,$,(#937,#839));
#6016=IFCSTYLEDITEM(#929,(#812),'Survey Marker Black');

#939=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#940=IFCGEOGRAPHICELEMENT('0000000000P11',#939,'P11','Survey Point P11',$,#945,#949,$,.USERDEFINED.);
#941=IFCCARTESIANPOINT((43.089, -33.717, 2.530));
#942=IFCDIRECTION((0.,0.,1.));
#943=IFCDIRECTION((1.,0.,0.));
#944=IFCAXIS2PLACEMENT3D(#941,#942,#943);
#945=IFCLOCALPLACEMENT($,#944);
#946=IFCCARTESIANPOINT((43.889, -33.517, 2.330));
#947=IFCBOUNDINGBOX(#946 ,0.2,0.2,0.2);
#948=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#947));
#949=IFCPRODUCTDEFINITIONSHAPE($,$,(#948,#839));
#6017=IFCSTYLEDITEM(#940,(#816),'Survey Marker Black');

#950=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#951=IFCGEOGRAPHICELEMENT('0000000000P12',#950,'P12','Survey Point P12',$,#956,#960,$,.USERDEFINED.);
#952=IFCCARTESIANPOINT((43.089, -35.717, 2.530));
#953=IFCDIRECTION((0.,0.,1.));
#954=IFCDIRECTION((1.,0.,0.));
#955=IFCAXIS2PLACEMENT3D(#952,#953,#954);
#956=IFCLOCALPLACEMENT($,#955);
#957=IFCCARTESIANPOINT((43.889, -35.517, 2.330));
#958=IFCBOUNDINGBOX(#957 ,0.2,0.2,0.2);
#959=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#958));
#960=IFCPRODUCTDEFINITIONSHAPE($,$,(#959,#839));
#6018=IFCSTYLEDITEM(#951,(#816),'Survey Marker Black');




#71=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#72=IFCWALL('0ZDZ3jCJ57Hw5fLEKxhgem',#71,'blue_bottom',$,$,#77,#90,$,.SOLIDWALL.);
#73=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.100000001490116));
#74=IFCDIRECTION((0.,1.,1.19248806385031E-08));
#75=IFCDIRECTION((1.,0.,0.));
#76=IFCAXIS2PLACEMENT3D(#73,#74,#75);
#77=IFCLOCALPLACEMENT($,#76);
#78=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#79=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#80=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#81=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#82=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#83=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#84=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,5.),(0.114820323884487,0.100347764790058,5.),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,5.),(4.89965200424194,0.114821046590805,5.),(4.89965200424194,0.114821046590805,-0.)));
#85=IFCPOLYGONALFACESET(#84,$,(#78,#79,#80,#81,#82,#83),$);
#86=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#85));
#87=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#88=IFCBOUNDINGBOX(#87,5.,5.,5.);
#89=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#88));
#90=IFCPRODUCTDEFINITIONSHAPE($,$,(#89,#86));
#91=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#92=IFCELEMENTQUANTITY('00OYWqfTf4LOsVA4fhxz9U',#91,'Qto_WallBaseQuantities',$,$,(#95,#96,#97,#98,#99));
#93=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#94=IFCRELDEFINESBYPROPERTIES('0yhGp9U619jQNJ3jCNGeGY',#93,$,$,(#72),#92);
#95=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#96=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#97=IFCQUANTITYLENGTH('Height',$,$,5.,$);
#98=IFCQUANTITYVOLUME('GrossVolume',$,$,2.39,$);
#99=IFCQUANTITYVOLUME('NetVolume',$,$,2.39,$);


#100=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#101=IFCWALL('2V4MkMOGj4E8ApC9tnAKLP',#100,'blue_front_above_ground',$,$,#106,#119,$,.SOLIDWALL.);
#102=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.300000011920929));
#103=IFCDIRECTION((0.,0.,1.));
#104=IFCDIRECTION((1.,0.,0.));
#105=IFCAXIS2PLACEMENT3D(#102,#103,#104);
#106=IFCLOCALPLACEMENT($,#105);
#107=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#108=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#109=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#110=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#111=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#112=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#113=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,4.69999980926514),(0.114820323884487,0.100347764790058,4.69999980926514),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,4.69999980926514),(4.89965200424194,0.114821046590805,4.69999980926514),(4.89965200424194,0.114821046590805,-0.)));
#114=IFCPOLYGONALFACESET(#113,$,(#107,#108,#109,#110,#111,#112),$);
#115=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#114));
#116=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#117=IFCBOUNDINGBOX(#116,5.,5.,5.);
#118=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#117));
#119=IFCPRODUCTDEFINITIONSHAPE($,$,(#118,#115));
#120=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#121=IFCELEMENTQUANTITY('287UxcYyP2Q9J3SjYrBsJy',#120,'Qto_WallBaseQuantities',$,$,(#124,#125,#126,#127,#128));
#122=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#123=IFCRELDEFINESBYPROPERTIES('1$8j1HnBz6J88Wb3x3CAj_',#122,$,$,(#101),#121);
#124=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#125=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#126=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#127=IFCQUANTITYVOLUME('GrossVolume',$,$,2.25,$);
#128=IFCQUANTITYVOLUME('NetVolume',$,$,2.25,$);


#129=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#130=IFCWALL('0Pj$j_uQ1AC8UbxYN6nDdg',#129,'blue_front_below_ground',$,$,#135,#148,$,.SOLIDWALL.);
#131=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.));
#132=IFCDIRECTION((0.,0.,1.));
#133=IFCDIRECTION((1.,0.,0.));
#134=IFCAXIS2PLACEMENT3D(#131,#132,#133);
#135=IFCLOCALPLACEMENT($,#134);
#136=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#137=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#138=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#139=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#140=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#141=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#142=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,0.300000011920929),(0.114820323884487,0.100347764790058,0.300000011920929),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,0.300000011920929),(4.89965200424194,0.114821046590805,0.300000011920929),(4.89965200424194,0.114821046590805,-0.)));
#143=IFCPOLYGONALFACESET(#142,$,(#136,#137,#138,#139,#140,#141),$);
#144=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#143));
#145=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#146=IFCBOUNDINGBOX(#145,5.,5.,5.);
#147=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#146));
#148=IFCPRODUCTDEFINITIONSHAPE($,$,(#147,#144));
#149=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#150=IFCELEMENTQUANTITY('1iabEfUUT9ZBZbbKYHHNNq',#149,'Qto_WallBaseQuantities',$,$,(#153,#154,#155,#156,#157));
#151=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#152=IFCRELDEFINESBYPROPERTIES('0lwAAcoFP0thWTNM4DSKWX',#151,$,$,(#130),#150);
#153=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#154=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#155=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#156=IFCQUANTITYVOLUME('GrossVolume',$,$,0.14,$);
#157=IFCQUANTITYVOLUME('NetVolume',$,$,0.14,$);



#158=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#159=IFCWALL('3zDy7ve$93B9oYmgkgIjTt',#158,'blue_left_above_ground',$,$,#164,#177,$,.SOLIDWALL.);
#160=IFCCARTESIANPOINT((38.0890007019043,-31.5960006713867,0.300000011920929));
#161=IFCDIRECTION((0.,0.,1.));
#162=IFCDIRECTION((1.19248806385031E-08,-1.,0.));
#163=IFCAXIS2PLACEMENT3D(#160,#161,#162);
#164=IFCLOCALPLACEMENT($,#163);
#165=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#166=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#167=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#168=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#169=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#170=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#171=IFCCARTESIANPOINTLIST3D(((0.,0.,-0.),(0.,0.,4.69999980926514),(-0.000302481203107163,0.0999995395541191,4.69999980926514),(-0.000302481203107163,0.0999995395541191,-0.),(4.99997711181641,0.0151240592822433,-0.),(4.99997711181641,0.0151240592822433,4.69999980926514),(4.99967479705811,0.115123599767685,4.69999980926514),(4.99967479705811,0.115123599767685,-0.)));
#172=IFCPOLYGONALFACESET(#171,$,(#165,#166,#167,#168,#169,#170),$);
#173=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#172));
#174=IFCCARTESIANPOINT((-0.000302481203107163,0.,-0.));
#175=IFCBOUNDINGBOX(#174,5.,5.,5.);
#176=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#175));
#177=IFCPRODUCTDEFINITIONSHAPE($,$,(#176,#173));
#178=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#179=IFCELEMENTQUANTITY('3iiDuUrQb3JvzQkbH3yjpY',#178,'Qto_WallBaseQuantities',$,$,(#182,#183,#184,#185,#186));
#180=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#181=IFCRELDEFINESBYPROPERTIES('3AB7qQcqH8XQ4avUWOQYmq',#180,$,$,(#159),#179);
#182=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#183=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#184=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#185=IFCQUANTITYVOLUME('GrossVolume',$,$,2.35,$);
#186=IFCQUANTITYVOLUME('NetVolume',$,$,2.35,$);


#187=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#188=IFCWALL('0_Nvu$MCr5xPQL_UDcevAD',#187,'blue_left_below_ground',$,$,#193,#206,$,.SOLIDWALL.);
#189=IFCCARTESIANPOINT((38.0890007019043,-31.5960006713867,0.));
#190=IFCDIRECTION((0.,0.,1.));
#191=IFCDIRECTION((1.19248806385031E-08,-1.,0.));
#192=IFCAXIS2PLACEMENT3D(#189,#190,#191);
#193=IFCLOCALPLACEMENT($,#192);
#194=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#195=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#196=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#197=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#198=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#199=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#200=IFCCARTESIANPOINTLIST3D(((0.,0.,-0.),(0.,0.,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.300000011920929),(-0.000302481203107163,0.0999995395541191,-0.),(4.99997711181641,0.0151240592822433,-0.),(4.99997711181641,0.0151240592822433,0.300000011920929),(4.99967479705811,0.115123599767685,0.300000011920929),(4.99967479705811,0.115123599767685,-0.)));
#201=IFCPOLYGONALFACESET(#200,$,(#194,#195,#196,#197,#198,#199),$);
#202=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#201));
#203=IFCCARTESIANPOINT((-0.000302481203107163,0.,-0.));
#204=IFCBOUNDINGBOX(#203,5.,5.,5.);
#205=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#204));
#206=IFCPRODUCTDEFINITIONSHAPE($,$,(#205,#202));
#207=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#208=IFCELEMENTQUANTITY('07czp0AcrBe9IMMUoawVu_',#207,'Qto_WallBaseQuantities',$,$,(#211,#212,#213,#214,#215));
#209=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#210=IFCRELDEFINESBYPROPERTIES('0dc6e5x2D3MB15C0VLFU9L',#209,$,$,(#188),#208);
#211=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#212=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#213=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#214=IFCQUANTITYVOLUME('GrossVolume',$,$,0.15,$);
#215=IFCQUANTITYVOLUME('NetVolume',$,$,0.15,$);


#216=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#217=IFCWALL('1CscwCyIL6s8mT9FmGysNV',#216,'blue_rear_above_ground',$,$,#222,#235,$,.SOLIDWALL.);
#218=IFCCARTESIANPOINT((43.0890007019043,-31.5960006713867,0.300000011920929));
#219=IFCDIRECTION((0.,0.,1.));
#220=IFCDIRECTION((-1.,-3.25841369885893E-07,0.));
#221=IFCAXIS2PLACEMENT3D(#218,#219,#220);
#222=IFCLOCALPLACEMENT($,#221);
#223=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#224=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#225=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#226=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#227=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#228=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#229=IFCCARTESIANPOINTLIST3D(((0.115124225616455,0.000348230707459152,-0.),(0.115124225616455,0.000348230707459152,4.69999980926514),(0.114821746945381,0.100347772240639,4.69999980926514),(0.114821746945381,0.100347772240639,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,4.69999980926514),(4.89965200424194,0.114821046590805,4.69999980926514),(4.89965200424194,0.114821046590805,-0.)));
#230=IFCPOLYGONALFACESET(#229,$,(#223,#224,#225,#226,#227,#228),$);
#231=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#230));
#232=IFCCARTESIANPOINT((0.114821746945381,0.000348230707459152,-0.));
#233=IFCBOUNDINGBOX(#232,5.,5.,5.);
#234=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#233));
#235=IFCPRODUCTDEFINITIONSHAPE($,$,(#234,#231));
#236=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#237=IFCELEMENTQUANTITY('0kjU8tcW9BZ8iYoK4d7J74',#236,'Qto_WallBaseQuantities',$,$,(#240,#241,#242,#243,#244));
#238=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#239=IFCRELDEFINESBYPROPERTIES('3s3Ubvwu1AyAVvOn0p4C5u',#238,$,$,(#217),#237);
#240=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#241=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#242=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#243=IFCQUANTITYVOLUME('GrossVolume',$,$,2.25,$);
#244=IFCQUANTITYVOLUME('NetVolume',$,$,2.25,$);


#245=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#246=IFCWALL('3Qp2Tio6X6_hsGdiXTzWRu',#245,'blue_rear_below_ground',$,$,#251,#264,$,.SOLIDWALL.);
#247=IFCCARTESIANPOINT((43.0890007019043,-31.5960006713867,0.));
#248=IFCDIRECTION((0.,0.,1.));
#249=IFCDIRECTION((-1.,-3.25841369885893E-07,0.));
#250=IFCAXIS2PLACEMENT3D(#247,#248,#249);
#251=IFCLOCALPLACEMENT($,#250);
#252=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#253=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#254=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#255=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#256=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#257=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#258=IFCCARTESIANPOINTLIST3D(((0.115124225616455,0.000348230707459152,-0.),(0.115124225616455,0.000348230707459152,0.300000011920929),(0.114821746945381,0.100347772240639,0.300000011920929),(0.114821746945381,0.100347772240639,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,0.300000011920929),(4.89965200424194,0.114821046590805,0.300000011920929),(4.89965200424194,0.114821046590805,-0.)));
#259=IFCPOLYGONALFACESET(#258,$,(#252,#253,#254,#255,#256,#257),$);
#260=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#259));
#261=IFCCARTESIANPOINT((0.114821746945381,0.000348230707459152,-0.));
#262=IFCBOUNDINGBOX(#261,5.,5.,5.);
#263=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#262));
#264=IFCPRODUCTDEFINITIONSHAPE($,$,(#263,#260));
#265=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#266=IFCELEMENTQUANTITY('2xeUzEs75749mejl$nY4NI',#265,'Qto_WallBaseQuantities',$,$,(#269,#270,#271,#272,#273));
#267=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#268=IFCRELDEFINESBYPROPERTIES('3k4Idi9cf9axIZXwQkQ_ID',#267,$,$,(#246),#266);
#269=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#270=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#271=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#272=IFCQUANTITYVOLUME('GrossVolume',$,$,0.14,$);
#273=IFCQUANTITYVOLUME('NetVolume',$,$,0.14,$);


#274=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#275=IFCWALL('129gVASXH6lfsqgVdtpKFf',#274,'blue_right_above_ground',$,$,#280,#303,$,.SOLIDWALL.);
#276=IFCCARTESIANPOINT((43.0890007019043,-36.5960006713867,0.300000011920929));
#277=IFCDIRECTION((0.,0.,1.));
#278=IFCDIRECTION((-4.37113882867379E-08,1.,0.));
#279=IFCAXIS2PLACEMENT3D(#276,#277,#278);
#280=IFCLOCALPLACEMENT($,#279);
#281=IFCINDEXEDPOLYGONALFACE((12,13,2,1,5,6,14,15,9,11,10));
#282=IFCINDEXEDPOLYGONALFACE((14,6,2,13,16));
#283=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#284=IFCINDEXEDPOLYGONALFACE((18,3,7,21,17));
#285=IFCINDEXEDPOLYGONALFACE((7,8,4,3,18,23,22,24,19,20,21));
#286=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#287=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#288=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#289=IFCINDEXEDPOLYGONALFACE((14,16,17,21));
#290=IFCINDEXEDPOLYGONALFACE((11,9,19,24));
#291=IFCINDEXEDPOLYGONALFACE((18,13,12,23));
#292=IFCINDEXEDPOLYGONALFACE((15,14,21,20));
#293=IFCINDEXEDPOLYGONALFACE((16,13,18,17));
#294=IFCINDEXEDPOLYGONALFACE((22,10,11,24));
#295=IFCINDEXEDPOLYGONALFACE((12,10,22,23));
#296=IFCINDEXEDPOLYGONALFACE((15,20,19,9));
#297=IFCCARTESIANPOINTLIST3D(((0.,0.,0.),(0.,0.,4.69999980926514),(-0.000302481203107163,0.0999995395541191,4.69999980926514),(-0.000302481203107163,0.0999995395541191,0.),(4.99997711181641,0.0151240592822433,0.),(4.99997711181641,0.0151240592822433,4.69999980926514),(4.99967479705811,0.115123599767685,4.69999980926514),(4.99967479705811,0.115123599767685,0.),(2.87900137901306,0.00870847795158625,2.23000001907349),(0.879001438617706,0.00265882606618106,2.23000001907349),(1.71082830429077,0.00517495768144727,2.23000001907349),(0.879001438617706,0.00265882606618106,3.40731334686279),(0.879001438617706,0.00265882606618106,4.25),(2.87900137901306,0.00870847795158625,4.25),(2.87900137901306,0.00870847795158625,3.0665762424469),(1.71082830429077,0.00517495768144727,4.25),(1.61112952232361,0.104873843491077,4.25),(0.879001438617706,0.102659277617931,4.25),(2.87900137901306,0.108708932995796,2.23000001907349),(2.87900137901306,0.108708932995796,2.96557569503784),(2.87900137901306,0.108708932995796,4.25),(0.879001438617706,0.102659277617931,2.23000001907349),(0.879001438617706,0.102659277617931,3.50831365585327),(1.61112952232361,0.104873843491077,2.23000001907349)));
#298=IFCPOLYGONALFACESET(#297,$,(#281,#282,#283,#284,#285,#286,#287,#288,#289,#290,#291,#292,#293,#294,#295,#296),$);
#299=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#298));
#300=IFCCARTESIANPOINT((-0.000302481203107163,0.,0.));
#301=IFCBOUNDINGBOX(#300,5.,5.,5.);
#302=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#301));
#303=IFCPRODUCTDEFINITIONSHAPE($,$,(#302,#299));
#304=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#305=IFCELEMENTQUANTITY('0nOs4nPrf6wh4F0wmANHnO',#304,'Qto_WallBaseQuantities',$,$,(#308,#309,#310,#311,#312));
#306=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#307=IFCRELDEFINESBYPROPERTIES('11D65eHcbCGPqd8yDJmiQ1',#306,$,$,(#275),#305);
#308=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#309=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#310=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#311=IFCQUANTITYVOLUME('GrossVolume',$,$,2.35,$);
#312=IFCQUANTITYVOLUME('NetVolume',$,$,2.35,$);


#313=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#314=IFCWALL('1POQQ24hzEQ80As95tMhP1',#313,'blue_right_below_ground',$,$,#319,#332,$,.SOLIDWALL.);
#315=IFCCARTESIANPOINT((43.0890007019043,-36.5960006713867,0.));
#316=IFCDIRECTION((0.,0.,1.));
#317=IFCDIRECTION((-4.37113882867379E-08,1.,0.));
#318=IFCAXIS2PLACEMENT3D(#315,#316,#317);
#319=IFCLOCALPLACEMENT($,#318);
#320=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#321=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#322=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#323=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#324=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#325=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#326=IFCCARTESIANPOINTLIST3D(((0.,0.,0.),(0.,0.,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.),(4.99997711181641,0.0151240592822433,0.),(4.99997711181641,0.0151240592822433,0.300000011920929),(4.99967479705811,0.115123599767685,0.300000011920929),(4.99967479705811,0.115123599767685,0.)));
#327=IFCPOLYGONALFACESET(#326,$,(#320,#321,#322,#323,#324,#325),$);
#328=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#327));
#329=IFCCARTESIANPOINT((-0.000302481203107163,0.,0.));
#330=IFCBOUNDINGBOX(#329,5.,5.,5.);
#331=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#330));
#332=IFCPRODUCTDEFINITIONSHAPE($,$,(#331,#328));
#333=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#334=IFCELEMENTQUANTITY('3Z3E2eBHXAaPhfLMDmu754',#333,'Qto_WallBaseQuantities',$,$,(#337,#338,#339,#340,#341));
#335=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#336=IFCRELDEFINESBYPROPERTIES('00YhtGu$r2NQjr1aNTofM7',#335,$,$,(#314),#334);
#337=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#338=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#339=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#340=IFCQUANTITYVOLUME('GrossVolume',$,$,0.15,$);
#341=IFCQUANTITYVOLUME('NetVolume',$,$,0.15,$);


#342=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#343=IFCWALL('0cpBg_MAT4f9kDeUP$2ZgH',#342,'blue_top',$,$,#348,#361,$,.SOLIDWALL.);
#344=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,5.));
#345=IFCDIRECTION((0.,1.,1.19248806385031E-08));
#346=IFCDIRECTION((1.,0.,0.));
#347=IFCAXIS2PLACEMENT3D(#344,#345,#346);
#348=IFCLOCALPLACEMENT($,#347);
#349=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#350=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#351=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#352=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#353=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#354=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#355=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,5.),(0.114820323884487,0.100347764790058,5.),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,5.),(4.89965200424194,0.114821046590805,5.),(4.89965200424194,0.114821046590805,-0.)));
#356=IFCPOLYGONALFACESET(#355,$,(#349,#350,#351,#352,#353,#354),$);
#357=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#356));
#358=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#359=IFCBOUNDINGBOX(#358,5.,5.,5.);
#360=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#359));
#361=IFCPRODUCTDEFINITIONSHAPE($,$,(#360,#357));
#362=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#363=IFCELEMENTQUANTITY('2cnXfFVQj6_BPPvY_mrHPV',#362,'Qto_WallBaseQuantities',$,$,(#366,#367,#368,#369,#370));
#364=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#365=IFCRELDEFINESBYPROPERTIES('3BxSiOEkjCNfKS45P119db',#364,$,$,(#343),#363);
#366=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#367=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#368=IFCQUANTITYLENGTH('Height',$,$,5.,$);
#369=IFCQUANTITYVOLUME('GrossVolume',$,$,2.39,$);
#370=IFCQUANTITYVOLUME('NetVolume',$,$,2.39,$);


#787=IFCSTYLEDITEM(#85,(#62),'Gloss paint blue');
#788=IFCSTYLEDITEM(#101,(#62),'Gloss paint blue');
#789=IFCSTYLEDITEM(#143,(#62),'Gloss paint blue');
#790=IFCSTYLEDITEM(#172,(#62),'Gloss paint blue');
#791=IFCSTYLEDITEM(#201,(#62),'Gloss paint blue');
#792=IFCSTYLEDITEM(#230,(#62),'Gloss paint blue');
#793=IFCSTYLEDITEM(#259,(#62),'Gloss paint blue');
#794=IFCSTYLEDITEM(#298,(#62),'Gloss paint blue');
#795=IFCSTYLEDITEM(#327,(#62),'Gloss paint blue');
#796=IFCSTYLEDITEM(#356,(#62),'Gloss paint blue');
#797=IFCSTYLEDITEM(#385,(#62),'Gloss paint blue');
#798=IFCSTYLEDITEM(#414,(#62),'Gloss paint blue');
#799=IFCSTYLEDITEM(#443,(#62),'Gloss paint blue');
#800=IFCSTYLEDITEM(#472,(#62),'Gloss paint blue');
#801=IFCSTYLEDITEM(#501,(#62),'Gloss paint blue');


ENDSEC;
END-ISO-10303-21;

Description

A Cadastral Parcel defined by a boundary line in 2D. The default geometry of this as a 3D unit is not specified, but may be derived from the boundary as an Extruded Surface using implicit or explicit limits. The boundary property is a sub-property of hasGeometry - so an application could infer the boundary as an available geometry. 

examples:lot1
  a parcel:PrimaryParcel ;
  rdfs:comment "A Cadastral Parcel defined by a boundary line in 2D. The default geometry of this as a 3D unit is not specified, but may be derived from the boundary as an Extruded Surface using implicit or explicit limits. The boundary property is a sub-property of hasGeometry - so an application could infer the boundary as an available geometry." ;
  rdfs:label "Lot 1 (2D)" ;
  geometry:boundary examples:lot1boundary ;
  parcel:appellation examples:Lot1_Appellation ;
  parcel:interest examples:Estate-Lot1 ;
  parcel:type examples:Subdivision ;
.
Informative Examples 
<Parcel gml:id="parcel_1">
  <gml:CompositeSolid>
    <gml:name>Blue spatial unit</gml:name>
    <gml:solidMember>
        <gml:Solid gml:id="s1">
            <gml:name>dim( I(Blue Box) ∩ E(Yellow Box) = 2), ST_Disjoint</gml:name>
            <gml:exterior>
                <gml:Shell>
                    <gml:surfaceMember>
                        <gml:Polygon gml:id="blue_top">
                            <gml:exterior>
                                <gml:LinearRing gml:id="lr1">
                                    <gml:pointProperty xlink:href="#p1"/>
                                    <gml:pointProperty xlink:href="#p4"/>
                                    <gml:pointProperty xlink:href="#p3"/>
                                    <gml:pointProperty xlink:href="#p2"/>
                                    <gml:pointProperty xlink:href="#p1"/>
                                </gml:LinearRing>
                            </gml:exterior>
                        </gml:Polygon>
                    </gml:surfaceMember>

Title

Survey Point - GML

Conforms To

specs:GML

Show Details 
<ex:GML-SpatialUnit>
  a prof:ResourceDescriptor ;
  dct:conformsTo specs:GML ;
  rdfs:label "Survey Point - GML" ;
  skos:editorialNote "This example is only for the GML geometry - the containing feature f_p1 will be based on the model element directly. " ;
  prof:hasArtifact """<Parcel gml:id="parcel_1">
  <gml:CompositeSolid>
    <gml:name>Blue spatial unit</gml:name>
    <gml:solidMember>
        <gml:Solid gml:id="s1">
            <gml:name>dim( I(Blue Box) ∩ E(Yellow Box) = 2), ST_Disjoint</gml:name>
            <gml:exterior>
                <gml:Shell>
                    <gml:surfaceMember>
                        <gml:Polygon gml:id="blue_top">
                            <gml:exterior>
                                <gml:LinearRing gml:id="lr1">
                                    <gml:pointProperty xlink:href="#p1"/>
                                    <gml:pointProperty xlink:href="#p4"/>
                                    <gml:pointProperty xlink:href="#p3"/>
                                    <gml:pointProperty xlink:href="#p2"/>
                                    <gml:pointProperty xlink:href="#p1"/>
                                </gml:LinearRing>
                            </gml:exterior>
                        </gml:Polygon>
                    </gml:surfaceMember>""" ;
.
 
<parcelSurface id="65987456">
            <parcelAnnotation>Retracement of Lot 1 DP 333333</parcelAnnotation>
            <parcelIntent>Fee simple parcel</parcelIntent>
            <parcelAppelation>Lot 1 DP 333333 North Auckland</parcelAppelation>
            <surfaceArea>6867</surfaceArea>
            <parcelArea>6864</parcelArea>
            <titleReference>NA 56872</titleReference>
            <compositeSurface>
                ...
            </compositeSurface>
</parcelSurface >

Title

Parcel-12d

Show Details 
<ex:Parcel12d>
  a prof:ResourceDescriptor ;
  rdfs:label "Parcel-12d" ;
  prof:hasArtifact """<parcelSurface id="65987456">
            <parcelAnnotation>Retracement of Lot 1 DP 333333</parcelAnnotation>
            <parcelIntent>Fee simple parcel</parcelIntent>
            <parcelAppelation>Lot 1 DP 333333 North Auckland</parcelAppelation>
            <surfaceArea>6867</surfaceArea>
            <parcelArea>6864</parcelArea>
            <titleReference>NA 56872</titleReference>
            <compositeSurface>
                ...
            </compositeSurface>
</parcelSurface >""" ;
.
 
<Parcels>
    ...
  <Parcel
      name="1" area="3225.6" parcelType="Single"
      state="proposed" class="Lot"
      useOfParcel="Public Reserve" parcelFormat="Standard">
    <Center/>
    <CoordGeom></CoordGeom>
    <LocationAddress></LocationAddress>
  </Parcel>
  <Parcel
      name="2" parcelType="Multipart">
    <Parcels>
      <Parcel name="A" pclRef="2A"/>
      <Parcel name="B" pclRef="2B"/>
    </Parcels>
  </Parcel>
  <Parcel name="2A" parcelType="Part"></Parcel>
  <Parcel name="2B" parcelType="Part"></Parcel>
  <Parcel
      name="E1" class="Easement"
      desc="Right of Carriageway Variable Width">
    <CoordGeom></CoordGeom>
  </Parcel>
  <Parcel
      name="R1" class="Road"
      desc="NICHOLSONS LANE (20.115 WIDE)">
    <Center/>
    <CoordGeom></CoordGeom>
  </Parcel>

</ Parcels>

Title

Parcel-ePlanNSW

Show Details 
<ex:ParcelEPlanNSW>
  a prof:ResourceDescriptor ;
  rdfs:label "Parcel-ePlanNSW" ;
  prof:hasArtifact """
<Parcels>
    ...
  <Parcel
      name="1" area="3225.6" parcelType="Single"
      state="proposed" class="Lot"
      useOfParcel="Public Reserve" parcelFormat="Standard">
    <Center/>
    <CoordGeom></CoordGeom>
    <LocationAddress></LocationAddress>
  </Parcel>
  <Parcel
      name="2" parcelType="Multipart">
    <Parcels>
      <Parcel name="A" pclRef="2A"/>
      <Parcel name="B" pclRef="2B"/>
    </Parcels>
  </Parcel>
  <Parcel name="2A" parcelType="Part"></Parcel>
  <Parcel name="2B" parcelType="Part"></Parcel>
  <Parcel
      name="E1" class="Easement"
      desc="Right of Carriageway Variable Width">
    <CoordGeom></CoordGeom>
  </Parcel>
  <Parcel
      name="R1" class="Road"
      desc="NICHOLSONS LANE (20.115 WIDE)">
    <Center/>
    <CoordGeom></CoordGeom>
  </Parcel>

</ Parcels>
""" ;
.

10.4.6. Class: Parcel Aggregate

A parcel aggregate is a collection of parcels whose collective extent may be described as a spatial unit.

Note
This superclass supports alignement with the LandInfra concept of a LandPropertyUnit without assuming that this is the only requirement to aggregate parcels.
Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from 3D Spatial Unit

overlaps

[0..*]

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:boundedBy

from 3D Spatial Unit

boundedBy

[0..*]

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

10.4.7. Class: Primary Cadastral Parcel

A parcel that may not overlap with other parcels of the same type - they represent exclusive rights. Different types of primary parcels may be nested within a given type provided no nested parcles are of this type.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from 3D Spatial Unit

overlaps

[0..*]

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:boundedBy

from 3D Spatial Unit

boundedBy

[0..*]

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

parcel:appellation

from Cadastral Parcel

appellation

[1]

Appellation

Specify Unique Parcel ID

Specify Parcel Appellation

parcel:interest

from Cadastral Parcel

[0..*]

Interest In Land

Specify Covenant Information

Specify Title Reference

parcel:qualityClass

from Cadastral Parcel

parcel quality

[0..1]

Quality Classification for Parcel

Specify Parcel Quality

parcel:surfaceArea

from Cadastral Parcel

The surface area of the parcel (in the units defined by the given implementation profile of this standard).

[0..1]

Specify Surface Area

parcel:terrainIntersectionCurve

from Cadastral Parcel

parcel-terrainIntersectionCurve

[0..1]

Linear Ring

Requires a Terrain Intersection Curve

parcel:type

from Cadastral Parcel

parcel type

[1]

Parcel Type

Specify non-primary parcel purpose

Specify Cadastral Parcel Type

Canonical Examples
blue box 

examples:cp1
  a parcel:Parcel ;
  geo:hasGeometry examples:s1 ;
  geo:sfWithin examples:lot1 ;
  rdfs:label "Blue spatial unit" ;
  foaf:depiction <https://surroundbitbucket.bitbucket.io/3d-cadastre/spec/blue_box.png> ;
  geometry:boundedBy examples:blue_yellow_boundary ;
  geometry:hasGeometryPart surveyfeatures_examples:g_p1 ;
  geometry:hasGeometryPart surveyfeatures_examples:g_p10 ;
  parcel:appellation examples:Appellation_Blue_unit ;
  parcel:interest examples:Strata_Title_1 ;
  parcel:surfaceArea 56643.4 ;
  parcel:terrainIntersectionCurve examples:blue_box_terrain ;
  parcel:type examples:Strata ;
.

ISO-10303-21;
HEADER;
FILE_SCHEMA(('IFC4'));
ENDSEC;

DATA;
/* site / project level information - mostly boilerplate*/
#11=IFCPROJECT('1Pv7U_QXf86vJbLHc6LgdI',$,'Project',$,$,$,$,(#20,#27),#15);
#12=IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#13=IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#14=IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#15=IFCUNITASSIGNMENT((#12,#13,#14));
#16=IFCCARTESIANPOINT((0.,0.,0.));
#17=IFCDIRECTION((0.,0.,1.));
#18=IFCDIRECTION((1.,0.,0.));
#19=IFCAXIS2PLACEMENT3D(#16,#17,#18);
#20=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#19,$);
#21=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model',*,*,*,*,#20,$,.MODEL_VIEW.,$);
#22=IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Box','Model',*,*,*,*,#20,$,.MODEL_VIEW.,$);
#23=IFCCARTESIANPOINT((0.,0.,0.));
#24=IFCDIRECTION((0.,0.,1.));
#25=IFCDIRECTION((1.,0.,0.));
#26=IFCAXIS2PLACEMENT3D(#23,#24,#25);
#27=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Plan',2,1.E-05,#26,$);
#32=IFCSITE('1KBmulBMf7MgB4kkr2pyT$',$,'Site',$,$,#47,$,$,$,$,$,$,$,$);
#34=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',$,$,$,#11,(#32));
#36=IFCBUILDING('23JhBYRQDDjws2fDYl7eZ5',$,'Building',$,$,#52,$,$,$,$,$,$);
#38=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',#37,$,$,#32,(#36));
#40=IFCBUILDINGSTOREY('23JhBYRQDDjws2fDYl7eZ5',$,'Building Storey',$,$,#52,$,$,$,$,$,$);
#42=IFCRELAGGREGATES('0MyLGeOvDDiQIJV8BnTpRw',$,$,$,#36,(#40));
#43=IFCCARTESIANPOINT((0.,0.,0.));
#44=IFCDIRECTION((0.,0.,1.));
#45=IFCDIRECTION((1.,0.,0.));
#46=IFCAXIS2PLACEMENT3D(#43,#44,#45);
#47=IFCLOCALPLACEMENT($,#46);
#48=IFCCARTESIANPOINT((0.,0.,0.));
#49=IFCDIRECTION((0.,0.,1.));
#50=IFCDIRECTION((1.,0.,0.));
#51=IFCAXIS2PLACEMENT3D(#48,#49,#50);
#52=IFCLOCALPLACEMENT(#47,#51);


/* IFC object definitions */

/* Traverse Points */
/* survey marker style material definition */
#809=IFCCOLOURRGB($,0.,0.,0.);
#810=IFCCOLOURRGB($,0.,0.,0.);
#811=IFCSURFACESTYLERENDERING(#809 ,0.,#810,$,$,$,$,$,.NOTDEFINED.);
#812=IFCSURFACESTYLE('Survey Marker Black',.BOTH.,(#811));

/* survey marker style material definition */
#813=IFCCOLOURRGB($,0.,0.,1.);
#814=IFCCOLOURRGB($,0.,0.,1.);
#815=IFCSURFACESTYLERENDERING(#813 ,0.,#814,$,$,$,$,$,.NOTDEFINED.);
#816=IFCSURFACESTYLE('Survey Marker Blue',.BOTH.,(#815));

/* style material - Gloss paint blue */
#59=IFCCOLOURRGB($,0.392156863,0.584313725,0.929411765);
#60=IFCCOLOURRGB($,0.392156863,0.584313725,0.929411765);
#61=IFCSURFACESTYLERENDERING(#59,0.,#60,$,$,$,$,$,.NOTDEFINED.);
#62=IFCSURFACESTYLE('Gloss paint blue',.BOTH.,(#61));


/* survey/traverse/occupation marker object - this is a cube */
#825=IFCINDEXEDPOLYGONALFACE((2,4,1));
#826=IFCINDEXEDPOLYGONALFACE((6,8,5));
#827=IFCINDEXEDPOLYGONALFACE((2,7,3));
#828=IFCINDEXEDPOLYGONALFACE((4,5,1));
#829=IFCINDEXEDPOLYGONALFACE((3,6,4));
#830=IFCINDEXEDPOLYGONALFACE((1,8,2));
#831=IFCINDEXEDPOLYGONALFACE((2,3,4));
#832=IFCINDEXEDPOLYGONALFACE((6,7,8));
#833=IFCINDEXEDPOLYGONALFACE((2,8,7));
#834=IFCINDEXEDPOLYGONALFACE((4,6,5));
#835=IFCINDEXEDPOLYGONALFACE((3,7,6));
#836=IFCINDEXEDPOLYGONALFACE((1,5,8));
#837=IFCCARTESIANPOINTLIST3D(((-0.1,0.1,0.1),(-0.1,-0.1,0.1),(0.1,-0.1,0.1),(0.1,0.1,0.1),(-0.1,0.1,-0.1),(0.1,0.1,-0.1),(0.1,-0.1,-0.1),(-0.1,-0.1,-0.1)));
#838=IFCPOLYGONALFACESET(#837,$,(#825,#826,#827,#828,#829,#830,#831,#832,#833,#834,#835,#836),$);
#839=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#838));



#1104=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1105=IFCGEOGRAPHICELEMENT('0000000000P26',#1104,'P1','Survey Point P1 ShowLabel',$,#1110,#1114,$,.USERDEFINED.);
#1106=IFCCARTESIANPOINT((38.089, -31.596, 5.));
#1107=IFCDIRECTION((0.,0.,1.));
#1108=IFCDIRECTION((1.,0.,0.));
#1109=IFCAXIS2PLACEMENT3D(#1106,#1107,#1108);
#1110=IFCLOCALPLACEMENT($,#1109);
#1111=IFCCARTESIANPOINT((38.889, -31.396, 5.));
#1112=IFCBOUNDINGBOX(#1111 ,0.2,0.2,0.2);
#1113=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1112));
#1114=IFCPRODUCTDEFINITIONSHAPE($,$,(#1113,#839));
#6003=IFCSTYLEDITEM(#1105,(#812),'Survey Marker Black');


#840=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#841=IFCGEOGRAPHICELEMENT('0000000000P2',#840,'P2','Survey Point P2 ',$,#846,#850,$,.USERDEFINED.);
#842=IFCCARTESIANPOINT((43.089, -31.596, 5.000));
#843=IFCDIRECTION((0.,0.,1.));
#844=IFCDIRECTION((1.,0.,0.));
#845=IFCAXIS2PLACEMENT3D(#842,#843,#844);
#846=IFCLOCALPLACEMENT($,#845);
#847=IFCCARTESIANPOINT((43.889, -31.396, 5.));
#848=IFCBOUNDINGBOX(#847 ,0.2,0.2,0.2);
#849=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#848));
#850=IFCPRODUCTDEFINITIONSHAPE($,$,(#849,#839));
#6004=IFCSTYLEDITEM(#841,(#816),'Survey Marker Black');

#851=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#852=IFCGEOGRAPHICELEMENT('0000000000P3',#851,'P3','Survey Point P3 ',$,#857,#861,$,.USERDEFINED.);
#853=IFCCARTESIANPOINT((43.089, -36.596, 5.000));
#854=IFCDIRECTION((0.,0.,1.));
#855=IFCDIRECTION((1.,0.,0.));
#856=IFCAXIS2PLACEMENT3D(#853,#854,#855);
#857=IFCLOCALPLACEMENT($,#856);
#858=IFCCARTESIANPOINT((43.889, -36.396, 4.8));
#859=IFCBOUNDINGBOX(#858 ,0.2,0.2,0.2);
#860=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#859));
#861=IFCPRODUCTDEFINITIONSHAPE($,$,(#860,#839));
#6005=IFCSTYLEDITEM(#852,(#816),'Survey Marker Black');

#862=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#863=IFCGEOGRAPHICELEMENT('0000000000P4',#862,'P4','Survey Point P4 ',$,#868,#872,$,.USERDEFINED.);
#864=IFCCARTESIANPOINT((38.089, -36.596, 5.000));
#865=IFCDIRECTION((0.,0.,1.));
#866=IFCDIRECTION((1.,0.,0.));
#867=IFCAXIS2PLACEMENT3D(#864,#865,#866);
#868=IFCLOCALPLACEMENT($,#867);
#869=IFCCARTESIANPOINT((38.889, -36.396, 4.8));
#870=IFCBOUNDINGBOX(#869 ,0.2,0.2,0.2);
#871=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#870));
#872=IFCPRODUCTDEFINITIONSHAPE($,$,(#871,#839));
#6006=IFCSTYLEDITEM(#863,(#816),'Survey Marker Black');


#961=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#962=IFCGEOGRAPHICELEMENT('0000000000P13',#961,'P13','Survey Point P13',$,#967,#971,$,.USERDEFINED.);
#963=IFCCARTESIANPOINT((43.089, -36.596, 0.000));
#964=IFCDIRECTION((0.,0.,1.));
#965=IFCDIRECTION((1.,0.,0.));
#966=IFCAXIS2PLACEMENT3D(#963,#964,#965);
#967=IFCLOCALPLACEMENT($,#966);
#968=IFCCARTESIANPOINT((43.889, -36.396, -0.200));
#969=IFCBOUNDINGBOX(#968 ,0.2,0.2,0.2);
#970=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#969));
#971=IFCPRODUCTDEFINITIONSHAPE($,$,(#970,#839));
#6007=IFCSTYLEDITEM(#962,(#816),'Survey Marker Black');

#972=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#973=IFCGEOGRAPHICELEMENT('0000000000P14',#972,'P14','Survey Point P14',$,#978,#982,$,.USERDEFINED.);
#974=IFCCARTESIANPOINT((38.089, -36.596, 0.000));
#975=IFCDIRECTION((0.,0.,1.));
#976=IFCDIRECTION((1.,0.,0.));
#977=IFCAXIS2PLACEMENT3D(#974,#975,#976);
#978=IFCLOCALPLACEMENT($,#977);
#979=IFCCARTESIANPOINT((38.889, -36.396, -0.200));
#980=IFCBOUNDINGBOX(#979 ,0.2,0.2,0.2);
#981=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#980));
#982=IFCPRODUCTDEFINITIONSHAPE($,$,(#981,#839));
#6008=IFCSTYLEDITEM(#973,(#816),'Survey Marker Black');

#983=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#984=IFCGEOGRAPHICELEMENT('0000000000P15',#983,'P15','Survey Point P15',$,#989,#993,$,.USERDEFINED.);
#985=IFCCARTESIANPOINT((38.089, -31.596, 0.000));
#986=IFCDIRECTION((0.,0.,1.));
#987=IFCDIRECTION((1.,0.,0.));
#988=IFCAXIS2PLACEMENT3D(#985,#986,#987);
#989=IFCLOCALPLACEMENT($,#988);
#990=IFCCARTESIANPOINT((38.889, -31.396, -0.200));
#991=IFCBOUNDINGBOX(#990 ,0.2,0.2,0.2);
#992=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#991));
#993=IFCPRODUCTDEFINITIONSHAPE($,$,(#992,#839));
#6009=IFCSTYLEDITEM(#984,(#816),'Survey Marker Black');

#994=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#995=IFCGEOGRAPHICELEMENT('0000000000P16',#994,'P16','Survey Point P16',$,#1000,#1004,$,.USERDEFINED.);
#996=IFCCARTESIANPOINT((43.089, -31.596, 0.000));
#997=IFCDIRECTION((0.,0.,1.));
#998=IFCDIRECTION((1.,0.,0.));
#999=IFCAXIS2PLACEMENT3D(#996,#997,#998);
#1000=IFCLOCALPLACEMENT($,#999);
#1001=IFCCARTESIANPOINT((43.889, -31.396, -0.200));
#1002=IFCBOUNDINGBOX(#1001 ,0.2,0.2,0.2);
#1003=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1002));
#1004=IFCPRODUCTDEFINITIONSHAPE($,$,(#1003,#839));
#6010=IFCSTYLEDITEM(#995,(#816),'Survey Marker Black');


#1005=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1006=IFCGEOGRAPHICELEMENT('0000000000P17',#1005,'P17','Survey Point P17',$,#1011,#1015,$,.USERDEFINED.);
#1007=IFCCARTESIANPOINT((42.252, -35.717, 2.530));
#1008=IFCDIRECTION((0.,0.,1.));
#1009=IFCDIRECTION((1.,0.,0.));
#1010=IFCAXIS2PLACEMENT3D(#1007,#1008,#1009);
#1011=IFCLOCALPLACEMENT($,#1010);
#1012=IFCCARTESIANPOINT((42.052, -35.517, 2.330));
#1013=IFCBOUNDINGBOX(#1012 ,0.2,0.2,0.2);
#1014=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1013));
#1015=IFCPRODUCTDEFINITIONSHAPE($,$,(#1014,#839));
#6011=IFCSTYLEDITEM(#1006,(#816),'Survey Marker Black');

#1016=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1017=IFCGEOGRAPHICELEMENT('0000000000P18',#1016,'P18','Survey Point P18',$,#1022,#1026,$,.USERDEFINED.);
#1018=IFCCARTESIANPOINT((42.252, -35.717, 4.550));
#1019=IFCDIRECTION((0.,0.,1.));
#1020=IFCDIRECTION((1.,0.,0.));
#1021=IFCAXIS2PLACEMENT3D(#1018,#1019,#1020);
#1022=IFCLOCALPLACEMENT($,#1021);
#1023=IFCCARTESIANPOINT((42.052, -35.517, 4.350));
#1024=IFCBOUNDINGBOX(#1023 ,0.2,0.2,0.2);
#1025=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1024));
#1026=IFCPRODUCTDEFINITIONSHAPE($,$,(#1025,#839));
#6012=IFCSTYLEDITEM(#1017,(#816),'Survey Marker Black');

#1027=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1028=IFCGEOGRAPHICELEMENT('0000000000P19',#1027,'P19','Survey Point P19',$,#1033,#1037,$,.USERDEFINED.);
#1029=IFCCARTESIANPOINT((42.252, -33.717, 4.550));
#1030=IFCDIRECTION((0.,0.,1.));
#1031=IFCDIRECTION((1.,0.,0.));
#1032=IFCAXIS2PLACEMENT3D(#1029,#1030,#1031);
#1033=IFCLOCALPLACEMENT($,#1032);
#1034=IFCCARTESIANPOINT((42.152, -33.517, 4.350));
#1035=IFCBOUNDINGBOX(#1034 ,0.2,0.2,0.2);
#1036=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1035));
#1037=IFCPRODUCTDEFINITIONSHAPE($,$,(#1036,#839));
#6013=IFCSTYLEDITEM(#1028,(#816),'Survey Marker Black');

#1038=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#1039=IFCGEOGRAPHICELEMENT('0000000000P20',#1038,'P20','Survey Point P20',$,#1044,#1048,$,.USERDEFINED.);
#1040=IFCCARTESIANPOINT((42.252, -33.717, 2.530));
#1041=IFCDIRECTION((0.,0.,1.));
#1042=IFCDIRECTION((1.,0.,0.));
#1043=IFCAXIS2PLACEMENT3D(#1040,#1041,#1042);
#1044=IFCLOCALPLACEMENT($,#1043);
#1045=IFCCARTESIANPOINT((42.052, -33.517, 2.330));
#1046=IFCBOUNDINGBOX(#1045 ,0.2,0.2,0.2);
#1047=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#1046));
#1048=IFCPRODUCTDEFINITIONSHAPE($,$,(#1047,#839));
#6014=IFCSTYLEDITEM(#1039,(#816),'Survey Marker Black');

#917=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#918=IFCGEOGRAPHICELEMENT('0000000000P9',#917,'P9','Survey Point P9',$,#923,#927,$,.USERDEFINED.);
#919=IFCCARTESIANPOINT((43.089, -35.717, 4.550));
#920=IFCDIRECTION((0.,0.,1.));
#921=IFCDIRECTION((1.,0.,0.));
#922=IFCAXIS2PLACEMENT3D(#919,#920,#921);
#923=IFCLOCALPLACEMENT($,#922);
#924=IFCCARTESIANPOINT((43.889, -35.517, 4.350));
#925=IFCBOUNDINGBOX(#924 ,0.2,0.2,0.2);
#926=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#925));
#927=IFCPRODUCTDEFINITIONSHAPE($,$,(#926,#839));
#6015=IFCSTYLEDITEM(#918,(#816),'Survey Marker Black');

#928=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#929=IFCGEOGRAPHICELEMENT('0000000000P10',#928,'P10','Survey Point P10 ShowLabel',$,#934,#938,$,.USERDEFINED.);
#930=IFCCARTESIANPOINT((43.089, -33.717, 4.550));
#931=IFCDIRECTION((0.,0.,1.));
#932=IFCDIRECTION((1.,0.,0.));
#933=IFCAXIS2PLACEMENT3D(#930,#931,#932);
#934=IFCLOCALPLACEMENT($,#933);
#935=IFCCARTESIANPOINT((43.889, -33.517, 4.350));
#936=IFCBOUNDINGBOX(#935 ,0.2,0.2,0.2);
#937=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#936));
#938=IFCPRODUCTDEFINITIONSHAPE($,$,(#937,#839));
#6016=IFCSTYLEDITEM(#929,(#812),'Survey Marker Black');

#939=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#940=IFCGEOGRAPHICELEMENT('0000000000P11',#939,'P11','Survey Point P11',$,#945,#949,$,.USERDEFINED.);
#941=IFCCARTESIANPOINT((43.089, -33.717, 2.530));
#942=IFCDIRECTION((0.,0.,1.));
#943=IFCDIRECTION((1.,0.,0.));
#944=IFCAXIS2PLACEMENT3D(#941,#942,#943);
#945=IFCLOCALPLACEMENT($,#944);
#946=IFCCARTESIANPOINT((43.889, -33.517, 2.330));
#947=IFCBOUNDINGBOX(#946 ,0.2,0.2,0.2);
#948=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#947));
#949=IFCPRODUCTDEFINITIONSHAPE($,$,(#948,#839));
#6017=IFCSTYLEDITEM(#940,(#816),'Survey Marker Black');

#950=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903018,#9,#8,1638903018);
#951=IFCGEOGRAPHICELEMENT('0000000000P12',#950,'P12','Survey Point P12',$,#956,#960,$,.USERDEFINED.);
#952=IFCCARTESIANPOINT((43.089, -35.717, 2.530));
#953=IFCDIRECTION((0.,0.,1.));
#954=IFCDIRECTION((1.,0.,0.));
#955=IFCAXIS2PLACEMENT3D(#952,#953,#954);
#956=IFCLOCALPLACEMENT($,#955);
#957=IFCCARTESIANPOINT((43.889, -35.517, 2.330));
#958=IFCBOUNDINGBOX(#957 ,0.2,0.2,0.2);
#959=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#958));
#960=IFCPRODUCTDEFINITIONSHAPE($,$,(#959,#839));
#6018=IFCSTYLEDITEM(#951,(#816),'Survey Marker Black');




#71=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#72=IFCWALL('0ZDZ3jCJ57Hw5fLEKxhgem',#71,'blue_bottom',$,$,#77,#90,$,.SOLIDWALL.);
#73=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.100000001490116));
#74=IFCDIRECTION((0.,1.,1.19248806385031E-08));
#75=IFCDIRECTION((1.,0.,0.));
#76=IFCAXIS2PLACEMENT3D(#73,#74,#75);
#77=IFCLOCALPLACEMENT($,#76);
#78=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#79=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#80=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#81=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#82=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#83=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#84=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,5.),(0.114820323884487,0.100347764790058,5.),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,5.),(4.89965200424194,0.114821046590805,5.),(4.89965200424194,0.114821046590805,-0.)));
#85=IFCPOLYGONALFACESET(#84,$,(#78,#79,#80,#81,#82,#83),$);
#86=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#85));
#87=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#88=IFCBOUNDINGBOX(#87,5.,5.,5.);
#89=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#88));
#90=IFCPRODUCTDEFINITIONSHAPE($,$,(#89,#86));
#91=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#92=IFCELEMENTQUANTITY('00OYWqfTf4LOsVA4fhxz9U',#91,'Qto_WallBaseQuantities',$,$,(#95,#96,#97,#98,#99));
#93=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#94=IFCRELDEFINESBYPROPERTIES('0yhGp9U619jQNJ3jCNGeGY',#93,$,$,(#72),#92);
#95=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#96=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#97=IFCQUANTITYLENGTH('Height',$,$,5.,$);
#98=IFCQUANTITYVOLUME('GrossVolume',$,$,2.39,$);
#99=IFCQUANTITYVOLUME('NetVolume',$,$,2.39,$);


#100=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#101=IFCWALL('2V4MkMOGj4E8ApC9tnAKLP',#100,'blue_front_above_ground',$,$,#106,#119,$,.SOLIDWALL.);
#102=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.300000011920929));
#103=IFCDIRECTION((0.,0.,1.));
#104=IFCDIRECTION((1.,0.,0.));
#105=IFCAXIS2PLACEMENT3D(#102,#103,#104);
#106=IFCLOCALPLACEMENT($,#105);
#107=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#108=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#109=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#110=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#111=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#112=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#113=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,4.69999980926514),(0.114820323884487,0.100347764790058,4.69999980926514),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,4.69999980926514),(4.89965200424194,0.114821046590805,4.69999980926514),(4.89965200424194,0.114821046590805,-0.)));
#114=IFCPOLYGONALFACESET(#113,$,(#107,#108,#109,#110,#111,#112),$);
#115=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#114));
#116=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#117=IFCBOUNDINGBOX(#116,5.,5.,5.);
#118=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#117));
#119=IFCPRODUCTDEFINITIONSHAPE($,$,(#118,#115));
#120=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#121=IFCELEMENTQUANTITY('287UxcYyP2Q9J3SjYrBsJy',#120,'Qto_WallBaseQuantities',$,$,(#124,#125,#126,#127,#128));
#122=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#123=IFCRELDEFINESBYPROPERTIES('1$8j1HnBz6J88Wb3x3CAj_',#122,$,$,(#101),#121);
#124=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#125=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#126=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#127=IFCQUANTITYVOLUME('GrossVolume',$,$,2.25,$);
#128=IFCQUANTITYVOLUME('NetVolume',$,$,2.25,$);


#129=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#130=IFCWALL('0Pj$j_uQ1AC8UbxYN6nDdg',#129,'blue_front_below_ground',$,$,#135,#148,$,.SOLIDWALL.);
#131=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,0.));
#132=IFCDIRECTION((0.,0.,1.));
#133=IFCDIRECTION((1.,0.,0.));
#134=IFCAXIS2PLACEMENT3D(#131,#132,#133);
#135=IFCLOCALPLACEMENT($,#134);
#136=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#137=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#138=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#139=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#140=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#141=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#142=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,0.300000011920929),(0.114820323884487,0.100347764790058,0.300000011920929),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,0.300000011920929),(4.89965200424194,0.114821046590805,0.300000011920929),(4.89965200424194,0.114821046590805,-0.)));
#143=IFCPOLYGONALFACESET(#142,$,(#136,#137,#138,#139,#140,#141),$);
#144=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#143));
#145=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#146=IFCBOUNDINGBOX(#145,5.,5.,5.);
#147=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#146));
#148=IFCPRODUCTDEFINITIONSHAPE($,$,(#147,#144));
#149=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#150=IFCELEMENTQUANTITY('1iabEfUUT9ZBZbbKYHHNNq',#149,'Qto_WallBaseQuantities',$,$,(#153,#154,#155,#156,#157));
#151=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#152=IFCRELDEFINESBYPROPERTIES('0lwAAcoFP0thWTNM4DSKWX',#151,$,$,(#130),#150);
#153=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#154=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#155=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#156=IFCQUANTITYVOLUME('GrossVolume',$,$,0.14,$);
#157=IFCQUANTITYVOLUME('NetVolume',$,$,0.14,$);



#158=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#159=IFCWALL('3zDy7ve$93B9oYmgkgIjTt',#158,'blue_left_above_ground',$,$,#164,#177,$,.SOLIDWALL.);
#160=IFCCARTESIANPOINT((38.0890007019043,-31.5960006713867,0.300000011920929));
#161=IFCDIRECTION((0.,0.,1.));
#162=IFCDIRECTION((1.19248806385031E-08,-1.,0.));
#163=IFCAXIS2PLACEMENT3D(#160,#161,#162);
#164=IFCLOCALPLACEMENT($,#163);
#165=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#166=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#167=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#168=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#169=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#170=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#171=IFCCARTESIANPOINTLIST3D(((0.,0.,-0.),(0.,0.,4.69999980926514),(-0.000302481203107163,0.0999995395541191,4.69999980926514),(-0.000302481203107163,0.0999995395541191,-0.),(4.99997711181641,0.0151240592822433,-0.),(4.99997711181641,0.0151240592822433,4.69999980926514),(4.99967479705811,0.115123599767685,4.69999980926514),(4.99967479705811,0.115123599767685,-0.)));
#172=IFCPOLYGONALFACESET(#171,$,(#165,#166,#167,#168,#169,#170),$);
#173=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#172));
#174=IFCCARTESIANPOINT((-0.000302481203107163,0.,-0.));
#175=IFCBOUNDINGBOX(#174,5.,5.,5.);
#176=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#175));
#177=IFCPRODUCTDEFINITIONSHAPE($,$,(#176,#173));
#178=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#179=IFCELEMENTQUANTITY('3iiDuUrQb3JvzQkbH3yjpY',#178,'Qto_WallBaseQuantities',$,$,(#182,#183,#184,#185,#186));
#180=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#181=IFCRELDEFINESBYPROPERTIES('3AB7qQcqH8XQ4avUWOQYmq',#180,$,$,(#159),#179);
#182=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#183=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#184=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#185=IFCQUANTITYVOLUME('GrossVolume',$,$,2.35,$);
#186=IFCQUANTITYVOLUME('NetVolume',$,$,2.35,$);


#187=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#188=IFCWALL('0_Nvu$MCr5xPQL_UDcevAD',#187,'blue_left_below_ground',$,$,#193,#206,$,.SOLIDWALL.);
#189=IFCCARTESIANPOINT((38.0890007019043,-31.5960006713867,0.));
#190=IFCDIRECTION((0.,0.,1.));
#191=IFCDIRECTION((1.19248806385031E-08,-1.,0.));
#192=IFCAXIS2PLACEMENT3D(#189,#190,#191);
#193=IFCLOCALPLACEMENT($,#192);
#194=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#195=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#196=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#197=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#198=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#199=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#200=IFCCARTESIANPOINTLIST3D(((0.,0.,-0.),(0.,0.,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.300000011920929),(-0.000302481203107163,0.0999995395541191,-0.),(4.99997711181641,0.0151240592822433,-0.),(4.99997711181641,0.0151240592822433,0.300000011920929),(4.99967479705811,0.115123599767685,0.300000011920929),(4.99967479705811,0.115123599767685,-0.)));
#201=IFCPOLYGONALFACESET(#200,$,(#194,#195,#196,#197,#198,#199),$);
#202=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#201));
#203=IFCCARTESIANPOINT((-0.000302481203107163,0.,-0.));
#204=IFCBOUNDINGBOX(#203,5.,5.,5.);
#205=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#204));
#206=IFCPRODUCTDEFINITIONSHAPE($,$,(#205,#202));
#207=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#208=IFCELEMENTQUANTITY('07czp0AcrBe9IMMUoawVu_',#207,'Qto_WallBaseQuantities',$,$,(#211,#212,#213,#214,#215));
#209=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#210=IFCRELDEFINESBYPROPERTIES('0dc6e5x2D3MB15C0VLFU9L',#209,$,$,(#188),#208);
#211=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#212=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#213=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#214=IFCQUANTITYVOLUME('GrossVolume',$,$,0.15,$);
#215=IFCQUANTITYVOLUME('NetVolume',$,$,0.15,$);


#216=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903015,#9,#8,1638903015);
#217=IFCWALL('1CscwCyIL6s8mT9FmGysNV',#216,'blue_rear_above_ground',$,$,#222,#235,$,.SOLIDWALL.);
#218=IFCCARTESIANPOINT((43.0890007019043,-31.5960006713867,0.300000011920929));
#219=IFCDIRECTION((0.,0.,1.));
#220=IFCDIRECTION((-1.,-3.25841369885893E-07,0.));
#221=IFCAXIS2PLACEMENT3D(#218,#219,#220);
#222=IFCLOCALPLACEMENT($,#221);
#223=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#224=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#225=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#226=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#227=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#228=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#229=IFCCARTESIANPOINTLIST3D(((0.115124225616455,0.000348230707459152,-0.),(0.115124225616455,0.000348230707459152,4.69999980926514),(0.114821746945381,0.100347772240639,4.69999980926514),(0.114821746945381,0.100347772240639,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,4.69999980926514),(4.89965200424194,0.114821046590805,4.69999980926514),(4.89965200424194,0.114821046590805,-0.)));
#230=IFCPOLYGONALFACESET(#229,$,(#223,#224,#225,#226,#227,#228),$);
#231=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#230));
#232=IFCCARTESIANPOINT((0.114821746945381,0.000348230707459152,-0.));
#233=IFCBOUNDINGBOX(#232,5.,5.,5.);
#234=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#233));
#235=IFCPRODUCTDEFINITIONSHAPE($,$,(#234,#231));
#236=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#237=IFCELEMENTQUANTITY('0kjU8tcW9BZ8iYoK4d7J74',#236,'Qto_WallBaseQuantities',$,$,(#240,#241,#242,#243,#244));
#238=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903015,#9,#8,1638903015);
#239=IFCRELDEFINESBYPROPERTIES('3s3Ubvwu1AyAVvOn0p4C5u',#238,$,$,(#217),#237);
#240=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#241=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#242=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#243=IFCQUANTITYVOLUME('GrossVolume',$,$,2.25,$);
#244=IFCQUANTITYVOLUME('NetVolume',$,$,2.25,$);


#245=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#246=IFCWALL('3Qp2Tio6X6_hsGdiXTzWRu',#245,'blue_rear_below_ground',$,$,#251,#264,$,.SOLIDWALL.);
#247=IFCCARTESIANPOINT((43.0890007019043,-31.5960006713867,0.));
#248=IFCDIRECTION((0.,0.,1.));
#249=IFCDIRECTION((-1.,-3.25841369885893E-07,0.));
#250=IFCAXIS2PLACEMENT3D(#247,#248,#249);
#251=IFCLOCALPLACEMENT($,#250);
#252=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#253=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#254=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#255=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#256=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#257=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#258=IFCCARTESIANPOINTLIST3D(((0.115124225616455,0.000348230707459152,-0.),(0.115124225616455,0.000348230707459152,0.300000011920929),(0.114821746945381,0.100347772240639,0.300000011920929),(0.114821746945381,0.100347772240639,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,0.300000011920929),(4.89965200424194,0.114821046590805,0.300000011920929),(4.89965200424194,0.114821046590805,-0.)));
#259=IFCPOLYGONALFACESET(#258,$,(#252,#253,#254,#255,#256,#257),$);
#260=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#259));
#261=IFCCARTESIANPOINT((0.114821746945381,0.000348230707459152,-0.));
#262=IFCBOUNDINGBOX(#261,5.,5.,5.);
#263=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#262));
#264=IFCPRODUCTDEFINITIONSHAPE($,$,(#263,#260));
#265=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#266=IFCELEMENTQUANTITY('2xeUzEs75749mejl$nY4NI',#265,'Qto_WallBaseQuantities',$,$,(#269,#270,#271,#272,#273));
#267=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#268=IFCRELDEFINESBYPROPERTIES('3k4Idi9cf9axIZXwQkQ_ID',#267,$,$,(#246),#266);
#269=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#270=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#271=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#272=IFCQUANTITYVOLUME('GrossVolume',$,$,0.14,$);
#273=IFCQUANTITYVOLUME('NetVolume',$,$,0.14,$);


#274=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#275=IFCWALL('129gVASXH6lfsqgVdtpKFf',#274,'blue_right_above_ground',$,$,#280,#303,$,.SOLIDWALL.);
#276=IFCCARTESIANPOINT((43.0890007019043,-36.5960006713867,0.300000011920929));
#277=IFCDIRECTION((0.,0.,1.));
#278=IFCDIRECTION((-4.37113882867379E-08,1.,0.));
#279=IFCAXIS2PLACEMENT3D(#276,#277,#278);
#280=IFCLOCALPLACEMENT($,#279);
#281=IFCINDEXEDPOLYGONALFACE((12,13,2,1,5,6,14,15,9,11,10));
#282=IFCINDEXEDPOLYGONALFACE((14,6,2,13,16));
#283=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#284=IFCINDEXEDPOLYGONALFACE((18,3,7,21,17));
#285=IFCINDEXEDPOLYGONALFACE((7,8,4,3,18,23,22,24,19,20,21));
#286=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#287=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#288=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#289=IFCINDEXEDPOLYGONALFACE((14,16,17,21));
#290=IFCINDEXEDPOLYGONALFACE((11,9,19,24));
#291=IFCINDEXEDPOLYGONALFACE((18,13,12,23));
#292=IFCINDEXEDPOLYGONALFACE((15,14,21,20));
#293=IFCINDEXEDPOLYGONALFACE((16,13,18,17));
#294=IFCINDEXEDPOLYGONALFACE((22,10,11,24));
#295=IFCINDEXEDPOLYGONALFACE((12,10,22,23));
#296=IFCINDEXEDPOLYGONALFACE((15,20,19,9));
#297=IFCCARTESIANPOINTLIST3D(((0.,0.,0.),(0.,0.,4.69999980926514),(-0.000302481203107163,0.0999995395541191,4.69999980926514),(-0.000302481203107163,0.0999995395541191,0.),(4.99997711181641,0.0151240592822433,0.),(4.99997711181641,0.0151240592822433,4.69999980926514),(4.99967479705811,0.115123599767685,4.69999980926514),(4.99967479705811,0.115123599767685,0.),(2.87900137901306,0.00870847795158625,2.23000001907349),(0.879001438617706,0.00265882606618106,2.23000001907349),(1.71082830429077,0.00517495768144727,2.23000001907349),(0.879001438617706,0.00265882606618106,3.40731334686279),(0.879001438617706,0.00265882606618106,4.25),(2.87900137901306,0.00870847795158625,4.25),(2.87900137901306,0.00870847795158625,3.0665762424469),(1.71082830429077,0.00517495768144727,4.25),(1.61112952232361,0.104873843491077,4.25),(0.879001438617706,0.102659277617931,4.25),(2.87900137901306,0.108708932995796,2.23000001907349),(2.87900137901306,0.108708932995796,2.96557569503784),(2.87900137901306,0.108708932995796,4.25),(0.879001438617706,0.102659277617931,2.23000001907349),(0.879001438617706,0.102659277617931,3.50831365585327),(1.61112952232361,0.104873843491077,2.23000001907349)));
#298=IFCPOLYGONALFACESET(#297,$,(#281,#282,#283,#284,#285,#286,#287,#288,#289,#290,#291,#292,#293,#294,#295,#296),$);
#299=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#298));
#300=IFCCARTESIANPOINT((-0.000302481203107163,0.,0.));
#301=IFCBOUNDINGBOX(#300,5.,5.,5.);
#302=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#301));
#303=IFCPRODUCTDEFINITIONSHAPE($,$,(#302,#299));
#304=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#305=IFCELEMENTQUANTITY('0nOs4nPrf6wh4F0wmANHnO',#304,'Qto_WallBaseQuantities',$,$,(#308,#309,#310,#311,#312));
#306=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#307=IFCRELDEFINESBYPROPERTIES('11D65eHcbCGPqd8yDJmiQ1',#306,$,$,(#275),#305);
#308=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#309=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#310=IFCQUANTITYLENGTH('Height',$,$,4.7,$);
#311=IFCQUANTITYVOLUME('GrossVolume',$,$,2.35,$);
#312=IFCQUANTITYVOLUME('NetVolume',$,$,2.35,$);


#313=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#314=IFCWALL('1POQQ24hzEQ80As95tMhP1',#313,'blue_right_below_ground',$,$,#319,#332,$,.SOLIDWALL.);
#315=IFCCARTESIANPOINT((43.0890007019043,-36.5960006713867,0.));
#316=IFCDIRECTION((0.,0.,1.));
#317=IFCDIRECTION((-4.37113882867379E-08,1.,0.));
#318=IFCAXIS2PLACEMENT3D(#315,#316,#317);
#319=IFCLOCALPLACEMENT($,#318);
#320=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#321=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#322=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#323=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#324=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#325=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#326=IFCCARTESIANPOINTLIST3D(((0.,0.,0.),(0.,0.,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.300000011920929),(-0.000302481203107163,0.0999995395541191,0.),(4.99997711181641,0.0151240592822433,0.),(4.99997711181641,0.0151240592822433,0.300000011920929),(4.99967479705811,0.115123599767685,0.300000011920929),(4.99967479705811,0.115123599767685,0.)));
#327=IFCPOLYGONALFACESET(#326,$,(#320,#321,#322,#323,#324,#325),$);
#328=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#327));
#329=IFCCARTESIANPOINT((-0.000302481203107163,0.,0.));
#330=IFCBOUNDINGBOX(#329,5.,5.,5.);
#331=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#330));
#332=IFCPRODUCTDEFINITIONSHAPE($,$,(#331,#328));
#333=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#334=IFCELEMENTQUANTITY('3Z3E2eBHXAaPhfLMDmu754',#333,'Qto_WallBaseQuantities',$,$,(#337,#338,#339,#340,#341));
#335=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#336=IFCRELDEFINESBYPROPERTIES('00YhtGu$r2NQjr1aNTofM7',#335,$,$,(#314),#334);
#337=IFCQUANTITYLENGTH('Length',$,$,10.,$);
#338=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#339=IFCQUANTITYLENGTH('Height',$,$,0.3,$);
#340=IFCQUANTITYVOLUME('GrossVolume',$,$,0.15,$);
#341=IFCQUANTITYVOLUME('NetVolume',$,$,0.15,$);


#342=IFCOWNERHISTORY(#9,#8,.READWRITE.,.MODIFIED.,1638903016,#9,#8,1638903016);
#343=IFCWALL('0cpBg_MAT4f9kDeUP$2ZgH',#342,'blue_top',$,$,#348,#361,$,.SOLIDWALL.);
#344=IFCCARTESIANPOINT((38.0890007019043,-36.5960006713867,5.));
#345=IFCDIRECTION((0.,1.,1.19248806385031E-08));
#346=IFCDIRECTION((1.,0.,0.));
#347=IFCAXIS2PLACEMENT3D(#344,#345,#346);
#348=IFCLOCALPLACEMENT($,#347);
#349=IFCINDEXEDPOLYGONALFACE((1,5,6,2));
#350=IFCINDEXEDPOLYGONALFACE((2,6,7,3));
#351=IFCINDEXEDPOLYGONALFACE((3,7,8,4));
#352=IFCINDEXEDPOLYGONALFACE((4,8,5,1));
#353=IFCINDEXEDPOLYGONALFACE((2,3,4,1));
#354=IFCINDEXEDPOLYGONALFACE((5,8,7,6));
#355=IFCCARTESIANPOINTLIST3D(((0.115122802555561,0.000348226400092244,-0.),(0.115122802555561,0.000348226400092244,5.),(0.114820323884487,0.100347764790058,5.),(0.114820323884487,0.100347764790058,-0.),(4.8999547958374,0.0148215098306537,-0.),(4.8999547958374,0.0148215098306537,5.),(4.89965200424194,0.114821046590805,5.),(4.89965200424194,0.114821046590805,-0.)));
#356=IFCPOLYGONALFACESET(#355,$,(#349,#350,#351,#352,#353,#354),$);
#357=IFCSHAPEREPRESENTATION(#21,'Body','Tessellation',(#356));
#358=IFCCARTESIANPOINT((0.114820323884487,0.000348226400092244,-0.));
#359=IFCBOUNDINGBOX(#358,5.,5.,5.);
#360=IFCSHAPEREPRESENTATION(#22,'Box','BoundingBox',(#359));
#361=IFCPRODUCTDEFINITIONSHAPE($,$,(#360,#357));
#362=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#363=IFCELEMENTQUANTITY('2cnXfFVQj6_BPPvY_mrHPV',#362,'Qto_WallBaseQuantities',$,$,(#366,#367,#368,#369,#370));
#364=IFCOWNERHISTORY(#9,#8,.READWRITE.,.ADDED.,1638903016,#9,#8,1638903016);
#365=IFCRELDEFINESBYPROPERTIES('3BxSiOEkjCNfKS45P119db',#364,$,$,(#343),#363);
#366=IFCQUANTITYLENGTH('Length',$,$,9.57,$);
#367=IFCQUANTITYLENGTH('Width',$,$,0.1,$);
#368=IFCQUANTITYLENGTH('Height',$,$,5.,$);
#369=IFCQUANTITYVOLUME('GrossVolume',$,$,2.39,$);
#370=IFCQUANTITYVOLUME('NetVolume',$,$,2.39,$);


#787=IFCSTYLEDITEM(#85,(#62),'Gloss paint blue');
#788=IFCSTYLEDITEM(#101,(#62),'Gloss paint blue');
#789=IFCSTYLEDITEM(#143,(#62),'Gloss paint blue');
#790=IFCSTYLEDITEM(#172,(#62),'Gloss paint blue');
#791=IFCSTYLEDITEM(#201,(#62),'Gloss paint blue');
#792=IFCSTYLEDITEM(#230,(#62),'Gloss paint blue');
#793=IFCSTYLEDITEM(#259,(#62),'Gloss paint blue');
#794=IFCSTYLEDITEM(#298,(#62),'Gloss paint blue');
#795=IFCSTYLEDITEM(#327,(#62),'Gloss paint blue');
#796=IFCSTYLEDITEM(#356,(#62),'Gloss paint blue');
#797=IFCSTYLEDITEM(#385,(#62),'Gloss paint blue');
#798=IFCSTYLEDITEM(#414,(#62),'Gloss paint blue');
#799=IFCSTYLEDITEM(#443,(#62),'Gloss paint blue');
#800=IFCSTYLEDITEM(#472,(#62),'Gloss paint blue');
#801=IFCSTYLEDITEM(#501,(#62),'Gloss paint blue');


ENDSEC;
END-ISO-10303-21;
 

examples:cp2
  a parcel:Parcel ;
  geo:hasGeometry examples:s2 ;
  rdfs:label "Yellow spatial unit" ;
  geometry:boundedBy examples:blue_yellow_boundary ;
  parcel:appellation examples:Appellation_Yellow_Unit ;
  parcel:type examples:Strata ;
.

Description

A Cadastral Parcel defined by a boundary line in 2D. The default geometry of this as a 3D unit is not specified, but may be derived from the boundary as an Extruded Surface using implicit or explicit limits. The boundary property is a sub-property of hasGeometry - so an application could infer the boundary as an available geometry. 

examples:lot1
  a parcel:PrimaryParcel ;
  rdfs:comment "A Cadastral Parcel defined by a boundary line in 2D. The default geometry of this as a 3D unit is not specified, but may be derived from the boundary as an Extruded Surface using implicit or explicit limits. The boundary property is a sub-property of hasGeometry - so an application could infer the boundary as an available geometry." ;
  rdfs:label "Lot 1 (2D)" ;
  geometry:boundary examples:lot1boundary ;
  parcel:appellation examples:Lot1_Appellation ;
  parcel:interest examples:Estate-Lot1 ;
  parcel:type examples:Subdivision ;
.

Description

A Cadastral Parcel defined by an extruded surface. The bounding geometry of this in 2D is also specified. 

examples:lot1_extruded
  a parcel:PrimaryParcel ;
  rdfs:comment "A Cadastral Parcel defined by an extruded surface.  The bounding geometry of this in 2D is also specified." ;
  rdfs:label "Lot 1 (3D, extruded)" ;
  geometry:boundary examples:lot1boundary ;
  parcel:appellation examples:Lot1_Appellation ;
  parcel:interest examples:Estate-Lot1 ;
  parcel:surface examples:lot1_surface ;
  parcel:type examples:Subdivision ;
.

10.4.8. Class: Secondary Cadastral Parcel

A parcel representing the extent of a non-exclusive right. Non-primary parcels may overlap primary parcels

Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

geo:ehOverlap

from Secondary Cadastral Parcel, 3D Spatial Unit

Allow a secondary parcel to overlap any other type of parcel.

overlaps

[0..*]

Cadastral Parcel

3D Spatial Unit

Intersections with other 3D Spatial Units

geo:hasGeometry

from 3D Spatial Unit, Feature

Constrain geometry to a form that supports calculation of interior and surface domains.

hasGeometry property inherited from geo:Feature

[0..*]

Abstract Solid Geometry

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geo:hasGeometry

from Feature

hasGeometry property inherited from geo:Feature

[0..*]

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

geometry:hasGeometryPart

from 3D Spatial Unit

A component geometry part potentially containing references to reusable used in the main geometry representation

[0..*]

Geometry

Solid Geometry Requires Topology

Geometries to be Referenced

parcel:appellation

from Cadastral Parcel

appellation

[1]

Appellation

Specify Unique Parcel ID

Specify Parcel Appellation

parcel:interest

from Cadastral Parcel

[0..*]

Interest In Land

Specify Covenant Information

Specify Title Reference

parcel:qualityClass

from Cadastral Parcel

parcel quality

[0..1]

Quality Classification for Parcel

Specify Parcel Quality

parcel:surfaceArea

from Cadastral Parcel

The surface area of the parcel (in the units defined by the given implementation profile of this standard).

[0..1]

Specify Surface Area

parcel:terrainIntersectionCurve

from Cadastral Parcel

parcel-terrainIntersectionCurve

[0..1]

Linear Ring

Requires a Terrain Intersection Curve

parcel:type

from Cadastral Parcel

parcel type

[1]

Parcel Type

Specify non-primary parcel purpose

Specify Cadastral Parcel Type

Informative Examples 
<Parcel
    name="E1" class="Easement"
    state="proposed" parcelFormat="Standard"
    parcelType="Single" desc="Right of Carriageway over track in use">
  <Center pntRef="LC-137"/>
  <CoordGeom name="E1">
    <IrregularLine desc="Approximate position of centreline of track in use"
        source="as determined by Aerial photograph – see film 4354 frame 77, 24 March 1997">
      <Start pntRef="11"/>
      <End pntRef="12"/>
      <PntList2D>1322.137070 897.047360
          1315.916630 896.467670
          1310.226980 897.991240
          1303.757680 903.401480
          1294.458130 911.729520
          1206.212380 967.435920
          1195.584230 974.819390
          1188.710850 975.722460
          1183.368710 976.036190
          1177.116210 974.874520
          1170.836800 971.127850
          1162.738330 965.201400
          1157.406840 961.6
          1289.443320 915.970390
      </PntList2D>
    </IrregularLine>
  </CoordGeom>
</Parcel>

Title

Easement-ePlanNSW

Show Details 
<ex:EasementEPlanNSW>
  a prof:ResourceDescriptor ;
  rdfs:label "Easement-ePlanNSW" ;
  skos:editorialNote "Easement is captured in ePlan as a class attribute of Parcel" ;
  prof:hasArtifact """<Parcel
    name="E1" class="Easement"
    state="proposed" parcelFormat="Standard"
    parcelType="Single" desc="Right of Carriageway over track in use">
  <Center pntRef="LC-137"/>
  <CoordGeom name="E1">
    <IrregularLine desc="Approximate position of centreline of track in use"
        source="as determined by Aerial photograph – see film 4354 frame 77, 24 March 1997">
      <Start pntRef="11"/>
      <End pntRef="12"/>
      <PntList2D>1322.137070 897.047360
          1315.916630 896.467670
          1310.226980 897.991240
          1303.757680 903.401480
          1294.458130 911.729520
          1206.212380 967.435920
          1195.584230 974.819390
          1188.710850 975.722460
          1183.368710 976.036190
          1177.116210 974.874520
          1170.836800 971.127850
          1162.738330 965.201400
          1157.406840 961.6
          1289.443320 915.970390
      </PntList2D>
    </IrregularLine>
  </CoordGeom>
</Parcel>
""" ;
.

Title

Easement-InfraGML

Show Details 
<ex:EasementInfraGML>
  a prof:ResourceDescriptor ;
  rdfs:label "Easement-InfraGML" ;
  skos:editorialNote "cannot paste example" ;
  prof:hasArtifact "" ;
.

Title

Easement-LADM

Show Details 
<ex:EasementLADM>
  a prof:ResourceDescriptor ;
  rdfs:label "Easement-LADM" ;
  skos:editorialNote "Easements are not directly related to the spatial unit. Easements are captured as a LA_Right:LA_RightType. This is attached to the LA_BAUnit which in turn is attached to the LA_SpatialUnit. They may then also be assigned a "Level" called easements." ;
.

10.5. Conformance Class: Container

https://linked.data.gov.au/def/csdm/container

10.5.1. Class: Cadastral Survey Dataset

The set of cadastral survey data necessary to integrate a cadastral survey into, or transfer survey observations from, a cadastral database. A CSD identifier may be used to reference a previous survey.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

container:adoptedObservations

from Cadastral Survey Dataset

Adopted observations (collection)

[0..*]

Collection of observations

container:bearingRotation

from Cadastral Survey Dataset

Bearing Rotation to adopt when referencing vectors in this CSD.

[0..*]

Report Adopted Bearing Rotations

Report Adopted Bearing Rotations

container:horizontalCRS

from Cadastral Survey Dataset

Horizontal CRS - in form to be defined by encoding requirements.

[1]

Specify Survey Orientation

container:occupationFeatures

from Cadastral Survey Dataset

A set of feature descriptions for occupation evidence. May be referenced by occupation observations for extended detail, or presence of such features inferred by presence of observations. This property supports use of multipe collections of features sourced from other systems.

[0..*]

Feature

container:occupationObservations

from Cadastral Survey Dataset

Optional observations about the nature of occupations, allowing arbitrary additional details to be recorded.

[0..*]

Collection of observations

container:parcels

from Cadastral Survey Dataset

[0..*]

Feature Collection

container:points

from Cadastral Survey Dataset

[0..*]

Feature Collection

Includes Boundary Marks

container:referencedCSD

from Cadastral Survey Dataset

A CSD containing referenced survey features and observations

[0..*]

Cadastral Survey Dataset

container:surveyProvenance

from Cadastral Survey Dataset

A bundle of survey provenance information must be present.

[1]

Bundle

Record dates relating to CSD status

container:surveyType

from Cadastral Survey Dataset

survey type

[1]

Survey Type

Survey Type

container:vectorObservations

from Cadastral Survey Dataset

The set of observations of surveyed vectors between SurveyPoints

[0..1]

Collection of observations

container:verticalDatum

from Cadastral Survey Dataset

Vertical Datum - in form to be defined by encoding requirements.

[0..1]

Vertical Datum

Vertical Datum

Specify Vertical Datum

Specify Vertical Datum

prov:alternateOf

from Entity

[0..*]

Entity

prov:atLocation

from Entity

[0..*]

Location

prov:generatedAtTime

from Entity

Generated at date or datetime

[0..*]

prov:hadPrimarySource

from Entity

[0..*]

Entity

prov:invalidatedAtTime

from Entity

[0..*]

prov:qualifiedAttribution

from Entity

[0..*]

Attribution

prov:qualifiedDerivation

from Entity

[0..*]

Derivation

prov:qualifiedGeneration

from Entity

[0..*]

Generation

prov:qualifiedInfluence

from Entity

[0..*]

Influence

prov:qualifiedInvalidation

from Entity

[0..*]

Invalidation

prov:qualifiedPrimarySource

from Entity

[0..*]

PrimarySource

prov:qualifiedQuotation

from Entity

[0..*]

Quotation

prov:qualifiedRevision

from Entity

[0..*]

Revision

prov:specializationOf

from Entity

[0..*]

Entity

prov:value

from Entity

[0..*]

prov:wasAttributedTo

from Entity

[0..*]

Agent

prov:wasDerivedFrom

from Entity

[0..*]

Entity

prov:wasGeneratedBy

from Entity

[0..*]

Activity

Record dates relating to CSD status

prov:wasInfluencedBy

from Entity

[0..*]

prov:wasInvalidatedBy

from Entity

[0..*]

Activity

prov:wasQuotedFrom

from Entity

[0..*]

Entity

prov:wasRevisionOf

from Entity

[0..*]

Entity

rdfs:seeAlso

from Cadastral Survey Dataset

Reference to a report or document with metadata about form and purpose?

[0..*]

Report

To Include Survey Adjustment Report

Field Record

Field Record

Field Record

To include Field Record

To include Field Record

To include Field Record

Survey Report

To Include Survey Report

To Include Correspondence

surv:purpose

from Cadastral Survey Dataset

[1]

Survey Purpose

State the purpose of a survey

Images
CSD logical
Figure 16. Diagram for Cadastral Survey Dataset

Format

image/png

Canonical Examples 

examples1:SurveyExample
  a container:CSD ;
  rdfs:label "Example Cadastral Survey Dataset" ;
  prov:wasGeneratedBy surveyobs_examples:surveyActivity1 ;
  container:calculatedObservations surveyobs_examples:calculated_observations ;
  container:occupationFeatures surveyobs_examples:fence1 ;
  container:referencedCSD surveyobs_examples:csd2 ;
  container:vectorObservations surveyobs_examples:vector_observations ;
.

10.6. Conformance Class: Provenance Profile

https://linked.data.gov.au/def/csdm/prov_profile_survey_dates

10.6.1. Class: Cadastral Surveyor

An identified agent licensed to undertake cadastral surveys.

Subclass of
Requirements
Canonical Examples

10.6.2. Class: Survey Activity

Entities, Activities and Agents for Cadastral Survey Data Exchange Activities.

Subclass of

10.6.3. Class: Survey CSD Lifecycle Activity

An activity in the lifecycle of a survey

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

prov:atLocation

from Activity

[0..*]

Location

prov:endedAtTime

from Activity

[0..*]

prov:generated

from Activity

[0..*]

Entity

prov:invalidated

from Activity

[0..*]

Entity

prov:qualifiedAssociation

from Activity

[0..*]

Association

prov:qualifiedCommunication

from Activity

[0..*]

Communication

prov:qualifiedEnd

from Activity

[0..*]

End

prov:qualifiedInfluence

from Activity

[0..*]

Influence

prov:qualifiedStart

from Activity

[0..*]

Start

prov:qualifiedUsage

from Activity

[0..*]

Usage

prov:startedAtTime

from Activity

[0..*]

prov:used

from Activity

[0..*]

Entity

prov:wasAssociatedWith

from Activity

[0..*]

Agent

prov:wasEndedBy

from Activity

[0..*]

Entity

prov:wasInfluencedBy

from Activity

[0..*]

prov:wasInformedBy

from Activity

[0..*]

Activity

prov:wasStartedBy

from Activity

[0..*]

Entity

sop:entailedWith

from Activity

The object is a rule entity used to infer additional information and add to the generated object

[0..*]

Entity

sop:transformedWith

from Activity

Transformed With

[0..*]

Entity

sop:usedConfig

from Activity

Used configuration

[0..*]

Entity

sop:usedRule

from Activity

Used Inferencing Rules

[0..*]

Entity

sop:usedSource

from Activity

Used Data Source

[0..*]

Entity

sop:userAgent

from Activity

User invoking activity

[1..*]

sop:validatedWith

from Activity

Validated With

[0..*]

Entity

Canonical Examples 

surveyobs_examples:extractCSD_1
  a survprov:SurveyActivity ;
  rdfs:label "Extract survey observations for parcel cp1 (Blue Spatial Unit )" ;
  prov:endedAtTime "20010120" ;
  prov:wasAssociatedWith <ex:LandOnlineNZ> ;
  prov:wasAttributedTo <ex:AH> ;
.
 

surveyobs_examples:surveyActivity1
  a survprov:SurveyActivity ;
  rdfs:label "Example typed activity using provenance model" ;
  prov:endedAtTime "2001-01-15T12:00:00"^^xsd:dateTime ;
.

10.6.4. Class: SurveyAgent

PROV Agent types

Subclass of

  • Agent (From W3C PROVenance Interchange Ontology (PROV-O) )

  • Survey Activity (From Provenance Profile )

Properties
Property Description Cardinality Range Use Case Requirement

prov:actedOnBehalfOf

from Agent

[0..*]

Agent

prov:atLocation

from Agent

[0..*]

Location

prov:qualifiedDelegation

from Agent

[0..*]

Delegation

prov:qualifiedInfluence

from Agent

[0..*]

Influence

prov:wasInfluencedBy

from Agent

[0..*]

Canonical Examples 

<ex:AH>
  a survprov:CadastralSurveyor ;
  rdfs:label "Andrew Hunter" ;
.

10.6.5. Class: SurveyEntity

A data object influenced by a SurveyActivity, such as a Cadastral Survey Dataset (CSD)

Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

prov:alternateOf

from Entity

[0..*]

Entity

prov:atLocation

from Entity

[0..*]

Location

prov:generatedAtTime

from Entity

Generated at date or datetime

[0..*]

prov:hadPrimarySource

from Entity

[0..*]

Entity

prov:invalidatedAtTime

from Entity

[0..*]

prov:qualifiedAttribution

from Entity

[0..*]

Attribution

prov:qualifiedDerivation

from Entity

[0..*]

Derivation

prov:qualifiedGeneration

from Entity

[0..*]

Generation

prov:qualifiedInfluence

from Entity

[0..*]

Influence

prov:qualifiedInvalidation

from Entity

[0..*]

Invalidation

prov:qualifiedPrimarySource

from Entity

[0..*]

PrimarySource

prov:qualifiedQuotation

from Entity

[0..*]

Quotation

prov:qualifiedRevision

from Entity

[0..*]

Revision

prov:specializationOf

from Entity

[0..*]

Entity

prov:value

from Entity

[0..*]

prov:wasAttributedTo

from Entity

[0..*]

Agent

prov:wasDerivedFrom

from Entity

[0..*]

Entity

prov:wasGeneratedBy

from Entity

[0..*]

Activity

Record dates relating to CSD status

prov:wasInfluencedBy

from Entity

[0..*]

prov:wasInvalidatedBy

from Entity

[0..*]

Activity

prov:wasQuotedFrom

from Entity

[0..*]

Entity

prov:wasRevisionOf

from Entity

[0..*]

Entity

10.7. Conformance Class: Survey Features

https://linked.data.gov.au/def/csdm/surveyfeatures

10.7.1. Class: Adopted Vector

A vector included in a CSD that has previously been observed and included in an existing CSD or Survey Plan.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

geo:hasGeometry

from Feature

hasGeometry property inherited from geo:Feature

[0..*]

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

surv:distance

from Surveyed Vector

Distance

[0..*]

Distance Measurement

surv:from

from Surveyed Vector

[1]

Survey Point

surv:horizontalAngle

from Surveyed Vector

[0..*]

Angle Measurement

surv:target

from Surveyed Vector

[1]

Survey Mark

surv:verticalAngle

from Surveyed Vector

the horizontal angle of the target point relative to the ??? setup bearing ???

[0..*]

Angle Measurement

Images
adoptedobs
Figure 17. Diagram for Adopted Vector

Format

image/png

Canonical Examples
adoptedobs 

surveyobs_examples:tv2
  a surv:AdoptedVector ;
  geo:hasGeometry [
      a gml:LineString ;
      geo:asGML """<gml:LineString gml:id="tl1">
                            <gml:pointProperty xlink:href="#t1"/>
                            <gml:pointProperty xlink:href="#t3"/>
                        </gml:LineString>"""^^geo:gmlLiteral ;
    ] ;
  rdfs:label "T1->T3" ;
  skos:editorialNote "referencedCSD refers to collection of these - logical model could provide back reference if required" ;
  foaf:depiction <https://surroundbitbucket.bitbucket.io/3d-cadastre/spec/adoptedobs.png> ;
  surv:distance 30.32 ;
  surv:from surveyobs_examples:t1 ;
  surv:horizontalAngle 257.6 ;
  surv:target surveyobs_examples:t3 ;
  surv:verticalAngle 88.26 ;
.
Informative Examples 
xpath = /LandXML/Survey/

  <ObservationGroup id="aa1">
    <ReducedObservation
        setupID="a1107" azimuth="277.07"
        horizDistance="6.3" equipmentUsed="unknown"
        azimuthType="adopted" distanceType="adopted"
        azimuthAccClass="A" distanceAccClass="A"
        adoptedAzimuthSurvey="DP 333333"
        adoptedDistanceSurvey="DP 333333"
        azimuthAdoptionFactor="0">
      <TargetPoint pntRef="108" pointGeometry="point"/>
    </ReducedObservation>
  </ObservationGroup>

Title

AdoptedObservations-12D

Conforms To

LandXML (proprietary)

Show Details 
<ex:AdoptedObservations12D>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/LandXML12D> ;
  rdfs:label "AdoptedObservations-12D" ;
  skos:editorialNote "test note" ;
  prof:hasArtifact """xpath = /LandXML/Survey/

  <ObservationGroup id="aa1">
    <ReducedObservation
        setupID="a1107" azimuth="277.07"
        horizDistance="6.3" equipmentUsed="unknown"
        azimuthType="adopted" distanceType="adopted"
        azimuthAccClass="A" distanceAccClass="A"
        adoptedAzimuthSurvey="DP 333333"
        adoptedDistanceSurvey="DP 333333"
        azimuthAdoptionFactor="0">
      <TargetPoint pntRef="108" pointGeometry="point"/>
    </ReducedObservation>
  </ObservationGroup>
""" ;
.
 
xpath = /LandXML/Survey/

  <ObservationGroup id="OG-1">

    <ReducedObservation
        adoptedSurvey=DP 333333
        name="15" desc="Connection"
        setupID="IS14" targetSetupID="IS15"
        azimuth="59.3032" horizDistance="324.525"
        distanceType="Adopted"
        azimuthType="Adopted"
        coordGeomRefs="LOT-103">
      <FieldNote></FieldNote>
    <ReducedObservation />

  </ObservationGroup>

Title

AdoptedObservations-ePlanNSW

Conforms To

ePlan NSW

Show Details 
<ex:AdoptedObservationsEPlanNSW>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/ePlanNSW> ;
  rdfs:label "AdoptedObservations-ePlanNSW" ;
  prof:hasArtifact """xpath = /LandXML/Survey/

  <ObservationGroup id="OG-1">

    <ReducedObservation
        adoptedSurvey=DP 333333
        name="15" desc="Connection"
        setupID="IS14" targetSetupID="IS15"
        azimuth="59.3032" horizDistance="324.525"
        distanceType="Adopted"
        azimuthType="Adopted"
        coordGeomRefs="LOT-103">
      <FieldNote></FieldNote>
    <ReducedObservation />

  </ObservationGroup>""" ;
.

10.7.2. Class: Boundary Mark

Means a location that defines a boundary corner or boundary alignment. The location will be physically marked unless the location is obstructed by a structure that can not be marked.

A boundary mark MAY be a Geodetic Reference Mark.

Subclass of
Requirements
Properties
Property Description Cardinality Range Use Case Requirement

commonpatterns:name

from Survey Point

[1]

CompoundName

geo:hasGeometry

from Survey Point, Feature

Note that a Survey Point may not have a geometry declared - it may be identified and described and its location determined at a future date.

hasGeometry property inherited from geo:Feature

[0..1]

Point

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

surv:monumentedBy

from Survey Mark

[1]

Monument

surv:provenance

from Survey Point

Provenance

[1]

Survey Point Provenance

surv:purpose

from Survey Point

[1]

Survey Point Purpose

State the purpose of a survey

surv:state

from Survey Mark

[1]

Survey Point State

Canonical Examples 

surveyfeatures_examples:p25
  a surv:BoundaryMark ;
  geo:hasGeometry surveyfeatures_examples:g_p25 ;
  rdfs:label "P25" ;
  commonpatterns:name [
      a commonpatterns:CompoundName ;
      dct:hasPart [
          a commonpatterns:NamePart ;
          dct:type "Source" ;
          skos:prefLabel "DP 333333" ;
        ] ;
      dct:hasPart [
          a commonpatterns:NamePart ;
          dct:type "Stamp" ;
          skos:prefLabel "IS II" ;
        ] ;
    ] ;
  surv:monumentedBy surveyfeatures_examples:m25 ;
  surv:purpose surveymark_condition_NZ:bound ;
  surv:state surveymark_condition_NZ:New ;
.
Informative Examples 
xpath = /LandXML/Survey/

  <SurveyMonument
      mntRef="OP VII DP 333333"
      purpose="boundary defined by survey"
      state="original"/>

xpath = /LandXML/Monuments/

  <Monument
      name="OP VII DP 333333" pntRef="109"
      desc="OP VII DP 333333" type="peg"
      condition="reliable" oID="8353475"/>

xpath = /LandXML/CgPoint/

  <CgPoint
      name="109" pntSurv="monument"
      oID="3748446">
    786033.6613 427102.5793
  </CgPoint>

Title

Boundary Mark

Conforms To

LandXML (proprietary)

Show Details 
<ex:BoundaryMark>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/LandXML12D> ;
  rdfs:label "Boundary Mark" ;
  prof:hasArtifact """xpath = /LandXML/Survey/

  <SurveyMonument
      mntRef="OP VII DP 333333"
      purpose="boundary defined by survey"
      state="original"/>

xpath = /LandXML/Monuments/

  <Monument
      name="OP VII DP 333333" pntRef="109"
      desc="OP VII DP 333333" type="peg"
      condition="reliable" oID="8353475"/>

xpath = /LandXML/CgPoint/

  <CgPoint
      name="109" pntSurv="monument"
      oID="3748446">
    786033.6613 427102.5793
  </CgPoint>
""" ;
.
 
xpath=/LandXML/Monuments/

  <Monument
      name="1" pntRef="109"
      type="Peg" state="Found"
      desc="Original lot peg" condition="Remains"
      originSurvey=OP VII DP 333333"/>

xpath=/LandXML/CgPoints/

  <CgPoint
      name="109" desc="A"
      state=existing" pntSurv="boundary"
      oID="8353475">
     786033.66 427102.58 72.20
  </CgPoint>

Title

Boundary Mark ePlanNSW

Conforms To

ePlan NSW

Show Details 
<ex:BoundaryMarkEPlanNSW>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/ePlanNSW> ;
  rdfs:label "Boundary Mark ePlanNSW" ;
  prof:hasArtifact """xpath=/LandXML/Monuments/

  <Monument
      name="1" pntRef="109"
      type="Peg" state="Found"
      desc="Original lot peg" condition="Remains"
      originSurvey=OP VII DP 333333"/>

xpath=/LandXML/CgPoints/

  <CgPoint
      name="109" desc="A"
      state=existing" pntSurv="boundary"
      oID="8353475">
     786033.66 427102.58 72.20
  </CgPoint>
""" ;
.
 
IfcCartesianPoint
    type=TRAVERSE MARK
        Properties - Coordinates, Monument Type,
            Monument State, Monument Condition

Title

BoundaryMark-IFC

Conforms To

IFC Version 4.3

Show Details 
<ex:BoundaryMarkIFC>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/IFCVersion4.3> ;
  rdfs:label "BoundaryMark-IFC" ;
  prof:hasArtifact """IfcCartesianPoint
    type=TRAVERSE MARK
        Properties - Coordinates, Monument Type,
            Monument State, Monument Condition""" ;
.
 
xpath=/LandInfraDataset/feature/

  <SurveyMonument gml:id="sm">
    <type
        xlink:href http://example.com/SurveyMonumentType#boundaryMark"
        xlink:title "boundaryMark"/>
    <documentation xlink:href "st1"/>
    <spatialRepresentation>
      <SpatialRepresentation>
        <geometry>
          <gml:Point gml:id="p1">
            <gml:pos>786033.66 427102.58 72.20 </gml:pos>
          </gml:Point>
        </geometry>
      </SpatialRepresentation>
    </spatialRepresentation>
  </SurveyMonument>

Title

BoundaryMark-InfraGML

Conforms To

InfraGML Part 7 Land Division

Show Details 
<ex:BoundaryMarkInfraGML>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/InfraGMLPart7Facilities> ;
  rdfs:label "BoundaryMark-InfraGML" ;
  prof:hasArtifact """ xpath=/LandInfraDataset/feature/

  <SurveyMonument gml:id="sm">
    <type
        xlink:href http://example.com/SurveyMonumentType#boundaryMark"
        xlink:title "boundaryMark"/>
    <documentation xlink:href "st1"/>
    <spatialRepresentation>
      <SpatialRepresentation>
        <geometry>
          <gml:Point gml:id="p1">
            <gml:pos>786033.66 427102.58 72.20 </gml:pos>
          </gml:Point>
        </geometry>
      </SpatialRepresentation>
    </spatialRepresentation>
  </SurveyMonument>""" ;
.
 
<LA_Point

    LA_PointType=Source (Boundary?
    )>

</LA_Point>

Title

BoundaryMark-LADM

Conforms To

ISO19152-2 Surveying

Show Details 
<ex:BoundaryMarkLADM>
  a prof:ResourceDescriptor ;
  dct:conformsTo <urn:x-evn-master:implementation_specifications/ISO191522Surveying> ;
  rdfs:label "BoundaryMark-LADM" ;
  prof:hasArtifact """<LA_Point

    LA_PointType=Source (Boundary?
    )>

</LA_Point>
""" ;
.

10.7.3. Class: Cadastral Feature

This is an abstract feature to identify elements of the Cadastral Survey Conceptual Model

Subclass of
Images
SurveyFeatures
Figure 18. Diagram for Cadastral Feature

Format

image/png

10.7.4. Class: Cadastral Mark

Any survey mark placed or observed as part of a cadastral survey that is not a boundary mark or a geodetic reference mark

Subclass of
Properties
Property Description Cardinality Range Use Case Requirement

commonpatterns:name

from Survey Point

[1]

CompoundName

geo:hasGeometry

from Survey Point, Feature

Note that a Survey Point may not have a geometry declared - it may be identified and described and its location determined at a future date.

hasGeometry property inherited from geo:Feature

[0..1]

Point

Geometry

Requires 3D Spatial Unit

Support 2D or 3D Surface Parcels

surv:monumentedBy

from Survey Mark

[1]

Monument

surv:provenance

from Survey Point

Provenance

[1]

Survey Point Provenance

surv:purpose

from Survey Point

[1]

Survey Point Purpose

State the purpose of a survey

surv:state

from Survey Mark

[1]

Survey Point State

Canonical Examples