Project

General

Profile

Actions

Feature #2687

open

Multiple super for place

Added by Alexander Watzinger about 1 month ago. Updated 21 days ago.

Status:
Acknowledged
Priority:
Normal
Assignee:
-
Category:
Backend
Target version:
Start date:
2025-11-23
Estimated time:

Description

As discussed in the last Welterbe meeting we still need a solution for multiple place supers.

Current scenario (simplified):
  • There are Places like estates
  • There are Features like border stones
  • A border stone can be located in two estates (directly at the border)
I already thought about using Place types but this wouldn't work in this case because:
  • They already need it for something different and will use it with the upcoming custom place type feature (#2505). If I remember correctly it was for "Kastralgemeinden".
  • The places (e.g. estate) have a lot of additional information that can't be tracked via a type. So a "normal" entity is needed.
One approach would be to implement multiple supers for place, but it would mean a lot of work and challenges like:
  • How do we manage situations like
    • A is super of B and C
    • X is super of Y and Z
    • But M has supers A and Y
  • How would the breadcrumb work
  • Danger of recursive relations
  • It could break a lot of existing functionality
If we decided to go that direction I would stay away from implementing it everywhere at once (Place, Feature, Strategraphic Unit, Human remains) in the first step. My 2 approaches would be:
  • Implement place subs (#2436) and allow only for places to have multiple super. In this case estates and border stones would be places.
  • Implement that features can have multiple places as super

Although more work I would prefer the first approach because place subs would help with issues of other cooperation partners too.

Ideas how to solve this more easily or comments about implementing supers are welcome.


Related issues 1 (1 open0 closed)

Related to OpenAtlas - Feature #2436: Structuring placesAcknowledged2025-01-27Actions
Actions #1

Updated by Alexander Watzinger about 1 month ago

  • Description updated (diff)

Because this issue will impact and bring challenges for many aspects (backend, frontend, API, ...) I added some people as watchers (feel free to remove yourself again).
I also added it to the agenda of the next Developer meeting in January.

Especial important will be the input from @Stefan Eichert, because I assume this will impact the archeological hierarchy a lot.
But it could also offer advantages for other desired features (not sure which ones right now but #1648 could have been one of them).

Actions #2

Updated by Alexander Watzinger about 1 month ago

Actions #3

Updated by Alexander Watzinger about 1 month ago

  • Target version changed from 9.2.0 to 9.1.0
Actions #4

Updated by Alexander Watzinger 21 days ago

@Stefan Eichert and I discussed it yesterday and he gave valuable input.
Because of CIDOC model related reasons we can't use P46 (is composed of) which we use for the existing hierarchy (see Archaeological sub units) to connect to multiple supers, so we have to think about alternatives.

Actions

Also available in: Atom PDF