Subscribe to this thread
Home - General / All posts - See attribute data for a lower polygon in a stack of polygons
578 post(s)
#12-May-18 03:02

I have a layer that contains polygons representing localities. Some localities are nested within other localities so I have a stack of polygons in some places. If a small polygon is covered by a larger polygon, the Alt-click often selects the large polygon and shows its associated record. I have not been able to figure out how to see the record for the smaller polygon or edit its boundary.


8,516 post(s)
#12-May-18 03:20

You might not like this but at least you’ll know.

Currently in 9, Z-order between objects is not defined and can’t be controlled. Order is arbitrary, so what is above and what is below are likewise.

As I understand it, this is something that is coming.

For now, when you need to control order, the only option is separation by layer. That works of course.


5,249 post(s)
#12-May-18 04:22

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.

578 post(s)
#12-May-18 11:01

Stacked polygons are fairly common in some disciplines. For example with old flora records, the location is not known precisely so is represented by a box rather than a point. It is common to have boxes with a 1 mile edge. If there are lots of records, then there will be lots of boxes in stacks. My case is similar. I am defining my own localities and small localities such as a deep hole in a river will be nested in larger localities such as a river delta. Please note that the wildly successful iNaturalist uses a very similar system.

Tim's answer is the one that I am looking for. I have used a transparent fill so I can see the smaller polygon that is underneath but I can't get to it with a mouse to show its attributes.


5,249 post(s)
#12-May-18 13:19

Tim's answer is the one that I am looking for. I have used a transparent fill so I can see the smaller polygon that is underneath but I can't get to it with a mouse to show its attributes.

Sure you can. Alt-click into the middle of the smaller polygon.

578 post(s)
#14-May-18 06:14

Trying same on a different machine with M9.0.167 I am finding that I can't click to see the record of a stacked polygon when the smaller polygon is *on top* of the larger polygon either. It seems that Manifold is using the spatial index to decide which polygon to show attributes for or to edit and is stopping at the first suitable entry. This might not be a case of Z order.


8,516 post(s)
#14-May-18 07:26

I know this is a big ask, but it's also something that matters to literally everyone.

Can you post an example of the last situation you mention?

A really limited example that shows it.


6,282 post(s)
#14-May-18 08:42

Here is a very simple example. I can not address the area on top with <ALT> click to see the record in centents.



5,249 post(s)
#14-May-18 11:54

Easy. Alt click the blue area in the center. In the record pane click the "next" arrow.

The visual metaphor for showing and designating data is great, but it only goes so far in cases where data is constructed so as to defeat the convenience of that visual metaphor. It's easy to say "oh, use Z order" as if that would be a magic wand, but it is not a magic wand that always resolves all ambiguities and cuts through absolutely every issue. In such cases it helps to use a mix of techniques.

Where I see Z order for rendering being especially helpful is, perhaps unexpectedly, in the case of points. Consider a case of cities where you render the size of each point symbol, say, a circle, by the population of the city. But if you have a situation like Paris where it is much more populated than the many immediate suburbs that are reported as separate cities you can easily have a situation where a big "Paris" circle covers up the many smaller circles for suburbs.

In that case, it would be useful to set Z order by population value with smaller populations being drawn above bigger populations. You can think up similar situations with road lines in layers, where you definitely want some road lines drawn above other road lines.

Areas can be trickier. In the example Klaus has attached from a purely visual assessment, suppose the Z value of the blue area was set for it to be drawn above the green area. OK, that's cool, that makes the blue area visible, but at a first glance it could be just a blue lake within a green land area, where the green land area has a hole in it that exactly matches the shape of the lake.

To resolve that as one object on top of another you need disambiguating border styles - rarely met on the fly in GIS packages and also bringing their own set of visibility issues.

To make it easier to deal with Klaus's example I could think up a number of rules. But to think up rules which would work all the time and not take away conveniences in other situations... not so easy. For example, suppose the rule is "always when alt-clicking choose the uppermost object." OK. That's cool and would certainly work in this example, but then you'd lose he ability to "click through" higher objects when using transparency with hatch styles to "see through" higher objects.

Another possibility might be to limit alt-click to selections. For example, we could alter the shortcuts so that a ctrl-alt-click puts it into editing (Ctrl = C for Coordinates) mode and a shift-alt-click applies the alt-click only to selected objects (Shift = S for Selected). You could then use the various selection modes to choose exactly what you want in an ambiguous situation and then Shift-alt-click on that.

287 post(s)
#14-May-18 12:14

No, not easy in general. If there are couple of zillion areas "between" them, you wouldn't know when you are going to reach the one you are interested in.

For a moment I thought that there is another "next" arrow that will cycle only through areas that were near the Alt-Click. No, the usual "next" arrow goes to any object, near or far.


5,249 post(s)
#14-May-18 12:16

Cross posted... see my other post. What's best and quickest, of course, depends on the data you are using. Arrows are fine for small data. Bigger data you'd use a different approach, like the second method I suggested.


5,249 post(s)
#14-May-18 12:15

Should have mentioned... using the "next" arrow is, of course, a hack that cannot be counted upon to work with very many records. Nothing prevents the upper and lower objects from being separated by a million other objects.

Two other methods:

Ctrl-click on the outer green area to select it. Press Ctrl X to Cut. Now, Alt-click onto the smaller area to read attributes. When finished, press Ctrl-C to paste the big area again. Not for the faint of heart, but effective. :-)

Less radically: Ctrl-click on the small area. That selects both. Shift-ctrl-click on the outer area to deselect it. Right-click on the drawing tab and choose Open Table. Read the values desired from the selected record.

The above case is also where I would love to see the Record panel swing into action to show attributes for the context record, which could be the selected record.


5,249 post(s)
#14-May-18 14:44

See also this topic.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.