DEV
Information for administrators and developers.
# Storing location information on the scan
The location on the scan is saved in the database in the “geometry” field. In order to ensure trouble-free operation by various tools supporting reading, writing, visualization and analysis of this type of “spatial” data, it is additionally necessary to define the type of geometry and reference system for the coordinates used. The database itself does not require additional definition of the geometry type or coordinate system. But the tools that use this data may require it. These requirements can be met immediately in the database, or each time individually in a given access application (library or other tool), specifying the metadata in a way that the given tool allows. Providing this metadata directly in the database means that you no longer need to do it in the access application (it should be read automatically from the database).
Geometry type The geometry type, depending on the type of data entered (one or more interconnected areas), can be defined as Multisurface or Multipolygon. Theoretically, Multisurface is better because:
A MultiPolygon is defined by one or more Polygons, referenced through polygonMember elements. Deprecated with GML version 3.0. Use MultiSurfaceType instead.
from: https://portal.ogc.org/files/?artifact_id=7174
In practice, using Multisurface can sometimes be problematic. For example, even if you can save and render in vector mode (WFS), rendering in raster mode (WMS) may result in an error:
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?><!DOCTYPE ServiceExceptionReport SYSTEM “http://172.18.12.112:8020/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1 .dtd”>
Which is manifested by the following visual condition: A red background means that the image of one of the layers could not be loaded (GS did not provide it) due to the above error. However, GML (a rectangle with a red outline) was successfully loaded.
Perhaps you can find such a combination of settings in the connection: OpenLayers (which forms GML for writing and displays the image passed by GS or renders GML itself) <-> Geoserver (which turns GML into SQL and vice versa) <-> PostgreSQL/PostGIS ( which, depending on what the Geoserver requests, gives it the data directly or recalculates it in advance), which, in combination with the appropriate coordinate system, would cause proper operation also using Multisurface. But experiments have shown that this is a very fragile state compared to the state when the Multipolygon type is used. Especially since the additional possibilities resulting from the Multisurface type (curved lines instead of regular ones) are not necessary.
Since OL prepares a write request from Multisurface by default:
/**
-
- Property: multiSurface
- {Boolean} Write gml:multiSurface instead of gml:MultiPolygon. Since
- the latter is deprecated in GML 3, the default is true. Then write
- gml:MultiPolygon instead of gml:multiSurface, set multiSurface to
- false in the options to the constructor (cannot be changed after
-
- instantiation). */ multiSurface: true,
To avoid the need to convert the geometry type somewhere along the way, the above parameter must be set to False.
Perhaps in the future it will be possible to determine all the environmental parameters that allow stable operation using Multisurface. Currently, Multipolygon guarantees more stable operation.
Reference system
The second parameter in determining the geometric type is the reference system. You need a flat metric coordinate system. There are such in the EPSG set, but for the purpose of handling spatial data but not directly related to the globe, the creators of Geoserver defined a system with the code 404000. It is hosted by Geoserver. However, it is not included in the default datum set for the PostgreSQL/PostGIS database. Which should not be a problem if there is no need to convert the coordinates by the database (which may occur, for example, when it receives an external request to provide them in a coordinate system other than 404000). Which results in the following message from the database side:
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?><!DOCTYPE ServiceExceptionReport SYSTEM “http://172.18.12.112:8020/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1 .dtd”>
Therefore, just in case, it is better to add this layout to the spatialrefsys table as defined on the website: https://spatialreference.org/ref/sr-org/epsg404000/
Ultimately, the definition of the field with geometry should look like this:
the_geom public.geometry(multipolygon, 404000) NULL
