Subscribe to this thread
Home - General / All posts - Question about buffers
dchall8
1,008 post(s)
#18-Jan-18 22:23

I'm not getting the expected result when using the buffer transform. Images attached. What's happening is the parcel is not enlarging in all directions equally. The parcel is three residential lots combined into one. The inner circular area is a cul-de-sac feature 80 feet in diameter. The blue line across the cul-de-sac is there only to serve as a point of reference for this question. Note that as the buffer distance increases, the cul-de-sac is unaffected as is the back of the lot for the most part. I attached a M8 20 ft buffer on the same lot for reference. Also you can see in image 3 that the buffer has jumped across a street without enveloping the street. Am I doing this correctly?

Attachments:
Buffer question 1.jpg
Buffer question 2.jpg
Buffer question 3.jpg
Buffer question M8.jpg

TAL7 post(s)
#18-Jan-18 23:21

It appears that the parcel that has the buffer applied to is under the other parcels. It is enlarging in all directions but is hidden were covered by the other parcels. Choose "Add Component" to create a new drawing and table of the buffered parcel, then add to map to confirm that it is expanded in all directions equally.

Edited: If you choose "Update Field" the buffered parcel will be drawn above all the other parcels, replacing the original parcel being buffered.

tjhb
10,094 post(s)
#19-Jan-18 00:28

TAL: The statement in your edit is incorrect for Manifold 9. See comments below.

tjhb
10,094 post(s)
#18-Jan-18 23:23

You're using the UPDATE method to replace the selected area with the buffered area, correct?

You have fully opaque area styles in effect.

It looks to me as if the new, buffered area is being masked by some of its neighbours.

That is, the buffered area overlaps [or "underlaps"] with other parcels.

That would be normal and expected.

If that is right then the reason it is throwing you, perhaps, is that the new, buffered area is not being drawn last in the drawing, so that it would appear above all of its neighbours.

That would be the case in Manifold 8--there the newest area is always drawn last. But that is not the case in Manifold 9, where Z-order amongst objects withiin a drawing is arbitrary. This is a minor cost of rendering in parallel.

To control Z-order in Manifold 9, we must show objects in separate drawings, and arrange them as ordered layers in a map. Sometimes this will mean using significantly more drawings and layers in Manifold 9 than we would in Manifold 8.

[Added.] Exactly as TAL has said more succinctly.

dchall8
1,008 post(s)
#19-Jan-18 16:55

Yes, in fact, the buffer transform was working and what TAL said (clicking Add Component) works to see the result, but clicking Update Component does not do what TAL suggested. So in addition to that not working, what else is not working is preview. This says to me, "preview does not always give you the result you would expect." When I set the opacity to 40% (image below) and do the transform, as soon as I click the Buffer template, the drawing switches to 100% opacity (image below) and hides part of the transform preview underneath adjacent parcels. When I choose Update Field, the transformed parcel still sits under the same parcels it was under before and the image remains at 100% opacity (image below). When I click Refresh the opacity returns to 40%; however, the transformed parcel remains hidden under several adjacent parcels as if the layer opacity were 100% (image below).

This is sort of an artificial case for me. I would never use a buffered parcel in the same layer as it originated. But the layer I use to create buffer parcels has scraps of lines, points, and areas lying around. I still need to see what the final result is.

Attachments:
100% Opacity with Buffer selected.jpg
40% Opacity.jpg
Buffer masked and opacity returned to 100%.jpg
Map refreshed - 40% restored - buffered parcel still masked.jpg

tjhb
10,094 post(s)
#19-Jan-18 21:29

1. None of the attachments can be accessed using the given links. Anyone wanting to read them should copy the link, then remove the % sign in the 100% or 40%--leaving the other percent signs, which are used as escape characters. (That is why the literal percent sign is throwing the server.)

Here are adjusted links to dchall8's attachments, with the literal % signs removed. (Links also reordered to match text.)

40% Opacity.jpg

Buffer masked and opacity returned to 100%.jpg

100% Opacity with Buffer selected.jpg

Map refreshed - 40% restored - buffered parcel still masked.jpg

dchall8
1,008 post(s)
#19-Jan-18 21:56

So sorry about that. I was surprised the % saved as a file, but did not think about the ramifications for the forum.

adamw


10,447 post(s)
#24-Jan-18 07:32

That's fine, it's the forum software that should have handled it properly. Filed a request to fix.

tjhb
10,094 post(s)
#19-Jan-18 22:00

