9.0.178.5

manifold-9.0.178.5.zip

SHA256: 9beb3a02b600b5ec600a3b409fc6b5a6d7f246af61d753d52b682c40664f4908

manifold-viewer-9.0.178.5.zip

SHA256: 1a1dceabc19c4ded476e5983862fc3fceba7e9b2893772155c65d13f7ec4637c

sql4arc-9.0.178.5.zip

SHA256: 4c924596b7868912edda7678b2b967841ef6e3d214a8a8f3501aa7d7af435072

Changes

(Fix) Reading TIFF files with data stored in strips with heights that are not powers of 2 no longer sometimes fails.

(Fix) Performing an EXECUTE [[ ... ]] on a SQL Server data source with a command that returns multiple results no longer returns the number of affected rows instead of the first result table.

The layout window limits the number of rendering threads for a map frame. This significantly improves performance when rendering maps that contains lots of layers: instead of trying to render all layers at the same time, the window now starts rendering a couple of layers and only starts rendering new layers after previous layers finish rendering. (We originally introduced this mechanic in the map window, now the layout window does the same.)

The layout window limits the number of rendering threads across multiple frames. This helps render layouts with multiple maps.

The layout window dynamically increases the limit on the number of rendering threads if the window gets active and decreases it if the window gets inactive. (The map window also does this; we tuned the adjustment to work smoother for systems with lots of CPUs.)

The filter button in the Layers pane includes the new Overlap Mode command which shows the overlap mode for label layers and allows editing it. Available overlap modes:

• layer - labels in the layer may not overlap each other, but may overlap labels from other layers, this is the default,
• map - labels in the layer may not overlap each other and may not overlap labels from other layers whose overlap mode is also set to 'map', labels from lower layers are given priority over labels from higher layers.

Overlap modes work in the map window, in the layout window and during printing.

Using map overlap only makes sense for multiple label layers. Editing a layer with map overlap or turning that layer on or off will repaint other layers with map overlap above it. Rendering layers with map overlap decreases parallelism as these layers have to be rendered in sequence. However, in practice, this does not necessarily decrease rendering performance, as the final number of labels to render also decreases.

End of list.

This is wonderful Adam! I've been hoping and agitating for the overlap control for a long time and how interesting that it shows up on my birthday. Hey, that's great.

Couple thoughts on making it a tad easier for people. Could default overlap mode switch to Map when 2 or more label layers are on the map? Why have labels lower in the layer list prioritized over higher ones, given that's opposite of how other layers render? Also, render time seems great so far.

-No sure about default map vs default layer. Sometimes when doing analysis or using manifold as a general data viewer you want to see all labels, even if they overlap. Sometimes, especially when printing, the opposite case is the usual one.

-Agree. Labels higher in the layer list should be prioritized over lower ones. They are placed over than others in the list because we want to see them better, or because they are more important.

that's opposite of how other layers render?

Ah, but other layers don't make objects disappear that conflict/overlap with each other. If they did, you'd probably want a "bottom up priority" system for clipping in vector layers as well.

Let's take vector layers as an example. Suppose Layer A has many areas and Layer B has many areas. Layer A is above Layer B.

OK. Suppose Layer A has a few big areas that completely cover some smaller areas in Layer B. Because A is above B, you don't see the covered areas in B at all. You don't even know you have a problem with some of the B areas being totally hidden by A areas.

How would you handle that with a clipping rule? If you say "Because A is higher, whatever is in A clips any conflicting area in B," that's simply saying what the visual effect is from A being higher, and thus covering, B. There's little point to having overlap resolution between layers if all you do is simply apply the visual effect you automatically get from A being higher than B.

If you're going to have an overlap resolution rule with multiple layers for vector objects, such a rule adds more to the party if it does something the default "higher layers cover lower layers" visual effect doesn't already do. An overlap rule between layers adds value if it prioritizes lower layers, because then if an object in A conflicts with an object in B by covering the B object the A object gets clipped, and you get something you don't get with the default visual effect: you can see those B objects which otherwise would be hidden by A objects.

Now generalize that thought experiment to labels. Big labels, especially those with boxes, can easily totally hide labels in lower layers. If the overlap clipping priority is the same as the layer stack visual effect where upper things cover lower things, then the clipping benefit is less. If, in contrast, the overlap clipping priority is bottom up, you get the benefit of revealing lower labels that otherwise could be hidden by higher overlapping layers. That's one reason for using bottom up priority.

