Subscribe to this thread
Home - General / All posts - How to get Viewbot-like readouts in Release 9

7,452 post(s)
#28-May-24 03:59

Viewbots are a popular feature in Release 8. I wrote the following in reply to a post in another thread where it is hard to find, so I thought it might be useful to repeat it here at the top level...

It's easy to use queries to implement the power of Viewbots in 9 but in a more general and more powerful way than in 8. There's a tradeoff between the very simple interface in 8 and the limitation of power you get with that, and the more difficult but far more powerful analogous capability in 9, but if you want to do simple things you can keep a few projects lying around with snippets that make it easier in 9.

There are three ways of doing Viewbot-like things in 9 that first come to mind:

1. Use computed fields. Much of what Viewbots do is to provide per-object computations and readouts, and those can be done with computed fields. If you want the areas of polygons, created a computed field that is powered by the expression GeomArea([Geom], 0). See the Computed Fields topic for many examples.

2. Create labels that include expressions. For example, you can have a computed field called [AREA] that gives the area of a polygon, or you can just create a label for which the text of the label is

Area: [[ GeomArea([Geom], 0) ]]

where the portion within [[ ]] doubled brackets is an expression. That's a more casual way to generate a readout than creating a computed field and then creating a label from that computed field.

3. Create a drawing from a query where the query does some wonderful SQL that computes the value a Viewbot would. Next, create a label from that drawing, add it as a layer in the map that contains the original drawing of interest, and put it in some visible spot in your map to report the output of that query. Or, you can just open the map in a second, small window with it zoomed to where you have the label that reports the output of the query to get a "readout in a floating box" effect.

An example

