9.0.178.2

manifold-9.0.178.2.zip

SHA256: b5e86eead8ccd716a6647ceb36db73649e4a53dbb19d45861dcd73d1d91ed9c7

manifold-viewer-9.0.178.2.zip

SHA256: 10bf331d155e5939b0dc88c58131df8f1b19ac2a3a3091402570fffe34d133ae

sql4arc-9.0.178.2.zip

SHA256: 818c56cc2d86a7134fbb098b44b2e39dbf11097f2cbc200cf412371d112f89ea

North Arrow / Scale Bar / Grid

The Layers pane for a map window shows virtual layers for the north arrow, the scale bar and the grid. The virtual layers can be turned on and off, by default they are turned off. The position of the virtual layers in the display stack cannot be changed. Double-clicking a virtual layer edits its parameters using a dialog.

The state and parameters of the virtual layers are saved in the map component. If the map window does not have a map component associated with it (for example, if it was created by opening a drawing), the virtual layers still work, but changes to their state and parameters are lost when the window is closed. If you want to save these changes, use Edit - Save as Map.

North arrow parameters:

• foreground color - the default is black,
• background color - the default is white, some north arrow shapes may use colors that are mixes of foreground and background colors,
• shape - north arrow shape, the default is compass,
• stroke - stroke width for shape, the default is 1 pt,
• text - whether to show text near north arrow directions, the default is off (do not show text),
• text NESW - text to use for each direction, the defaults are empty strings,
• text font - font for text, the default is Tahoma,
• text size - size of font for text, the default is 8 pt,
• align - horizontal and vertical align relative to the map, the default is right top,
• margin - horizontal and vertical margin on the map, the default is 8 x 8 pt,
• size - size of shape, the default is 96 x 96 pt,
• halo - size of halo for shape and text, the default is 1 pt, setting halo to 0 turns it off,
• bearing - bearing, the default is to compute bearing automatically first based on the center of the north arrow shape, and then, if that fails because the north arrow is outside of the coordinate system domain, based on the center of the map.

Scale bar parameters:

• foreground color - the default is black,
• background color - the default is white,
• shape - scale bar shape, the default is rect,
• stroke - stroke width for shape, the default is 1 pt,
• text - whether to show text with the number of units, the default is on (show text),
• text font - font for text, the default is Tahoma,
• text size - size of font for text, the default is 8 pt,
• align - horizontal and vertical align relative to the map, the default is right bottom,
• margin - horizontal and vertical margin on the map, the default is 8 x 8 pt,
• size - size of shape, the default is 144 x 8 pt,
• halo - size of halo for shape and text, the default is 1 pt, setting halo to 0 turns it off,
• unit - unit, the default is to use the coordinate system unit.

The length of the scale bar is computed automatically based on the specified size and unit and the current scale. The width of the scale bar is slightly reduced so that the reported length is somewhat round (has no more than two significant digits).

Grid parameters:

• foreground color - the default is black,
• background color - the default is white,
• style - grid style, the default is lines,
• dashes - dash pattern for lines, the default is 3 pt dash + 3 pt space,
• stroke - stroke width for lines and points, the default is 0.75 pt,
• point size - size for points, the default is 5 pt,
• halo - size of halo for lines and points, the default is 0 which means that halo is turned off,
• spacing - minimum size of a grid cell, the default is 72 pt, the minimum allowed value is 36 pt,
• use latitude / longitude - whether grid uses lat/lon (on) or the projection of the map (off), the default is to use the projection of the map.

The grid step is selected automatically based on the specified spacing and the current scale. The grid step is rounded up to the closest power of 10 multiplied by 1, 2 or 5 (eg, 100, 200, 500, 1000, etc).

The dialogs that edit the parameters of the north arrow / scale bar / grid include previews which update after changes to the parameter values.

Other

(Fix) Going back and forward between views in a map window no longer fails to update the scale readout in the status bar.

Connections to SQL Server try using specific versions of the MSOLEDBSQL driver if the generic version fails to start due to being misconfigured.

