9.0.169.9

Here is a new build.

manifold-9.0.169.9-x64.zip

SHA256: 161ea694e3eec0d555fd51ab581e1d077b7975a1d2b7adff7b2f75535ecb634f

manifold-viewer-9.0.169.9-x64.zip

SHA256: bacb65197806fbfe35e0ddb7ea0880d592c68c8f9b271e152d88452119118d52

Changes

(Fix) The tracker tool no longer ignores curves, and instead linearizes them with fixed number of intermediate coordinates per curve part.

The context menu for the tracker tool allows copying the last clicked location. The Copy Location command uses lat/lon in the datum of the current layer. The Copy Location (Projected) command uses the coordinate system of the current layer sans local scales and local offsets (same as the 'Projected' coordinate readout in the status bar).

Snap in a map window is turned off by default.

New edit commands for lines and areas in a map window: Add Mid Coordinate (appears in the context menu for a segment) adds a new coordinate in the middle of the clicked segment, Add Spline Coordinate (appears in the context menu for a spline coordinate) adds a new spline coordinate in the spline part following the clicked coordinate.

(Fix) Switching the edit mode in a map window from Insert Coordinates to Move Coordinates or Move Coordinates + Split no longer stays in Insert Coordinates if the focus coordinate has been moved away from the insert coordinate in the coordinate list in the Record pane.

(Fix) Deleting start or end of a closed area branch no longer does nothing.

Deleting coordinates of the edited geometry in a map window automatically deletes ellipse arcs that became incomplete. Deleting coordinates of a line or an area deletes finished branches that became incomplete. Deleting coordinates no longer always deletes the insert coordinate, switching away from the Insert Coordinates mode. Instead, the location of the insert coordinate is checked after the deletion and if it remains valid, the insert coordinate is kept. Deleting coordinates no longer always resets the focus coordinate to coordinate zero. If the focus coordinate remains valid after the deletion, the focus coordinate is kept. Otherwise, the focus coordinate is set to the closest (in list order) remaining coordinate in the same branch as the deleted focus coordinate. Deleting coordinates no longer always closes the last branch. If the last branch is opened, it is kept opened.

New edit commands for points, lines and areas in a map window: Delete Coordinate (appears in the context menu for a coordinate or spline coordinate) deletes the clicked coordinate. If the clicked coordinate is selected, the command deletes all selected coordinates.

(Fix) Deleting all coordinates of the edited point, line or area in a map window no longer prevents new coordinates from being inserted (deleting everything and creating new geometry from scratch now works).

Attempting to end a branch of the edited area in a map window using Shift-click does nothing if the branch contains less than 3 coordinates. (Previously, the branch was ended with coordinates padded to 3 coordinates + closing coordinate.)

Attempting to end a branch of the edited line or area in a map window using the End Current Branch command pads the branch to 2 coordinates for line and 3 coordinates + closing coordinate for area.

Inserting coordinates into the last branch of the edited point, line or area in a map window allows using the Delete Last Coordinate command to delete last inserted coordinate (Backspace). The command can be used repeatedly until the branch is deleted entirely.

Turning the Insert Coordinates mode when editing a (multi-)point in a map window always moves the insert coordinate to the end of the coordinate list. (Multi-point branches are preserved, but you cannot insert into the middle.)

(Fix) Moving the Record pane to a record with no geometry (a NULL) no longer paints a fake bounds rectangle near the left top corner of the window.

New edit command for points, lines and areas in a map window: Delete Branch (appears in the context menu for a coordinate, curve coordinate or segment) deletes the clicked branch.

New edit command for lines in a map window: Reverse Branch Direction (appears in the context menu for a coordinate, curve coordinate or segment) reverses the direction of the clicked branch. Curve arcs are reversed as well.

New edit command for lines in a map window: Continue Branch (appears in the context menu for a coordinate that starts or ends a branch) starts inserting coordinates into the clicked branch from the clicked end. The branch is moved to the end of the coordinate list, and is reversed as necessary.

Pressing Escape in a map window no longer clears the picked / edited record and no longer clears the cursor mode. (It is too easy to lose changes to geometry / values otherwise.)

New edit command for tracker in a map window: Clear Tracker (Ctrl-Backspace, same as Undo Changes for a record) clears tracker coordinates.

The Record pane allows switching the coordinate list for a line or area to show metes and bounds instead of XY / XYZ coordinate values. The metes and bounds are shown in the format used by ESRI traverse files.

The Record pane allows saving the coordinate list to a text file. If the coordinate list shows XY / XYZ coordinates, the file uses a simple format specific to Manifold that closely matches what is displayed in the list and preserves all data, If the coordinate list shows metes and bounds, the file uses the ESRI format and preserves XY values (not Z) and circle arcs (not ellipse or spline arcs). Short descriptions of both formats follow.

The Record pane allows loading the coordinate list from a text file. Both the Manifold format and the ESRI format are supported, with the format being detected automatically (no need to switch to coordinates or metes and bounds prior to loading data).

