[MaxNumerique]

No description provided.

[MaxNumerique]

CRS support — back-end part

Part of the CRS work for Geode-solutions/Vease#798. Overview of the 4 PRs and merge order: see Geode-solutions/Vease#818. This PR goes first.

New crs blueprint — routes/crs/blueprint_crs.py (/opengeodeweb_back/crs/...)

Route	Params	Response	Notes
geographic_list	geode_object_type	crs_list: [{authority, code, name}]	Replaces /geographic_coordinate_systems (removed, no alias: no project to keep compatible yet). 2D or 3D list depending on the type
active	id	crs_name, crs_info?	crs_info only when the active CRS is geographic
assign_geographic	id, authority, code, name	crs	Label only, coordinates unchanged. Only the native file is rewritten
convert_geographic	id, authority, code, name	crs, binary_light_viewable	400 if no geographic CRS yet, or if PROJ rejects the coordinates (out of domain)
align	id, source_points[3], target_points[3], authority, code, name	crs, binary_light_viewable	3-point affine transform (create_crs), then assigns the target CRS. 400 if a geographic CRS is already set, or if points are colinear

Common rules:

• Supported objects: CRS_GEODE_OBJECTS in crs_functions.py (BRep, Section, PointSet 2D/3D, EdgedCurve 2D/3D, SurfaceMesh 2D/3D, SolidMesh3D and their subclasses). Others → 400. Unknown id → 404.
• Only CRS from the PROJ list are accepted. geographic_coordinate_systems(is_3d) builds an AUTHORITY:CODE → info dict once (functools.cache, ~13k entries), and known_geographic_info looks it up. Unknown CRS → 400. The name stored comes from that list, not from the request. Before this, an unknown CRS was saved, and the next conversion crashed the whole process (segfault in OGRCoordinateTransformation::Transform).
• Assigning or converting to a CRS that is already active → 400. A registered but inactive CRS with the same name is deleted first (_prepare_crs_name), so it is recomputed instead of reactivating stale coordinates.

Models and meshes — geode_objects/*

• New methods on the CRS-capable wrappers: crs_manager(), delete_crs, assign_crs, convert_crs, create_crs. Models (BRep, Section) have no CRS manager of their own: they apply the operation to every component mesh, and crs_manager() reads the first component (ValueError if the model has none).
• geode_objects/crs_coordinates.py → delete_crs_with_coordinates: when a geographic CRS is deleted, its coordinate vertex attribute is deleted too, unless the active CRS still uses it. Without this, each convert round trip left a full coordinate array in the native file (874 → 2604 bytes after 6 Lambert↔UTM round trips on a 1-point PointSet).

CRS in data responses

• crs_functions.active_crs(geode_object) returns {authority, code, name} or None. It catches ValueError/RuntimeError and logs a warning: the CRS is extra information and must never fail a data response.
• utils_functions.save_all_viewables_and_return_info adds crs when present, so save_viewable_file, the create/* routes and project import return it. It is computed from the loaded object, not stored in the database: the native file stays the source of truth.
• Optional crs declared in the response schemas: save_viewable_file, create/point_set, create/edged_curve, create/polygonal_surface, and the CRS routes.

⚠️ Temporary PROJ workaround

In packaged apps (PyInstaller), libproj is loaded from _internal/ instead of opengeode/lib64/, and opengeode/share/proj is not bundled. PROJ then cannot find proj.db (ERROR 1: PROJ: proj_get_crs_info_list_from_database: Cannot find proj.db): the CRS list is empty and conversions fail. This is what broke the Vease browser e2e on CI (Linux and Windows).

• crs_functions.py: os.environ.setdefault("PROJ_DATA", <opengeode>/share/proj). An existing PROJ_DATA is respected; no effect in a regular venv.
• opengeodeweb-back.spec: collect_data_files('opengeode', subdir='share').
• Both are marked TEMPORARY. The proper fix belongs in OpenGeode: set PROJ_DATA (or OSRSetPROJSearchPaths) on import, and ship a PyInstaller hook (pyinstaller40 entry point) collecting share/. Until then, every packaged back using CRS needs the spec line (Vease-Back is done in feat(crsAssign): crs support Vease-Back#158; PEGGHy-Back and Vease-Modeling-Back will need it).

Other changes

• test_utils.py: check_upload_file / check_save_viewable_file moved here from tests/test_routes.py to be shared.
• pyproject.toml: crs.schemas package data.
• .releaserc: semantic-release success/fail comments disabled (unrelated to CRS).

Tests — tests/test_crs_routes.py

geographic_list; active; assign (and errors: 404, unsupported type, already active); convert (and errors, out of domain); align (and colinear points, already georeferenced); reassign after convert; crs returned by save_viewable_file for a georeferenced native file; unknown CRS on assign/align/convert and name taken from the list; no file growth over round trips; assign leaves viewables untouched; unreadable CRS does not fail active_crs; PROJ_DATA points to an existing proj.db.

Known limitations

• RegularGrid 2D/3D subclass SurfaceMesh2D/SolidMesh3D, so convert/align accept them, but only the vertices move, not the grid origin/spacing. Left as is for now.
• No lock on concurrent writes to the same data (same pattern as apply_time_series).

[JulienChampagnol]

Utilisé ?

[JulienChampagnol]

Et si l'erreur est autre chose ?

[JulienChampagnol]

Pourquoi ne pas mettre tout ça dans crs_functions et ne laisser que le routes dans blueprint ?