Subscribe to this thread
Home - General / All posts - New video showing new style features
Dimitri

5,082 post(s)
#31-Oct-18 13:04

There's a new video in the Gallery page showing new style features. Along with updated topics (many more to got...) like the Style: Drawing topic that helps getting started with the new style features.

[Pretty amazing to hear the drop down Symbol menu for points now has over 1300 symbols in it...]

Mike Pelletier


1,529 post(s)
#31-Oct-18 15:06

Very helpful video Dimitri. Thanks for putting that together.

I really like the ability to use the preview button to do fast thematic formatting. Great addition!

Some thoughts:

1. Should the stroke button for areas in the main style pane apply to the perimeter of the area object rather than hatching? Seems like that might be better given that to apply hatching you have to go to the "more" button on the symbol anyway.

2. In the area symbol dialogue probably should add "hatch" and "perimeter" to the two "stroke" labels to clarify.

3. Would it make more sense to automatically filter thematic formatting to objects of the matching object type. So when you apply thematic formatting to areas the dialogue filters out lines and points and you don't have to waste time applying formatting to objects that aren't relevant.

4. As your video shows, sometimes formatting exceeds the size of the display area. Perhaps it should be scaled to still be readable, but with some sort of indicator to show it is being scaled.

5. Related to #4, perhaps there will be some quick way to view the full effect of all the formatting in the legend either for a map or individual drawing. Still I wonder if that can be made better than having it reside in the style pane somewhere.

6. Why have an update style button needed for some format changes and others apply it instantly? Of course some sort of undo would be most welcome along with an easy save/retrieve format scheme.

Dimitri

5,082 post(s)
#31-Oct-18 16:45

1. Should the stroke button for areas in the main style pane apply to the perimeter of the area object rather than hatching?

Stroke color is the primary color. When there is hatching or options, both start by inheriting their colors from that.

3. Would it make more sense to automatically filter thematic formatting to objects of the matching object type. So when you apply thematic formatting to areas the dialogue filters out lines and points and you don't have to waste time applying formatting to objects that aren't relevant.

? I don't follow. When you apply thematic formatting to, say, areas, those controls you use to apply thematic formatting to areas don't apply thematic formatting to lines or points.

5. Related to #4, perhaps there will be some quick way to view the full effect of all the formatting in the legend either for a map or individual drawing. Still I wonder if that can be made better than having it reside in the style pane somewhere.

The Style pane is not a legend. The focus here should not be doubting there should be a legend, but detailed discussion on what you want the legend to be.

6. Why have an update style button needed for some format changes and others apply it instantly?

Because sometimes you want to do something simple instantly and other times you want to compose an effect and then be able to decide OK or Cancel.

Simple things happen instantly, that is, choices from the top level menus for individual style properties. Change multiple things at once within a bigger dialog and that's something you confirm.

There will be an undo, likewise an easy save/retrieve. There is infrastructure in there already (like the named groups of symbols) that will allow adding collections, etc.

Mike Pelletier


1,529 post(s)
#31-Oct-18 18:16

Thanks!.

Take a look at the attached file to see what I meant with #3. Click on the drawing's style preview for areas lines, and points. I added some bright color formatting to objects that does not get applied because you obviously can't color an area with the line formatting tools or use the area formatting tools to style a line. I'm just suggesting it might be better to automatically filter those out.

Attachments:
test.map

Dimitri

5,082 post(s)
#01-Nov-18 08:31

I still don't get it. I get the feeling that you're saying "The format does what I tell it to do. If I deliberately assign a daft format the visual effect is daft." Well, sure. If you use the thing wrong at an extremely elementary level the results will, as expected, be wrong. If you skillfully use the thing to do nutty formatting, the formatting will, as ordered, be nutty.

There are all sorts of nutty things people can do. They can format areas or lines in white color so they cannot be seen against a white background. They can use a thematic format that uses the value of the mfd_id field to assign variations which cannot be seen because there is no object of that type for some mfd_id values used in the format. There are good reasons for such rich capabilities, but eliminating the misuse of rich capabilities by getting rid of rich capabilities is not the right approach.

Consider the example: you have a drawing with areas, lines and points in it. OK. So far, so good.

Opening the Style panel and looking at the properties specified, the area style has black color both for stroke color and fill color. The result is black areas, as it should be. Why would you expect anything different?

It is an elementary blunder, a failure to learn the system at the most beginning levels, to think that commanding a change in style for lines would have any effect at all on areas. A key element that allows having areas, lines and points in the same drawing is the compartmentalization of style controls that only apply to areas and only apply to lines and only apply to points.

I added some bright color formatting to objects that does not get applied because you obviously can't color an area with the line formatting tools or use the area formatting tools to style a line

Well, sure. When you color a line, that shouldn't apply to areas. Why would somebody expect that, instead of coloring the line, coloring that is specified for lines should apply to areas?

Let's dissect the above more closely:

I added some bright color formatting to objects that does not get applied

False. It does get applied, exactly as you specified. Consider the thematic format you applied to lines. Your thematic format applies bright colors to any lines that have an mfd_id of 8 or 9. Lines with any other mfd_id values are colored black. In your drawing the three lines have mfd_id values that are 4, 5 and 6, and each of those lines, as you have commanded, are indeed colored black. Suppose you copied a geom with a line in it from some other record, and you pasted that into the Geom field for the record with mfd_id of 8. It would still be the same record, with an mfd_id of 8, but now the geometry it hosted would be a line and not a point. As your thematic format for lines specifies, it would indeed be displayed in the bright color you have commanded.

Suppose you added a new line: that would be colored in the brighter color at the tail end of the thematic format for lines, exactly as commanded.

Try the experiment yourself: open the drawing, and insert a new zig-zaggy line. It immediately appears in the brighter color of the last interval of your thematic format. Open the drawing's table. Copy the geom for that last record, and Paste it into the geom for the record with mfd_id of 8. Delete the last record (the last line you added). Back in the drawing, you see that the zig-zaggy line that was added, which is now the geom for the record with mfd_id of 8, is colored bright yellow, as your thematic format says it should be.

The ability to set thematic formatting for objects which might not yet exist is a critically important feature. It allows you to configure styles for displays which might be changed by adding or deleting objects or where objects might be changing from being points to areas to lines and so on.