The other reason for doing it is speed. Taking the time to compute rendering on something that later is all or partially hidden is a waste, and you can get inaccurate rendering results using many threads when using top down clipping on overlays (alas, the margin of this paper is too narrow to write out the proof...) using only a single pass. To ensure accurate rendering with many threads using top down clipping you'd need at least two and possibly more passes depending on how many layers are in play. That could immediately divide by two the speed of rendering, which could easily become perceptable with larger data.

But even for small data where speed might be a don't care, the value of surfacing hidden labels using bottom up priority is still a factor.

In any event, asthe recent video shows, it takes but a fraction of a second to drag a label higher to set rendering priority however you want it in the stack.

On making overlap mode switch to Map for multiple layers -- that's essentially making Map the default overlap mode. We don't want to do this because it would change the appearance of existing maps. We are trying hard to avoid changing the defaults like that because it always backfires. (Even if our changes to defaults are so good that 80% of our users like or at least don't mind them, and only 20% don't like them and would prefer old defaults -- since we are constantly issuing new builds, over time everyone will be hit by multiple changes to the defaults that they don't like. This makes the process of upgrading to a new version of the product scary and unpleasant. Because who knows what will change in the way you don't want this time, and who knows how long it will take you to fix things.)

On giving priority to labels in higher layers vs lower layers -- in general, the direction is arbitrary. The argument for giving priority to labels in higher layers is that higher generally means 'more visible'. The argument for giving priority to labels in lower layers is that lower generally means 'bigger' and 'bigger' frequently means 'more important'. For example, in a single state with multiple cities on top of it where you took care to add labels for both the state and the cities, do you really want the label for the state to be hidden by a label for some random city? It seems better to let go of a label for one city out of tens but still see the only name of the state. In practice, we started with giving priority to labels in higher layers, but then we discovered that this is very unfriendly to printing (the immediate effect is a big drop in output quality as labels can no longer stay vectors and have to be rasterized, this can only be improved with a significant rework of the printing pipeline which should get much more complex and perform multiple passes instead of one), so given that the direction is arbitrary, we reversed it.

Thanks to you both for the explanations of why this is challenging. Some thoughts:

1. Rendering speed is always great, more so for web and mobile mapping, while less so for printed maps.

2. Rendering more labels is a sign of quality. It gives more info quickly to the user. The video above demonstrates how the current system is not very robust at placing labels. When the city labels are given priority, the region labels don't display when there is clearly enough space for them. I suppose this is due to the label adhering to the polygon's bounding box. Hopefully this isn't unavoidable due to parallelism, but if it is then it would be nice to have the option to give up parallel rendering or at least some speed for better quality labeling.

3. A logical user interface hopefully means faster user understanding. Obviously most users won't know the nuisances of parallelism. However, if label vs. other layer ordering needs to be different for speed and quality, so be it. The layer pane is indeed easy to use.

4. The policy of not changing existing maps is good, but in the case of overlapping labels I'd be surprised to hear that you'd get many complaints. Sure sometimes people want maximum labels and are willing to live with overlaps but it isn't something they spent a bunch of time setting up and it is less likely to be something they shared with others as a high end product. Defaulting to map overlap mode seems worth it in this case.

5. It is great to have overlap control and I hope Manifold continues to improve placement. Thanks!

Rendering more labels is a sign of quality.

That is false.

I agree that quantity does not equal quality. But I assumed that by "more labels" Mike meant more labels in a cartographically constructive way.

That's a matter of taste, for sure, a balance between too aggressive clipping and too little clipping of overlaps and near-overlaps. But it may not be the right approach to ask clipping algorithms to deal with aesthetic issues that may arise from data that leads to overly dense label fields.

For example, if you want to label populated places, if the source points layer has very many points you could end up with a labels layer using small point sizes where no label overlaps another, but where the result is such a dense mass of labels that it is visually unpleasant and harder to parse. The way to get a better appearance I think is not with tinkering with settings such as font size, or allowed margins between labels before they start clipping each other, but by thinning the source point data set to fewer points, perhaps showing only labels for those populated places with larger populations.

I frequently use this technique to "thin" my labels by using a transparent style on less populated places. When that isn't quite sufficient, I'll create a VISIBLE field, populate it with a YES or NO based upon my initial population requirements and then modify the visibility field for points that don't meet the population requirement, but for other reasons, I want them to display on my map.

My biggest difficulty is the inability to completely turn off clipping for a layer. There are layers where I want to make sure all labels are shown. If there are a lot of them, it's easy to miss that one or two have been clipped. I often create separate points for my labels so I can easily move them around to prevent clipping, but in moving them, they will then collide with another label, which then disappears and I have to dig for that label and move it until there is no collision.

Being able to always see all labels, even if there are collisions, would make it much easier for me to make those small modifications to insure every one is seen.