We have a drawing layer of polygonal areas called Parcels which has a computed field called Area that reports the area for each parcel. We don't really need that computed field but I've included it so that in illustrations each parcel can be labreled with the area, so we can see how the Viewbit (I'll call it that in 9) reports a correct result.

We want a readout that shows the largest area of any of the parcels in the drawing. If we change the size of a parcel or add or delete parcels it should update itself.

Here's a screenshot that shows my Parcels Drawing with a few other open windows as well:

This is what I did to create it:

1. Create a new drawing called marea (for maximum area) and drag and drop it into the Parcels Drawing window as a layer.

2. Create a single point in the marea layer where I want my Largest Area readout to appear.

3. Create a query called mquery that contains the SQL text:

-- $manifold$


That query (as can be seen in the results table) creates a table with two fields: a Geom field that just contains the geom for the single point in the marea drawing, and an aliased field called [MAXAREA] that contains the single value that results from the SQL statement


Note that when we put together a field like this for a table we can use a SELECT statement, but if we were to create a computed field within a table we cannot use a SELECT (I don't think...) but have to use a simpler expression.

4. Create a drawing from the mquery query. The geom that comes in from the marea drawing is in Pseudo Mercator (I created the marea drawing using default settings) so that's what we use for the drawing.

To learn all about creating drawings from queries, see the Example: Create a Drawing from a Query topic.

5. I added the drawing created from the query, called mquery Drawing, as a layer to the map window that shows the Parcels Drawing just to make sure it did, indeed, create a point at the desired spot, but that's not necessary.

6. Create a new Labels component called Maximum Area from the mquery Drawing. The text for that label is

Largest Area: [MAXAREA]

When you add the Maximum Area labels component to the Parcels Drawing window, it reports the value for the MAXAREA aliased field from the drawing created by the query.

7. If you change the size of the polygons or otherwise modify them, the Largest Area readout updates:

If it is inconvenient to have to pick a spot for your readouts in your main map that will always be in view, you can just open the Map window in a second window, undock that window and just park it somewhere on your Windows desktop in view. That will allow you to put your "viewbit" readouts in a part of the map far away from your working space, and to zoom the second window into just those portions.

The above technique, creating a field in a query which is generated from a SELECT that is later reported in a label is a very useful and powerful technique. Because SELECT statements can be very, very extensive and powerful, they allow you to do all sorts of things that cannot be done with Viewbots.

Read the topic on creating drawings from queries to learn how to do things like reckon only those objects that are selected, so you can use this technique to create viewbits that report results only for, say, selected objects. The possibilities are pretty much endless, so long as the result of that SELECT is a single number which can then sensibly be reported in a readout. But that's the same limitation you get with Viewbots so overall you get more power.

This post also reports a technique, reporting the result of a query as a label, which is useful in other circumstances. For example, suppose you want to see the current results of a query, perhaps a big complex query that reports some parameter of interest in a database of fleet vehicles or website you are monitoring. You can put that into a label in map, create a location zoomed into that label, and then when you want to see what the query result is just view the label. Since it has the map as context it pops open and you see the value.


3,412 post(s)
#28-May-24 12:53

Now imagine the potential if you allowed Manifold Server to to retain the state of selected object (you first have to allow selections in the first place):

  • Include a separate frame as part of the browser display, with the data linked to the map.
(the “view bots” can now be shown on a side panel on the Internet)

  • Added a simple pie or bar chart capability to the styling
(dynamic pie and bar charts that provide summaries can be shown on a side panel, or even over the spatial object on the map)

  • Allow a query object on the server to reference the map display extent
(You can now have a label showing summaries of every item in the map display - either for the entire extent, or just the objects on the screen when zoomed in)

Those 3 things, along with the selection state, probably comprise 90% of what most users show in a dashboard or Esri Experience. I don’t believe it is a large engineering effort to add that, and it opens up a ton of analytical capabilities.


7,452 post(s)
#29-May-24 08:49

what most users show in a dashboard or Esri Experience. I don’t believe it is a large engineering effort to add that, and it opens up a ton of analytical capabilities.

That's a new topic different than what Viewbots do in 8 or analogs in 9, but what the heck, let's dive into that. Let me respectfully disagree with you before I move on to agree with you...

Respectfully, whether the above quote is true or false doesn't really bear on whether Manifold should do that or not in 9. More essential questions are...

  • Are there other approaches, which already exist, that people who want to do such things would prefer?
    • Do significant numbers of existing 9 users want to do that?
    • If such features were added, would that recruit significant numbers of new 9 licensees?

    That first question bears upon the last two, especially because the answer to it is yes, there already is a lot of dashboard-creating software, both commercial and open-source. You can also do much of the three points in the post with Manifold's Release 8 IMS, a very affordable solution.

    Most such packages have no problem connecting via ODBC to Manifold data sources, so you can use them out of the box for all sorts of dashboard and/or analytic wonderfulness using Manifold data sources just as you might Oracle, SQL Server, PostgreSQL, GPKG or other data sources. Most such packages also have very rich feature sets, with the better ones making Esri Experience look poor in comparison. Tableau comes to mind as an exceptionally spiffy analytic/exploration package.

    The commercial vendors spend hundreds of millions in promoting their dashboard solutions, and open source folks apply their usual enthusiasm for whatever package they like. It's not an easy market to get traction in. To do what you want Manifold would have to get traction in that market for the project to be worth doing.

    After all, why would a Tableau user replace Tableau with a Manifold experience if the Manifold experience was much poorer? Esri users are welded into Esri so tightly it takes extraordinary circumstances, like necessary capability Esri does not have at all, for them to consider alternatives. An alien package that is only 90% analogous to Esri is not enough.

    The same logic applies for open source dashboard/analytics packages: why should their users stop using what they already love when they can continue using exactly the same thing with Manifold? That it could be easier with Manifold? For many open source users, the greater complexity of use and deployment of their beloved package is not a bug: it's a feature that underpins their identity as a more sophisticated user.

    It might seem that adding superficial things like simple pie charts or bar charts is not rocket science. That's true in that it doesn't involve inventing any new mathematics, the way parallel work sometimes does. But that doesn't mean that it doesn't require a lot of experience and skill and the investment of much calendar and labor time to do it well. It's also not just engineering but vast amounts of time doing supporting work like encoding very many palettes, symbols, and similar design element infrastructure.

    Manifold is certainly as capable at that as anyone, but it would require very large amounts of resources and time invested in things that any contemporary tech company could do just as well, and much of it would be reinventing the wheel by duplicating the approaches used by market leaders like Tableau. It would require investing large resources into work where Manifold does not have some unique ability that others do not. Warren Buffett would tell you that's a huge strategic mistake: he likes to invest only in projects where the company has some barrier-to-entry advantage others do not.

    I agree with him. I think Manifold should prioritize effort in areas where Manifold can do something that others cannot. That seems more important than diluting effort by spending a lot of time reinventing existing wheels that easily can be obtained off the shelf by anybody or just as easily (or even easier) reinvented by anybody else.

    So now that we've answered that first question with a big "Yes," let's move on to answering the other two key questions based on that first answer.

    Do significant numbers of existing 9 users want to do that? - Apparently not, because if they did there would be threads in this forum talking about the various open source or commercial packages that can already do that today with Manifold.

    If such features were added, would that recruit significant numbers of new 9 licensees? - Highly unlikely, because those people who want to do such things already have solutions they know and love, and they're not going to spend money to switch to something from Manifold unless it is seriously better than what they already know and love.

    But that's not likely because premises in the original quote are not really in play. A few simple features are not enough, and creating a starter set of acceptable features is a huge effort. It also would not open up new analytic features that you can't do today with SQL in Manifold or with existing dashboard / analytic packages that can connect to Manifold data via ODBC.

    If dashboards / analytics package features are a good thing that significant numbers of existing Manifold users really want or are something that will result in significantly greater uptake for 9, I respectfully suggest a better approach would be to pick one of the better commercial or open source packages and provide information and examples on integrating with that package.

    That's what Manifold did with Kobo for field data acquisition, and it worked out great. Leveraging the Kobo ecosystem has delivered a mature, worldwide, rich solution to Manifold users. The slight amount of engineering work done to provide easier integration is less by orders of magnitude compared to the work that would have been required to cobble up some proprietary Manifold competitor to Kobo. Leveraging Kobo also has the good vibe of working together with decent people in a common cause, and not competing against them and making their good work harder.

    I'd also suggest that the first test on whether it makes sense for Manifold to invest time into such a project is to see if anybody takes a look at using existing dashboard / analytics packages with Manifold and reports their experience or asks questions about it in this forum.

    I get the feeling from anecdotal evidence that those people who are into such things are already doing that, and those people are not bringing it up in this forum because it's one of those specialty tasks that people do and don't think about otherwise. I don't get the impression anybody already using Tableau deep in some giant corporation who happens to be harvesting Manifold data sources is going to launch threads about that in this forum. They're also unlikely to ever see this post and comment, given that it's buried within a Viewbots titled thread. :-)

    For all that, I've always thought such packages were cool. When I find time I'd like to see how existing options work with 9. Art, maybe you could turn some of your students loose on an overview project like that?

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