Suppose you create a map for where fish have been caught. You want one style for locations where tuna have been caught and another for cod and so on. The drawing starts out blank... do you want your users to call the GIS department to change the format when a boat lands a catch of cod, to add cod to the style? Or do you want to have all that set up in advance so when the first point with a "Species" attribute of "Cod" gets created, there's a cool "cod" symbol there?

Here's another example. The thematic format for points is also weird because it uses the mfd_id field for thematic formatting, but it only assigns visibly different point styles to mfd_id values where there are no points in the geometry. The result, as expected, is that when the thematic format says to use default formatting for the mfd_id values of records which do have points, well, those points are (as they should be) shown in default formatting. The system is faithfully doing what you have told it to do.

Select the lines in your drawing. With the Transform panel set to Restrict to Selection, choose Center and press Update Field. You've just converted the geoms in the records with those mfd_id values into points. Since those are the mfd_id values you assigned to being visibly different dots (red dots), that is exactly how those points are styled.

I guess there are some key questions:

1. Most GIS systems are limited to allowing only objects of one type in a drawing. It's either all points, all lines or all areas, but a mix of points, lines and areas is not allowed. If you have such a limitation, then, sure, you can get by with only one set of controls. But then you have the impoverishment of drawings where people can only have lines or only have areas or only have points. Do you want that for Manifold? That seems really stone age to me, so I don't want that.

2. If you allow drawings to have a mix of areas, lines and points, then there is a question how you want the three sets of style controls to be displayed. I think it's visually clear what the difference is between the group of controls for areas, for lines and for points. I like the speed of having all that immediately visible, and I wouldn't want to have to, say, select which I want to use before I use it. Do you want to trade off an instant view for a slightly more compact display?

3. Do you want to be able to specify the formatting of drawings before all objects that might be in the drawing appear in the drawing? If you don't, or if you want to make that more difficult, then you could reduce the use of screen real estate. For example, when a blank drawing opens up there is nothing in there, so no need for any style controls, right? If somebody adds an area object to the drawing, well, then we could show area controls. But that would eliminate the ability to quickly set format for how you want lines to appear, or at least require some secondary step to turn on controls even if there is no such object there. It's not clear that would help out people who refuse to RTFM, either, because the moment you allow such an override control you're going to confuse people who think that style controls for an object appear only if there are objects of such type in the layer.

I think it is simpler and quicker the way it is, at least for people who do that initial bit of learning to know that having the controls available lets you set formatting for any objects of that type that might appear in the drawing, even if you do not as yet have such objects. I do that all the time, for example, when tracing over a satellite photo and I want my lines to appear in bright green. Or, for example, when I copy a standard format I used in some other drawing to use in this one.

For example, if I'm looking at real estate parcels I might have a standard drawing where I have a thematic format arranged on fields so that waterfront parcels have their outlines in blue and other parcels are outlined in green. I can start with that even with a blank drawing, and all will be in place for when parcels of different types are copied or created in that drawing.

As a general rule it doesn't make much sense to mix different types of objects or, for that matter, different categories of the same object within the same drawing if you want to thematically format them by some attribute that doesn't make sense for all objects. That's not an effective use of the organizational means, layers, that you have available for grouping your data efficiently.

So, suppose you have a drawing that shows features using a mix of points, lines and areas where an attribute gives the OwnerID for each feature, with OwnerID being something like "Army", "County", "State", "Federal" or "Private" and you want to assign a stroke color based on that, so that all "Federal" objects, whether they are points, lines or areas, are colored bright blue. That makes sense. But using an internal structural field like mfd_id that is a pretty abstract deal does not make sense.

Whew! Long post. But I hope it helps the discussion be more productive than simply saying, "well, sure, if you tell it to do daft things it will do those daft things exactly as you command..." :-)

Dimitri

5,082 post(s)
#01-Nov-18 12:21

Don't know. Been thinking about this some more.

If the desire is to see only one set of controls at a time, that's easy to do: add a filter button at the top of the Style display, in the toolbar space in the row where the Drawing, Options tabs are. You could then pull down the filter menu list of areas, lines, points to show controls for whichever objects you want. Plan on working with only Areas? Check areas in the filter list and only the controls for areas show up.

But that means a click or choice in a filter box every time you want to change whatever are the controls that are shown, and it is one more thing for a new user (or someone who doesn't use the system frequently) to find/learn how to use.

On the other hand, well, let's face it: given all the legacy GIS out there most layers are either all areas, all lines or all points. You could scrunch down the size required for controls, especially if they auto-scoped to automatically filter to whatever are the types of objects in the layer. Heck, you could even have a "reduced" form of the Contents pane, like a minimized music player, that was just a toolbar size.

But then, that also is something more to learn, to understand with many variations possible. :-)

Likewise with filtering to show/not show what might apply to different object types in thematic formats. That's always possible, and there are some nifty ways of doing that, but what all of them have in common is that they'll make perfect sense to experienced users who are in the groove but won't be obvious to beginners. Some of the new Style panel is a simplification for just that reason, since doing a combo style by having multiple columns in the thematic format interval pane to change multiple properties at once was, historically, a challenge for people to learn.

Mike Pelletier


1,529 post(s)
#01-Nov-18 13:57

Isn't amazing how sometimes what seems so clear to one person can be understood so differently by another :-) Thanks for going to such extremes to try and understand no matter how absurd my suggestion is appearing.

Let me try again. I'm suggesting to copy the behavior in Mfd 8. See the attached Mfd 8 file. Look at the what values (objects) show up in the thematic formatting dialogue for points, then lines, then areas for the simple drawing. Unlike Mfd 9, it only displays values corresponding to objects of the same type (points in point formatting, lines in line formatting, areas in area formatting). Why would we want the thematic formatting dialogue to show us line objects in the point thematic formatting dialogue? I wish we were in the same room and laugh about this.

Attachments:
test.map

Dimitri

5,082 post(s)
#01-Nov-18 15:41

Why would we want the thematic formatting dialogue to show us line objects in the point thematic formatting dialogue?

Well, the thematic formatting dialog doesn't show you any objects. It shows you intervals based on the field, method, and breaks you choose.

As a general rule, you don't want any dialog to tell you things that aren't true. So, if you tell it you want six intervals with an equal count of values in each, you want it to do that. You don't want it to think "Oh, he really doesn't want me to count these records here or those records there, so I won't count those or use them..."

