Project

General

Profile

Actions

Question #2687

closed

Multiple super for place

Added by Alexander Watzinger 2 months ago. Updated 1 day ago.

Status:
Closed
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 (0 open1 closed)

Related to OpenAtlas - Question #2436: Structuring placesClosed2025-01-27Actions
Actions #1

Updated by Alexander Watzinger 2 months 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 2 months ago

Actions #3

Updated by Alexander Watzinger 2 months ago

  • Target version changed from 9.2.0 to 9.1.0
Actions #4

Updated by Alexander Watzinger about 2 months 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 #5

Updated by Alexander Watzinger 1 day ago

  • Tracker changed from Feature to Question
  • Status changed from Acknowledged to Closed

Because the model won't allow for this approach and we found another solution for the Welterbe project, I'm changing this issue to a closed question in case we want to revisit it.

Actions #6

Updated by Alexander Watzinger 1 day ago

  • Target version deleted (9.1.0)
Actions

Also available in: Atom PDF