Quick description of the Manifold format:

The first line contains P for point, L for line, A for area.

The following lines contain coordinates:

• C <x> <y> [<z>] - coordinate.
• CC <x> <y> [<z>] - circle arc coordinate.
• CE <x> <y> [<z>] - ellipse arc coordinate.
• CS <x> <y> [<z>] - spline coordinate.
• E <x> <y> [<z>] - coordinate that ends a branch.

Quick description of the ESRI format (also see this link):

The first two lines denote format for direction type (quadrant bearing, north azimuth, south azimuth, we do not currently support polar) and direction units (decimal degrees, degrees-minutes-seconds, radians, gradians).

The following lines contain coordinates:

• SP <x> <y> - starting coordinate.
• EP <x> <y> - ending coordinate.
• DD <direction> <distance> - coordinate in specified direction.
• AD <angle> <distance> - coordinate in specified direction relative to the current direction.
• TC <circle arc parameters> - circle arc tangent to the current direction. The arc parameters are any pair out of central angle / arc length / chord length / radius plus whether the arc turns left or right.
• NC <circle arc parameters> - circle arc not necessarily tangent to the current direction. The arc parameters are those for the tangent arc plus one extra direction, any of: tangent / radial / chord.

For both formats:

Case is not important. Whitespace, apart from line ends, is not important. Line ends can be either CRLF or LF or CR. Text encoding is detected automatically, supported encodings are: ANSI, UTF8, UTF16 BE, UTF16 LE. The file can contain empty lines, they are ignored. The file can contain comment lines with comments starting with #, comment lines are also ignored.

All of this only applies during loading. When we are saving data, we are using single spaces, uppercase letters, no comments, etc, following the 'be conservative in what you produce and liberal in what you accept' robustness principle.

Loading the coordinate list validates all data after loading and removes invalid curves or branches. Loading the coordinate list from an ESRI format file remembers the format used for direction type and direction units as well as the format used for each coordinate, and keeps them during editing. (We are going to allow changing the format for direction type and direction units using the UI. We are also going to allow closing a branch distributing closing error between branch coordinates using a command.)

The coordinate limit in GeomLinearize query function applies per curve part instead of per curve, so that spline curves with many control points produce more intermediate coordinates.

The View - Panes - Log Window command has an icon.

(Fix) DELETE / UPDATE / SELECT INTO / GROUP / SPLIT query constructs no longer sometimes stop the query if the source table contains no records. (This was not happening often - mostly when the source table was the result of a join with specific optimizations. The query was aborting instead of producing nothing.)

(Fix) The status bar no longer sometimes fails to turn on the busy indicator during long operations that run in background (eg, creating a temporary spatial index for drawing or image).

New query functions for viewsheds:

• TileViewshedMake takes an image and global viewshed creation parameters, and returns a viewshed buffer. Global viewshed creation parameters are: a refraction coefficient (0 allowed), an option of whether to use datum curvature. TileViewshedMakePar is a parallel variant.
• TileViewshedAreaAll takes a viewshed buffer, a drawing with XYZ points, viewshed creation parameters, and returns an area visible from all points in the drawing. Viewshed creation parameters are: an option of whether Z values are absolute or relative to the image, maximum visible radius (a negative value means that there is no limit), minimum and maximum angles of the camera in degrees (-90 / 90 means that there are no limits). TileViewshedAreaAllPar is a parallel variant.
• TileViewshedAreaAny takes the same parameters as TileViewshedAreaAll and returns an area visible from any point in the drawing. TileViewshedAreaAnyPar is a parallel variant.
• TileViewshedTilesCount takes a viewshed buffer, a drawing with XYZ points, viewshed creation parameters, and returns a table with tiles with pixel values containing the number of points visible from the pixel. TileViewshedTilesCountPar is a parallel variant.
• TileViewshedTilesLevelAll takes a viewshed buffer, a drawing with XYZ points, viewshed creation parameters, and returns a table with tiles with pixel values containing the visibility level of the pixel from all points. If the visibility level of the pixel is positive or zero, the pixel is visible from all points. If the visibility level of the pixel is negative, it contains the difference between the height at which all points become visible and the height of the pixel (the bigger the magnitude of the value, the more pixel has to be raised to become visible from all points). TileViewshedTilesLevelAllPar is a parallel variant.
• TileViewshedTilesLevelAny takes the same parameters as TileViewshedTilesLevelAll and returns a table with tiles with pixel values containing the visibility level of the pixel from any point. TileViewshedTilesLevelAnyPar is a parallel variant.
• TileViewshedTraceLine takes a viewshed buffer, begin and end XYZ coordinates, viewshed creation parameters, and returns the visibility level of the end coordinate from the begin coordinate.

(We are going to provide transform templates for viewshed functions in further builds.)