I get it that you want to do thematic formatting based on a field, but you also want the thematic formatting dialog to consider only objects of the type from which you launched the dialog. So, if you clicked on the Stroke color button for lines and you chose a field, you only want to see fields and values where line objects have a value there.

But that's asking the thematic formatting dialog to do a round of filtration, to bring some order to your records, when really it is better not to mush together records in the same table that really should be separate.

Let me give an extreme example of what I mean to help illustrate the matter:

Suppose you have a data set of oil wells as points, with a bunch of attributes that are relevant to managing oil wells. Suppose you also have a data set of electric transmission lines as lines, with attributes that electric power utility cares about for delivering electricity and maintaining transmission lines. And, you have a data set of areas that represent wetlands, with a variety of attributes setting forth the regulatory status of those wetlands under different federal, state and local regulations.

If you wanted, you could put all those different objects together into the same table. That table could have 200 columns if you wanted so that all the columns you needed for all attributes from the three different data sets could be there for each record.

You'd just have a situation where, say, the oil well records would have NULLs in the fields that are there to host attributes for the lines and the wetlands, and so on.

You could do that, but it would be an absolutely terrible way to organize your data.

And now, suppose you want to start doing thematic formatting. Pick any field and you're not going to have it in common in all three data sets, so there is no sensible way to do thematic formatting because it's not a sensible collection of data mushed all together in one table.

What you are asking for would help, because you could do thematic formatting on the oil well points, the lines, or the wetlands areas pretending the other objects weren't in that table. But that's a really sloppy way to approach the data, which will bite you in the long (or short) run.

The right way to deal with the situation above is not to ask the thematic formatting dialog to play tricks that pretend some of the data in the table is not in the table, it is to select the various three groups of data and put them into their own tables. Then you can sensibly, and easily thematically format them without having to pretend that some of the data in a table is not in the table.

Release 8 is very cool, but it is woefully slack compared to 9 when it comes to clear, crisp, and correct data management. If you need tricks like the illustration in the 8 project, that usually indicates you've munged together data in one table that really should be in separate tables.

By the way, it is also a very powerful notion to be able to set thematic formatting by a field value based on that field value and not filtering by the object geometry type: there are plenty of cases where somebody might add data to a drawing and they might add that data as a point, a line or an area.

Suppose, for example, you're marking archaeological finds or traces in a region: You might mark the location you found a shard or stone tool, a line where you found traces of an old road, or an area that marks carbon traces from an ancient burn. You might not know in advance what the object will be, but you might want to set formatting for different cultures or epochs by color, so all similar finds stand out regardless of whether they are areas, lines or points.

By the way, I'm not saying that there aren't times when you might want filters of various kinds in the thematic formatting intervals... I'm just saying such interests usually indicate inappropriately blended data that can be handled in better ways with other tools.

Mike Pelletier


1,529 post(s)
#01-Nov-18 19:38

Okay, I thought it was probably just an oversight but I see now it is purposeful to have Mfd 9's thematic formatting dialogue show values of object types (points, lines, areas if present) that do not correspond to the object type of the dialogue.

So in your example of archaeological finds when the point symbol thematic dialogue displays that 50 objects fall into a particular interval the user must realize that it actually means there are 50 objects made up of an unknown number of points, lines, or areas. We would not want to display that on a map so we need to prep the data first to avoid this. At this point we are probably second guessing why put all the data in one layer.

Assuming the future legend making tools allow this new method could create a legend that shows archaeological finds as a color blob (probably should not be a point, line, or area to not imply a specific type) with counts for objects in the thematic intervals. This maybe useful but not sure it is worth downside in paragraph above. Time will tell what users think.

Dimitri

5,082 post(s)
#02-Nov-18 09:08

it is purposeful to have Mfd 9's thematic formatting dialogue show values of object types (points, lines, areas if present) that do not correspond to the object type of the dialogue.

That's phrasing it wrongly, in a way that may indicate conceptual errors, which might slow you down and prevent you from using the tool to make life easier. (I'll get back to that after we lay a foundation.)

Look, the idea is not to make things more difficult, the idea is to make things faster and easier. Clarity in how you organize your data works wonders for that.

Sometimes what matters is the object type (point,line,area) and sometimes what matters is an attribute. The key thing is to organize your data so what matters to you comes easily to hand in fast and easy work flow.

Use powerful tools to better organize your data. Don't use powerful tools to organize data poorly, and then ask other powerful tools to be weakened in special case ways to work around poor organization.

It's like organizing employees who must work together all the time in two different floors and then suggesting that guard rails on stairs between the floors should be removed so you can jump from one floor to the next more quickly. Better to organize employees more effectively so nobody needs to risk jumping.

A parable:

Joe's Aerospace Parts is a business providing bolts and other parts in aluminum, titanium and almag (aluminum/magnesium alloy). Joe sells bolts, connecting rods and cover plates that are identical except for the material.

Jeff works for Joe. Jeff is an experienced craftsman who handles the anodizing of metal parts, where a different chemical mix is used depending on the material. He anodizes aluminum in blue, titanium in deep purple and almag in magenta so that it is easy to tell which parts are made from which material.

One day, Jeff gets a new helper: Joe's nephew, Sonny, who got hired on a summer job during college.

Jeff tells Sonny, "We're going to anodize today so let's start with the bolts... go to the warehouse and get the bolts." Sonny runs out and a few minutes later brings one big bucket of bolts on a parts cart.

Jeff looks at the bucket and says, "OK, which are these? The aluminum, titanium or almag? Where are the others?"

Sonny replies, "Oh, since they're all bolts I put them all in the same bucket." He reaches behind him to the parts cart and brings out two more buckets, "And here is the bucket of connecting rods, and here is the bucket of cover plates."

Jeff sighs. He explains to Sonny that different chemicals are used to anodize the different materials, so they can't all be anodized in the same batch.

The reason the aluminum, titanium, and almag bolts were kept in separate bins in the warehouse was so you could scoop them out in seconds into three separate wire buckets and then dip each bucket into the right anodizing solution for that material.

Now that Sonny has mixed them all together, they will have to spend all day carefully weighing hundreds of bolts one at a time to sort them, based on slight differences in weight, into three buckets for anodizing. Same with the connecting rods and plates. By poorly grouping his data, Sonny just transformed an easy fifteen minute job into something that will take many hours of annoying, error-prone work.

