Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.169.8
adamw


10,447 post(s)
#13-Sep-19 16:48

9.0.169.8

Here is a new build.

manifold-9.0.169.8-x64.zip

SHA256: bd23fb2cb772b6cf24cd5b27fdf5e7d086f8c8c765d18eb1b509c48e83198896

manifold-viewer-9.0.169.8-x64.zip

SHA256: 2efe66a85a14b56c9625ba2bfd6abe1e204426a24a4b82952b62b61e010610a1

adamw


10,447 post(s)
#13-Sep-19 16:49

Changes

Map window disallows editing, picking and selecting records in hidden layers.

Map window displays focused pixel in a picked tile. Clicking a pixel in a picked tile moves focus to that pixel and scrolls it into view in the list of pixels in the Record pane.

(Fix) Map window no longer sometimes paints a "the picked record is too small" box around the corner of a picked tile if other corners are off-screen.

The Layers pane includes an option to display field type (instead of the default field width) for table fields in the dropdown menu on the filter button.

The Layers pane allows editing pick mode for map layers. The default is to allow picks. Alt-click in map window tries to pick a record from the active layer. Shift-Alt-click tries to pick a record from all layers that allow picks, preferring layers that are higher in the display stack.

Alt-click in map window is reworked to never clear the cursor mode. Using Alt-click in the default cursor mode picks records. Using Alt-click in other cursor modes (eg, tracker) works like click would, the Alt modifier is ignored.

Alt-clicking a record that is already picked in map window no longer re-picks the record, abandoning all changes made to it. Alt-clicking a stack of records keeps the picked record if it is in the stack.

Ctrl-click and Ctrl-drag in map window are reworked to never clear the cursor mode or the edited record. Using Ctrl-click and Ctrl-drag in the default cursor mode with no edited record selects records. Using Ctrl-click or Ctrl-drag with an edited record with editable geometry selects coordinates.

Selecting records using Ctrl-drag in map window no longer slightly extends the selection box to make the single pixel box work as Ctrl-click would. Instead, Ctrl-click continues to select data within some distance of the click, but Ctrl-drag is allowed to make the selection box as thin as possible (the window only starts tracking the box if the cursor is dragged far enough from the initial click point).

Clicking a coordinate or pixel of a picked record in map window switches the Record pane to the Coordinates / Pixels tab if it is not already in that tab. Clicking some distance away from all coordinates or pixels switches the Record pane to the Values tab. (This allows starting or stopping the process of editing coordinates of a picked record: Alt-click a record to pick it, click a coordinate handle to make coordinate handles writable, do some editing, click "far" away from the record to make coordinate handles read-only again or take a peek at the field values, etc.)

Clicking a segment of a picked record in map window sets the focus coordinate to the beginning of the segment.

The context menu for an edited record in map window no longer includes commands to commit or cancel changes if the record is read-only.

Editing geometry in map window allows switching the edit mode between Insert Coordinates (keyboard shortcut: I) and Move Coordinates (M) using the context menu. (The Insert key formerly used to create / move / delete the insert point in the map window or in the list of coordinates in the Record pane, which behaved somewhat similarly to the new edit modes, no longer works.)

New edit mode in map window: Move Coordinates + Split (P). While in this mode, clicking a coordinate handle sets focus to that coordinate, clicking a segment inserts a new coordinate at the clicked location and sets focus to that coordinate, dragging a focused coordinate handle moves that coordinate (plus other selected coordinates if the dragged coordinate is selected, or all coordinates if the Shift key is pressed - similar to Move Coordinates).

Editing line or area geometry in map window adds new commands that work with branches to the context menu: Begin New Branch, Continue Last Branch (shown if there is an unfinished branch), End Current Branch (shown if there is an unfinished branch that is currently being added to).

Clicking a segment of an edited line or area in map window allows changing the segment type using new commands in the context menu: Convert to Line, Convert to Circle, Convert to Ellipse, Convert to Spline. (To convert a curve segment back to a line one currently has to right-click a coordinate handle for one of the curve control points, right-clicking the curve itself does not work.)

The Layers pane allows editing snap mode for map layers. The default is to allow snaps. Editing geometry in map window allows switching between snapping to the active layer and snapping to all eligible layers (A, the default is to snap to the active layer), as well as toggling snap on and off (Space) using the context menu.