2. There is a lot to say here--some things are wrong, one or two possibly right--but I'm not going to say any of that for now since the post is not set out clearly (written in frustration I suspect). It would be a lot of work to unpack and unpick it all, and frankly I can't be bothered, because (a) it is sunny here and the dogs want to go to the beach, and (b) I think it would be a waste of time, for the reason below.

3. I get the impression that in this post and other recent posts, what you are trying to do could be described like this:

  • Starting from the procedures I use in my work in Manfold 8, how can I best reproduce my workflows in Manifold 9?

I think that's a mistake, likely to lead to unnecessary grief and perhaps not much else.

To underline the point, look at your last paragraph, beginning "This is sort of an artifical case for me..." Well preferably, don't do that.

Don't start with the means you would use in Manifold 8, and bang your head against the wall trying to make that work in Manifold 9. They are very different applications.

Instead try something like this:

  • Starting from a defined purpose, and given the tools available in Manifold 9, how can I best achieve the result or output I need?

That middle part--"given the tools available in Manifold 9"--obviously involves a lot of reading. There is no getting around it. You did that once for Manifold 8, now you have to start doing it all over again for Manifold 9, assuming you do want to make the transition (over time). Videos can be a big help of course, though not on their own.

Don't be impatient with yourself about the process. There are a large number of new concepts to learn. No one can do it all at once.

Another comment: don't be in a hurry to avoid SQL. If it's daunting (sure), try small chunks. Use the Edit Query button sometimes, when you have time, just to see what the engine will do to implement a transform. It doesn't matter if you can't make out much of it at first. That's normal.

Lastly, when you bring a problem/puzzle to the forum, to discuss how it can best be achieved in Manifold 9, first say what the objective is. Purpose and context are hugely important, whether it's a real-world challenge or a learning exercise. (I'm partly repeating Dimitri here.)

I'm giving all this advice to myself as well.

dchall8
1,008 post(s)
#19-Jan-18 22:33

I am guilty of having a hammer and seeing everything as a nail. The other thing is that I understand American English, when someone from Scotland speaks to me using their vernacular, there is some translating needed. In M8 I used centroids. In M9 I will be using Center and Center, Inner and Center, Weight. In M8 I think of 'center' as a verb to move the map to the center of the window.

In M8 when I want to make a circle, I use the icon that looks like a circle. In M9 I use a Compose tool, specifically the Compose Circle tool. Interestingly if you are looking for the tools to make circles, points, rectangles, line segments, triangles, instead of being in their alphabetical locations, they are collected under the Compose family of tools.

That middle part--"given the tools available in Manifold 9"--obviously involves a lot of reading. There is no getting around it. You did that once for Manifold 8, now you have to start doing it all over again for Manifold 9, assuming you do want to make the transition (over time). Videos can be a big help of course, though not on their own.

For the simple things I do, I did very little initial reading. Had I needed to read about Manifold up front, I would still be piddling around with some non GIS tools. No, I got started by watching Art Lembo's first videos in 2004. Within one week of receiving my Manifold CD I had a fully labeled map of 5 counties showing all the abstracts, my client's leased property (color coded), her competitor's leased property, and her target zones for future leases. I printed all that from a template layout to a layered Adobe Acrobat file. I like to tell people that story when I tell them how easy Manifold is to use.

tjhb
10,094 post(s)
#19-Jan-18 23:41

For the simple things I do, I did very little initial reading [but relied only on video training] ...

I really don't think that's going to be possible for Manifold 9.

But everyone has the inalienable right to shoot himself or herself in the foot.

You can probably expect other users to bear another user's own investment in mind, though, when deciding how much time to offer in discussing forum questions.

adamw


10,447 post(s)
#23-Jan-18 12:44

Didn't read yet through the end of the thread, but a quick remark:

Setting opacity for a layer works on the entire layer, not on individual objects. The individual objects will not be seen through each other. As Tim said, the issue is that the transformed object is getting partly obstructed by other objects. We understand this is undesirable and have two things planned to fix it: (a) render selected objects on top of unselected, (b) allow ordering objects explicitly using a field.

Dimitri


7,413 post(s)
#23-Jan-18 17:50

Neither (a) nor (b) is a solution to confusion caused by objects that are overlapping in the same layer.

(a) Select the object and it renders above overlapping objects. You still cannot see the overlaps underneath but I agree that at least you can see the entire selected object.