SHP and other dataports read coordinate system data from PAM XML files (.AUX.XML). (PAM XML files may encode coordinate system data in many different ways, we are supporting all ways that we are aware of, but this is a moving target. If you come across a PAM XML file with coordinate system data that we do not load, contact sales with a suggestion to support it.)

(Fix) Exporting data to GPKG no longer sometimes fails. (This was a regression after changes in the previous build.)

Reading data from PDS reads inventory data.

Reading data from PDS supports floating-point values with non-Intel byte order.

(Fix) IMG ERDAS dataport no longer reads Albers conical equal area projection as Lambert conformal conic.

(Fix) Reading coordinate system from WKT data no longer incorrectly reads several variants of Hotine oblique Mercator systems.

(Fix) Exporting data to MDB no longer fails if the file path contains spaces.

(Fix) Reading data from XLS no longer fails to locate MFD_META$ sheet.

End of list.

Nice changes to the drawing tools. A few thoughts :

- like the metes/bounds, continue branch and backspace options

- would be nice to have the ability to see the next coordinate show up in the record list as the cursor is being moved around before clicking its final location and add a way to enter values for the final location instead of clicking in the drawing for its the location. Currently one has to click to create and then edit values afterward.

- miss the escape option for changing to the default tool but understand why. Is there another shortcut that could be used for this. Also miss shortcuts for area, line, and points.

- might be fairly handy to allow the backspace to work when editing an existing geometry. It's a quick way to delete a bunch of coordinates rather than selecting then deleting.

- glad to see the metes option fit nicely into the existing UI and that you are using the ESRI metes format. Big help for those wishing to transition.

- also glad to see your intending to add closing options, polar bearings, and hopefully the other options in the Plot Traverse add-in.

Great work!

- miss the escape option for changing to the default tool but understand why. Is there another shortcut that could be used for this.

In edit mode, Ctrl-backspace does what Esc used to do. I don't think there ever was an Esc option to exit Insert Line, etc. mode. Also, just clicking another layer tab and then back also drops out of an Insert Line, etc, mode and back to default navigation.

- Also miss shortcuts for area, line, and points.

I don't recall any keyboard shortcuts to switch the cursor from navigation mode to Create Line, etc, mode. What were they?

Right you are. My memory failed me.

What if pressing the Alt key returned to navigation mode? That way when you want to switch from creating to editing a feature, there isn't the need to first switch to navigation mode by other means.

Pressing Alt on its own normally has a defined Windows feature--to activate the application menu bar.

That way when you want to switch from creating to editing a feature,

Well, that depends upon the context of the above, which might have two meanings.

1) Suppose you mean that in the middle of creating a new line you want to stop adding vertices and instead go back to editing some prior clicks in that creation sequence, say, if you forgot to click around some region that should have been part of the line. That's easy: press the M or P key to switch into Move Coordinates or Move Coordinates + Split mode. You're now editing. Press I to go back to Insert Coordinates mode. Or use the right-click context menu.

2) Suppose you mean you want to stop creating objects of that type, and switch to editing other, existing features. Abandoning a creation in process should not be a single-click key, especially not one frequently used in combination with other keys, because people often invest significant effort and thought into creation... not something you want to lose too easily (and that will be true even when you have a one-step undo, as surely will be happening one fine day...). As it is now, you just click on the main toolbar and choose the default cursor and the editing session is abandoned. Alt-click to pick the existing object of interest and you're viewing/editing attributes in the record pane. Click a vertex or segment (that safety thing...) and you're editing coordinates.

Scenario #2 is what I was thinking. When your creating a new object sometimes you realize its better to stop and modify an existing object then go back to the new object. I agree that there needs to be some safe guards to avoid unwanted changes but of course they are a trade-off to speed. Saving every record with the Ctrl Enter keystroke seems like a good compromise, although at first it seemed too far toward the slow side.

Having to mouse over to the main toolbar and choose default or one of the drawing types seems slow to me. I definitely hit the escape key a few times while drawing an object, so can appreciate the desire to remove that.

However, Alt Clicking another object while in the edit mode of a different object is no accident. So perhaps that could trigger a save of the current feature and put the newly clicked object in edit mode. Alternatively or in addition to perhaps some shortcuts for all the items in the toolbar dropdown (default, area, line, point, tracker).

By the way, I'm really liking the new tools so this is just minor fine tuning things to consider based on very limited use.

Thanks!

might be fairly handy to allow the backspace to work when editing an existing geometry. It's a quick way to delete a bunch of coordinates rather than selecting then deleting.

We'll consider extending the Backspace to work for existing branches. The concern here is that once you completely deleted an existing branch, we don't want the Backspace to just jump into a different branch and start deleting coordinates there - because it is unclear which branch to jump to. But we can either disallow deleting an existing branch (using Backspace) completely or perhaps allow deleting it and then get out of the Insert Coordinates mode.

miss the escape option for changing to the default tool but understand why. Is there another shortcut that could be used for this. Also miss shortcuts for area, line, and points.

