Subscribe to this thread
Home - General / All posts - Things I don't like in 9
dchall8
436 post(s)
#13-Feb-18 16:36

A couple weeks ago I made the comment that there were several things I did not like about 9. Adam asked about what those were, so here we go.

To be fair there is a lot I like about M9, but Adam asked me to go into what I do not like. So there is no balance to this listing. I suspect a lot of what I don't like are features under development. Other things I don't like may be from the fact that 9 does not seem to want to emulate the way 8 worked. We've been over this before, but some of the work flow in 9 seems to take more clicking around than in 8. Also the rapid development may have rendered some concerns on my list to be obsolete or overcome by events.

General:

Cannot export a drawing or table to Manifold 8. Exports to other legacy GIS formats presumably work, but not to Manifold 8.

Drawings

1. Right-click in a record in a drawing doesn't open a context menu.

2. Clicking on a feature in a map does not activate the bottom row tab for that feature. I use that feature in M8 all the time as a shortcut to select elements from different tabs.

3. When selected for editing an area, the vertex points are too small to see

4. Lat/Long data not available in drawing. I was getting XY data instead of lat/long.

5. Deleting a drawing from the Project Pane does not delete/refresh the map or Layers Pane. Clicking Refresh does not delete/refresh the map or Layers Pane.

6. Ctrl-x,c,v, and z not working in drawings.

7. A drawing layer is opaque within itself even when opacity is not 100%. User cannot see a shadow of underlapped records hidden behind an overlapping record.

8. Unable to select a record in a drawing or table and zoom to the record in the map or drawing.

9. Once a record is selected for editing, user has to click out of the map into the Contents>Record>Coordinates element before points can be moved.

10. Alt-click selects a record for editing in a drawing but Shift-Alt-click does not deselect it (but Shift-Ctrl-click in the record deselects it)

11. When a record is Alt-clicked to select for editing edit in a drawing, once the Coordinates pane is selected in the Record pane, the record cannot be deselected in the drawing. Also cannot select another record without deselecting the editable record first.

12. When creating a new triangle area (for example), a redundant coordinate is created at the origin following a right click to end the drawing. Instead of having the 3 coordinates of a triangle, there are 4 coordinates. If you move one of those redundant coordinates, the resulting area appears to have 4 coordinates; however, a 5th coordinate has been created at the new location of the moved coordinate.

13. Snapping only works when drawing, not when selecting.

14. The Undo shortcut (Ctrl-Backspace) is a change from the 30+ year old standard of Ctrl-z. Ctrl-Backspace requires letting go of the mouse, seeking out the backspace key, finding the mouse again, and moving to the next object to be deleted.

15. When a point is selected to be snapped to, the indicator becomes a small, dark blue, open box around the selected point. If your color scheme is dark and earth tones or with Google Maps in the background, the blue square is very hard to see (both tiny and low contrast).

16. The thin, crosshair, pointer style gets lost in a drawing. Even small movements don't appear in peripheral vision if you are looking at a different corner of a drawing. Crosshair has shadow now.

17. Outlines of parcels dim along with fill color. For example set fill opacity to 40% and the outlines also go to 40% gray. Outline should have it's own opacity setting.

18. No handy toolbars.

19. If two areas overlap and you try to select the top one, both are selected.

Tables

1. Relating and un-relating multiple tables requires knowledge of SQL.

2. Lat/Long data not available as a field in table. There is probably a way to make a computed field from the geom.

3. Once a computed field is created, it cannot be modified. To change a parameter the computed field must be deleted and created with different parameters.

4. Clicking the Add button to add a new field to a schema does not preview the new field in the table. Only after clicking OK does the table change, and once OK is clicked, the field Expression cannot be edited.

5. Clicking the Add button to make a new field in Schema resets the width of all the fields in the table.

6. Ctrl-click selects a record in a table but Shift-Ctrl-click does not deselect it as it does in a drawing.

7. Selecting or deselecting records in a drawing does not refresh the table filtered to show only selected records. You have to nav up to the View and refresh the filter to update the table.

8. Making a universal change to a table field across many selected records requires a cumbersome transform rather than simply typing the new value and having all the selected records changed (a la Manifold 8).

9. There's no apparent field showing record selectedness in a table. I use the Selectedness of an element to change style on selected records. There may be a way to create a Selected field using the geom, but it needs to refresh automatically.

10. Filtering within a table is done with a right click to context menu. Clearing a filter has to be done from the View menu.

11. Filtering on text 'starting with', containing, etc. requires knowledge of SQL.

adamw


7,903 post(s)
#13-Feb-18 16:48

Thanks a lot for the list!

Some of the items are indeed something we are planning to change or fix and some are being worked on already. I have a couple of questions or notes regarding other items, I will try to post them later (in some cases we are doing things slightly differently and I am not sure if the new way is worse or just not very apparent).

Again, thanks for the list, it is very useful!

Dimitri


4,843 post(s)
#13-Feb-18 17:52

Great list! Don't forget to send in Suggestions for what you want changed, to how you want it to be changed.

Some notes...

9. Once a record is selected for editing, user has to click out of the map into the Contents>Record>Coordinates element before points can be moved.

10. Alt-click selects a record for editing in a drawing but Shift-Alt-click does not deselect it (but Shift-Ctrl-click in the record deselects it)

These two are related. To go into immediate edit mode, Shift-alt-click an object. You can then immediately drag vertices about.

11. When a record is Alt-clicked to select for editing edit in a drawing, once the Coordinates pane is selected in the Record pane, the record cannot be deselected in the drawing. Also cannot select another record without deselecting the editable record first.