Editing geometry in map window allows snapping while dragging coordinates. Keyboard shortcuts for snap modes work during dragging as well.

New snap mode in map window: Snap to Grid (G). There is a new Snap Parameters command (found in the main menu, in the toolbar selector for the cursor mode, and in the context menu for an edited record) that allows specifying grid size and grid unit (the default grid step is 10x10 units of the coordinate system). Snap parameters can be edited outside of an editing session. (We do not currently save snap parameters to component properties, but we likely will.)

New snap mode in map window: Snap to Bearing (B). The Snap Parameters command allows specifying the number of bearing divisions (the default is 4, which means that there are 4 fixed directions: 0, 90, 180, 270 degrees, this is frequently called "ortho mode" where only horizontals or verticals are allowed).

Editing geometry of an existing record in map window no longer snaps to the old version of the geometry. Instead, editing snaps to the edited coordinates. Snapping to coordinates of an edited object uses a smaller snap distance than snapping to coordinates of other objects (50 pixels instead of 150) and is disabled if the edited object is a point. (This is done to help avoid creating empty segments and walkbacks.)

The Table.SearchBatchRTreeThin method in the object model accepts a new boolean parameter to return data either touching or completely within the search rectangle.

There is a new dataport for JSON data that is not GeoJSON. Top-level structures in JSON data that look like lists of records are exposed as tables. Other top-level structures are exposed as comments. *.JSON files are remapped from GeoJSON to JSON.

There is a new dataport for web JSON data.

Web CSV / JSON / GeoJSON dataports allow refreshing tables to re-read them from the web.

(Fix) CSV dataport correctly parses data that uses a whitespace character as the field delimiter.

Web CSV dataport uses a more sophisticated content type check (blacklist instead of whitelist) to allow custom content types.

Oracle dataport optimizes bulk reads. (Reading big tables in 9 should be at least on par with 8.)

GDB dataport supports storing MFD_META properties inside the geodatabase. This allows overriding coordinate systems, setting up styles, etc.

GDB dataport allows creating (also renaming and deleting) components of all types, storing component definitions inside the geodatabase.

GDAL dataport supports GDAL 2.3, 2.4, 3.0.

MySQL dataport no longer creates virtual drawings for tables with geometry fields.

GPKG dataport provides its own versions of spatial functions required to enable writes to spatial indexes when SpatiaLite or similar extensions that normally provide these functions cannot be loaded. This allows operating GPKG databases in full read-write mode with just SQLITE3.DLL.

LAS / LAZ dataport optimizes spatial queries to perform significantly faster (4x or so).

LAS / LAZ dataport uses significantly less memory when creating spatial indexes.

Dataports for databases allow tables to have virtual computed fields. This allows having, say, a field with virtual geoms composed from X and Y values stored in the database. Computed fields on databases cannot refer to other computed fields and cannot participate in indexes.

Web image server dataport uses new URLs for Yandex maps.

There is a new dataport for PDS files. (Currently we support tables and images.) *.XML files are mapped to PDS. (*.XML files were not mapped to any particular dataport before even though many formats use them. There is no better extension to map to PDS, however, so we are going to map *.XML to PDS first and remap to other dataports later as part of automatic detection where it will make sense to do so.)

The API doc has been updated to include latest changes to the object model. Topics for several existing calls have been extended. There is a new VBScript example for ValueSet.CreateLocked (mostly provided for completeness because the performance gain from using ValueSet.CreateLocked for VBScript is minimal).

End of list.

Mike Pelletier

2,122 post(s)
#13-Sep-19 21:24

Lot's of nice improvements. Appreciate the new Move + Split tool. Couple thoughts.

1. Need a way when editing a line to start adding vertices at the end of the line. Currently pressing Insert starts a new branch. Maybe clicking the bottom of the coordinate table could start this mode.

2. Would very much appreciate having the backspace work like in Mfd 8 while drawing a feature.

3. It will be nice to trace objects faster with the arc tools. Perhaps add a tool that afterwards allows converting it to straight segments with a specified distance for each segment.