In this parable the key factor of interest in the data is the material (an attribute), not whether the part is a bolt (point), a connecting rod (line) or a cover plate (area). You could put all the aluminum bolts, connecting rods and cover plates together in the same bucket for anodizing with no problem. But mixing the aluminum, titanium and almag bolts together in the same bucket is a terrible data management error that leads to slower and much more tedious workflow.

to have Mfd 9's thematic formatting dialogue show values of object types (points, lines, areas if present) that do not correspond to the object type of the dialogue.

That's phrasing it in a way that takes you further away from understanding the reality. Thematic formatting is about fields in tables, not about object type. If you are using thematic formatting to sort out object types that are inefficiently mixed in the same table with attributes that don't make sense together in the same table, you are doing it wrong and you are missing a big opportunity to make life a lot easier.

What you have is a Contents pane that operates on the active drawing, which means it is operating on that drawing's table. The relationship is between the pane and the entire table. That's a good thing, because otherwise you could not have a Select panel with templates that apply to all objects, and you could not have a Transform panel that applies to all objects. It's also good that Style applies to the entire table. That makes the tool far more powerful.

For example, suppose you have a real estate business and you have a ForSale drawing that sometimes has area objects, for empty lots for sale, and sometimes point objects, for houses that are for sale. There is also a Price field and other attribute fields.

It is good that the Transform panel applies to all of the objects so you can quickly mark, for example, all Waterfront real estate as such, or all real estate in High Risk Fire areas as such, whether they are areas or points. Same with the Select panel. It's a good thing you can select all items above a certain Price, regardless of whether they are areas or points.

In that particular example, it's great that Style panel thematic formatting applies to attributes regardless of what type they are. You can color your drawing using a thematic format for Fill color that is based on the Price field, and if you choose sensible symbols for areas and points the effect will be very good, showing you by color where lots or houses for sale are higher priced or lower priced, without regard to whether they are areas or points. Sure, you have to copy the format you create to additional properties, but that is what one-click copy and paste are for.

So in your example of archaeological finds when the point symbol thematic dialogue displays that 50 objects fall into a particular interval the user must realize that it actually means there are 50 objects made up of an unknown number of points, lines, or areas. We would not want to display that on a map so we need to prep the data first to avoid this. At this point we are probably second guessing why put all the data in one layer.

I picked an example (a real life one) where it makes sense to have a mix of points, lines and areas in the same layer, because the user cares about the attributes, not about the object type. The object type is used to make finding the place easier in real life - it's not used to tell the difference between Roman sites and Gallic sites.

Suppose we have a map of archaeological locations in France, using a mix of points, lines and areas to mark various places of interest. Fields where towns used to be might be areas, visible stretches of roads might be lines and individual monuments like fragments of tombs or temples are points.

We have an attribute field called "Epoch" that can have values such as "Roman," "Neolithic", "Celtic", "Gallic", "Carolignian", "Unknown" and so on. All of our records have a value in the Epoch attribute, since that is what we care about.

Suppose we have a total of 50 objects that are Roman, a mix of Roman settlement areas, stretches of Roman roads as lines, and fragments of Roman buildings as points. In our thematic formatting we color all objects with a value of "Roman" in the Epoch field bright orange in the Fill color. We use sensible symbology so that Fill color is a distinctive element for all objects.

To use thematic formatting to do that in this map, you apply the same thematic format, coloring Roman items bright orange, to points, to lines and to areas. That's just a couple of clicks to copy the style in the mfd_meta dialog or in the drawing's properties. It works perfectly because we have an Epoch field in all of our objects, since that is what we care about.

We can easily organize a thematic format so that Roman items are bright orange, Celtic items are bright green, Gallic items are blue and so on. At a glance, we can look at the map and see where all of our Roman items are, so on our next road trip across France we can divert our path a bit here and there to visit some aqueducts, settlements, amphitheaters and temples on our way.

the point symbol thematic dialogue displays that 50 objects fall into a particular interval the user must realize that it actually means there are 50 objects made up of an unknown number of points, lines, or areas.

Well, sure, if the user cares about that. So what? In this example, the user cares about whether items are of a particular Epoch, not about how many are points or lines or areas. If the user cared about what were points, lines or areas, they could organize the data slightly differently. Not a big deal either way: the key is to match how you organize your data to what interests you.

We would not want to display that on a map so we need to prep the data first to avoid this.

I don't understand that. It's pretty obvious looking at a map what is a point and what is a line. In such applications (in the real life application from which the example is drawn, for instance) people typically use labels or symbol types if they want to show auxiliary info. For example, mark all temples with a "Temple" icon.

There are many, many ways to make maps as instantly readable as you want them to be, even if they contain a mix of complex information.

Consider the real estate example I gave: when I mix logically different object types together in the same layer that happen to have common attributes I will often create a second, computed Geom field to provide an option for common symbology. So, if I have a mix of parcels as areas (empty land for sale), or houses as points as "For Sale" records, I'll create a second, computed geom field that generates the inner centroid of areas. That gives me the ability to create a drawing that is all points if I just want a dot at each property for sale when I'm looking at an entire region. You can use different symbols for houses or for empty lots.

At this point we are probably second guessing why put all the data in one layer.

It all depends on what your objectives are and what is important to you. I've never second guessed mixing my archeology in France in the same layer using points, lines and areas, because I care about the attributes. I like looking at a map and in one glance seeing what is Roman and what is Neolithic.

Sometimes it makes sense to put all of your data in the same layer and sometimes it doesn't. If you are second guessing why you put all the data in one layer, that usually indicates you did not organize your data as well as you should have. Organize your data well to suit your purposes, and you won't be second guessing.

The example you give of having multiple different object types in the same layer where they don't logically align by attribute in terms of what you care about, and thus thematic formatting based on a given attribute becomes clumsy, is an example of where it is less efficient to mix all the objects together in the same layer. If you had them in different layers, you wouldn't be asking for the thematic formatting intervals to ignore some data that is in the table, you'd be effortlessly using the thematic formatting because your data organization would not be fighting what it is you want to show.

It is important to keep coming back to that key idea that the objective is to make workflow easier and quicker. The best way to do that is to organize your data effectively, which is what a lot of database practice is about. Poor data organization causes difficult workflow far more effectively than more sophisticated tools can save people from poor data organization. Don't be the workman who blames his tools for poor data organization.