Renamed: closest scale -> minimum scale, farthest scale -> maximum scale. (The new names help recall which of the two numbers should be greater.)

(Fix) The table window showing a table from a MAP file no longer suggests to refresh data after changes to values in non-key fields. (Tables from MAP files show such changes immediately without any need to refresh.)

Exporting a data source to MAP writes tables with an invalid schema (this typically happens when the schema cannot be read due to insufficient permissions) as tables with a single default field and no records.

Exporting a data source to MXB writes tables with an invalid schema as tables with a single default field and no records.

End of list.

Hi Adam, the new features look great for instant previews with the map files. It'd be great to see them being implemented soon in the layout as well, namely the grid and an option to view coordinates with the ability to customize grid spacing and font size. Is this viable in a short term?

Yes, of course, we will add all of these things to layouts as well. We just started with maps.

If I get it right, you cannot currently set the grid spacing by real world coordinates. I suppose setting spacing by real world coordinates is going to be added, because otherwise grid is without much real use. Also snapping to grid is important, in order to georeference a scanned map to it for example, and also setting grid limits.

I had wondered that too.

I hope we have both misunderstood, and grid spacing is (somehow) tied directly units we actually use.

Why on God’s Green Earth would anyone be interested in point spacing? Maybe it’s a typo.

The grid step is selected automatically so that the grid is neither too dense, nor too wide. We can think of the selection process like this: (a) the system tries to use a grid step of 1 unit, (b) if this creates a grid that is too dense (denser than the spacing), the step is increased (to 2, 5, 10, 20, etc, units), alternatively, (c) if this creates a grid that is too wide, the step is decreased (to 0.5, 0.2, 0.1, 0.05, etc, units).

We will allow specifying the minimum grid step, which will work as a base step.

We will also probably remove the snapping grid and will snap to the grid shown in the virtual layer directly.

We will allow specifying the minimum grid step, which will work as a base step.

If by that you mean that the grid step will be always the one the user wants, and never changes automatically, this is what I am talking about.

There could be various cases the user need to totally control a grid. The most usual for me could be divide an area in parts, or georeference a scanned map with a specific grid. An auto generated grid, with density auto-set is probably of little use.

As an example of good functionality, M8 grids are fine.

Let's say the user specifies a grid step and we never change that step. What should happen when the user zooms out so that grid cells are like 1x1 pixels? If we were to interpret "the grid step ... never changes automatically" literally, the screen would be solid black, nothing under the grid would be visible. Snapping to the grid would essentially mean "click anywhere to get a somewhat random grid location". We are not sure how this is good. We think it makes sense to automatically increase the step so that you still have the grid, but a coarser one, with the grid lines occurring, say, 10x or 20x or 50x less often. That's what the current implementation does. Are we wrong to think that automatically increasing the step in this case is better than getting a dense grid that essentially hides everything else is not much help during snapping?

When the user zooms too much out, M8 does what you describe (fills the screen with lines to close). It is true that with this behaviour grid stops being useful.

If we want to address this in M9, the grid could be turned off instead of changing step.

Anyway, maybe we should thing "what does the user need the grid for?" I personal find no use in a grid that changes step automatically. It is just squares that fill he screen.

Instead of that, a grid that has permanent step, show something what give a optical indication of scale, something meaningful to snap to, and something that the user can "extract" vectors to use for some practical reason ("create" button in M8).

Anyway, maybe we should thing "what does the user need the grid for?"

You open a map of the entire Earth in, I don't know, Mollweide. You turn on the grid and force it to lat/lon. Since the screen is showing the entire Earth, the grid has a step of 50 degrees, the grid lines bend to show the rough shape of the projection. Then you zoom in to view, say, Europe. The grid adapts and uses the step of 5 degrees to show major meridians / parallels in Europe. Then you zoom in to some city, the grid adapts again and uses a step of, say, 0.05 degrees (could have been 1 arc minute) to show whatever passes for "round" lat/lon in the scope of that city.