4. Going along with metes and bounds discussion from earlier threads and whether it should be a separate add-in. Perhaps allow a user to toggle between the list of coordinates and a new distance/bearing view for each segment. Provide a means to toggle between various distance formats, basis of bearings, and survey adjustment factors. Eventually adding tools to close a line into an area per common survey methods. This would give users the valuable ability see/edit each segment in real time. This tool is needed for general CAD style work and adding a few extra tools makes it ready for survey work. Perhaps importing of traverses from files would be a good add-in example.

Thanks!

adamw


10,447 post(s)
#16-Sep-19 15:16

1 - You can currently extend an existing branch by right-clicking the segment you want to extend it from then entering the coordinates that you want and deleting the previous final coordinate. We agree this could be made better though and are considering two options. First, we might do a command like Continue Branch which would appear on the end of a line branch - this would take the branch, possibly reverse it, make it the last branch, unclose it and start adding coordinates (we realize this might seem like redundant detail, but we think being able to work with coordinates as a list is useful - for metes and bounds, for copy / paste, etc - this is why we are mucking around with this first-last branch and the coordinate order). Alternatively, we might let you enter a new branch starting where the previous branch ended and then do a command like Join Branches to take two branches and join them together. Didn't decide yet.

2 - We will consider adding Backspace to take back the last inserted coordinate like in 8, yes.

3 - We already have the Linearize transform that converts curves to straight line segments. Do you mean something like a Linearize command that would appear in the context menu for a curve segment and linearize just that segment? The linearize distance could be determined from the current zoom level.

4 - Doing metes and bounds as a mode in the list of coordinates in the Record pane is one of the options we are considering, yes. Regarding importing traverses from files, any examples would be helpful (we understand a lot of this is fairly freeform text with a separate line per each coordinate but not much structure beyond that, but still, examples would be helpful).

Mike Pelletier

2,122 post(s)
#16-Sep-19 16:12

1. The Continue Branch command option sounds best. QGIS has a little + sign at the end of the line. Click it and your off extending the line. Seems to work well.

3. This is low priority but it might be nice to quickly trace an object in an aerial with an arc and then linearize that segment at some defined level before moving on. That way it doesn't get linearized later at a some crude scale that doesn't have the right amount of coordinates.

4. I'll send some examples to Tech.

Thanks.

dchall8
1,008 post(s)
#17-Sep-19 15:19

4 - Doing metes and bounds as a mode in the list of coordinates in the Record pane is one of the options we are considering, yes. Regarding importing traverses from files, any examples would be helpful (we understand a lot of this is fairly freeform text with a separate line per each coordinate but not much structure beyond that, but still, examples would be helpful).

Curves are the only issue I have with the current add-in to Manifold. I have two examples showing how curve data comes to me. One is from a plat map of a subdivision. I frequently redraw subdivisions, because it seems my predecessors were in a hurry the first time. They didn't get the straight lines right, and the curves are only roughed in. The attached drawing identifies curves by number which have to be looked up in a table on another page. I pasted the curve table into the drawing to make it easier. For a concave curve typically I will go to the curve, take the radius, draw a circle of that radius (transform Spline 6), move it into position, and transfer Clip with Subtract to remove the circle from the parcel. For a convex curve I will create the circle in the parcel layer, move it into position, and transform Union into the parcel.

The second example is from field notes in a deed. In this case the chord direction and length were not specified. If there is chord data, I use that. In this case I leave an "open jaw" in the drawing and fare the shape of the parcel according to imagery. I'm also attaching the txt file for this example.

Attachments:
5.466 acres to Hensley.txt
BANDERA RIVER RANCH U 1 42 D w curve data.jpg
Vol 484 pg 810_Page_6.jpg

adamw


10,447 post(s)
#17-Sep-19 16:36

Thanks, this helps.

tjhb
10,094 post(s)
#14-Sep-19 01:01

So much to explore here. I would love to see the acres of whiteboard behind this build! Yikes.

My favourite thing so far is the way we can inspect individual pixel values interactively. Very intuitive and informative.

A comment to one of Mike's comments:

3. It will be nice to trace objects faster with the arc tools. Perhaps add a tool that afterwards allows converting it to straight segments with a specified distance for each segment.

How about if the Segmentize transform (and the GeomSegmentize function) could be made to step along curved segments (circular and ellipsoidal arcs, splines), converting them to multiple straight segments divided at the segmentization distance along the curve? (Currently each curved segment is replaced with a single straight segment.)