As has been said already, the switch has to be made difficult enough so that it is never or nearly never accidental. A single key is too brittle, so we are currently using two keys: Ctrl-Backspace = cancel changes or Ctrl-Enter = accept changes. Requiring two keys is relatively safe.

We can perhaps add a two-key combination to not just cancel changes, but also switch to the Default cursor mode. We don't know whether switching to Insert Area / Insert Line / Insert Point / Tracker need their own shortcuts, but switching to Default is perhaps frequent enough to have a shortcut. Or maybe we can just press Ctrl-Backspace twice, first to cancel changes, second to switch to the default cursor mode.

We have been considering other options, too, some of them are dependent on undo which we might add. This is a work in progress.

We don't know whether switching to Insert Area / Insert Line / Insert Point / Tracker need their own shortcuts, but switching to Default is perhaps frequent enough to have a shortcut.

Could we just have customizable menu access keys for each menu item.

Alt+v,d,d for Default mode would be great. As would Alt+v,d,a for Create Area.

I would customize not necessarily by first letter, but so that most keys are under my left hand.

It works already with main menu. Adding '&' in ui.en.txt makes the next letter the access key. Works in any language.

Attachments:
Custom_access_keys.png

Guess it is time to implement this long-requested feature, yes. :-)

We'll try to do this.

Regarding metes and bounds

Thanks for getting going on this. It's different from the M8 add-in, but so is the rest of M9 different from M8.

I created the following .txt file using Notepad.

DD N0-0-0E 105

DD N90-0-0E 100

DD S0-0-0E, 100

DD S90-0-0W, 105

I don't see a way to import the file. When editing an existing object, there is a folder to click on in the Record pane. Clicking on the folder and selecting the file gives an error, Unknown file type. I don't think the .txt file is out of the ordinary.

Beyond that, opening a file in the middle of editing another object does not seem right. My intuition tells me to select the Create Area or Create Line tool first and then select the .txt file via right-click context menu or Open folder option.

Also I don't see a way to change from decimal degrees to degrees, minutes, seconds in the Record pane.

Again, I appreciate getting this going. I'm not sure if my issues are learning issues or beta development.

You are trying to use the ESRI format. I suggest you study the link that came in the version notes for the "traverse-file-format.htm" . You also included commas where not needed. This below worked for me without the comments.

It might be easier to grossly duplicate the line traverse and then save the file first. Then use the saved file as an example to generate your own. I assumed your test meant to Not return to the same location, otherwise check your numbers. I haven't tried the Manifold format yet.

Side note to Adam and rest of team. Thank you for this feature(s). I think it may come in very handy when moving to create an US/PLSS land section alaquot tool.

DT NA (required first line for Direction type)

DU DD (required second line for Direction units,i.e.DD)