Database people don't talk about concepts like "normal form" because they are pompous idiots, they talk about that stuff because such notions in real life can save them enormous amounts of time and free them from tedium. Applying such database insights to GIS can save a lot of time and tedium in GIS, too.

That the Style panel can apply specific visual styles to different types of objects is, indeed, a filtration. It is a very convenient filtration for the visual case where the stylistic, visual appearance of points, lines and areas really are different things: a point doesn't look anything like an area, so it makes sense to have visual controls which are specific to points and others which are specific to areas. But that is only one dimension of organization, and it is a different dimension of organization than groupings based on attribute values, which is what thematic formatting is about.

Can you intersect the two types of groupings? Sure, but hacking special cases into thematic formatting intervals is not the clearest or most orthogonal way of doing that. There are better ways that are more productive with less overall effort.

If you care both about attribute value and about object type, nothing prevents you from taking a few moments to arrange your data so that both aspects of what you care about are represented by convenient groups (layers).

Care about whether something is a line or a point? Easy. Put your lines in one layer and your points in another. Care about colors aligned to a specific attribute as well? No problem. Set up the thematic format however you like it, and then apply it to however many layers have objects with that attribute that you care about. That's what one-click copy and paste can do for you instantly.

Heck, if you want to apply the same thematic format to a thousand layers, use the Select panel to select that property for a thousand layers and then it is a one-click Copy to Selection to apply it to a thousand layers at once.

Could that be made even easier? Sure. One can imagine Copying a style property button and Pasting onto a different style property button as a way of copying and pasting thematic formats or static formats or whatever. There are endless small conveniences like that which could be done, with the usual question of just how many of them one wants to snowball into the UI knowing that at some balance point there will be endless conveniences that relatively few people ever learn or use.

My message is this: don't hack a powerful tool to try to get around poor data organization. That's a lost cause and is nowhere near as effective in making life smoother and easier as good data organization.

When your data is organized well to suit your purposes and your interests, you'll find that everything becomes much easier and things like thematic formatting will flow effortlessly. If you find yourself trying to hack around special cases, like the field you're thematically formatting against has no meaning for objects that you care about, that's usually an indicator that the problem is poor organization of data, not inoptimal use of thematic formatting controls.

Mike Pelletier


1,529 post(s)
#02-Nov-18 15:34

Okay I get it we should organize our data well. Of course that is a well beaten drum. On the other hand, Mfd's flexibility is a great asset and works well with the real world were unique circumstances might mean it might make sense setting up data in a way, perhaps temporarily, that isn't normal practice.

I get that values are displayed in the thematic dialogue not objects, but hey they are values attached to the objects which is what matters here. I get that we can do a copy/paste in the field to apply the color instead of the style pane. Fine. Actually no, this is great :-)

I also get that we might want to use one field to display the same color for points, lines, and areas all from one table. Absolutely. That is good.

In order to do the formatting with the style pane, we go to the controlling color button for each object type and apply the thematic formatting. Perhaps I'm missing something but is that not what we must do? If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?

If no efficiency is gained, then the question is whether it is better to display values for all object types in the thematic dialogue or not. If setting up intervals in the thematic dialogue for let's say points, is it more helpful to know what percentages of points are in each interval or the percentages of all object types? I'd say the former but a check box like Adam suggested below to switch between the two would be fine. If using unique values in the point thematic dialogue, do I really want to have an option to apply a color to values associated with lines or areas? That just adds clutter to the dialogue.

Dimitri

5,082 post(s)
#04-Nov-18 08:48

You raise good points as always. But you're making assumptions and stepping past a very big world of functionality as if it isn't there. So, to answer a simple question like this:

If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?

... I have to get into a discussion of that big world you've stepped past. The short answer is that filtering object types in the thematic format list is throwing away data, but it is data that you have declared is important to you. It wastes time and causes inefficiency to use powerful facilities to group data, in a way that you say is the essence of what you want to do, and to then throw away some of the data you say you want to see.

Given the possible confusion that seems to be in play here, it takes a fair number of words to clarify that. And there's none of this "Yeah, beating the drum about good data organization. I get that. Now let's ignore that drumbeat... " allowed if you want to get to the powerful logic of how to use the thing effectively. :-)

In order to do the formatting with the style pane, we go to the controlling color button for each object type and apply the thematic formatting. Perhaps I'm missing something but is that not what we must do? If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?

The Style dialog serves two purposes. It provides instant changes applying the same setting, and it also allows per-object changes using thematic formatting. When you apply thematic formatting, you're doing it to a layer where all objects are in there for a reason, because they all share the same intent of thematic formatting by a specific field. If they don't (like your Release 8 example), they don't belong in the same layer.

If you intend to apply a thematic format, mixing objects together in a layer to which your thematic format will be applied is a declaration on your part that those objects that have been mixed together belong together because they have a field in common where the variation in values in that field makes sense as a control for all of the objects in that layer. If that's not the case, it was an error on your part to mix the objects together in the same layer. Better to organize them in different layers.

The above is talking about thematic formatting. That's just one of the ways we might want to style objects. The other situation is where we just want to apply the same color or symbol to, say, all points or all lines. In that case you don't care about a common field value, but you just want to click on controls quickly to achieve some visual effect.

In both situations, there are controls which serve the same, or almost the same, function, so it helps to keep the same what controls can be kept in common, the old "orthogonality" bit.

To get back to your question, answering it from a slightly different approach:

Perhaps I'm missing something but is that not what we must do? If so, I don't see any time/efficiency being saved by not filtering object types in the dialogues for points, lines, and areas?

The "why" has a lot to do with two key intents: a) your intent in keeping areas, lines and points together in the same layer, and b) your intent in applying a thematic format to any of those objects.

The following is a key sentence, because habits in GIS have often been developed in a way that opposes efficient exploitation of data:

it might make sense setting up data in a way, perhaps temporarily, that isn't normal practice.

Consider key intent a), why somebody keeps areas, lines and points together in the same layer. This often is an example of "normal practice" in GIS that is opposed to efficient exploitation of data. That happens when people dump points, lines and areas into the same layer just for the convenience of keeping everything in one layer (turning it on/off, copying/pasting, etc.). and not because the areas, lines and points have any functional commonality in attributes.

