Subscribe to this thread
Home - General / All posts - Pan to selection in M9
596 post(s)
#15-Aug-19 03:23

As far as I can tell this function is not available as of (Aug 2019). If I select a single point in a table and then use a map to zoom to selection, then it zooms out the whole world. It should maintain the current scale and pan to place the point at the centre of the view. Another compounding issue is that for rare flora and fauna, the coordinates for observations are often truncated, so stacks of points are present at locations which have coordinates with round numbers (usually degree or 0.1 degree precision). It seems that if I select a point using the table, which happens to be in a stack of points and it is not the top point, then there is no red selection mask. In combination, these issues make it really hard to find points of interest.

596 post(s)
#15-Aug-19 05:11

Got a system half worked out. Firstly I have to select the stack of points on screen using Ctrl-click and drag. Then I can Alt-click on the stack to show the records pane and can select 'move to only selected records' option. Using this combination, I can cycle through the records in the stack. I can also use a filter on 'Selected' records. This lets me investigate the contents of one stack at a time.

What I would like to be able to do is see how many stacks have Square-tailed kites. I though that I could use thematic formatting to make different icons for selected records.

I tried to make a query like

SELECT * FROM [qrySpeciesLocationsWitheld] CALL Selection([qrySpeciesLocationsWitheld],true);

That I could create a dynamic layer on but don't know how to make it work. If I could create the layer, I could put it on top of the layer with the stacks and then see stacks that contain the species of interest.



5,620 post(s)
#15-Aug-19 06:49

Then I can Alt-click on the stack to show the records pane and can select 'move to only selected records' option. Using this combination, I can cycle through the records in the stack. I can also use a filter on 'Selected' records.

There's an illustration of the above technique in the Example: Edit Covered Objects topic.

The basic problem is that stacking multiple points on top of each other using identical symbols is a good technique for breaking a visual user interface that depends on items of interest being visually separate.

It's a bit like police asking a witness to pick the robber who mugged them from a lineup of suspects, but then putting a bag over all the heads so the witness cannot see their faces: that breaks the visual user interface upon which the lineup depends - you cannot identify that which you cannot see.

If you have a data set that gives coordinates for rare flora with truncated coordinates that have too low resolution to show where the rare flora are located, well, that may be useful for some purposes, such as aggregating counts of flora per region or per country, but it's no longer useful for identifying specific locations of individual examples.

There are ways to extract what you can out of such data. For example, you can write SQL to generate summaries that show locations of co-incident point objects and attach to each such location a count of the number of coincident points. Create a bigger, green point for such locations and use that as a layer under your other points layers. That will highlight locations where you have "stacks."

Another technique is to use different symbology for different items within a stack. For example, suppose you have an oak, a pine, and a linden tree at exactly the same location. Use a long, skinny triangle for each in a thematic format that rotates each to a different angle and colors each differently.

The result of the stack will be symbols that do not completely overlap but which instead are visible by virtue of their different rotation no matter where they are in the stack. To get more emphatic differences, you could also vary the Move and offset parameters in addition to Angle for each different symbol in the thematic format, so they are offset away from each other at different angles and thus not overlapping at all.

How to do such thematic rotation is illustrated in the Example: Point Style using Move and Rotate topic.

596 post(s)
#15-Aug-19 10:43

Thanks Dimitri,

I got close with the use of thematic formatting to show items hidden in the stack of symbols but it does not work. The orchid is at the bottom of a stack of 46 symbols. It does not matter than I assign a 20 point dot to the orchid to make it expand out beyond the margins of the other symbols, it still does not draw.

I have also tried selecting the points in the drawing and pasting them as a new drawing but I get a table rather than the drawing I want.

I have also tried just writing a select query and selecting only one species, which works but I can't get a drawing based on the table to show any features, even though the query returns rows with a geom column.

I am also wondering how to get a filter applied to a table to reflect in the drawing based on that table. That is if I filter for one species, surely the dependent table should respect that filter.

I am currently working on a guess machine no my own, so I am using viewer and not my machine which has a licensed full version of manifold. I also thought that if I could create a couple of valid use cases for viewer, I could spread a few copies around the ESRI dominated company I work at.

