Abu Dhabi As-Built Geospatial Data Submission
- Standard version
- Final, 30 March 2022
- Primary format
- ESRI file geodatabase (.gdb)
- Submission stages
- DS · PC · HO · OM
The Department of Municipalities and Transport publishes a single document governing how as-built geospatial data is handed over in Abu Dhabi: the Unified As-Built GeoSpatial Data Submission Standards, issued in its Final version on 30 March 2022. It applies to developers, consultants and contractors delivering urban development projects in the emirate, and it is specific in a way that matters commercially, because it fixes the format, the coordinate references, the metadata and the geometry rules before anyone reaches site. This guide sets out what the standard asks for. Where Petra Point does something, that is said separately and plainly.
Who the standard applies to
The standard names its audience directly: developers, consultants and contractors implementing urban development projects in Abu Dhabi Emirate. It is not addressed to surveyors as a profession. It is addressed to whoever is delivering the project, which means the obligation sits with the party holding the contract even when the data is produced by someone else.
Submissions go to one of the DMT affiliate entities: Abu Dhabi City Municipality, Al Ain City Municipality, Al Dhafra Region Municipality, or the Integrated Transport Center. Which one depends on where the project sits and what it is, and each publishes its own support address.
The four submission stages
The standard carries its stages in the file naming convention rather than in a schedule, which is why they are easy to miss. There are four, and they are not alternatives. A project passes through them.
The practical consequence is that as-built data is not one handover at the end. A project that treats it as a single event at completion discovers at the first stage gate that the data was expected earlier, in a defined structure, and that retrofitting that structure to a survey already delivered in another format is a second piece of work.
- DS — initial submission, at the planning and design stage.
- PC — at project completion.
- HO — at final handover.
- OM — for operation and maintenance works.
ESRI file geodatabase, and when CAD is accepted
The primary submission format is an ESRI file geodatabase. The standard supplies templates, and the templates are not empty containers: they carry a predefined coordinate system, feature classes and business tables, attribute definitions, mandatory field constraints, domain values, relationships between features, and geometry rules expressed as topology. Delivering into the template is most of the compliance.
CAD is not the default. The standard accepts DWG and DGN only if specifically requested by the project owner entity. That single line reverses the assumption most project teams start from, and it is the assumption worth checking before a scope is priced: a deliverable written as “as-built DWG” may not be the deliverable the receiving entity will take.
Coordinate and vertical references
Horizontally, the standard specifies UTM projection on the WGS84 ellipsoid at ITRF 2000, epoch 2000.0, in Zones 39N and 40N, in metres — EPSG 32639 and 32640. Vertically it specifies Ras Ghumays, based on mean sea level observations, and requires it for all mapping, planning, design and construction on infrastructure projects within the municipal and transport sector of the emirate.
These are decisions taken before capture, not conversions applied after it. Control established on a different reference can often be transformed, but the transformation is an added step with its own error budget, and on a vertical reference it is the step most likely to be discovered late.
Metadata and geometry validation
Metadata follows ISO 19115-1:2014(E) with Amendment 1:2018. This is the part of a submission most often left until last and it is the part that cannot be produced retrospectively with any confidence, because it describes how the data was captured, by whom, when and to what accuracy.
Geometry is validated against explicit topology rules rather than inspected by eye. Points must be disjoint. Lines must not overlap, must not have dangles, must not self-intersect and must not self-overlap. Polygons must not overlap and must not have gaps. There are cross-feature-class rules on top of those. A drawing that looks correct on screen can fail every one of them.
Why the format decision comes before mobilisation
Reality capture produces a measured record. What that record becomes is a separate decision, and the standard makes it early: the template fixes the feature classes and attributes, which fixes what has to be identified and coded on site, which fixes how the capture is planned. A point cloud collected without reference to the receiving schema is still a good point cloud, and it is still a second exercise to turn it into a compliant package.
The question worth asking at scoping, before anything is priced, is which entity will receive the data, at which stage, and whether that entity has requested CAD in addition to the geodatabase. Those three answers determine the rest.
What Petra Point provides
Petra Point measures and documents existing conditions: 3D laser scanning, registered point clouds, as-built drawings and Scan-to-BIM models. Those are the inputs a geospatial submission is built from, and they are what Petra provides on Abu Dhabi projects.
Stated as plainly: this guide describes a government standard, not a track record. Petra Point does not claim to have submitted a package under it, and where a project requires that submission the sensible first conversation is with the receiving entity about scope and stage.