Not exactly. Click the value tab to release the "safety" hold Coordinates puts on editing. Then you can deselect, alt-click on another record to select it and so on. Coordinates is a safety, so you can move the main display about, panning and zooming it, in the middle of an editing process. You can even switch to a different drawing window and work there, then come back to the prior window and the editing session is still intact.

12. When creating a new triangle area (for example), a redundant coordinate is created at the origin following a right click to end the drawing. Instead of having the 3 coordinates of a triangle, there are 4 coordinates.

Yes, that's how area objects are created I think in pretty much every vector GIS. The area is "closed" by the final vertex that is the same as the first one.

If you move one of those redundant coordinates, the resulting area appears to have 4 coordinates; however, a 5th coordinate has been created at the new location of the moved coordinate.

That's always a judgment call, how to provide the ability to insert a new coordinate or to just move the start/end together, in terms of what the default is. If you want to move both together so the initial point is moved without adding another vertex, you can of course do that.

14. The Undo shortcut (Ctrl-Backspace) is a change from the 30+ year old standard of Ctrl-z. Ctrl-Backspace requires letting go of the mouse, seeking out the backspace key, finding the mouse again, and moving to the next object to be deleted.

Ctrl-Z means Undo. It's not a "cancel" like you see in dialogs that give you a choice of OK, Cancel or Apply. You can only Undo with Ctrl-Z something you've done, not something that you are getting ready to do, have not yet done, and now decide you do not want to do. When Manifold allows an Undo, Ctrl-Z will be the key for that.

Until then, Ctrl+Back is not an UnDo like Ctrl+Z... it is a "cancel" since the operation is just a preview and not done until you confirm you want it done. If you don't want to take your hand off the mouse, right click and choose Undo Changes. It's captioned "Undo" Changes because that's shorter than "Abandon Changes" or "Cancel Changes" and only four characters like the accompanying Save Changes. I suppose even shorter would be "Cancel" or "Apply" captions.

18. No handy toolbars.

Instead, there are handy panes. :-)

2. Lat/Long data not available as a field in table. There is probably a way to make a computed field from the geom.

Lat/long data is available as a field in a table. Keep in mind that what one person wants for lat/lon for an area or a line is not what somebody else wants, as opinions strongly differ as to how that should be.

Yes, you can get that from the geom, in a trivially easy way if you are using lat/lon coordinate system (see the example topic). It can also be done for projected coordinate systems, but in my view that should be made easier with a packaged function to extract lat/lon so people don't have to use a complicated expression.

5. Clicking the Add button to make a new field in Schema resets the width of all the fields in the table.

? Haven't been able to duplicate that. Are you using the latest build?

6. Ctrl-click selects a record in a table but Shift-Ctrl-click does not deselect it as it does in a drawing

Correct. Shift-Ctrl-click in tables is used for the extremely useful swath selection technique: ctrl-click a record and then Shift-ctrl-click some other record and you select all in between as well.

8. Making a universal change to a table field across many selected records requires a cumbersome transform rather than simply typing the new value and having all the selected records changed (a la Manifold 8).

That's a highly contentious feature in 8, as some people love it and other's think it the world's worst trap for the unwary. You wouldn't believe the anger that feature inspires when folks forget they have something selected that is scrolled offscreen and then when they change a cell in the one selected row they seen in front of them they don't realize/remember a thousand other selected items offscreen have also been changed. Despite very long familiarity with it I've had that feature bite.

The Transform can be very quick, by the way: click the Expression tab and enter what you want the field to be. You do have to put it in single quotes, which I don't like, but it does have the tremendous value of previewing what is about to happen, a really super way of avoiding errors.

The things which make such work faster are always the contentious features. For example, you could have autoscope on by default, so that if there is a selection in the table the Restrict to selection box is automatically checked, and if there is no selection that box is automatically not checked. People who like autoscope love that, but people who dislike autoscope really hate it.

Likewise, you could autoscope the target field to whatever column header is picked out (darkened) by the cursor position in the table.

Last, perhaps we could add a new template at the top of the list for a default, captioned (value) where whatever you entered into a box would be taken as a literal. Transforms are about to be reworked to make it easier to enter literal (hate those single ' quote characters around text literals...) values. If you had autocontext to whatever was the current column and a default of (value) with a box open that you could enter stuff into, well, that would be very, very quick and not at all cumbersome, plus it would still have the benefit of delivering a preview for one last chance at review before error.

11. Filtering on text 'starting with', containing, etc. requires knowledge of SQL.

? Just use the Select pane. No SQL required. Filter on the selection. Personally, I'd like to see more dynamic updating of filtering in tables, so you don't need to re-apply the filter. That's coming.

dchall8
436 post(s)
#13-Feb-18 19:49

Thank you for the background, corrections, and tips to correct my usage of 9.

I use lat/long fields in M8 to sort a selection of parcels for numbering. Neighborhoods here are numbered from north to south or west to east. Having the lat and long fields makes it easy to sort the records in any direction and use the numbering tools to number the records in a batch mode. This ability seems to get me jobs that ESRI shops don't want to do.

5. Cannot duplicate in 165.2.

8. I absolutely rely on that contentious feature of changing all selected records at one time. I remember I hated it the first time I made that 'mistake,' but I quickly adapted and now rely on it. Maybe there could be a switch to turn this feature on in a global Options setup window?? Here's how I use it every day in M8. We have two people in the office finding properties to be combined, so these come at me pretty steadily. These are adjacent properties going into one account number (PID). I have both the map and table open with the Selection Filter button clicked (first thing I do when I open a table). 1) Select (click and alt-click) the properties to be combined, 2) click the table to make it active, 3) find the PID I want to change all the parcels to and double click. Done. I can easily do 10 of these in 10 minutes which includes finding the parcels to be combined. Here's how quickly it goes in 9, assuming both map and table are open. 1) click the correct tab for the drawing layer to be changed, 2) alt-click the areas, 3) click the table to activate, 4) go to the View menu to filter only the selected records, 4) pick the Transform pane from the drop down menu in Contents, 6) select the PID field from the drop down menu of fields, 7) select the Expression tab, 8) quadruple click the field to highlight the entire field, 9) Ctrl-C to copy, 10) type a ' and ctrl-v to paste the PID value followed by another ', and 11) click Update Field button. Done. I hope I missed a short cut in that process. The process in 9 seems like a step backwards. The final step in M8 is to Union transform on the drawing to make one record out of the two. If I fail to change the PID numbers first, Manifold will inevitably use the wrong PID to create the one area.