Steep learning curve over here!



8,775 post(s)
#15-Aug-19 12:38

If several points are on top of each other in the same drawing, rendering is going to omit some, that's on purpose. We don't have a way to specify which ones to omit vs which to keep at the moment, that's on the wishlist for future additions.

What specifically does not work with writing a query to select specific points and creating a drawing based on that? If you provide a sequence of steps you are following, we can look at it. Alternatively, post a MAP file with a drawing, say which points you want to keep vs which to hide, and we can show how to do that.

If you have a filter applied to a table and you want it reflected in a drawing, you can (a) invoke View - Filter - Filter using Query in the table window to express the filter as a query, this will open a new command window, (b) invoke Edit - Save as Query in the command window to save the query text as a query component, (c) create a drawing based on that query (right-click the query component in the Project pane, select Create - New Drawing, etc).

PS: When you create a drawing based on a query, do you specify the coordinate system of the geometry field? The coordinate system that the field is going to use is shown in the New Drawing dialog. You should set it to the same coordinate system as for the original table.

667 post(s)
#15-Aug-19 14:32

I have a similar situation. We track mobile homes by their address. In a mobile home park all the homes have the same address with a different box number. I use BatchGeo to locate the addresses, export results from BatchGeo to Google Earth, and import the kml file to Manifold 8. For me the coincident points has not been an issue, because I don't necessarily care that there are multiple points at the same location as long as a search for the ID number sends me to the right address.

596 post(s)
#16-Aug-19 00:17

A subset of the data I am working with is posted below. It is publicly available BioNet data supplied by the State of New South Wales Australia. To see the issue, import the data and make a drawing from it and then select all the 'Sooty Owl' records. I have attached a screen clip of the the result below.

In response to Adam's comment that not all points are rendered. I think that is fine as long as the selected points are rendered on top of the non-selected points. That way if any selected point is rendered, it will be obvious that the stack of points contains at least one selected point.


596 post(s)
#16-Aug-19 00:42

Regarding converting the filter to a query and then creating a drawing on the query, I did this for 'Sooty Owl' and the query returns the correct numbers of rows but the drawing is empty. I am setting the projection to be the same as that which was set for the original layer (lat-long).

I agree with Dimitri about changing the data model but that approach also requires writing queries that can support drawings.



5,620 post(s)
#16-Aug-19 05:40

that approach also requires writing queries that can support drawings.

True, and that can seem daunting at first, but it is one of those things where, as the adage has it in some cultures, "the eyes are afraid but the hands do the work." It looks scary but it turns out to be simple if you just do it.

Creating a drawing from a query is easy: it's the same as creating a drawing from a table: right-click the query and choose Create - New Drawing and the dialog is the same as for a table.

OK, so that leaves writing a query from which a drawing can be created. That's easy too. All you need is a query that includes a geom field from the table(s) it uses.

For your task, you want a query that grabs only selected items from the original table (or drawing... same thing). That's a one line, simple query:

SELECT * FROM CALL Selection([Mexico Table]TRUE);

Every step for using the above query to create a nicely-styled drawing is simple but to help out when you do it the first time every step is covered in the Example: Create a Drawing from a Query topic. I recommend downloading the Mexico example map and then repeating the example.

Here's your setup for your task: the original drawing with many stacked points is your lower layer in the map. Above that in the layer stack is the drawing created from the query above, styled so that any points in it are big and brightly colored and can't be missed.

When you select points in your original drawing's table, they automatically appear as points in the drawing created from the query above any stacked points, because they are created by the query in a drawing layer that is above the original, full of stacks, drawing.

Using a query is a simple way to put selections above any stacks, using the data model as is. So it is limited by the data model. For example, if you select in the table two or three species which happen to have observations at the same spot you could end up selecting two or three points in the same stack.

That will generate two or three co-located points in the query results, and thus in the drawing created from the query. The query-generated drawing will show a bright dot at that location, but you won't know if it is just one point there or a stack of two or three co-located points.

I can think of various contortions (like using more than more drawing generated from a query when you want to simultaneously select more than one species...) to deal with that. But so long as you have a data model that stacks many points at the same spot, there will be inelegance involved.