(b) Doesn't really help unless you know the right order to show all of a particular object in a given overlap situation. I wouldn't prioritize this since systematic Z order for many objects is probably an indicator you should have them in different layers.

The basic problem is that overlapping areas in the same layer are intrinsically a mess. Dealing with them visually usually works best if you use a style that uses transparent fill color for areas so the borders are visible. Then you can more clearly see overlaps. Dealing with them topologically means getting rid of the overlaps.

tjhb
10,094 post(s)
#23-Jan-18 20:00

I gently disagree.

I think both Adam's (a) and (b) would make a big difference, probably enough.

Regarding (a), Dimitri's own response seems to confirm rather than dispel its utility.

If I, the user, am wondering whether there are some overlaps which I can't see, then clicking on a single object is a natural instinct--with the equally natural expectation that the selected object will be privileged (drawn on top of other objects).

Regarding (b), yes it does not help in all cases. But to a significant extent, the cases where explicit Z ordering cannot help are also the cases where it doesn't matter! The converse is also true: cases where explicit Z ordering can help tend to be cases where it does matter.

Examples of typical values for Z ordering: area (larger first, smaller on top); elevation (lower first, higher on top). Natural, useful, almost (I would say) necessary.

As to Dimitri's last point, that "overlapping areas are intrinsically a mess", that is a great example of goal displacement, and quite unrealistic. Whether my data has overlaps, and why, is my business. It can often be meaningful, natural, and efficient. (Just like an Oxford comma.) The software has to be able to cope with overlaps, without getting in the way of my work, but on the contrary helping where it can.

apo
171 post(s)
#30-Jan-18 10:32

Just a remark on this quote

Setting opacity for a layer works on the entire layer, not on individual objects.

This is for me a big change from M8 as shown in the screen shot. In our mapping works the way M8 is handling the opacity is a must because it allows us to show overlapping objects even located in the same layer. The M9 way to handle opacity is on my point of view lacking this opportunity which is a necessary feature in cartography but maybe less for other uses.

Any chance to set that in the M9 version? If yes my vote is

Attachments:
m8-m9-opacity.png

adamw


10,447 post(s)
#30-Jan-18 17:04

We can allow this in 9 too, sure. Vote taken. :-) Thanks for the note and the screen.

dchall8
1,008 post(s)
#31-Jan-18 18:02

There is a nuance not discussed in the single layer opacity discussion. See the attached image for reference. When I go to do a buffer transform, the opacity of the green layer changes from 40% to 100%. That's the nuance. The red record shows the original parcel in a different drawing layer. The blue is the preview of the 1,000 ft buffer around the parcel from the green layer. Quite often simply seeing the preview would give me an answer to my question, but when the preview masks and is masked randomly by the selected layer, it would require a host of extra steps to see what I want to see.

Attachments:
Buffer masking in Transform.jpg

Dimitri


7,413 post(s)
#31-Jan-18 18:30

simply seeing the preview would give me an answer to my question, but when the preview masks and is masked randomly by the selected layer,

So, basically what you would like are two things:

a) whatever is the layer's opacity would also apply to previews shown in that layer, and

b) you would like opacity to apply on a per-object basis within the layer, so that if two objects in the same layer overlap the region of overlap would be a combined opacity effect, like cutting the two objects out of a semi-transparent film and overlapping the shapes.

I think both are doable and reasonable.

StanNWT
196 post(s)
#31-Jan-18 20:27

Would it help if there is a transparency field where you could assign a transparency interger value to any objects you want in the drawing then if you wanted an overall secondary transparency of the first set of transparency values for the drawing as a whole?

Dimitri


7,413 post(s)
#01-Feb-18 06:12

Well, virtually anything is possible, but the question then becomes which of those broad range of possibilities should be implemented, and at what cost.

Two of the biggest costs are, first, the cost of learning wheels within wheels, fractal complexity, and then, second, decoding what someone (perhaps even yourself a few weeks ago...) has done using such complexity.

Good examples of the costs are the various text editors out there catering to niche interests that allow infinite customization and personal macros for everything, so people who use them constantly might customize them mightily, only to discover that after coming back from a one-week vacation they are completely unable to use their own, "home" editor.

In the case of wheels within wheels application of transparency, sure, you can get exactly the effect you want in some particular case, but then perhaps even you, yourself, might have to work to decode exactly what the visual display is all about, only towards the end drilling down into an "aha... I have individual transparency set per object based on this field..." moment.