11. Oops! Sure enough they're right there.

Dimitri


4,843 post(s)
#14-Feb-18 05:19

seems to get me jobs that ESRI shops don't want to do.

The highest of all callings! You can do that with 9 as well. However, you haven't mentioned how it is that you like to tag an irregular area with just one lat/lon number. I suppose you use a centroid of some kind. But, as every experienced GIS operator knows, there are different types of centroids.

Adding lat and lon columns to a table is easy. The absolute easiest way is to keep your parcels drawing in lat/lon, create a centroid geomof the desired centers type, and then based on that centroid geom (a point), add two columns, one for latitude and one for longitude, as set forth step by step in Example: Create a Geocoded Table from a Drawing.

It's just a short use of a couple of functions:

VectorValue(GeomCoordXY([Geom], 0),1)

for latitude and

VectorValue(GeomCoordXY([Geom], 0),0)

for longitude.

You don't have to know why those work to use them. Just copy/paste. See the extra note below if you don't want to keep your parcels in lat/lon projection.

If you do this a lot, have a project that's full of helper resources, like imageserver data sources you like, data layers you use frequently, and comments components full of stuff you like to copy/paste. Leave that project open in a Manifold session on your Windows desktop so you can copy/paste things you need out of it into your working session.

When I do projects I always have some Manifold session running in the background. When I want to launch a new Manifold session, I don't chase around to try to find the latest build's folder with an .exe in it to double click on, I just right click on that Manifold icon that is sitting in the Windows taskbar for the open Manifold session and I launch a new session right from there.

Likewise, I'll use the taskbar to find and to jump to an open session of Manifold that has something I want. If there are snippets of SQL or functions I use, I try to avoid re-keyboarding them. Better just to copy/paste. It's also convenient to have an older version of a project open when I'm doing ambitious things to a newer version of the project. If I do something wrong, like accidentally mess up a bunch of areas, I can get back to the earlier version just by copying the table out of the open session with the older version of the project, deleting the messed up table in the working session with the newer version, and then pasting the copied table into the working session.

You can even do that with an individual geom for an individual object. Mess up the object? No problem. Copy the geom cell for that record from the old version's table and paste it into the geom cell for that record in the new version's table, and the thing is restored to how it was.

Maybe there could be a switch to turn this feature on in a global Options setup window??

8 has that switch. The theory is that people will set the switch to how they like it and then leave it like that, so no heartburn. The reality was that people would go back and forth with changing the switch and then forget how it was set and got bitten. If you went back and forth using different settings of the switch, as workflow would frequently require, you had to check what the tools options setting was to be sure you were doing what you wanted. That's a delay (which doesn't happen if a checkbox is in front of you).

The commitment in 9 is to make such things more transparent, with forewarning if possible. I think a few minor adjustments to the dialog would make it as fast or faster than 8 to do analogous workflow and also way less dangerous.

By the way, perhaps you don't realize it, your comparisons between 8 and 9 are distorted in that you give workflow for 8 which incorporates multiple steps into one, but then in the equivalent for 9 you break out those steps individually. It looks like you are grinding an ax trying to make 9 sound more complicated instead of providing an accurate comparison.

For example, with 8 you start with

I have both the map and table open with the Selection Filter button clicked (first thing I do when I open a table).

But then with 9 you itemize

1) click the correct tab for the drawing layer to be changed

Well, heck, if you have a map open in 8 you also have to click the subject tab to get context. It's the same in both. Likewise, you'll have the table open in 9 too. If you are going to itemize those steps for 9, itemize them for 8 as well.

You are also shortening the process for 8 by not mentioning various clicks and enters, and you are following a less-than-optimal flow for 9, doing roundabout steps, doing extra work, and not doing it the way someone who is familiar with the process would.

Suppose my task is to put the same PID (I suppose that is short for "parcel ID") number from a central parcel into three or four other parcels that are adjacent. The quickest way to do that is to use the drawing as an interface, and not mess with a table at all. Alt-click the central parcel and the Record - Values tab automatically pops open, showing the PID for that parcel. Right-click on that and choose Copy, which is a one-click Copy in 9. Alt-click on the desired adjacent parcel and right click on the PID for that parcel and choose Paste, which is a one-click Paste in 9. Done. It's quicker to do that with one or two parcels than it is to use selection in tables in 8.

If you have many parcels, then sure, you can use selection. With a few ctrl-clicks select the parcels that are to have the same PID. Alt-click the central one and Copy the PID out of the Record - Values display that pops open. Click the Transform panel expression tab, check restrict to selection and enter ' Ctrl-V ' and hit the Update button.

By the way, if you do this on a regular basis the Restrict to selection box will already be checked, since it will have been remembered from the previous few dozen such maneuvers. You only check it the first time. It's not an extra click in such repetitive workflow.