Suppose somebody wants to mobilize a community action group to get more trees planted in a town. That person might create a layer - one drawing - for a town that shows the city council voting precincts as areas, the streets as lines, and many points that are a mix of points which show the locations of existing trees as well as the addresses of people who are ready to be volunteers to go out to knock on doors. He wants to get people organized in the various precincts of the various city council members to put grass roots voting pressure in action to get more trees planted. That's a mess of an organization to put data with four very different purposes into the same layer, but hey, people do such things all the time.

Historically, GIS packages have been wretched at data management, so that's one reason why you have so many forums full of people asking "hard to get there from here" questions because they did things like mix in all their volunteer points with tree location points. It is a well-beaten drum to say "organize your data with clarity", but because of the facilities offered in classic GIS it is also often a well-ignored drum in normal practice.

Setting up data with clarity and good organization, if your GIS package can handle it, is always a good idea as your foundation, not as a temporary measure.

In the case of 9, the unit is a project where you can have as many layers as you want. There is no need to artificially group dissonant objects together in the same layer, or, the obverse mistake to fail to group consonant objects together in the same layer, because of any artificial restrictions on grouping or lack thereof in the storage format.

If you choose to group your data into one layer, and you intend to apply thematic formatting to that data, then you darned well should have chosen the data to put into that one layer because it has values in fields that are the essence of your thematic format that are common to all of the objects in that layer.

In order to do the formatting with the style pane, we go to the controlling color button for each object type and apply the thematic formatting. Perhaps I'm missing something but is that not what we must do?

Yes, that's exactly right, and that is just as true for thematic formatting as it is for direct formatting. When you want to apply thematic formatting and mix areas, lines and points in the same layer, you do that because they have a common association in their attributes that you intend to use in a thematic format.

That association could be explicit, like all of the objects having a common field containing a value, such as the date the data was acquired, that is the same for all of them and thus it makes sense for all of them to be in the same layer, or it might be an implicit association, such as "OK, these are all the Ft.Worth objects in this layer, and the Dallas objects are in that layer over there..."

In such cases, any direct formatting you do is typically a one-click operation on symbology or colors or sizes where you just want all the objects of that particular type to be styled a particular way. It is very convenient in that case that you have controls that apply style by object type.

Thematic formatting is a very different case logically, because, while it also varies style properties, it varies them on the basis of a field as the primary control. If thematic formatting is your intention, you should not mix objects in the same layer which do not have the controlling field in common - complete with values in that field - that you intend to use as the guide for thematic formats.

If you vary the appearance of something based on a field, the value of that field better be something that you care about. If there are objects that don't have a value in that field (NULLs) or which are so alien that any mention of that field makes no sense with them, well, then they simply don't belong in that layer to which you apply thematic formatting based on that field. It's simply a mistake to have mixed them in. [I emphasize I don't mean "mistake" because of some abstract desire to be politically correct in DBMS theory, I mean "mistake" in the practical sense of causing yourself extra work and unpleasantness that is easily avoided by doing it right. It's like Sonny mixing all the different material bolts together in the same bucket.]

When you put objects into a layer that is to be thematically formatted by some field, you are saying "This field is important to me. It's what I care about, and what I want to show where and how it varies." You shouldn't be putting objects into that layer which don't participate in that field.

If using unique values in the point thematic dialogue, do I really want to have an option to apply a color to values associated with lines or areas? That just adds clutter to the dialogue.

That's a very good question, but you get a wrong answer if you assume it is OK to mix objects together in a layer where the mixing of them works directly against what you say is important to you.

First, it is not an "option" to show all records in a thematic formatting dialog. It is the primary reason to have the dialog in the first place. It's supposed to show all the records, because that's why you put them all together. [If you didn't intend to mix them all together but they all just fell into the same bucket without you realizing it, well... that's a different problem. Also solvable easy enough, but it's a different problem.]

When you mix points, lines and areas in a layer to which you intend to apply a thematic format, you are declaring two things: you are saying they all have some field in common with values that are important to you, and that thematic formatting based on that field makes sense despite the disparity in object type. If both of those things are not true, almost certainly you made a mistake mixing the objects together in the same layer.

That latter bit is subtle, but it is powerful, and it does frequently arise, for example, in cases where you might be changing areas to their centroids, areas to lines on the boundary of areas, or where you might be creating additional geometry in the same record, for example, having parcels in a record both as area objects and also as a computed field giving the inner center.

If the reply to the above is , "Well, gee, I didn't intend any of that and none of that is important to me. I just inherited this data the way it is and now I want to make some visual distinctions to what I care about with points."

To that I say, OK, easy to do it the right way: Take two clicks to select the points and put them in their own layer. You can now do what you want with the points without being distracted by having a lot of objects mixed in that don't have anything to do with what you want to accomplish. Takes less than ten seconds.

Suppose the reply is, "Well, fine, but I don't want to spend even ten seconds. I just want to hack at this right now and color points. 8 let me do that, by hiding any interval numbers associated with lines or areas."

I look at that and I ask, "what's the intent of coloring the points? Is the way 8 does it the best and easiest way?" As they say, the road to you-know-where is paved with a combination of good intentions and cutting-corners laziness, so it pays to take a moment to consider very carefully if you really do want to set foot on a path that very quickly might lead you into more of a mess.

If the reason you want to thematically format points has to do with an attribute those points have where it is important to you to use visual appearance to show differences in values in that attribute, and where the lines and areas really do not participate in that attribute, then most frequently it is a terrible error to not take a moment to move those points into their own layer. That is true for a long term reason and for a short term reason.

The long term reason is beating that drum about organizing your data clearly, having the foresight to keep your bolts of different materials in different bins and not letting a guy like Sonny mix them together.

The short term reason is to avoid having controls like those in 8 which show things not as they really are. If you do a thematic format on points with just, say, two intervals in 8 and it excludes the lines and areas, the numbers you see won't add up to the total number of records the table says it has.

That will be puzzling to anyone who thinks that a histogram reporting what is in a field should report what is in there, without silently ignoring some of the records. It will also be puzzling to those people who are trying to set up a thematic format for a table that is not yet fully populated, either because the points have not all be created or because they want to set up an arrangement that will continue to work as they want when areas and lines might later be changed into centroid points.

Such puzzlement is related to what are the best controls if, indeed, you do want filtration.

You might say, "OK, I get all that, but right now I have good reasons why I want to mix points, lines and areas together, and for the sake of convenience I really do want to see only intervals that have to do with points when I click the thematic formatting button for points."

What is the best control to do that? What's "best" isn't just what works in one special case, at the cost of confusing the dickens out of everybody else in other cases. The control also should not be something that assumes people aren't ever going to learn to do it right. It has to make sense for people who are doing it right, also.

In that context, I don't think the way 8 does it is a good approach: it automatically hides part of the data in the table, the records that have to do with lines and areas, when it computes intervals for points. By doing so, it shows "wrong" statistics for anybody who is also looking at the associated table that doesn't hide data for lines and areas. It also prevents you from setting up a thematic format for situations where object types change, that is, reducing capability, flexibility and orthogonality.

OK, so one approach is to put a filter button on it. That's explicit. But it is also slightly risky, in that beginners will have to learn to push that filter button, and any need to RTFM is a risk. And then you have to pay attention to the setting of a button in terms of understanding what you are doing.

An even worse risk is that it continues what 8 does, which is to encourage a too-loose approach to data, just hacking at it instead of taking a moment to structure it in a way that makes the task easier now and in the future. It's the old "Yeah, I should take a moment to fix this but right now I just want to color it...". As they say, "Nothing is as permanent as a temporary solution."

Compare that to a different way of providing a "filter button:" use the infrastructure that is already there, which requires no remembering of secret handshakes or button settings. If you want to format points in a thematic format without being confused by lines or areas that have nothing to do with those points, well, take ten seconds to move those points into their own layer. Done.

You then have layer structure, a really obvious infrastructure thing with no hidden machinery, that controls everything in a crisp, obvious, hard-to-get-wrong way. It also has the wonderful side effect of grouping data that has some commonality in what it means as data within the same table, so that naturally the shared meaning of data can be used for visualization, as in thematic formatting.

If the push back on that is a desire to share related thematic formats more easily between different layers, well, that's easy enough to do. It could be made even easier, as with a simple "Copy" on one style property in one layer and a "Paste" onto another. But that's a somewhat different theme in terms of how one can construct thematic formats for one drawing and then recycle some of that arrangement into different drawings.

So far, all this is talking around the edges. What really helps in nailing down some of these concepts is a discussion of real world data and real world tasks.

I want to emphasize there's no resistance of any kind to making anything easier and quicker. There's only the question of what is the best way to do that. There is also some understandable resistance to making one special case easier at the cost of creating misery in other settings, and a respectful insistence that if there is a very powerful way to do something desired that is easy and already there, to see if perhaps whatever is preventing that from being used can be removed, before introducing something else that may or may not be easier or better.

Mike Pelletier


1,529 post(s)
#05-Nov-18 01:39

Cool let's keep thinking on ways to make it better. One of the things I've loved about Mfd 8 (same in Mfd 9) is the flexibility for me to be me. I don't mind making a mess on my garage workbench in the interest of getting a job done fast or not knowing how big the job might become. I know that I'll clean it up later. Mfd makes it fast to clean up :-)