SP 0 0 (required third line for Starting Point.

DD 0 105

DD 90 100

DD 180 100

DD 270 105

Thank you for the kick start oeaulong. I had read and reread the notes and ESRI, but was not understanding the first line, second line stuff. Your example got me over that. I used the ESRI example modified as to start and end points. Here is the file.

DT QB

DU DMS

SP 2694.3674135 1058.4196717

EP 2694.3674135 1058.4196717

DD N90-0-0E 105

AD 45-0-0 100

TC C 45 D 100-0-0 L

NC C 45 D 100-0-0 C N45-0-0E R

where the SP and EP are taken from the coordinates in my file. It would be much nicer if I could copy those points inside M9.

The result looks like the image.

Now I need to study the input and output for better understanding.

Attachments:
Result of ESRI MnB Example.jpg

You can currently copy the XY of any location using tracker: turn on the tracker tool, turn on / customize the snap as needed, click the location you want, right click to invoke the context menu and use one of the Copy Location commands.

The only gotcha is that the copied values will be either in lat/lon or in the coordinate system of the active layer with the local scales and offsets removed. We will add means to copy the XY values from the coordinate list in the Record pane, this will provide a way to copy the XY of a location in the coordinate system of the active layer as is, so that these values can be used in SP / EP of an ESRI traverse file.

This capability is off to a fantastic start! I found a way to do the SP coordinates and also found some possible bugs and learning curve issues.

There is another way to copy the coordinates. What I tried first was to Ctrl-click the coordinate and copy. That didn't work. What did work is, if you are looking at the coordinates in Record, you can quad-click on the X or Y which highlights the value to copy. Then paste X and Y, one at a time, into the txt file. That is fine with me.

Here is something I believe to be a (temporary) bug. I redid one of my relatively large txt files from the M8 add-in format to M9 ESRI complete with curve data. The file plotted perfectly. So far so good. In my county the older surveyor notes need a rotation adjustment of +/- 0.5 degrees to fit the current Earth. When I made that rotation adjustment with the newly plotted lines, the beautiful curve turned into a straight line. I Ctrl-clicked the line and did a Rotate Transform for -0.5 degrees. I added it as a new component and dragged it to the Map to illustrate. The black line is the added component.

Something else came up which I believe to be a learning curve issue. To identify the SP I clicked on an adjacent line where the SP for the new line is. I used the coordinates for the point as described above. Then I brought the txt file in with that line selected, because if I deselect the line, there is no apparent way to bring the text file in. When I updated the field, it replaced/updated the original line. I understand why that happened, but how can I import the txt file without preselecting an object...for future replacement? With the M8 add-in we have to select a point, not a line, as the point of beginning (SP). When the file reads in the original point is left unchanged.

It appears the Manifold input format will be simpler than the ESRI coding. For now it seems the Manifold format doesn't provide for direction/distance or curve input. Am I missing something? Is there a way to set the starting point with the M9 format? The M8 add-in process of preselecting a point in the layer works fine, but it doesn't work in M9. If you select a point and, using the ESRI file I made, import the coordinates you get a constellation of points instead of the expected line.

Attachments:
Rotated component in M9 lost curve.jpg

My understanding is that the Manifold format is for import/export coordinates, whereas the ESRI format is for import/export of distance/bearings. Essentially Manifold is adopting the ESRI format for the later which is good.

Here is something I believe to be a (temporary) bug. I redid one of my relatively large txt files from the M8 add-in format to M9 ESRI complete with curve data. The file plotted perfectly. So far so good. In my county the older surveyor notes need a rotation adjustment of +/- 0.5 degrees to fit the current Earth. When I made that rotation adjustment with the newly plotted lines, the beautiful curve turned into a straight line.

What specifically did you do in the last step to apply the adjustment?

On bringing the file without pre-selecting an existing object - you can start a new object and load the file into it. There is currently no way to preserve the starting coordinate, if you want to preserve it, you have to type it into the file. You won't have to do it in the future, we are extending what the tool can do.

On the Manifold format not having direction / distance or curve input - Mike is correct, the Manifold format is just coordinates, it does not do direction / distance and other incremental things. If you want to build geometry incrementally, use the ESRI format. The Manifold format is for preserving all data (the ESRI format does not support, say, spline curves or Z values or, well, point geometry) in the most direct form possible.

I meant to put my process in the earlier msg, but the office has been very distracting today. Apologies.

• Ctrl-clicked the line,

Got it. The Rotate transform does not currently support curves. We'll see if we can extend it to support them.

On starting a new object and loading the file into it - select Create Line (to set the cursor mode), click on an arbitrary location in the map window (to start a new object), go to the Record pane, switch to the Coordinates tab, then load the coordinates from the file - this will overwrite the coordinate you clicked.

Thank you for that. Sometimes it's just that simple.

Could the Load feature be included in the context menu for the various Create modes? I'm thinking of clicking a point, right clicking anywhere, and getting a Folder as a choice among the other choices on the menu. This is a Yes or No question, not a suggestion for a change. I'd like to see what Mike P and others think about the idea.

Maybe I'm not seeing everything you have in mind, but the current method Adam described works well enough I think.

Yes it does. I was thinking it was more intuitive using the context menu.

Mike or Adam, do you know if the initial point selected with the Create tool can be used as the SP without specifying the SP in the txt file? Although I like the idea of specifying the SP in the txt, it goes a lot faster without the "extra" steps of inserting the POB into the txt. Oeaulong used SP 0 0 but I was afraid my line would end up off the Ivory Coast.

Yup, your suggestion would be more intuitive but much of Mfd requires some creative thinking to run with the upside of a clean flexible interface. I'm thinking the way it is now fits with the rest of the UI pretty well.

Regarding the SP, once you load a txt file it clears whatever current coordinates are in the record. Perhaps load the txt file and then drag/snap the feature to your desired location would be quicker than dealing with SP coordinates. Start the record nearby your location to avoid a drag across the ocean :-)

Loading and moving is what I did with the test files above. That's my standard operating procedure in M8, also. The original file I'm working with is largely based on imprecise historical surveys and no benefit of decent imagery, so nudging the lines around is par for the course. I was suggesting a way to speed up the loading process by clicking an arbitrary SP and defaulting to the coordinates of that spot.

A short example of using the new viewshed functions.

Let's say we have a MAP file with the image called 'german_alps' that contains heights. We open a new command window and type:

--SQL9

VALUE @v TABLE = CALL TileViewshedMake([german_alps], 0, false);

This creates a viewshed object initialized with the image, we can use that object to build viewsheds. The creation should not take long.

We then open the image, switch the status bar to show 'Pixels / stored' coordinates and note the locations of two points - say, 610, 186 and 620, 300.

We go back to the command window that has the viewshed object, and check whether the first location is visible from the second:

--SQL9

? TileViewshedTraceLine(@v,

    VectorMakeX3(620, 300, 0), VectorMakeX3(610, 186, 0), true, -90, 90)

-- float64: -152.1152484130871

The result is negative, so, no, the first location is not visible from the second location, it has to be raised 152 meters (well, whatever units the raster is in) to become visible.