Anyway, the above works directly against the drawing, with no need to open up tables unless you want to see a preview in the table. If you are comparing it to 8, well, since 8 doesn't do previews let's make it an apples to apples comparison and look at the workflow in 9 without popping open interfaces that give you a preview. It's no big deal to leave a table floating open but if you want to do it in the quickest way possible you can save yourself that small step.

For extra credit:

There are often many ways of doing the same thing in 9 (likewise in 8, of course). If you don't want to keep your parcels table in lat/lon, but you like the convenience of very simple expressions to generate latitude and longitude fields in the table, you can have your cake and eat it too.

1. Put your parcels drawing into whatever projection you want, say, some State Plane coordinate system the state or county insists must be used. No problem.

2. Use Edit - schema to add a geom field to the table. I call such fields Geom_center, so I can tell what they are supposed to be next month when I come back to a now-forgotten project.

3. Use the Transform panel to put whatever is the desired form of centers from the Geom field for the parcels into the Geom_center field.

4. Create a drawing using the table and Geom_center. Open the drawing and change the projection to lat/long.

You now have the super-cool situation of a table that has two geom fields for each record. One has areas and the other has centers for each area. The areas geom uses the State Plane projection and the centers geom uses lat/lon.

5. Create latitude and longitude fields using the Geom_centers field.

What is nice about the above is that everything is above board and transparent. No secret handshakes, no magic numbers creating lat/lon from... ? what? What is going on is perfectly visible. If you want to order your parcels using the lat/lon fields in the table, you can do so, and if something unexpected happens you can even pop open the centers drawing to see how maybe an unexpected "center" for a highly irregular area is the cause of a strange result. When such calculations are buried behind the scenes in the computation of an intrinsic field, such revelations are harder to get.

It's true that 8 provides the illusion of fewer steps, but I write "illusion" because you are giving up choice. It's like when you are traveling and you open up google.com in the airport in Beijing when changing planes and it gives you everything in Chinese. Sure, that's one step less for local people but it is also the wrong result for a foreigner just changing planes who wanted google.com, not the local Chinese google. Yes, it is fewer steps if the software guesses for you and you are willing to accept what it does behind the scenes - fewer steps until what it did was not what you wanted.

tjhb
8,010 post(s)
online
#14-Feb-18 05:32

You don't have to know why those work to use them.

Poison.

Consider the case where X uses Manifold's Latitude / Longitude, and Y uses a fake Google projection (which shamefully is the Manifold 9 default).

Chaos.

Wash your mouth out Dimitri.

(You are also leaving datums out of account, which have massive importance even when things seem "the same". Really inviting disaster here.)

Dimitri


4,843 post(s)
#14-Feb-18 05:49

Are you saying the example cited as written does not work?

Are you saying that applying these snippets against a drawing of points in latitude / longitude projection won't work?

VectorValue(GeomCoordXY([Geom], 0),1)

for latitude and

VectorValue(GeomCoordXY([Geom], 0),0)

for longitude?

Don't grind an ax that confuses the innocent. With seriously expert techniques you could poison a coordinate system so that a geom used numbers from one coordinate system in X coordinates for points, say, degree-based lat-lon values, while using numbers from a different coordinate system in Y coordinates for the same points, say, meter-based pseudo-mercator systems.

But that situation has to be contrived. Neither Google nor any other user (use now is universal for essentially all web servers) of Pseudo-Mercator provides a mix of X coordinates that are degree based and Y coordinates that are meter-based. Just does not happen.

Likewise, data provided in latitude/longitude does not mix up degree based X coordinates with meter based Y coordinates. The "consider the case" situation you raise is a false strawman because it does not occur in real life.

No, you don't need to know why those snippets work against lat/lon data to be able to use them. If people really needed to know why things worked to use them, nobody would use smart phones and most people would stay away in fear from touching anything that used electricity. Wise people who thoughtfully apply electrical insulation to cords and use plastic, non-conductive materials for wall switches have made it safe for people to use electricity who don't know how it works.

Likewise, those snippets of functions will work every time with latitude / longitude data, without the operator understanding why they work. Much of GIS is like that: people click buttons and copy and paste without knowing exactly why it works. That they can often do more with greater understanding I do not deny, but I don't "make the perfect the enemy of the good."

As for Google's "fake" projection, it is no more fake than any non-formulaic projection, such as the Robinson or the US 50 States and similar, some of which our patron saint J.P. Snyder himself cobbled up. The key question is whether it is reproducible with desired accuracy in transformations to and from other coordinate systems, which it is.

I don't see any shame, by the way, in adopting as one possible default a projection which is used by perhaps a million to one margin over any other. Why is it shameful to offer as a default a coordinate system that in real life is used by a million to one margin over any other? You may quibble with the million to one bit, but surely the universal use of the web for presentations is easily 100 to 1 greater than whatever the much, much smaller GIS community is doing compared to Internet.

tjhb
8,010 post(s)
online
#14-Feb-18 05:56

Dimitri, you are so far wrong I have no idea what planet you live on.

Please, re-read Snyder.

Do not skip a word (as you are so fond of saying to others).

I will try to respond point by point tomorrow.

Dimitri


4,843 post(s)
#14-Feb-18 05:51

(You are also leaving datums out of account, which have massive importance even when things seem "the same". Really inviting disaster here.)

Given that implicit fields in 8 completely hide all that, exactly how is the above comment relevant to a comparison of implicit lat/lon fields in 8 with computed fields using the recommended code snippets in 9?

How does using those functions in 9 invite disaster more or less than using implicit fields in 8? It's a puzzling comment so I'm asking that as a purely technical question.