596 post(s)
#16-Aug-19 07:10

Thanks Dimitri, your advice is correct. Now everything works and I can't make it not work. But until now the opposite was true. Sometimes it is my error - I was using double quotes on strings in WHERE clauses, other times I have no idea and the issue seems to just go away by itself. Below is a screenshot of an attempt that did not work.



8,775 post(s)
#16-Aug-19 12:14

I can see at least one problem with the drawing linked from a query in the MXB file attached - it is lacking coordinate system and so renders in the wrong place compared to the rest of the data.

If you open the MXB, qrySpeciesLocationsWitheld is the data table, qrySpeciesLocationsWitheld Drawing is the drawing for that table, Query is a query with SELECT ... WHERE ... 'sooty owl' from that table, and Drawing is a drawing for that query. However, the coordinate system of qrySpeciesLocationsWitheld Drawing is set to EPSG:4326 (with the axes being YX, not forced to be XY, this is fine for now, but something to keep in mind as well), you can see that if you open the drawing and then go to the Contents - Component pane. And the coordinate system of Drawing is not set to anything and so it uses the default pseudo-Mercator. When these drawing are overlaid on top of each other, data goes to different locations, the coordinate systems should be the same but they are not.

To fix this: open Drawing, go to the Contents - Component pane, click the coordinate system picker button, select Assign Initial Coordinate System - Edit Coordinate System, select the EPSG tab, type in the filter '4326', select the EPSG:4326 system in the list, *uncheck* Force XY at the bottom of the dialog (because the coordinate system of the original data uses YX, we have to be the same), then click OK. Now, if you open qrySpeciesLocationsWitheld Drawing (or Map, which is a map component that has a single layer for that drawing), and drop Drawing into it, the objects in the two drawings are going to overlap (set some formatting to tell the two drawings from each other).

Thoughts: we should perhaps add means to set the coordinate system of a component to that of another existing component. This would simplify things.

There is one more gotcha - if you open Drawing on its own instead of dropping it into an existing map, it does not know where to zoom to because it does not know where the data is because this is a query and not a table, and there is no telling what the bounding box of data in the query is without reading all its records and this could be slow so we don't do it automatically. So, when you open Drawing, the screen is empty. Worse, if you click Zoom to Fit, the screen remains empty, we still don't know where to zoom. You have to right-click the layer tab at the bottom and select Zoom to make the window go "ok, fine, I am going to read through all data and find where it is" and finally zoom to the data. We will make Zoom to Fit do the same thing as Zoom in this case.


5,620 post(s)
#15-Aug-19 13:02

Regarding adamw's reply: I didn't expect the rendering optimizer to eliminate points on top of each other, so sorry for the bad advice. But it makes sense why the rendering optimizer does that. Even if it didn't, a stack of 46 symbols would be a challenge.

In cases where you have very many data points in a stack, I suppose it is time for a different data model, because visually what you have now is no longer "normal form" with so many at one spot. It's like having a table of Employees where there are two fields, a department field and a names field. The department field has a list of departments like Sales, Personnel, Manufacturing, etc., and the names field has a list of the names of each employee in that department, like Sam Jones, Tom Wilson, Janet Kline,... and so on.

That's a mess for data organization, not normal form, because you have so many employees colliding at the same "spot", that is, the same record. So you have similar issues trying to pull out an individual employee, to trying to pull out one record from many that collide at the same spatial location.

The right way to organize such a company grouping is to have a table of Departments, where each department has just one record and an ID, and then a table of Employees, where each record is one employee name and that table includes a field called Department which gives the department ID for that employee. At any time you can JOIN to get a table with a list of employees by department, etc. See any of Chris Fehily's books for a discussion of how you save lots of time and hassle by organizing data in normal form.

In your task, your new data model you might call places of interest (POI?). Each place where there is at least one record is a place of interest, and that place of interest has an ID. Places of interest are unique, no duplicates.