Instead of raising the first location, let's try raising the second:

--SQL9

? TileViewshedTraceLine(@v,

    VectorMakeX3(620, 300, 0), VectorMakeX3(610, 186, 200), true, -90, 90)

-- float64: 47.8847515869129

Yep, the first location is now visible.

OK, let's see what other locations are visible from the raised second location. We create a drawing and set it to use the exact same coordinate system as the image. Then we insert a 3d point into it and set the height to 200:

--SQL9

INSERT INTO [viewpoints] ([Geom])

VALUES (GeomMakePoint3(VectorMakeX3(610, 186, 200)));

We also need to put the visible area somewhere. We create a second drawing, set it to use the exact same coordinate as the image as well, then compute the area visible from the location in the first drawing:

--SQL9

INSERT INTO [viewareas] ([Geom])

VALUES (TileViewshedAreaAll(@v, [viewpoints], true, 0, -90, 90));

This takes a couple of seconds to compute and then we have our area.

I'm very excited about this, the viewshed functions. Now Manifold is the tool for mapping visibility, a pretty big deal for environmental planning and for telecommunications. (Other people will be equally excited about the metes and bounds toolset. You seem to have decided to cover absolutely everything there too.)

These examples are super useful, thank you.

Thanks for fixing the gpkg export bug. However, now there's a bug when exporting map to GDB:

"Unspecified FGDB error: 0x8004005."

Does not occur in 9.0.169.7 (and possible .8, not sure)

Thanks a lot for the report.

We did find two defects in GDB since publishing the build, and one of them could theoretically be responsible for the error above (an access violation, probably happens because parameters passed to a specific function in the ESRI GDB SDK are invalid). But it'd have been great if you could upload example data which trigger the issue in your case somewhere, that would allow us to make sure the issue with your data is the one we found and not something else.

Did some more testing. The error originally appeared when exporting a map with more than 10 quite complex vector layers.

So I also tried exporting to GDB with just a single vector layer - and the same error results.

I have attached a .map file saved by the latest edge version with that single layer.

Attachments:
gdb_export_error.map

Thanks for the file. It exports fine in our tests, using unmodified 9.0.169.9, but that does not mean that everything is fine - for one thing, the issue could be related to reading uninitialized memory which happens to contain values that do not trigger the failure in our environment but do trigger the failure in yours. So, we will keep looking.

Ok. This may not be any new information, but here the error is caused by the extgdb.dll version included with 9.0.169.9

If I export a map using 9.0.169.9 but replacing extgdb.dll with the version used in 9.0.169.7, there is no error.

Both filegdb versions are attached.

Attachments:
extgdb_versions.zip

Thorough! Nice work.

While we are on the subject of broken data ports, I am unable to link/import any laz/las using 169.9. Attempting to his fails quietly with 'Unspecified LAS error' being written to the log.

All functions as expected in 169.8 and the last official release of M9.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

Erm, that's unexpected. We'll take a look at this as well. Thanks a lot for the report.

Two quick questions:

1. Does linking work?

2. Do the files that fail to import have the .MAPINDEXP file near them (produced by linking)? If so, do they import fine if you remove the file?

We did not see this issue on our testing and this was tested, I just checked the logs, but maybe this has to do with a particular type (eg, version) of LAS / LAZ files. So, one more question:

3. Can you link / upload example file that fails to import?

Thanks again.

Thank you, we'll take a look!

A follow up on both GDB and LAS / LAZ issues:

We have a theory regarding what these issues might be about and why we have a hard time reproducing either of them on our systems (we verified that the supplied EXTGDB.DLL binary coincides with what we shipped with 169.9, this exact binary works without issues in our tests, etc).

Could you please install the latest version of the Visual C++ Runtime from this Microsoft page:

The latest supported Visual C++ downloads

Install both the 32-bit package and the 64-bit package, then see if this fixes the issue. If it does, great. If it does not, also great, because we can rule out a couple of things.

That did the trick. Linking and importing of las/laz now working perfectly. Many thanks for such a quick turnaround.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

And also resolves the GDB export issue!

Also, a separate bug when exporting to gpkg.

The attached .map contains two drawings:

• np2 Drawing has just a float64 field called 'hectares'
• np4 Drawing has a nvarchar field called 'CEA' and a float64 field 'hectares'

9.0.169.9 drops the hectares field from both drawings when exporting to gpkg.

9.0.169.7 exports the hectares field successfully.

(Note that both edge versions are using the same sqlite-spatialite extension dll package as downloaded from manifold.net a few months ago.)

Attachments:
gpkg_export_error.map

This is a feature, not a bug. :-)

The fields you are referring to are computed, 9.0.169.9 exports computed fields to GPKG / GDB as computed = there is no physical field and no values stored, what is stored is an expression that gets evaluated on demand. Previous builds added this for SQL Server / PostgreSQL / Oracle and other databases, this build extends the feature to GPKG / GDB.

