LocDB About primary and secondary IsIn

In module "Main", we require one primary IsIn and an arbitrary number of secondary IsIns. What's special with the primary IsIn?

Breadcrumb trail
The breadcrumb trail in the header of each article has turned out to be an important help for navigation. It also visualizes the hierarchical position in an easy and intuitive way. The breadcrumb trail is driven by primary IsIn relations.

Logically, an arbitrary number of IsIns without distinguishing primary or secondary would be possible. However, the result would be a trail net rather than a simple straight forward path. Its clear graphical representation would be a chellange, if possible at all. It is in question whether this really would be a help for navigation or rather confusing, specially for unexperienced readers.

Currently, we do display direct secondary parents of the article's location together with the primary parent. Maybe, it would be a help to turn on the trails starting from each of the secondary parents by some JS driven drop down box. But again, all higher levels only would regard the primary IsIns.

Listings of sublocations
When listing sublocations of a location, there is no need to distinguish between primary and secondary children. We simply can show them all.

However, when making recursive listings (with subsub- and subsubsub- and subsubsub...-locations), there is a pitfall: We must not recursively follow secondary children. Let's look on an example demonstrating the logical problem.

Supposed the following scenario:

When listing Italy or France recursively, we should list Mt. Blanc area. For both, this is a secondary child. But we must not follow this childline further down as it would lead us to Chamonix being shown when listing Italian locations or to Courmayeur being shown when listing French locations. Both would result in wrong listings.

Out of this problem results a rule, simply for logical reasons:

(a) Only follow primary children in recursive listings.

Hm, but what if we want to have a recursive listing of all locations in the Alps? According to (a), we should not to follow down Mt. Blanc area, but if we do not follow we will get an incomplete list as result. So we have to find some criterion that distinguishes location Alps from locations Italy and France. There are basically two ways: Either leave it up to the authors or let the LocDB decide. As this is a rather tricky matter, author decisions might be error prone. At the other hand, the LocDB does not have any idea about what's the actual meaning of locations like Alps or Italy. It only can use formal concepts, i.e. the data set entered by authors. However, there would be a possible solution: Make sure that there is no location that has Alps in its breadcrumb trail built from primary IsIns. If this is the case, we can call Alps a pure secondary location. In other words, a pure secondary location is a location where all trails down to each recursive sublocation go along at least one secondary IsIn. Now, we can replace rule (a) by this:

(1) For pure secondary locations, follow all children in recursive listings.

(2) For all other locations, only follow primary children in recursive listings.

Of course, it would not make sense to give Italy or France the Alps as secondary IsIn. If we would do so, all Italian and French places would show up in the recursive listing of the Alps.

Maps
In maps, specially when clickable, each point of the map only can represent one location. This means that the location shown in the map must be unambigously partitioned into sublocations. This is equivalent to that any pair of sublocations shown on the map must not overlap. Mathematically speaking, all sublocations must be disjoined.

As long as we completely discard secondary sublocations, this is allways the case.

See Clickable Maps from LocDB and free data sources for how areas belonging to a given location are calculated. First, the algorithm calculates the areas for so called geoatomic locations. Then, it calculates the areas of all other locations by building the geometric union of its sublocations. To be more precise, it is the union of all geoatomic locations listed in the location's recursive sublocation listing. The difference between pure secondary locations and other locations made in section "Listings of sublocations" also holds here.

This means that locations that are not pure secondary are assembled from all geoatomic locations that have the location in question on its breadcrumb trail built from primary IsIns. A direct consequence is that the areas of direct secondary sublocations are either not part of the parent location's area or overlap with other primary sublocations' areas. Thus, secondary children can never be dislpayed in maps. Furthermore, we can not be sure any more that all primary sublocations locations to be shown on the map are disjoined.

Supposed location Vatican is geoatomic, i.e. it has coordinates given in the locDB and it has no children. Also, suppose this IsIn relations:

Vatican is listed in the recursive listing of Italy as it is a direct secondary child of Rome. Thus, its area is supposed to be a part of Italy 's area. If we wanted to generate a map for Southern Europe, locations Vatican and Italy do overlap. A solution could be to discard secondary IsIns when conflicting with primary IsIns. This would mean not to add Vatican 's area to Rome 's area and thus not even to Italy 's area.

The area of a pure secondary location is calculated as the union of the areas of all geoatomic locations listed in the recursive listing. Thus, the areas of all sublocations are part of the parent location's area, but the sublocations' areas are not necessarily disjoined. This may lead to unresolvable problems.

Supposed Locarno is geoatomic and the following IsIn relations are given:

Also supposed locations Maggia Vally, Lago Magggiore and Alps are pure secondary locations. When we wanted to draw a map of the Southern Alps we find that its sublocations Maggia Vally and Lago Magggiore are overlapping since both contain location Locarno. As the situation is absolutely symmetric in both Locarno 's secondary IsIns Maggia Vally and Lago Magggiore, the locDB has no hints to solve this contradiction. The only thing it can do is to display an error message explaining why it cannot generate the requested map.

There is a way to solve all this problems. But it might be too strict for many contributors. So, not sure if this rule is really applicable.

(3) Reject all user input in the locDB's maintenance interface that leads to overlapping sublocations.

If we wanted to apply this rule, we had to remove all secondary IsIns that break it, first.

Definitions
A location is called atomic if it has no children. Remark: An atomic location needs not to be geo-atomic and a geo-atomic location needs not to be atomic.

A location is called regular if
 * 1) it is atomic or
 * 2) if has at least one primary regular (primreg) child.

A primary regular child location is called primreg.

A location is called pure secondary (P2) if it is not regular, i.e. Remark: Condition 2 is equivalent to: It has no direct primary children or all of its direct primary children are pure secondary.
 * 1) it is not atomic and
 * 2) it has no primreg children.

A regular location with only primary children (no matter if regular or not) is called clean regular.

A regular location that is not clean is called unclean regular.

A location is called clean pure secondary (CP2) if complies all of this conditions:
 * 1) it is P2
 * 2) all its direct children are disjoined.

A location is called unclean pure secondary (UP2) if it is P2, but not CP2.

Remark: Ideally, all locations should be clean, i.e. either clean regular or CP2.

Making listings, maps, etc.
For direct listings, simply list all direct children.

For recursive listings, regard two cases:
 * 1) parent is regular: Only follow primary( not only primreg!) children, but include secondary children themselves into the listing.
 * 2) parent is P2: Follow all children.

For listing of direct sublocations for a given interwiki identifyier, recursively descent the childline until you meet a location with an alias for that iw. Regard two cases:
 * 1) parent is regular: Only follow primary( not only primreg!) children, but include secondary children themselves into the listing. Once a childline has passed a primary P2 sublocation, skip secondary children below it. (Scnd. children of prim P2 sublocs always should be accessable by an other, primreg childline)
 * 2) parent is P2: Follow all children. (Should work fine if parent is CP2, might underrun the hierarchy if parent is UP2 what should be avoided, anyway)

When calulating a location's area, regard two cases:
 * 1) location is regular: Build the union of its direct primreg children's areas. Discard all other children.
 * 2) location is P2: Build the union of its direct children's areas, no matter if regular or P2 or primary or secondary.

When generating maps, regard three cases:
 * 1) location is regular:  Only show direct primreg children. Discard all other children.
 * 2) location is CP2: Show all direct children.
 * 3) location is UP2: No map possible as some direct children do overlap. Return an error message.

Loss of children
According to Impact from children on parents, each of the above cases may have an impact on the parent's parent.

Getting children
According to Impact from children on parents, each of the aboce cases may have an impact on the parent's parent.

Merging
Redirecting back refering locs should not have any impact.

Unmerging
Each of both locs needs to be evaluated after broken references have been fixed and back references have been redirected. No general rules possible.

Deleting
Special cases of Loss of children, Getting children and Impact from children on parents.

This table assumes that all prim. children of the deleted child are redirected to become prim. children of the parent, all scnd. children of the deleted child are discarded.