This new feature to be able to prioritize which layers can clip other layer labels has been very helpful in eliminating another cause for disappearing labels.

We can allow turning off overlap control for a specific layer, no problem. I will put that into the wishlist.

That would be great...I did submit a suggestion earlier today for that!

Sounds very reasonable to have the clipping algorithms work hard to place labels (losing label tries to find a new location as AdamW mentioned below) and let users decide what to thin. We have the lovely ability to write SQL in the Style Pane to thin labels and I have done the same as wvayens by using a separate field to fill with desired labels.

This is better but not really fine grained in that a larger population city beats a smaller one for what is being asked to be labeled. Am I correct in assuming that using Order By in the label pane's SQL wouldn't help prioritize label rendering?

It would be great if the user could have some additional control to the clipping algorithm to allow or not allow label stacking, font reduction, etc. to help lessen clipping.

Also, I think it would be great if the Style Pane for vector layers also had a SQL dialogue, similar to labels, that allowed only displaying the desired objects. ESRI calls this a definition query. We can currently write a separate query and create a separate drawing component but that is cumbersome compared to the approach now available for labels.

Mike, let’s face it, there is no successful labelling algorithm. No one has ever devised one. (Or: they are all wrong.) Just look at Google Maps: horrible!—despite what we can assume to be unlimited resources.)

Labelling well is one of the hardest aspects of cartography. It cannot be automated.

What Manifold can do is to give us tools to label well, manually. Meaningful control.

Let’s make sure we aim for that. Great progress is being made (partly because of good suggestions like yours).

Sure nothing will be as good as manual if enough time and care is used and yes whatever scheme Manifold comes up will hopefully allow for that relatively easily. For web maps, phone apps, and quick static maps a decent automatic labeling method is really helpful though. MapText.com is the best I've seen and they have expanded their labeling method for static maps into a phone app. Their selling point compared to other phone mapping apps is more info from the map at a glance.

You are right. Helpful is not to be sneezed at.

I will look at MapText.com on your recommendation. Thanks.

(I will still bet on the useful, not the automatic.)

creative labelling

https://github.com/mdsumner

My favourite there Mike is the USGS Colorado map.

Totally correct [I assume], and totally useless!

I think we have the same sense of humour.

Funnily enough I don't see anything wrong with the Tokyo/Kanto map. It does show one thing clearly. (Well enough that it doesn't even need a legend.)

(And while I don't understand Czech, I think that post, and perhaps others, were possibly added by bots? Not very current with poor benighted Twitter. It seems to be blanketing in perytons.)

Manual labeling at its finest

What Manifold can do is to give us tools to label well, manually. Meaningful control.

Let’s make sure we aim for that.

To this end, what would good manual labeling tools would look like?

Seems like one should start with automatic labeling and adjust it to improve as much as possible. The labels should be linked to the original vector tables as long as possible. Then there needs to be an override scheme/tools that allows moving a labels coordinates without modifying the vector's geometry. These overrides could live in the map project as a separate label component that has top priority for labeling.

To make it easy to adjust the label's geometry, it's geometry should be just the bare minimum coordinates needed to display it, rather than coordinates of the vector from which it originated. Perhaps just a line with the minimum coordinates.

If you often make maps with the same map extent and page size, then this override label component could be useful in multiple maps.

This is better but not really fine grained in that a larger population city beats a smaller one for what is being asked to be labeled. Am I correct in assuming that using Order By in the label pane's SQL wouldn't help prioritize label rendering?

No, ORDER BY won't help. We can allow prioritizing labels by a field in the future. This would also be useful for ordering vector objects in drawings.

Regarding 2, I think the key to showing more labels is not in reversing the priority from 'lower layer wins' to 'higher layer wins', but rather in adding means for the losing label to try moving around so that it can still be shown. We'll think about what we can do here. (For labels bound to points in particular there are certainly some easy things to try.)

On speed vs quality, we are not going for speed at the cost of quality. Whenever speed and quality collide (all the time, obviously), we pretty much always tend to choose quality and then do whatever is needed to get the speed, too. If we cannot get 100% quality without conceding a significant amount of speed, eg, we can get to 80% quality with a certain speed and getting from there to 100% quality makes things slower 2x and this just cannot be helped -- then we provide an option to choose between the two ways. We do not see 'higher wins' as obviously better than 'lower wins' in terms of user experience (as I said, there are arguments both ways), that's why we do 'lower wins' because that also helps performance. If we decide that 'higher wins' is significantly better in terms of user experience, we will add means to specify that the overlap mode should use 'higher wins' at the cost of switching to a more complex rendering logic, and then try to make this rendering logic not significantly slower than the current one.

Like the logic!