tjhb
8,010 post(s)
online
#14-Feb-18 06:04

As I said, I'll try to comment point by point tomorrow.

But latitude / longitude coordinates depend crucially on what coordinate system they are measured in.

Mostly they depend on the datum.

Encouraging anyone to ignore the importance of these factors (and just copy and paste) is worse than reckless.

Dimitri


4,843 post(s)
#14-Feb-18 07:25

I respectfully remind you this thread is about how workflow in 9 compares to 8, with the initial post setting forth specific workflow in which the 8 way is preferred to 9. That is a fair and important topic to raise.

The discussion is comparing the use of latitude and longitude computed fields in 8 to analogous computed fields in 9. It is not about other issues, and using expertise to toss in factors that apply identically to both 8 and 9, but which do not differentiate the workflow in 8 or 9, are red herrings that end up confusing the innocent.

The following comment is a perfectly true factoid that is a red herring in this thread:

Mostly they depend on the datum.

Yes, sure. What does that have to do with comparing workflow using intrinsics in 8 or the computed field expressions I suggested for 9? Nothing.

Whatever datum is used for the latitude / longitude coordinate system, if a lat / lon system is used, has identically the same effect on the intrinsic field values surfaced by 8 for latitude and longitude as surfaced by those expressions for the computed field values in 9.

Given that a user who is fond of intrinsics in 8 probably is unaware exactly what centroid those represent for an area (inner, weight, etc.) talking about datums (a far more nuanced point at much finer levels of detail) is just using expert insight for... what purpose?

If you want to play that game, I respectfully submit that the 9 way I advocate is more respectful of datums and other details. After all, I suggested the data first be projected into lat/lon if it is not already in lat/lon. Doing that takes whatever coordinate system it was in and re-projects into some explicit choice of lat/lon, which includes an explicit choice of datum. People might not pay attention to it, but it is there.

That is more explicit and transparent then the 8 way where if the data is not in lat/lon the intrinsic field derivation is for everybody but one in a million a black box. Quick: for those who are experts: what are all the parameters of the lat/lon coordinate system in which latitude and longitude intrinsic fields in Release 8 are reported? When is the last time even maximum experts ever dug into 8 lore to discover that info?

Tim, if you really do have some significant technical reason why the specific expressions I gave for the recommended process in 9 is "worse than reckless" while using intrinsic fields in 8 is not "worse than reckless" I'll look forward to reading and to learning from your detailed discussion tomorrow. Until then, as far as I can tell, for all practical purposes when comparing the 8 way with the 9 way the two approaches are equally good, bad, indifferent, reckless, worse than reckless, or brilliant, but both in the same way.

If that's not what you meant, but instead you intended to express a general notion, albeit a big fork away from the discussion in this thread, that there is more than meets the eye to "latitude and longitude" coordinates, well, then please start another thread to express such notions as they are way off topic here where already our colleague is not too certain how to do an analogous thing in 9 that he is doing in 8. No point in adding confusion by discussing extraneous things that do not bear directly on the specific differences between 8 and 9 in this workflow.

It is, of course, doing good work to try to remind people that latitude and longitude numbers are not enough, as the Latitude and Longitude are Not Enough essay illustrates. So I do not mean in any way to discourage you from trying to help educate people on such matters. Just please start a thread for such topics since in no way has any of what you mentioned, at least as far as I can see, differentiates use of intrinsics in 8 with the cited use of computed fields in 9. Let's open just one can of worms at a time, and let's not mix those cans of worms.

tjhb
8,010 post(s)
online
#15-Feb-18 22:52

It's not worth responding point by point--especially as you keep creating new points.

It's sufficient to say that I over-reacted to your initial statement:

Adding lat and lon columns to a table is easy. ...

You don't have to know why those work to use them. Just copy/paste. ...

You were wrong in making those latter statements, and yes, I would still say reckless, likely to cause damage to data if anyone took them to heart. It would have been better if you had just acknowledged your error and withdrawn the statements (perhaps posting your link to the "Latitude and longitude are not enough" essay earlier, since that is the exact antidote), rather than protesting in a series of rants.

But that's us.

Dimitri


4,843 post(s)
#16-Feb-18 05:33

I would still say reckless, likely to cause damage to data if anyone took them to heart.

Overreacting or under-reacting is easy, I grant, but the above seems to me to be a well thought out statement that is seriously intended, not on the spur of the moment. It raises serious issues that should be respected. I respect what you write so if you write something could cause damage to data I am intensely interested in learning more.

I honestly do not see how using the computed field equivalent in 9 to computed fields in 8 is any more reckless or more likely to cause damage to data than the use of 8 computed fields. (That such built-in computed fields in 8 are called "intrinsic fields" does not make them something other than computed fields... they are still computed, just in a hidden, built-in way)

I'm always up for learning something new and being corrected when in error. So... please, give me an example how adding lat / lon columns as I described for a 9 alternative to 8 intrinsic fields is any more reckless or more likely to cause damage to data than the use of the equivalent 8 intrinsic field.

I should pause to respectfully remind you that at no point did I say "you don't have to know why these work, and you don't have to copy and paste them as written... make up whatever you want...". I wrote "copy/paste," as I do agree that accurate use of the expressions as recommended and as set forth in the documentation is essential to correct function.

By the way, this forum is a conversation... if points related to a discussion are raised that bear on the discussion, all that is fair game. If you think any such points are wrong, I encourage you to set forth a correction. Calling a specific series of points a "rant" is an ad-hominem attack that, I feel, is beneath you.

I'm eager to hear you reasons for, apparently, thinking that computed fields in 9 are a reckless act while computed fields in 8, apparently, are not a reckless act. It could be I misunderstand your view, in which case a technical discussion would help with clarification.