But yes let's talk real life GIS examples.

Years ago I set up a Mfd project for a weed sprayer. It made sense to sometimes collect info as points (small areas), sometimes a lines (sprayed from a truck along a road), and sometimes as areas (sizeable area of weeds). The same data attributes however was collected regardless of the object type. In this case it was nice having all the info in one layer to simplify data management for a GIS challenged guy and because it was connected to a data form.

So suppose I want to show all the lines formated by year. I don't want to include the areas and points. Sure there are lots of ways to do this, but I think the best is a new drawing attached to the same table (theme in Mfd 8) because I want to keep my existing formatting of the table. As I'm setting up the formatting, I don't want the areas and points to influence my decision making. So hopefully I can check a box that says to filter by object type. Good thing I did because no lines were created in 2007 and without the filter I might have created a colored line for that year even though no lines exist on the map. Yes I could inspect the table as well but this was quicker.

Another scenario that often happens is that time to make a quick one off map for someone. I pull in the usual layers: aerial, parcels, roads, etc. Then I add an area boundary line around the area of interest. Add some point symbols, some labels, some lines for arrows, etc. The project may grow into something bigger later so I definitely want to keep the work.

As I draw in the various object types I start formatting as well. Got to follow the inspiration and go fast :-) I keep it in one layer. There's not that many objects so I can use the unique value setting for applying the formatting based on mfd-id. When I'm looking at the format dialogue for each object I don't want to see values that are irrelevant so hopefully I can check a box that filters by object type.

Dimitri

5,082 post(s)
#05-Nov-18 08:20

So suppose I want to show all the lines formated by year. I don't want to include the areas and points.

There's nothing wrong with acquiring all that in one layer. It's directly analogous to my archeology example where somebody might want to mark sites as points, as lines or as areas.

The question next comes, "How do I want to use this data?"

If you care about the year for everything, then all objects have a common field [year] and there you want your thematic format to evenly cover all years, for example, showing a smooth gradation of colors from 2000 to 2018, or whatever.

Suppose you do not want that, but instead you really do want to have a [year] based thematic format that is restricted to only those years that appear for line objects. You also want to have a view, like a theme in 8, that just shows the lines. Easy: create a query called Lines that contains (assuming your drawing is called Drawing):

SELECT * FROM [Drawing]

WHERE GeomIsLine([Geom]);

Right-click that query and create a drawing, called Lines Drawing. Tell it the same coordinate system that Drawing uses when you create the drawing. Open that Lines Drawing and do a thematic format for lines. The only values for the [year] field it contains are for lines, since the query only has lines in it.

If you ever forget what the SQL should be in that query, just open your Drawing and in the Select pane choose the Lines template and press the Edit Query button... it will create that query above, the one you need to just select lines from the drawing.

It is usually best practice in situations like you describe to keep things you want to visualize separately using separate rules in separate tables, but you can simulate that by extracting those things on the fly from a common table using a query.

You could do the same as the above for areas and points, and then create a map using all three drawings-from-queries as layers, if you wanted fine control.

If you *must* for some reason create drawings directly from the same table, you can do that as well, but then you have to jump through some hoops in penance for mixing things together that logically you want to deal with separately. But that, too, is easy.

So, suppose you want to thematically format lines in a drawing that is directly created from the same table in which lines, areas and points are mixed. You want only a year field for lines to appear. OK.

Open the drawing's table and launch Edit-Schema, and then add a computed field called L-year (for "lines year") that is computed using this expression:

CASE WHEN GeomIsLine([Geom]) THEN [year] ELSE 0 END