If you link the exported data back in Manifold, you will see the computed fields and will be able to access them. We realize sometimes you want to export computed fields as regular fields, eg, for use in a third-party application. We will likely add an export option to do that. We will also add means to quickly convert computed fields to non-computed ones in the UI - perhaps not just for MAP files but for all data sources.

Ok that makes sense, thanks. And one person's bug is another one's feature, so true! I'll hunt around for some VBscript or SQL to convert the computed fields before I export.

Estonian translation file updated.

Attachments:
ui.et.txt

German ui file for v 9.0.169.9

Attachments:
ui.de.txt

thank you Klaus, very good job as as always

A heads up:

We are planning to issue the next build during the next week, likely at the end of it. We have been working on vector editing tools. We will also have an important extension for projections. Plus various smaller fixes and improvements, as usual.

Shortly after the next build we will likely issue a public build.

Keep up the great work!

I have lost track of the order in which features from 8 are being added to 9. That's ok, of course, but perhaps there's value in using a tool like https://canny.io/ to track suggestions and discourse around features? A great example is the data collection application "Fulcrum", which uses Canny at https://fulcrum.canny.io/.

I have found that features which generate discussion in this forum tend to appear in subsequent builds, even if they may not have been on any roadmap prior. Most recently a discussion around metes and bounds (http://www.georeference.org/forum/t148616.52#148851) resulted in the functionality being added to a build very soon thereafter. I'm not saying there's anything wrong with that (it's great, in fact), but we can probably leverage even more insight into community wishes/suggestions/priorities by using a tool like Canny.

My $0.02, unsolicited. Thanks.

Interesting idea, but you know it will not happen.

Manifold has its own systems, much more powerful, integrated with their work, and proven. Let alone secure and private.

It is interesting to note that Canny seems to assume that feedback is always positive, informed, and helpful. I'm basing that on the screenshot listing Status categories, which include Open, Under review, Planned, In progress, Complete and Closed.

There is no Rejected.

It's smiles all round.

Thanks for the suggestion.

We understand where you are coming from and we would like nothing more than to have a better sense of what proportion of users are interested in what feature. However, this seems much more complicated than a plain numeric vote.

We saw numeric votes implemented many times by other products and after some time this was invariably getting into complications to the point where it was hard to tell whether the voting actually benefits anything. To take just one example, the Visual Studio team tried to do this many times, and it was always going like this: create a new site with nice interface and pretty +1 buttons -> very quickly there appear features that get upvoted into the sky, but which the development team does not want to take on for some reason -> some time later, after the features with most votes do not get taken, there is a revolt in comments (in the particular case of Visual Studio we were actually users so we were seeing this how you see our product, similarly having no clue why the hell the most upvoted features which we think make all sense in the world were nonetheless not being taken on and their status was not being clarified one way or the other) -> it all goes down in flames, talks stop, everything pauses for a couple of years and after that, a new voting site appears, to follow a similar story soon. Some of this could perhaps be fixed by better feedback, but it is hard to tell for sure if it really can, and seeing how initiatives like this can go gives us a pause at implementing them.

Still, as I said, we would like nothing more than having some measure of which asked-for features are more important and which are less important, even an imperfect one. We currently have our hands full and our feature landscape is filled pretty tightly with plans for at least the next several years. But we will keep thinking about it and maybe sometime in the future we will come with something that would allow posters to +1 requests and us to see those +1s and factor them into our decisions of what to do first and what to do second.

For now, we believe in email. :-) Yes, email is 20th century, but the key here is not the specific technology of submitting a feature request, the key is submitting something that has been thought through vs submitting a random thought. Having to prepare an email works as a filter. Although we agree, there are cons, too.

Thanks for an interesting post.

The current system seems pretty good to me. It does seem more effective if the "why" of the suggestion is well though out and articulated, but also if the timing is good. Knowing what you guys are working on through this new "beta" process has been good.

Maybe ask the community specifically what suggestions topics would be most helpful at a given time (occasionally has happened) would be useful. Sometimes that is obvious, like now with vector stuff, but perhaps there's other useful and timely input that could be given. Most stuff though will just need to be comments in reaction to latest builds.

I trust Mfd to do what is best to keep the lights on :-)

I like the Canny idea, too. The problem with email is that it seems like a black hole. If I send in a request to add metes and bounds, and someone else requests field notes, and someone else requests distance and direction, is that three votes for the same concept or is that one vote each for three different topics? Perhaps something like Canny could clear that up.

As for the metes and bounds topic, I understand what you're talking about. We've been talking about it for well over a year off and on and recently got revived. I believe M9 and the users had to mature to a point where it could be implemented. Sometimes an idea needs to sit on the back burner awhile before it can "suddenly" come to fruition. But on a slightly different topic, image manipulation, that went from concept to beta to production almost overnight several months ago. Really? Image manipulation in a GIS program?? Honestly I don't have a problem with the idea of shooting at targets of opportunity as long as the overall objective is not lost or forgotten.