Related: I wonder whether the I (Insert) and P (Move Coordinates + Split) drawing modes could allow adding coordinates along curved segments as well as along straight segments. I'm not sure if that would always be feasible with splines and elliptical segments while maintaining their current shape.

These comments are anyway premature since I have been tinkering with the new featres for such a short time. They are motivated by enthusiasm, certainly not frustration. Everything seems to work really well and feels easy to learn.

KlausDE

6,410 post(s)
#14-Sep-19 07:08

Somewhere along the way the DWG importer learned to import splines as splines

In Mfd8 the importer transformed curves to straight segments. That code could probably become a part of the Segmentize function.


Do you really want to ruin economy only to save the planet?

Dimitri


7,413 post(s)
#14-Sep-19 07:37

Enthusiasm is good. :-)

I think of this build as a foundation build, that sets up infrastructure that many additional interactive tools can utilize. For example, snaps are used everywhere, and they have to be functional everywhere, regardless of how many layers, what types of objects, whether there are curved or linear segments in play, etc.

Snaps are surprisingly complex when you can have many (dozens or hundreds) of layers, when layers can come in from external sources, and can change constantly based on other processes and threads, and when layers can have billions of objects and be in different projections. So if you want to draw a line in ortho mode and snap to where the extension of the line intersects with some object (possibly between vertices and not just to a vertex) in another layer, all that has to be reckoned correctly, and done without reducing performance.

With this build we get a major increase in the functionality of interactive editing, just as it is, and we get a solid foundation to add endless more editing tools, like drawing specific shapes, automatic filling in, cuts and trims of various kinds, metes and bounds, well, pretty much anything one can think of. So we can all think big. :-)

KlausDE

6,410 post(s)
#14-Sep-19 09:00

A very useful additional editing tool would be to modify the bearing snap turned on during editing to use the bearing of the last segment as reference for a relative bearing snap.

Analogical a function to toggel curved mode while editing a branch should use the bearing of the last segment for the starting bearing of the curve when bearing snap is turned on.

Orthogonal oriented bearing snap is fine to start interactive editing of a new branch (or geom?).


Do you really want to ruin economy only to save the planet?

geozap
264 post(s)
#16-Sep-19 05:17

Analogical a function to toggel curved mode while editing a branch should use the bearing of the last segment for the starting bearing of the curve when bearing snap is turned on.

Would be very useful when doing on-screen digitizing of entities known to have perpendicular sides, such as most buildings.

adamw


10,447 post(s)
#16-Sep-19 15:40

Thanks - we'll consider both a snap mode for "relative bearing" and a similar adjustment to Convert to Circle / Ellipse / Spline commands.

adamw


10,447 post(s)
#16-Sep-19 15:34

Regarding GeomSegmentize stepping through curves - you can do GeomLinearize first and GeomSegmentize second.

Regarding adding coordinates into curves - we will add means to add coordinates to splines, but probably not to circles and ellipses for the moment. Unlike with splines where you can click a control point, splitting circles and ellipses requires clicking curves directly, and this is fairly involved, particularly with projections - in a nutshell, it is pretty hard to click a curve exactly, you end up clicking a location that is close to it, this "close" could be ambiguous and the segment might get split not at the expected location - this is all solvable, we just don't think this is the right thing to concentrate on right now.

tjhb
10,094 post(s)
#16-Sep-19 17:55

Regarding GeomLinearize then GeomSegmentize--aha! I hadn't thought of that. Will try it tomorrow. (Maybe there is still room for building it in with one transform? Don't know yet.) [And I see you and Mike have covered this better above.]

On coordinates onto curves--that makes sense, especially given translation of projections. It could create more frustration than utility for now.

Thanks.

dchall8
1,008 post(s)
#16-Sep-19 16:54

So much to explore here. I would love to see the acres of whiteboard behind this build! Yikes.

I'm glad I'm not the guy updating the documentation and videos. At first glance this seems like paradigm shift after paradigm shift. I need to dig in.

rk
621 post(s)
#14-Sep-19 09:04

Here is the estonian ui file for 9.0.169.8

Please include this in ui.zip download file also.

Attachments:
ui.et.txt

Dimitri


