I have not been able to figure out how to see the record for the smaller polygon or edit its boundary.
The easiest way is to use a style that has transparent area fill color and, say, black color for the area boundary. You can then see the small areas within other areas, and you can Alt-click or Shift-Alt-click them to edit their boundaries. Another way to use style is to format different hatch patterns in addition to using transparent fill color. The bigger area could have vertical hatch lines, the smaller one horizontal lines, and then where the two overlap you see a cross-hatch. Clever use of thematic formatting (by object size, unique values, a numeric field you call "Z") will give different hatch patterns for overlapping objects. From a spatial perspective, it's not "normal form" to nest localities within other localities. Often when you see this it is an indication the data needs to be repaired or better organized. Consider a non-spatial table analogy: Suppose you had an "employees" table with an ID, name, address, telephone number and comments field. You have one record for each employee. Suppose that in addition you want to capture information on manager-subordinate relationships. One way of doing that would be to add a "manager" field to each employee record which gives the ID of that employee's manager. A second, non-normal form, way of doing that would be to have the records in the employees table be records only for those employees who are managers, and then within the comments field for each manager have a JSON expression in plain text that listed in JSON form the records for all of that manager's subordinates. That is, you'd be nesting records for sub-employees within other employees. That would be cumbersome and clearly not the best way to organize the data. But that is analogous to nesting, as polygons, localities within other localities. It's pretty rare that "localities" from any sort of administrative perspective really do cover each other. You do not have islands of territory inside Germany, for example, which also at the same time are different countries. It's true you may have islands of territory that belong to one country which are entirely surrounded by another country, such as Campione (a part of Italy) that is entirely within Switzerland. But Campione is not both Italy and Switzerland at the same time, and should not be represented by having a small Campione polygon entirely covered by a much larger Switzerland polygon. There should be a hole in Switzerland exactly corresponding to the Campione island. Likewise, disputed territory is often chunked out as a separate polygon. In cases like the above an overlap is wrong data, that should be corrected. In other cases, for example, a history of mining claims filed in a given region, then it's true that some polygons could be entirely within other polygons and covered by them. That is more difficult to organize around (layers by date, perhaps, since two claims cannot rightfully cover the same spot?). In some cases there really is no recourse but z order and formatting tricks. I include formatting tricks because just using Z order doesn't solve the display problem, since you don't know if you are looking at an upper, smaller area that is an island in a hole of a surrounding area (like Campione within Switzerland), or if you are looking at an upper, smaller area that is located within a larger area that has no hole in that spot.
|