If I send in a request to add metes and bounds, ...

The Suggestions page has a good discussion. If all you do is send in a suggestion "add metes and bounds" that doesn't do much, since nobody really knows what you want. In contrast, thoughtful, fully-articulated suggestions presented by users who have good skills in the thing being requested carry more weight.

As the page puts it: "For those suggestions that are contributed by only a few people the personal credibility and expertise of the suggester count for a lot. People who provide expert, complete and detailed suggestions win the credibility that makes it easier for product planners to commit more time to exploring the possible implementation of the suggestion, even if only one person has requested it."

Image manipulation in a GIS program??

Yes, of course. Look at all the image manipulation capabilities in 8. Much of modern GIS is all about image manipulation, from mosaicking lots of drone images to enhancing displays of terrain elevation, etc.

The current system for intake of suggestions works very well. When people really want something, wild horses cannot prevent them from speaking up about it, so there is automatically a mechanism that weights for the most important thing: priority. It's easy to think up thousands of small features and enhancements. No problem doing that. But what's important is to focus on priorities and also at the same time to balance those priorities against the opportunities and costs of "bang for the buck" implementation.

What I mean by the latter is that if there are ten features that are all very high priority to do, but one of the ten items takes as much time to implement as the next hundred features, it is often better to defer that tenth item and instead do another 99 features. So there's a balance between all that.

There is also the art of introducing totally new things that are not known to be possible and thus poorly harvested in "what do you want" polling. Henry Ford touched on that when he said "If I had asked people what they wanted they would have said 'a faster horse'."

Last but not least, there is a lot of value in getting priorities based on what people really find they need on a day to day basis, and not what they think "oh, that would be cool" based on a snap reaction to something read online. It takes virtually no effort to write and send in a one paragraph suggestion, but somehow the minor effort that requires achieves a filtering function that a reaction in social settings (like a forum) does not. You also tend to get more authentic expressions when voting is done in private, than when people feel peer pressure from "voting" in public. The Suggestions topic touches on that as well.

Perfect post, very balanced Dimitri, though for myself I would add two things.

First, I think there has been an unofficial shift or nudge over the past year or two, towards taking seriously suggestions made only here on the forum, as well as suggestions made more officially by email. I think that has been enormously welcome and a benefit. It is not as "clean", but it is good.

Secondly, echoing something Mike said above, I very much like it when Manifold occasionally sketches out where it plans to go, and asks for direct feedback on priorities. Roadmap <-> feedback.

I would like more of this second thing. Maybe two or three times a year would be good.

One reason is that it is obviously helpful for the product (assuming that users know something). Another is that it directly encourages the enthusiast community, helping us to all feel involved. It seems to me that both reasons are serious Manifold assets, and both things need looking after.

I have also really welcomed the shift towards discussion and in some cases being suggestions taken from the forum. Often this falls upon something that several people care about, stimulating discussion, helping to shape a request, a refinement or identifying opportunities for to extend infrastructure already in place.

Likewise any form of roadmap, even ones subject to change are also most welcome. Like most I suspect, there are particular features that I am hanging out for and having even a broad roadmap helps to identify when such features might appear and good times to think about lobbying.

While neither are as clean as a suggestion email, they are none the less, a great way to make this feel like a community effort and act as a mechanism for taking the pulse of the community at a time which is optimal from an engineering perspective.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

There is also the art of introducing totally new things that are not known to be possible and thus poorly harvested in "what do you want" polling. Henry Ford touched on that when he said "If I had asked people what they wanted they would have said 'a faster horse'."

A good example of this is Adam's post

On managing 1:X relations - we are planning to add a UI tool for transferring data between components without writing code. We might have some smarts in the Record pane to manage this, too - eg, we could allow you to specify in the Manifold 8-like manner that table X and table Y share a common key, and then when you are looking at a record from table X we could show you corresponding records from table Y and vice versa.

As far as I know this isn't done in any GIS, yet it would make this often dealt with issue so much easier to setup and then accessible to limited GIS users. Could be a real standout feature and one I hadn't thought to ask for.

Image manipulation in a GIS program??

GIS is different things to different people. Personally, I have no use for metes and bounds and am always hanging out for anything to do with LiDAR and image manipulation which form the bulk of my work. Having said this, I welcome both as they are equally important to a well rounded tool.

Landsystems Ltd ... Know your land | www.landsystems.co.nz

I was thinking in particular of the various image matrix filter effects and infrared color effects considered back in February. While I don't think of special image effects being necessary in a GIS package, I'm completely comfortable with the addition and discussion of the topics as M9 had matured that direction. It was just a surprise to see.

I would like to see more done with LiDAR as I happen to have data for most of my county. As Mike sort of said, I trust Manifold to get to when they get to it.

An update: we will probably slip a little with the build into Monday / Tuesday / Wednesday. We are integrating a big feature and several things need smoothing out. We also started a bug hunt in anticipation of the public build, to make it as clean as possible.