In addition you have a table of observations. Each observation has the flora name and other data, and one of the fields is the place of interest where that flora item was observed. So you could have ten records for orchids and each would be different, because it would have a different place of interest. At any time, for any place of interest you can generate a list of whatever was observed at that place of interest, and for any flora item you could generate a list of all places of interest where it was observed.

Such extractions of data are very simple queries that select what you want, and drawings can be dynamically created based on those, so you don't care about 46 collisions at the same spot, since your drawing dynamically shows you only what interests you, using a technique like that in the Example: Create a Drawing from a Query topic.

A small note:

I have also tried selecting the points in the drawing and pasting them as a new drawing but I get a table rather than the drawing I want.

Points copied from another drawing can be pasted into another drawing. Pasting them into the Project pane pastes a table (from which a drawing can be created if you want). See the Copy and Paste between Drawings topic for various copy/paste combinations and illustrated, step by step examples.


5,620 post(s)
#15-Aug-19 06:28

If I select a single point in a table and then use a map to zoom to selection, then it zooms out the whole world.

? Right-click on the layer's table, choose Zoom to Selection. That does not zoom to the whole world, just to the selected point. I'm glad you found a solution, but the above is so off that it merits some discussion.

A map consists of layers, each of which is a drawing, image, or labels layer. When you select a record in a table for a geom that is a point, there will be a corresponding selection in the drawing created from that geom.

To zoom to that selection, you have to right-click onto the layer tab for the drawing that is created from that geom and then choose Zoom to Selection. This is a good thing, because it allows you to have different selections in different drawings that may be in the map and then zoom to the selection for the layer of interest.

The above is a pretty simple deal, but there are, of course, ways to force unexpected results. I can think of two, one of which is simply inattentiveness that can happen to any human person, and the other is a result of one of those dark practices that can catch the righteous unaware:

1. Is only one record selected?

Ctrl-click in a table toggles the selection status of a record. It's like Ctrl-clicking a file in Windows Explorer to toggle whether it is picked or not. Toggling selection of a record with a Ctrl-click does not de-select all other selected records. When picking records out of a table, people sometimes select multiple records and then, because they see only one record selected in the view, forget they have selected others as well. [Personally, I think the Status Bar should show a "Selected: " readout when something is selected (but not show it if zero items are selected) in a table or window. ] To be sure you can always clear the selection with a Select None or a Shift-Ctrl-A shortcut.

Anyway, if you have multiple points selected and those are widely spread out, a Zoom to Selection might give the impression of zooming to the whole world. That's not wrong, it's just the system doing what has been commanded.

2. The Dark Side of the Force: Multipoints. The documentation discourages the use of multipoints for the very good reason that they often cause chaos. If the single record you selected is a multipoint, when you issue a layer tab context menu command to Zoom to Selection, you of course will get what you commanded, a zoom to a display that encompasses the entire multipoint.

There are times when it is easy to convince oneself that for a specific, limited purpose, using multipoints is a good idea. For example, when creating point equivalents to areas so you can have multiple geoms in the same record you might want to use a multipoint. The main geom is an area, another geom has the centroid of the area, a third geom has the bounding box of the area as an area and a fourth geom might have the bounding box of the area as a multipoint, with what seems to be a "point" at each of the four corners of the bounding box. Select that record and Zoom to Selection in a layer that is the drawing made from the bounding box multipoint geoms and you get a Zoom that displays the extent of the bounding box.

If the bounding box is big, it can seem you've zoomed to the whole world. There are plenty of military data sets, evolved from data originally created for very primitive hardware, where there are such multipoint artifacts.


It should maintain the current scale and pan to place the point at the centre of the view.

I respectfully disagree, as what you describe would be a "Pan to Selection" and not a "Zoom to Selection." The current command is really a "Zoom and Pan to Selection", but the Zoom part of it is an essential part.

Consider a thought experiment to see why:

You have a layer that shows tens of thousand points, say, fire hydrants in a big city, or all oak trees in a big mixed forest area. You have a view that shows a few thousand of the points. You pick one of them in a table, and then in the drawing you right-click on the layer tab and choose Zoom to Selection. If it pans while maintaining the current scale, you can get an imperceptible shift in the display given the very many points in view. In contrast, if it also zooms to center the selected point, you can see it better.

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