7,413 post(s)
#14-Sep-19 12:27

Done! Thanks Riivo!

rk
621 post(s)
#20-Sep-19 09:03

One more thing. On the flags list should be ee.png. currently there is Ethiopian flag with title Estonia.

<img src="/images/flags/24x24/et.png" title="Estonia">

geozap
264 post(s)
#15-Sep-19 16:07

An important step forward in this version.

Regarding snaps I thing manifold should give the option to have several snap modes on simultaneously, rather that having to chose one of them. I mean on should have the option to snap on coordinates and grid, instead of having to chose coordinates or grid (or bearing). Of course more options should be available for snapping. I think "snap to nearest", "snap to perpendicular", "snap to line segment midpoint" and "snap to intersection" will cover most needs.

I would prefer snaps to be changed by toggle buttons somewhere in the main interface, instead of the right click pop up menu. In this way the active snap modes will be constantly visible to the user.

Also the user should have the option to temporary override the current snapping options. Like in Autocad for example, one might have snap to centre and snap to perpendicular "permanently" on, but also can chose to snap to nearest for just one click, and then automatically return to the "permanent" snaps. This is done in Autocad by using the command line, while manifold could use a keyboard combination.

Grid visibility (not currently available) and snapping should be a component property, as mentioned as a likely option in Adam's post.

As a general comment I thing manifold could do fine in this area by just copping what common CAD software do.

Dimitri


7,413 post(s)
#15-Sep-19 19:51

Great comments.... I agree 100%

Also the user should have the option to temporary override the current snapping options.

That's in there: the spacebar toggles snap off/on.

geozap
264 post(s)
#16-Sep-19 05:14

Spacebar toggles on all snaps off/on. What I am talking about is having some snap modes on while drawing a entity, then use a specific snap type to draw a single coordinate as needed, and then, after having used the temporary snap override, return automatically to the previous snapping state. AutoCAD (and its Intellicad clones) and Bentley products have this option, I suppose other CADs too.

adamw


10,447 post(s)
#16-Sep-19 16:15

Regarding snaps - we were considering adding more modes. Some of the modes you mention fit well into what we have, others less so. Snap to intersection (of two other geoms) is perhaps better done in the context of GIS as normalize topology -> snap normally. There might be many situations where there are multiple intersection points near each other that are best collapsed into one, etc, etc, etc, it makes sense to resolve things like that separately. Snap to nearest (location on a geom under the cursor) is fine, but it requires keeping potentially a lot of data to perform a snap, GIS geoms can be very complex. We'll probably take some time to think about what we can do here. Other two modes are no problem, we'll consider adding them.

Regarding having multiple snap modes on - we will think about allowing that, but in general snap modes frequently don't mix and contradict each other. Eg, if you are snapping to bearing, there is little chance you can also snap to grid or to coordinates, it is rare when both snap modes will be satisfied, one of them will have to win. We agree it makes sense to combine grid with coordinates though and we aren't against combinations which make sense, so perhaps that should be allowed.

We'll think about making the current snap mode visible to the user. The challenge is that the snap mode can be a combination of settings, a single icon is not enough *and* we don't really want to spend a toolbar on it (we have plenty of other things to add to the toolbar, have to keep things tidy). We'll try to come up with something.

We'll probably allow showing the snap grid via an option. (And we'll save snap parameters into component properties.)

We aren't sure about having a temporary override for snap - we realize CAD packages do this, but it currently seems like an overkill to us. Instead of setting up a snap mode that is so complex, you don't want to re-set up it again after you temporarily switch to some other snap mode, and want to "go back" to it because going back is just a single key, we'd rather keep snap modes simple or somehow smart so that you can switch back with a single key directly.

tjhb
10,094 post(s)
#16-Sep-19 18:13

My thoughts for what they are worth:

In the GIS context, especially where we can have multiple layers with different projections, geometry over imagery, and above all topology, I think reliability of snaps is much more important than infinite flexibility. They should always work, always exactly. No tiny slivers or gaps, no fixing afterwards. (That is hours and hours of time.) Simple and reliable is best.

Regarding individual toggling of snap modes, I think single keyboard characters for toggles are very fine, and one mode at a time is also fine, perhaps even better than multiply-active snaps. What matters is fine-grained exact control, during actual drawing. Beyond that, there is no point in adding "flexibility" if it amounts to snapping that is arbitrary, or letting the user continue without first deciding what s/he means exactly to do, or adding opportunities for very fine mistakes.