Kind of a hack, but what the heck... It repeats the year if the object is a line, and otherwise puts zero for the year. You can then format the thing using transparent color for the 0 interval.

The easiest way to do what you want is to create "views" that are drawings built on queries, which extract the objects you want from mixed objects. That's your "filter button" in this case.

It's important to remember that when you mix data together like this, you end up paying the piper sooner or later. There's always a price that gets paid when data is stirred up in a stew. It's just that sometimes it doesn't seem like that price is paid because the workarounds have become very familiar and automatic.

As I draw in the various object types I start formatting as well. Got to follow the inspiration and go fast :-) I keep it in one layer.

As the opportunities to go faster in 9 become automatic, part of your muscle memory, you'll reflexively split things out into more than one layer, just for the speed and convenience that brings.

I do formatting based on mfd_id all of the time. It's a quick and convenient hack, but even better would be a one-click auto-color facility that would add a field and color on that so, say, adjacent areas were always a different color, etc.

Mike Pelletier


1,529 post(s)
#05-Nov-18 15:53

Sure writing queries works and has the benefit of keeping my head in the SQL game. It keeps the interface clean as well. That works for people who use the software often.

Still I'm a fan of a GUI that makes repetitive tasks easier and have sent in lot's of suggestions that way. Thanks for listening :-)

Dimitri

5,082 post(s)
#05-Nov-18 17:35

That works for people who use the software often.

Still I'm a fan of a GUI that makes repetitive tasks easier

Just one more thing to consider... promise to be quick.

It's easy to think of a button here and there as a quick convenience. But they add up, and then the remembering gets harder. If you have a simple, general purpose way of doing something, that's easier to remember than remembering how to work a GUI that grows more and more hair with more and more buttons to do special case things.

Consider the case of filtering thematic format intervals. OK, you can have a button for just lines. And then somebody wants lines and points. Someone else wants areas and lines. And then somebody else wants all three but only for those years where there are no points. I'm not making fun, I'm just saying people want what they want, and they're entitled to that.

With the same itty-bitty SQL they get whatever they want, and they don't have to master a GUI that tries to give them similar ease with combinations of buttons. So, if you use what really simple queries can do for you, well, you can do all that with ease just learning a little bit.

Mike Pelletier


1,529 post(s)
#05-Nov-18 19:08

Yup its a balance that Mfd has to find. My own personal taste is that currently too many common tasks are left to SQL in Mfd 9, for example simple statistics in tables, and that the GUI in general is more simplistic than it need be. Itty-bitty SQL requires quite a bit of background knowledge. That's fine for me but generally not for other Mfd users in my organization. Ah well, I'll cry uncle on this topic :-)

adamw


8,204 post(s)
#02-Nov-18 11:06

Okay, I thought it was probably just an oversight but I see now it is purposeful to have Mfd 9's thematic formatting dialogue show values of object types (points, lines, areas if present) that do not correspond to the object type of the dialogue.

So in your example of archaeological finds when the point symbol thematic dialogue displays that 50 objects fall into a particular interval the user must realize that it actually means there are 50 objects made up of an unknown number of points, lines, or areas.

We are not against filtering by object type.

What Dimitri's example shows is that sometimes you want to have no filter by type (when you are showing areas / lines / points which have to be formatted using a common attribute and that attribute has a common meaning for all object types - eg, when there are areas / lines / points for archaeological finds and you don't care which object type it is, you just want to paint year 2018 green and years prior to 2018 gray), and sometimes you want to have such a filter.

Right now, 9 never filters by type. 8 always filtered by type. Maybe we should add a switch to 9 to filter by type so that you have both options in 9. (However, frequently, as Dimitri says, the right approach is to split data into multiple different tables - depending on which attributes make sense for which objects - and then you mostly don't need to filter by type because all objects in a particular table are of the same type.)

Mike Pelletier


1,529 post(s)
#02-Nov-18 15:36

Thanks for the summary and consideration of a switch. See response to Dimitri above.

lionel

476 post(s)
#02-Nov-18 11:22

Hi

what is very nice is that all style properties can be use has a theme. In mfd8 theme icon button don't appear for size and font so really nice !! When use theme i mean applys style refer to the diferent value of a column . And what is really nice ....people can now create their own font style in PUA range using glyph editor !! the best tool are for mac is glyphs and for windows dektop there are tools that cost a lot and not ergonomic . inkscape support a little ( test it in the past ) but perhaps now more instead using illustrator . Web tool do more and the best for web designer are fontawesome ( label name see in the video) and icomoon . Create SVG icon can be done using SVG edit ( available in bluegriffon )

1) Don't test ( TODO test) but does all font must be in OS level or can we import font locate near the manifold gis project .

2) Rotation can be rotation of shape or rotation of pattern ( TODO test) here it seem only on shape

3) Can we add rectangle around text content ( TODO test ) , it seem yes for icon but for list of glyph icon ( character ) ? .

4) when add vector icon inside a file font format ( ttf ...) , Does a name ( file name or custom) can be added inside the ttf file . In the video when use more option we can't select icon by name ( there is no input form text filter for icon name ).

i don't know about pattern ...( TODO test) for area point line ...

regard's


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

adamw


8,204 post(s)
#02-Nov-18 13:36

1 - fonts currently have to be installed.

2 - rotation for areas rotates area pattern, rotation for points rotates point symbol (and labels get auto-rotated when following lines, which rotates both text and things that surround text).

3 - yes, there is a style option to paint a rectangle around text.

4 - are we talking about filtering a list of characters available in a font by name, in the style editing dialog? If so, we are looking to allow this for standard symbols since they have names, and maybe synthesizing some names for font characters (they don't have any built-in names stored in the font file, but there is always a character code).

lionel

476 post(s)
#02-Nov-18 18:57

here video that show convert one svg to ttf ( only the end is usefull , 80 % of timeline is about create a svg shape ) .here video to edit glyph in a context of custom police use ina website . good tutorial here. manifold 9 become awesome


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

lionel

476 post(s)
#04-Nov-18 13:31

here good tutorial too about illustrator and icomoon and good capture screen to understand the way vector line should be appear in a drawing to be compatible with font and reference axes in illustrator artboard : https://www.sitepoint.com/create-an-icon-font-illustrator-icomoon/


join image "Because my dad promised me" interstellar from Manifold: Time by Stephen Baxter. power Math destruction

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