feature request #9502
Updated by Andreas Müller about 3 years ago
#5050 defines the subarea preference rule and also describes implements it for areas Ju, Cz, IJ and LS which are relatively easy to handle in the hierarchy.
Some more areas are more difficult to handle:
* ~~SM and Sr as they are not on first level and they have already a fallback parent~~ => fixed by #9521
* Cc as subarea Rf(CS) has another parent
* ~~Tcs as it is not on first level~~ => fixed by #9521
* Bt as subarea Rf(K) has another parent
* ~~Cm (still to decide if the hierarchy should stay as it is)~~ => fixed by #9521, UK => UC, UK(K) => UK, UC becomes fallback-area
Most of these issues can be solved by using a term tree (of areas). This will also make hidden areas obsolet (they simply do not appear in the tree).
Fallback areas should then be marked in the tree not in the area (as it is a publication decision not a data property).
Areas with >2 parents can be handled twice in the tree (allowDuplicates=true).
A problem with this solution might be the ordering. If ordered via the natural tree order areas may show up at the wrong place if they have fallback parents.
Maybe this can be solved by having fallback children >1x in the tree. Once at the correct position and once with at the fallback parent position with a convention that the fallback position is only for computation of the fallback area, not for handling the subarea itself. The children list then can always be flat (e.g. in case of Ju/CM).
See also duplicate #9486
The remaining issues are probably blocked by #6794