On hiding the grid if the cells get too small - yes, we can do that. Maybe we should do that as an option so that whenever you see grid lines / points, you can be sure that the distance between them is the step you specified, if that's desired.

You may have heard of a search grid. Military uses a matrix of land divisions all the time.

I'm in the middle of searching for all the schools in Tucson, Arizona (because they all have solar panels over their parking lots, not because I'm creepy). It would be nice to have a grid with attributes to identify sections of the areas where I have already searched. In this use I'm not going to zoom out so far that the image becomes black with lines.

I'm using the Google Street Map custom point markers to find the schools. When you zoom out to cover more area, it all looks the same unless you have a way to know where you've already looked. A fixed grid would be one way to do that.

Attachments:
Tucson School with Solar Panels.jpg

Not having to do with grids, but an idea that may help in your search: extract the locations of schools from OpenStreetMap for your area of interest, using the techniques in this topic.

Thank you. Interestingly the data for the US comes from the same server in Europe. You do have to get it in large areas, but who doesn't like to download 700 million records to get the 300 you need?

The query did not work off the shelf. I isolated the issue down to the following line of code.

  PROPERTY 'FieldCoordSystem.Geom' ComponentCoordSystem([cyprus-latest 

 Drawing])

What I ended up with looks the same (except for a space after ComponentCoordSystem), but that word seems to have an issue when pasted into the query. Retyping fixed it - whatever. Getting the schools this way works and definitely finds schools where I wasn't looking.

As for the solar arrays, it's almost as if it is mandatory to have a solar sunshade over school parking lots. Solar sunshades over the play ground seems more optional.

Thanks again.

A much easier and faster way is to use https://overpass-turbo.eu/

It lets you query a specific type of objects, schools in your case. Zoom in to the area of interest and run this query:

/*

This has been generated by the overpass-turbo wizard.

The original search was:

“college”

*/

[out:json][timeout:25];

// gather results

(

  // query part for: “college”

  node["amenity"="school"]({{bbox}});

  way["amenity"="school"]({{bbox}});

  relation["amenity"="school"]({{bbox}});

);

// print results

out body;

>;

out skel qt;

Depending on the size of the area it fecthes all the objects in a couple of seconds. Export the result to geojson and off you go...

http://www.mppng.nl/manifold/pointlabeler

A changing grid might be nice for a general public software such as Google earth, just to give a general impression of the latitudes and longitudes, but nothing much more probably. For a professional software like manifold, a fixed and with a user defined step grid should be the default. We need precision and control when we do analysis. A changing grid distorts the user's impression of scale, and is also useless for snapping to it. Of course, it could be an optional case.

For printing, fixed step and total control from the user should be even more standard behaviour.

Hear you. We'll allow fixing the step, of course. (As well as saving a grid as a real drawing, etc.)

What's the use case for grid limits? I am asking because the cases we were thinking of (visual, mostly) were better addressed by saving a grid as a drawing with physical records so that some of them could be deleted or styled differently from the rest, for example.

A for example of needing a vector grid is to determine the Area of Occupancy (AOO) of threatened species or those under investigation of threat status. The IUCN recommendation for the grid size used to calculate AOO is 2km but is user-definable. This grid is placed over all selected taxon records within the user-defined area. So if there were 100 records scattered across a 2 kilometer square grid, no matter how widely spaced, the AOO would be 400 km^2. The other metric is Extent of Occurrence EOO which is convex hull around all records.

An example of the need for vector points grid is that here in NSW Australia there is a threatened plant survey requirement for walking parallel transects of varying width depending on the target species and vegetation type. To accomplish this a grid of points gets uploaded into a GPS and and the surveyor walks from point to point, being required to stop at each point and look around. I know, who thinks this stuff up, only those who don't have to do it. But I have found it effective occasionally; a lot of walking!

All easily accomplished in M8 setting limits to cover the survey area.

Aussie Nature Shots

Thanks!

Let's take the first example, AOO. We will allow specifying the base grid step, which in your case will be 2 km (perhaps separately for X and Y, so 2x2 km). But ideally, you want something like this:

...right?

That is, you are given some area (blue border) and you want to divide it into cells of 2x2 km (gray). The result is not a full grid because some cells are outside of the area.

If so, that's probably better done with grid being a drawing, with each grid cell being a separate record. You can then delete the records you don't need, merge some records if you want, add attributes (eg, the date of the last investigation and some numeric results, etc).

I mean, we aren't against specifying XY limits for the grid (as a virtual layer of a map). It just sounds like we are more in need of a tool that would take the parameters for a grid and create a drawing with it.

Attachments:
grid-aoo.png

I think there are two similar, but different things going on. One is the use of grids and graticules as purely display overlays, to provide cartographic context, either as lat/lon graticules or as regular grids in grid-based systems. For extra credit, those same grids could be used as "rulers" to facilitate drawing real objects freehand, for example, to align frames in layouts, or to draw shapes using snap-to-grid to defined grid spacings in CAD work, like the kitchen CAD map shown in the Clip topic.

The other use is of grids (rectangular, hexagonal, etc) is as tilings of area objects, where the grid of objects is used (through joins and other tools) as a way of sampling/analyzing or organizing other data, used to generate from the bounding boxes of each object to generate a layout for map books, and similar tasks. I think those are best generated by transforms. You could also have a control in the cartographic grid dialog to generate a layer of objects based on that grid.

There is also the difference between grids for use in web maps where grid/graticule spacing is more important (though specifying the minimum base step will be nice) vs in printed layouts for maps where specifying the grid/graticule values is paramount. This build seems focused on the web mapping. The ability to create a drawing and adjust style of a sub grid would be nice.

Created with the query in the attached map file. Specify the dimensions of the cells and the drawing for the extend. Afterwards use the Select Pane to get rid off the unwanted grid cells...

Attachments:
create grid.map

http://www.mppng.nl/manifold/pointlabeler

well done!

Useful, thanks.

Aussie Nature Shots

Not quite, we are dealing with point occurrence records as per the attached illustration.

It just sounds like we are more in need of a tool that would take the parameters for a grid and create a drawing with it.

Correct, both outer limits and cell size being square, so 2x2 km in this case.

Attachments:
AOO vs EOO.jpg

Aussie Nature Shots

First time in months having an occasion to use Manifold. I'm pleased to see North Arrow and Scale bar. I notice I cannot have both the scale bar and north arrow in the same place (e.g., bottom left), it's either the scale bar or the north arrow but not both.

Also fur future feature, it would be nice to have free form placement of both scale bar and north arrow, drag and drop. Then Manifold can post-calculate the new coordinates for the scale bar or north arrow. Second choice for customized placement would be trial and error by nudging north-south and east-west.

[update1 Just noticed, as HMS did, scalebar and north arrow though applied to Maps do not appear in Layout.

Tony, place both the scale bar and the North Arrow in the same place (bottom left)

Click into the North Arrow, and change the margins, that will make the arrow visible, and align the arrow on the scale bar.

Agree with free form, and/or preview in changing margins. Even better, would be user defined default. ( I must email sales with the suggestion)

Thanks Dale. That worked.

So the first number controls east-west placement, the second number controls north-south placement. By trail and error, I found at my scale, I needed multiples of about 8 times (to 60 from 8 units on the margin) for north arrow to nudge far enough north for the scale bar to show.

Watch the video here, our dulcet toned YouTuber gives a pretty good run through of the feature.

We started with free-form placement of north arrow / scale bar when we were making this build. We took that away and went with specifying the positions explicitly using a dialog because we found that windows get resized (eg, when you open your map with configured north arrow / scale bar on a different system with a different display size), and then the positions have to change, and when this happens you nearly always want to specify the positions in terms of which side to align to -- which is done much better using explicit choices in the dialog rather than some visual magic like 'align to whichever side is closest' (we tried this and other variants, we think they all break too easily).

We might add free-form placement later as an option.

Status update: the next build (9.0.178.3) should be out this week.