Mike Pelletier

2,122 post(s)
#16-Sep-19 18:32

Very good points Tim. I'll just add that snapping to locations along a segment is important and it would be nice to toggle that somehow fast like the spacebar does now for turning snapping on/off.

Not sure if this thought is worthwhile, but what if the snapping distance could be adjusted on the fly. Something like pressing S and a colored haze goes up around the active coordinate showing the distance and a text box appears nearby with the current distance. Type into the box to change it or press up/down arrows.

When a feature(s) rotation tool gets added, it would be nice if it worked similarly with a rotation handle for dragging the amount of rotation and a nearby text box that shows the current angle as it gets dragged and allows typing the angle as well.

dchall8
1,008 post(s)
#18-Sep-19 21:51

Another change, which may have happened in an earlier version, but I just noticed it...

Alt-Click on a docked tab used to undock the tab. Now it's Shift-Click on the tab. The fine manual has been updated.

KlausDE

6,410 post(s)
#13-Sep-19 23:20

Here is the german ui file for 9.0.168.8 - missing parameters now checked.

Attachments:
ui.de.txt


Do you really want to ruin economy only to save the planet?

Dimitri


7,413 post(s)
#14-Sep-19 07:07

Thank you, Klaus!

BerndD

162 post(s)
#14-Sep-19 07:29

Thanks, Klaus!

Can't beat the response time of that language patch.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

KlausDE

6,410 post(s)
#14-Sep-19 08:39

When you stay tuned it takes not long to added the additions for every new build. It's more of a side effect while following Adams annotations of new features.


Do you really want to ruin economy only to save the planet?

BerndD

162 post(s)
#14-Sep-19 16:08

Well, we all know the true value of your work and it's highly appreciated.

Thanks again.


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

adamw


10,447 post(s)
#16-Sep-19 14:53

A couple of additional notes on the build before I start replying to posts:

As you might have noticed, many of the editing tools have keyboard shortcuts. Hint 1: in case you ever forget the key for a specific tool, you can always refresh your memory by invoking the context menu. Hint 2: if you temporarily switch away into a different window, eg, if you go to inspect some values in the Values tab in the Record pane, and then want to switch back into the map window where you are editing your geometry, this also can be done using right click. Depending on what editing mode you are in, left click can add some coordinates, but right click is guaranteed to not alter edited geometry in any way and just bring up the context menu *and* move focus to the clicked window so that it accepts keyboard shortcuts again.

As mentioned above, clicking on a segment sets the focus coordinate to the beginning of that segment. What isn't mentioned above is that this allows you to right click a segment, select Insert Coordinates and this will start inserting coordinates and form a chain of segments replacing the segment that you clicked. This is a good way to add more detail to a line or area - click the segment you think should be replaced with a more detailed chain, select Insert Coordinates and on you go. Another thing - if you try Insert Coordinates on a curve segment, the first entered coordinate will remove the curve.

A word on snaps and coordinate systems - snaps are done in the coordinate systems of the map. Or, if the window was opened on a drawing / image / labels component, in the coordinate system of that component, because the virtual map created for that component uses that coordinate system. What this means is that if the coordinate systems of the edited drawing and the map are different, then snap will snap to a location that is closer to the cursor in the coordinate system of the map - and that might not be the closest location to the cursor in the coordinate system of the drawing. Since we are talking about a visual tool anyway and you can see what happens on the screen, the distinction is normally nothing to worry about, but it is worth having in mind when the drawing is in, say, transverse Mercator, the map is in Mercator, and the editing is done far from the central meridian so the distortions are high - in such cases it is perhaps best to switch the map to transverse Mercator as well to do the editing there.

The default grid unit is the unit used by the coordinate system without local scales applied. That is, if the coordinate system of the drawing / map uses 50x50 meters, the default grid unit is a single meter and the default grid is 10x10 meters.

Separate snap distance for snapping to coordinates of an edited object is an experiment and we are not sure we are going to keep it. We made it separate because it felt that the default snap distance was too much for self-snapping, but having lived with it for some time we start thinking that maybe we should just decrease the default snap distance. We are going to allow setting snap distance explicitly in Tools - Options and maybe we'll have just one distance instead of two.