We can see those factors in play right now in 9 when you consider a) formatting, and b) formatting with per-object style overrides.

a) is straightforward to explain and to understand, and it is very WYSIWIG in terms of understanding what style in a given layer is about. One layer, one style, is an easy model to grasp and to apply. Use layers to group whatever you want into whatever constellations of styles that you want.

b) is much more complicated for beginners to grasp, much more difficult to explain, and, potentially, staggeringly more complex to decode what is going on in a visual display. When any one object can modify some part or all of a style for a layer, just for itself, you get into a true labyrinth of possibilities.

Another example is the "every window can have its own selection" notion originally introduced in 9 and then later withdrawn. It was a case of a bridge too far in terms of possibilities, where a return to the constrained, simpler situation of one selection for every component based on a given table was a true example of the adage, "less is more."

I feel that way about per-object formatting as well. I don't like style overrides at all for that reason, but I understand that it is one of those things where there is no point in arguing with the market. Some things people have to learn the hard way, for themselves.

I strongly recommend people make the effort to think in terms of "normal form," to borrow a DBMS concept, where if classes of objects are distinguished enough to use different styles they probably should be organized as different layers, that is, distinguished into different data bins as well. Yes, that does take a bit more effort initially at organization than just forcing a color here and there on the fly. But it is effort that pays off over and over in the future while the forcing of appearance using things like style overrides is borrowing now at what often ends up being a vicious payback rate later on.

All the above come together with special ferocity when leveraging 9, because 9 makes it so easy to introduce endless, wheels within wheels complexity. 9 has so much raw power internally that intricate chains of display rules which simply could not be possible in classic GIS technology like Arc, Q or 8, where they would be too slow, are perfectly doable in 9. So you don't have the constraint of being forced into a better, "less is more" interface, and can make it as opulently baroque as you like.

That means the only limitation we have on achieving a "less is more" balance is the good taste and self-restraint we ourselves, as a community, can summon. :-) So, anyway, I'd close this mini-rant with the observation that not everything that is possible should be done. We should always really think hard about the cost of teaching beginners some new intricacy, to consider if there really is a need for that intricacy, and to consider how maintainable/understandable the intricacy would be in practice in a project months or years after we did something intricately clever.

Hope that helps!

tjhb
10,094 post(s)
#31-Jan-18 20:44

How about staging changes in a priority order? This order is a suggestion.

(a) Whenever a preview is shown, preview object(s) (in blue) would be drawn last (shown on top) within their own layer. If more than one object is previewed, Z order among them would be arbitrary--until (c) below. In a map, any higher layers would still mask the target layer.

(b) When there is a selection, selected object(s) would be drawn before preview objects (if there is a preview), but after all unselected objects, again within their own layer. The last two sentences for (a) would also apply for selected objects.

(c) Add a means to control Z order explicitly for the objects within a layer. If this imposes a significant cost (i.e. serialization), make it optional, defaulting to arbitrary Z order (as now).

(d) Given (c), also apply explicit Z order amongst preview objects (a) and amongst selected objects (b).

(e) Apply transparency amongst objects within a layer (and again within preview and selection).

(f) (Possibly) Add a means to control transparency per-object (as suggested by StanNWT).

adamw


10,447 post(s)
#01-Feb-18 09:24

I will offer the following amendments:

Z order: There should be a way to specify Z order via a numeric field. If Z order is not specified, it is random except that selected objects are put on top of unselected objects. If Z order is specified, it is still random for objects which have the same value of the Z order and the selection does not alter it (we can also make it so that selected objects still come on top of unselected objects, this is best discussed after we have the first implementation).

After Z order is figured out, we can work with per-record opacity, because it will now behave predictably.

Opacity for individual objects: there is no need to control it separately using a field, we can simply use the alpha channel in the style color. We need a custom color picker dialog / control to specify the alpha value when picking a color.

Opacity for layer: we are not sure if we should apply it to the preview for transforms. For unaltered objects, yes, but for altered objects, perhaps not. We are throwing away colors for altered objects in order to make it easy to see where the changes are and what they look like. If we leave the opacity on and it is set to a low value, it will be hard to see what the transform is doing. Maybe what we need is to make the bodies of previewed areas naturally semi-transparent with a fixed value of the opacity.

Dimitri


7,413 post(s)
#01-Feb-18 12:09

there is no need to control it separately using a field, we can simply use the alpha channel in the style color.

Yes, perfect. Forgot about that! :-)

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