We delete it right after having validated it, we promise. The report is however available to anyone who knows its ID.
The report lists all the 3D primitives with some statistics about them, and gives if invalid one or more errors for each.
If your your file is a GML file and the primitives have gml:id (for gml:Solid and gml:Shell and gml:Polygon) then these are used to report the errors, if not then the number means the order of the primitives in the file (the first one being 0). We offer a small service that adds a gml:id to all the gml:Solid in your file. Some examples, referring to the example above. The first (ID #0) solid in the file is valid, and some of its properties are shown. The solid with ID #1 is invalid with error 102. The solid with ID #5 is invalid because its face ID #c6e90d82 is non-planar; if the tolerance was modified to 0.20m then it would be. The solid with ID #68 is invalid its exterior shell (ID #0) has holes (2 of them).
Geometries modelled in GML store amazingly very little topological relationships. A cube is for instance represented with 6 surfaces, all stored independently. This means that the coordinates xyz of a single vertex (where 3 surfaces “meet") is stored 3 times. It is possible that these 3 vertices are not exactly at the same location (eg (0.01, 0.5, 1.0), (0.011, 0.49999, 1.00004) and (0.01002, 0.5002, 1.0007)), and that would create problems when validating since there would for example be holes in the cube. The snap tolerance basically gives a threshold that says: “if 2 points are closer then X, then we assume that they are the same”. It’s setup by default to be 1mm.
This is a very common error, actually 203 is the most common error for all the files so far uploaded.
A polygon must be planar, ie all its points (used for both the exterior and interior rings) must lie on a plane. To verify this, we must ensure that the the distance between every point and a plane is less than a given tolerance (eg 1cm). In the validator, this plane is fitted with least-square adjustment, and then the distance between each of the point to the plane is calculated. If it is larger than the given threshold (0.01unit by default; can be changed as a parameter) then an error is reported. The distance to the plane, if larger than the threshold, is also reported in the report.
To ensure that cases such as that below are detected, error 204 is introduced. In the solid, the top surface containining 8 vertices (abcdefgh) is clearly non-planar since there is a vertical “fold” in the middle. The normal of the sub-surface abgh points upwards, while that of bcfg is perpendicular to it. But this surface would not be detected the error 203 test and a tolerance of 1cm for instance, since all the vertices are within that thresfold. Thus, another requirement is necessary: the distance between every point forming a polygon and all the planes defined by all possible combinaisons of 3 non-colinear points is less than a given tolerance. In practice it can be implemented with a triangulation of the polygon (any triangulation): the orientation of the normal of each triangle must not deviate more than than a certain usef-defined tolerance; this tolerance is in val3dity set to 1 degree, but can be defined (not in the web-version), but in the executable.
A surface is first check for error 203, if valid then error 204 is checked. By definition, if an error 204 is reported then all the vertices are within 1cm (tolerance you used), thus you wouldn’t be able to visualise them. That usually means that you have vertices that are very close (say 0.1mm) and thus it’s easy to get a large deviation (say 80degree; the report contains the deviation).
It’s normal: as shown in the figure below, a solid is validated hierarchically, ie first every surface (a polygon embedded in 3D) is validated in 2D (by projecting it to a plane), then every shell is validated, and finally the interactions between the shells are analysed to verify whether the solid is valid.
If at one stage there are errors, then the validation stops to avoid “cascading errors”. So if you get the error
203 NON_PLANAR_POLYGON_DISTANCE_PLANE, then fix it and re-run the validator again.
That does mean that you might have to upload your file and get it validated several times—if that becomes too tedious we strongly suggest you to download the code, compile it and run it locally (it’s open-source and free to use).
There are many (or more precisely: too many) ways to model a volume/polyhedron in GML (eg a building in CityGML), but usually practitioners do it with either gml:Solid or gml:MultiSurface. See the same simple volumetric objects, first modelled with a gml:Solid and then with gml:MultiSurface:
Yes, all the 3D primitives in the file will be validated, one by one.
No we don’t. Each solid is validated completely independently from the others.
50MB. If you need more, download the code, compile it and run it locally.
We offer a small service that adds a gml:id to all the gml:Solid in your file
We maintain a repository of unit tests (file containing one solid that has one error) for testing our code. Also, on the official CityGML website there are a few files with 3D buildings, and on the CityGML wiki there are links to rather large datasets of cities (although they do no always contain gml:Solids).