Snap reaction to layers with lots of data is to not snap to coordinates until all potential snap locations are known. We tried variants where snap would start working on partial data way before all snap locations are known, but this did not work all too well in that the snap reticule would be jumping somewhat erratically as better snap locations are discovered and in the end we found that we just wait until the jumps stop and the snap reticule would change its color from the light shade of "I am still retrieving data" to the darker share of "I am done". So, now we just don't snap at all until all snap locations are known and then we jump once. This has an obvious drawback in that if you zoom to a new view which contains a lot of snappable data, it might take some time for snap to begin working. When this happens, (a) check whether you are snapping to the active layer or to all snappable layers and if you don't need to snap to all snappable layers, snap just to the active layer, and (b) if you do need to snap to more than just the active layer, consider reducing the number of layers you are snapping to - particularly those that are big or on slow data sources - you can do this by making layers unsnappable in the Layers pane or by just turning them off temporarily.

Finally, a word on curves and their control points. Circle arcs are the simplest - a circle arc has a single control point which, together with the start and end of the arc define both the circle and the arc. Splines are second simplest - spline arcs created by interactive editing tools use one or more control points, the spline does not run through these control points but it runs somewhat towards them, the control points define tangents. Ellipse arcs are the most cryptic - there are three control points and they are all different. The first control point chooses the side of the ellipse the arc is on. The second control point is the center of the ellipse. The third control point defines the orientation and one of the axes of the ellipse (the other one is defined by the start and end of the arc). Three control points plus start and end is too many numbers to define an ellipse arc, so some of these numbers might not agree with each other, our way of resolving ambiguities is to trust the control points and adjust the first and final segment of the arc to bend and meet the start and end coordinates if they are not on the ellipse defined by the control points.

On to the replies.

geozap
264 post(s)
#17-Sep-19 08:51

I found out that the new vector editing functions work on tracker too, something that is very nice. Although you can add curved segments (circles etc) to tracker, their length is not summed to length. I suppose curved length adding is not implemented yet, rather than a bug.

adamw


10,447 post(s)
#17-Sep-19 16:53

We noticed this too late to fix for this particular build, so it got added into a queue for the next build (the one we are doing now). :-/

We will either disable curves for the tracker tool (while keeping everything else enabled for it), or linearize them on the fly to some scale that does not depend on the current zoom level.

Ian
268 post(s)
#20-Sep-19 04:50

Is it possible to have the same snapping option as in M8 when you hold down the Alt key and it will trace around an area or along a line. I find this really useful.

adamw


10,447 post(s)
#23-Sep-19 16:22

We have that on the wishlist, yes.

gjsa100 post(s)
#26-Sep-19 06:09

Anyone else getting "Operation Failed" when exporting a map as a gpkg using 9.0.169.8 ?

Have installed all the spatialite dlls, so it should just work as it does in the previous Edge version.

adamw


10,447 post(s)
#26-Sep-19 07:37

We have a known (in that we already identified it) issue in the export to GPKG, yes. Apologies. We will fix it in the next build. In the meantime, try exporting using 169.7.

adamw


10,447 post(s)
#26-Sep-19 09:18

A word on the next build - we are planning to issue it next week, as early as possible. We are going to have various additions and improvements to vector editing, plus the usual fixes, plus possibly a bunch of new analysis functions.

adamw


10,447 post(s)
#03-Oct-19 14:48

Status update: we are adding a lot of small features related to vector editing and will likely slip one-two days into the next week.

As part of this build we also moved to a newer major version of the compiler + platform SDK, which feels great. There were a few compatibility issues, but not many, and they all are already fixed. In return we got more code optimizations, better build times, etc.

We have also been preparing for machines with high numbers of cores. Writing multi-threaded code for 8-12 threads is different from writing multi-threaded code for 20-100 threads, getting the best out of each type of configuration comes with practice. As CPU prices fall and CPUs with 24 (48) or 32 (64) cores become more affordable, we are now writing our code to scale to both 8-12 and 20-100 cases. Better scaling for high numbers of cores will first come to new analysis functions that we write, and after some time we will adjust existing analysis functions to use similar techniques.

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