tjhb
8,010 post(s)
online
#16-Feb-18 06:10

Dimitri you are one of the five or six people I most respect in the world. (I could go to 10 or 12 if we can include the deceased.) Nothing you could say could ever change that. That's probably why I tend to argue with you extremely frankly. Just so that's clear.

My only point--really--was that you seemed to be saying that it is fine to copy and paste latitude/longitude values without understanding them. It seems clearly that you didn't mean to say that. But the notion that you were saying so raised every allergic node on my skin.

It's as simple as that.

I don't think we actually disagree.

Sorry.

tjhb
8,010 post(s)
online
#15-Feb-18 23:14

[I'll leave other discussions for later.]

dchall8
436 post(s)
#14-Feb-18 17:11

As usual there is a lot to process and learn from your post.

As for my step by step between 8 and 9, I think I got it right. With 8 I can click on a parcel no matter which tab is active. The active layer changes to the parcel layer and the parcel is selected. Of course I have to avoid clicking on higher level elements I might also have open. But in 9 I have to ensure the correct tab is active first. If it is already active then I could eliminate step 1 in the 9 list making steps 1-3 in 9 the same as 1-2 in 8. I will practice the short cuts you suggested using the drawing.

However, you haven't mentioned how it is that you like to tag an irregular area with just one lat/lon number.

Excellent point. For the neighborhoods I have drawn the areas are largely regular. The attached map shows my typical starting point. Originally there were 21,481 lots in that subdivision. Each lot is 25x90 feet with 30-ft roads. So it is easy to select a row of blocks, sort them by lat or long depending on which direction the numbers go, and use the transform toobar in 8 to assign block numbers. Then when I create the lots they are numbered the same way. This is a very rough explanation, but the point was to illustrate the regularity of the original drawing making it easy to sort by lat/long.

Attachments:
Avalon 1959.tif

Dimitri


4,843 post(s)
#15-Feb-18 05:51

With 8 I can click on a parcel no matter which tab is active. [...] Of course I have to avoid clicking on higher level elements I might also have open. But in 9 I have to ensure the correct tab is active first

That is a good example of trade-offs, different approaches to where you want to spend your time. Here is why it is how it is in 9:

With 8 you don't click the tab but then with every click after that you must be attentive to not clicking on something else in another layer. With 9 you do click the tab but there is no need after that to pay attention to layers.

Consider how that works where you start doing the work just once, but after that you have very many clicks.

With 8, every time you click you have to pay attention to other layers. With 9 you pay attention just once to click the tab and then you can click away without worrying about clicking in other layers.

Needing to pay attention to layers with every click is way more tiring and ultimately more time consuming than needing to pay attention to layers on just one click, the first click.

The 8 way has utility in cases where you have a very busy map with zillions of layers and you only want to click just once. In that case, it can be handy to click on something you see and to have the system auto-activate the layer. But if thereafter you must click on things in that busy map where they might be close together all you need is one mistake and you've just burned more time than the 9 way.

Even worse, it's easy with 8 and that feature to make a systematic mistake, where a dozen or so clicks into the procedure you've accidentally clicked something similar, but in a different layer, and then only some time thereafter do you realize that for the last, unknown number of a dozen or so clicks you've been clicking into and transforming the wrong layer.

Sometimes, "less is more," and there are very many examples of workflow where the 9 approach, first choosing the layer to which you want clicks constrained, requires less attention (= less stress and less mental energy expended) and less time overall, plus results in fewer errors. Overall that is better in sufficiently many cases that the mode for 9 is constrained to the active layer.

So it is easy to select a row of blocks, sort them by lat or long

I see what you are doing, but the sort by lat/lon presupposes you have a lat/lon for each area. The question is... where did that lat/lon come from? Is it a corner of the area? A centroid? If it is a centroid, which of the three common centroids is it? (see the illustrations in that topic).

I get it that with very regular parcels such nuances may not matter much. But even with a very regular Avalon layout, there are tricky situations like the following:

In the above (click the picture to make it bigger) you have some wildly intermixed parcel numbers, like 9 then 109, 111 and 35, not in sequence. When parcels are less regularly shaped, with weird, serpentine, or crescent shapes you get other effects.

I know you are just using this as a helper in workflow, so no doubt you've seen where it helps and where it hurts, but I don't think it hurts to know explicitly where the lat/lons come from that you are using as a proxy for ordering parcels.

"Avalon," by the way, is a very ancient name. The original derivation from ancient Celtic means "apple orchard."

Attachments:
avalon_detail.png

ColinD


1,863 post(s)
#15-Feb-18 06:52

To be fair, there are Restrictions available in 8 preventing clicks or selections of objects in a layer. Will 9 select an object that is under another layer if clicked through that object. That isn't available in 8.


Aussie Nature Shots

Dimitri


4,843 post(s)
#15-Feb-18 09:05

To be fair, there are Restrictions available in 8 preventing clicks or selections of objects in a layer.

Very true, but those require more clicks. If the complaint is a single click on a tab in 9, then more clicks with 8 to get a similar effect is not what someone who complains about the single click is seeking.

There's also the issue that when you put restrictions on layers in 8 they end up being "secret handshake" settings that are not immediately obvious if you forgot how you set them. You have to check. Sure, they are useful, and sure there are interfaces such as layers panes that can show such status. But it is still better if you can get to a "less is more" arrangement where there is no need for that.

Will 9 select an object that is under another layer if clicked through that object.

Yes, it does, ignoring objects above the hidden one in layers that are not the active layer. I just tried it.

A gentle tweak: that is trivially quick to try for yourself to see if it does or doesn't. Please try it, and then you can report what it does. :-)

ColinD


1,863 post(s)
#15-Feb-18 10:31

A gentle tweak: that is trivially quick to try for yourself to see if it does or doesn't

Ha! I was on a computer without 9


Aussie Nature Shots

Dimitri


4,843 post(s)
#15-Feb-18 13:31

Ah... there's a Viewer for that situation! :-)

KlausDE

6,170 post(s)
online
#13-Feb-18 18:40

14. The Undo shortcut (Ctrl-Backspace) is a change from the 30+ year old standard of Ctrl-z. Ctrl-Backspace requires letting go of the mouse, seeking out the backspace key, finding the mouse again, and moving to the next object to be deleted.

On a german keyboard with 'z' where you find 'y' you needed pianists hands for <Ctrl><Z> and a <Ctrl><Backspace> is easier with the left hand typing <right Ctrl><Backspace> - especially alternative to <right Ctrl><Enter> to accept edits. So I like this combination better.

I want to add

20. I'm to quick for grafic editing and the system loose points.

Bernd Raab30 post(s)
#13-Feb-18 19:24

<!--[if gte mso 9]> <![endif]-->

<!--[if gte mso 9]> Normal 0 21 false false false DE X-NONE X-NONE <![endif]--><!--[if gte mso 9]> <![endif]--><!--[if gte mso 10]> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Normale Tabelle"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0cm; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} <![endif]-->

To alter tables in M8 I can right click on the column-title and get a menue for editing name, format, transfer rules and adding fields, fit titles. That is what m8 makes very cool.

In M9 I have first to got to schema, then click on a field to change the name - I cannot change the format, especially this is bad for german date format. To add a new field i must click <new field> give it a name, give it a format and then i must cilck <add> and then <ok> to do the changes – more clicks than in M8.

So I would like to see a right click on a column-title with all the possibilites as we have in M8.

What is cool in M9 – I can easily create computed fields, easier than than the active columns in M8.

geozap73 post(s)
#23-Feb-18 16:53

1. I don't like that the "plus boxes" that show/hide a drawing's table, or a label that is a child to a drawing are missing.

2. I don't like the preview in the Contents/Transform panel. It can be confusing, and in many cases I thing it is useless. At least, there should be a "show preview" checkbox, to let the user decide when preview is needed.

I am using Viewer 9.0.165.3

adamw


7,903 post(s)
#26-Feb-18 15:24

Regarding previews, we might add an option to turn them off.

If the previews for some transforms are confusing, though, we'd like to fix that. Could you elaborate a bit on what specific transforms are we talking about and what happens?

Thanks a lot for the note.

geozap73 post(s)
#27-Feb-18 12:37

On example of confusion is this: You open a drawing (Drawing A), you go to Contents/Transform templates and you select a Transformation. You preview the result. If you return to the Project Panel and double click the Drawing A, you see the posisble result of the transformation, even thouth you have left the Transform panel. You have to open another component, to "refresh" the view and see the actual Drawing A as it is now. One may easily confuse himself and think "when did I press "update"?".

Gerenaly, instantly changing what the user sees on screen when the user has just selected a Transformation may confuse new users.

Most imprortant, I thing that preview is usualy useless, except when the visual result has to be apealing to the eye. But that's not the most common case in GIS. For example what's the point in previewing centroids? You just need them for some reason. What usefull information does preview give, and who cares about how do centoids look? Would anyone change his mind on whether on not centroids are needed by looking on the preview?

I think previews should be shown only when the user asks for them. Better that an option to turn them off in general, there could be a "show preview" button in the Transform panel.

adamw


7,903 post(s)
#27-Feb-18 12:46

You open a drawing (Drawing A), you go to Contents/Transform templates and you select a Transformation. You preview the result. If you return to the Project Panel and double click the Drawing A, you see the posisble result of the transformation, even thouth you have left the Transform panel. You have to open another component, to "refresh" the view and see the actual Drawing A as it is now. One may easily confuse himself and think "when did I press "update"?".

Going to the Project pane and double-clicking the same drawing A that is already opened in a window that is currently active will just switch back to that window. If you opened a different component, it wouldn't have the preview. You can remove the preview without switching windows, just switch to a different pane under Contents or stay in Contents - Transform and set the transform to '(no action)', the topmost choice.

The preview allows you to make sure you are doing the operation you want with more or less the parameters you want. Ie, with centroids, there are multiple types of them and maybe you don't want the centroids on all objects, just on the selection. The preview allows you to eliminate a lot of mistakes before they are done. This is especially true if you are doing a particular operation the first time and / or are trying to fine-tune the values of some parameters.

All that said, we aren't against an option to turn the preview off.

Thanks for the note.

cab75 post(s)
#19-Mar-18 13:28

M8 is still No. 1

Dimitri


4,843 post(s)
#19-Mar-18 15:14

Depends what you do.

For example, I don't known anybody who thinks less speed is better than more speed. Do you really prefer taking 18 hours to do something in 8 that 9 can do in seconds?

Some recent examples reported by Adam:

Test 2.

Build 12 contour areas on 3,600 x 3,600 pixels.

Manifold 8: 14.365 sec.

Manifold 9: 1.068 sec with 8 threads.

Test 3.

Build 10 contour lines on 21,500 x 21,600 pixels.

Manifold 8: 1646.015 sec. [Almost half an hour]

Manifold 9: 28.431 sec with 8 threads.

Test 4.

Build 11 contour areas on 21,500 x 21,600 pixels.

Manifold 8: canceled after 12+ hours, would have likely finished in 18 hours.

Manifold 9: 44.999 sec with 8 threads.

Test 5.

Trace areas on 10,300 x 7,300 pixels.

Manifold 8: 969.668 sec to trace a single (biggest) area.

Manifold 9: 7.471 sec with 8 threads, to trace all 250+ areas.

[That last one is 16 minutes for just one area as compared to around 7 seconds for all 250 areas. ]

A few more items...

Do this video in Release 8, and tell me how long it takes you to open 110 GB of images in a Release 8 project: https://www.youtube.com/watch?v=Gvib5LqqE2o

Is it absolutely instantaneous like in 9? Can you pan and zoom instantly like in 9?

How long to do this in 8? https://www.youtube.com/watch?v=T_IbHfCgCSU If you could get the data (8 cannot) it would be far, far longer than in 9.

My point is simply this: 8 is great, but it ain't 9. Hands down 9 is way faster than 8, and it can do far, far more with data than 8, grab data from way more data sources and way easier than 8. If there is something you don't know how to do in 9, sure, then for you 8 will be easier. If 8 does something not yet done in 9, then sure, 8 will be better. But 9 is just getting started.

The smart thing is to take advantage of 9, and to join in on molding it to be what you want. If there is something you use in 8 not yet in 9, speak up. Get your priorities into the pipeline. Other people are, so why not join in?

cab75 post(s)
#27-Mar-18 01:06

M8 is slow compared to M9

but more user friendly than M9

ColinD


1,863 post(s)
#27-Mar-18 01:38

But M9 is getting there!


Aussie Nature Shots

Dimitri


4,843 post(s)
#27-Mar-18 09:06

M8 is slow compared to M9

but more user friendly than M9

Again, that depends on what you are doing. For many things 9 is not just faster, it is way more user-friendly than 8.

How is 8 easier and more user friendly in what you are doing? What should 9 do in those specific cases for you to say "hey, now 9 is more user friendly"?

I respectfully point out that participating in this forum is buying into the requirement for mindful discussion - if people ask a question when you post, to clarify the context or to better understand your remark, you have an obligation to follow up. This is a discussion forum, not a place for fire-and-forget one-liners.

9 does many things easier than 8. Anybody who's learned 9 can give examples that are a real pain, or impossible, in 8 and totally easy in 9. For all that, 8 still does a few things that are easier than 9.

At the same time, big, sophisticated products like either 8 or 9 serve a very wide range of users and applications. There are people who use them for lightweight tasks, almost as a replacement for Paint or a personal data manager, and there are people who use them for mind-bending sophisticated, enterprise level tasks. Some people who use either 8 or 9 are beginners at just about everything. At the other end of the power user curve are people who are maximum experts in all sorts of Enterprise stuff. The characteristics that make either 8 or 9 "user friendly" in one setting for one group of people might make them totally not "user friendly" in a different setting for other people.

Adobe Photoshop is a good example of that. It is a product that is totally famous among beginners and people who don't RTFM as a truly horribly not user-friendly product. At the same time it is totally famous among people for whom it was designed, grown ups interested in a full power graphics arts package, for hitting the sweet spot in terms of being profoundly user friendly in making it exceptionally easy to do all sorts of wonderfully fantastic things.

Does the Adobe user community, together with Adobe engineers, care about making Photoshop even more powerful and even more user friendly? Of course. They take that very seriously and are very eager to discuss any and all improvements. But if you want to participate in that discussion you have to do more than just say "it is not user friendly." Improving a sophisticated product like Adobe Photoshop, or, for that matter, 8 or 9, requires a fairly significant level of mindfulness and attention to detail.

Along with many others, I helped design 8 so I'm quite proud of what my colleagues and I accomplished with 8. It's a heck of a product with very good balance for what it is intended to do. There is no way anybody will ever offend me by praising 8.

For all that, part of what 8 does well comes from limitations within 8 that are acceptable within 8's mission but which are less acceptable given how GIS is evolving. GIS is evolving not just into the need to handle much bigger data, but also to handle far greater complexity in terms of how that data is used and shared. GIS is also becoming more sophisticated as it interacts to a greater degree with more sophisticated parts of computing, such as DBMS.

9 already is much better at such things than 8, even now, long before 9 is anywhere near the level of finish it will have in two months, in four months or in eight months. Already today, in cases where 8 is totally intolerable and unusable, 9 is a joy to use.

I don't mean just raw speed, either, although of course raw speed is a big deal. For example, 8 is not just "slow" in many instances of modern GIS tasks compared to 9, it is completely unusable. When something is too slow to be used, well, it's not at all user friendly.

For all that I would be the first to agree that if you are happy with how 8 does things and 8 meets all your requirements, don't worry about shifting into something new. It takes a special kind of stupid to toss out a trusted and spectacularly useful tool just because one has successfully used it for years. But, if your requirements are evolving and especially if your requirements are evolving as the art and practice and business of GIS is evolving, then it makes sense to learn how to use new tools to fulfill those new requirements, and to participate in ensuring that as those tools evolve they evolve in directions that are to your taste.

Anyway... please tell us what you are doing and how, given that workflow, you find 8 to be more user friendly than 9. That is a very positive thing to do for two reasons, one selfish for you and one a matter of generosity to this community.

The selfish bit is that if you describe what you are doing it could be you've missed something in 9 that makes your task far easier. Other people here can offer tips and you might discover that "Whoa! It's way easier in 9..."

The generosity bit is that if you discuss the ins and outs of what you are doing and how 8 is more user friendly, that gives other people the opportunity to think on that and to in turn contribute their ideas. Quite a few of those will end up being suggestions, steadily increasing the user friendliness of 9 for the benefit of all.

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