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


9,283 post(s)
#12-Apr-20 16:45

9.0.171.3

Here is a new build. It contains a lot of small bits and pieces of mainly vector-related functionality which we either needed for bigger things that are in the works, such as registration, or wanted to add for a long time. Works on vector to raster joins are close to completion, we'll likely see the results in the next build. (And in the build after that we hope to have a first version of registration.)

manifold-9.0.171.3-x64.zip

SHA256: 470fcec9de58b1bfff5e427ffb154c07df6730750664479857cfb3a09b21bab0

manifold-viewer-9.0.171.3-x64.zip

SHA256: b97eee50f321d2a45bc3228369ccac018d784b7b199b0e4d19f7c9ae7cfb22d3

adamw


9,283 post(s)
#12-Apr-20 16:47

Functions and Templates

There is a new GeomScaleCentered query function that scales a geom around the specified center location. The Scale transform template is adjusted to use that function and scale around the centroid.

There is a new GeomShift query function which calls GeomScaleShift with scales equal to 1, only applying a shift. There is a new GeomScale query function which calls GeomScaleShift with shifts equal to zero, only applying a scale. There is also a new GeomScaleRev function which calls GeomScaleShift with scales equal to 1/scale, unscaling the geom scaled with a previous call to GeomScale back.

There is a new GeomFlip query function that flips a geom horizontally and / or vertically, and a new Flip transform template that calls it.

The GeomFlip / GeomRotate / GeomScale / GeomScaleRev / GeomScaleCentered / GeomScaleShift / GeomShift functions preserve curves in 2d geoms and preserve Z values but not curves for 3d geoms. Caveat: attempting to apply uneven XY scales to a circular arc will currently not convert it to an ellipse arc, and will instead compose a new circular arc that passes the scaled ends and the scaled control point. We are planning to address that in the future (with a slight rework of curves in geoms).

There is a new GeomReverseLine query function that reverses a line, and a new Reverse Line transform template that calls it. Reversing a line preserves curves and Z values.

There is a new GeomIsLineClosed query function that reports whether each branch of a line geom is closed (has the starting coordinate equal to the ending coordinate), and a new Lines, Closed select / transform template that calls it.

There is a new ComponentCoordSystemAutoXY query function that returns the coordinate system for a component and forces the coordinate system for an image to use XY axes. This reflects the fact that for an image, because it is stored in a special way, the axes of a coordinate system are ignored and are always interpreted as XY / XYH, and allows passing the returned coordinate system without any further modifications to the coordinate converter object. Queries generated by the UI tools have been modified to use the new function instead of ComponentCoordSystem.

The CoordConvertTile query function allows specifying interpolation type: 0 = nearest neighbor (the only former option), 1 = bilinear, 2 = bicubic. If the interpolation type is set to a negative value (auto), the function will use nearest neighbor, for compatibility with previous builds and due to the principle of least surprise.

The CoordConvertTileSet / Par query functions are renamed to CoordConvertTileSetDirect / Par. There are new CoordConvertTileSet / Par query functions that use the standard projection method, allow specifying interpolation type and return the projected image as a table. The result tables returned by the CoordConvertTileSetXxx functions (all four) support a BTREE index on XY fields, which allows efficiently using them in a join directly without having to copy the returned data into a different table.

(A tech note on performance of query functions for projecting images: for the standard projection method there are thus two ways to perform the projection with multiple threads - either use CoordConvertTile in a SELECT with THREADS, or use CoordConvertTileSetPar. The CoordConvertTileSetPar should generally be able to arbitrate threads better. If the result of the projection will be used as a temporary table in a join, the use of CoordConvertTileSetPar is thus preferable. However, if the result of the projection will simply be used to populate a persistent table, it is better to use CoordConvertTile because this will avoid creating a copy of the projected image in memory.)

There is a new GeomCoordLine query function that takes a line and a distance and returns the coordinate on a line at the specified distance from its start. The function considers all line branches - if the first branch ends before the specified distance, the function moves on to check the second branch and so on, until the distance is reached. If the distance is negative or bigger than the total length of all line branches, the function returns a NULL value. There is a new Line Coordinate transform template (available when used on a field of x2 type, we'll perhaps rework it so that it should be used with a geom field instead) that uses the function.

There is a new GeomToCoordsLineSequence query function that takes a line and returns a sequence of coordinates at the specified distances on a line. The distances are specified as begin distance, end distance and step, similarly to ValueSequence. The step can be positive or negative. (Eg, for begin = 0, end = 5, step = 1, the function will return coordinates at 0, 1, 2, 3, 4, 5, and for begin = 5, end = 0, step = -1, the function will return coordinates at 5, 4, 3, 2, 1, 0.) One or both of begin / end can be outside of the line. (Eg, for begin = -2, end = 50, step = 10, the function will return coordinates at 8, 18, 28, 38, 48.) The coordinates are returned as a table with two fields: distance from the start (Value) and coordinate (XY). There is a new Decompose to Line Coordinates transform template that uses the function.

There is a new CoordSystemScaleXYToUnit query function which takes a coordinate system and a unit name and returns the XY scale required to scale the geom in the coordinate system to the specified unit. If the specified coordinate system and unit are incompatible (eg, the coordinate system is metric, but the unit name is 'degree'), the function returns a NULL value.

(The idea behind CoordSystemScaleXYToUnit is to use it together with GeomScale / GeomScaleRev instead of more complex coordinate converter functions, to perform measurements in the desired units when the math required is minimal. Eg, if you want to find a location on a line 2 miles from the start of the line, you could call CoordSystemScaleXYToUnit and pass 'mi' to get the scale required to convert the line coordinates into miles, call GeomScale with that scale on a line, call GeomCoordLine and pass 2 as a distance, then convert the returned x2 value to a geom using GeomMakePoint, and finally call GeomScaleRev with the exact same scale as before to convert the created geom to the coordinate system of the line.)

Other

(Fix) The TileGeomXxx query functions used in the Join dialog for raster to vector joins no longer fail to produce values for some of the lines.

Trying to use a transform that needs to know the bounds of a map layer on a layer based on a query that does not know them auto-computes the bounds (instead of silently failing).

The Join dialog copies tile reduce / tile size / tile type properties for newly created tile fields.

The Reproject Component dialog for an image allows specifying interpolation type: nearest neighbor (the only former option), bilinear (the default since this build), bicubic.

End of list.

antoniocarlos

538 post(s)
#12-Apr-20 17:43

I get this note from MS Defender trying to install (copy and paste the latest zip) the latest version. It is probably an false negative but I want to make sure.

Attachments:
Capture.JPG


How soon?

Dimitri

6,064 post(s)
#12-Apr-20 18:35

False positive (Wrongly says there is a problem.) I have the latest Defender updates and didn't get that.

adamw


9,283 post(s)
#13-Apr-20 12:21

Whenever this happens, verify the SHA256 checksum. If the checksum matches, you can be sure that the file you downloaded is the one we published = the file created by the build process, safe to use.

False positives are, unfortunately, fairly frequent. The root cause of this is (a) all malware detection tools are using heuristics as part of their analysis, these heuristics cannot be accurate 100% of the time. This then gets exacerbated by (b) there are many different malware detection tools, each with their own set of heuristics. The original proposed way of dealing with false positives is for someone to declare that a particular detection is a false positive - except this does not really work for anyone because there are many different vendors each with their own reporting mechanisms, with processing delays, and because there are typically hundreds to thousands of files being released per year (if you count all EXE / DLL files, we are releasing ~40 files each build, with the vast majority having different signatures from earlier versions). What works is the reverse - if a particular tool flags, eg, WINWORD.EXE (Microsoft Word) as being dangerous, the vendor of that tool adds an exception to their database with no action from Microsoft required. But you have to be Microsoft or Google to enjoy that.

Windows Defender used to have very few false positives, but this seems to have changed in the past year or so. In particular, in many cases it may flag a ZIP or a different type of an archive but then if you try to check which exact files in the archive are problematic, it will report that all of the files are completely safe. So, the archive reportedly has a problem, but none of the files in it do. That for sure seems to be an error and unfortunately this has yet to be fixed.

vincent

1,913 post(s)
#13-Apr-20 15:40

There is a new GeomCoordLine query function that takes a line and a distance and returns the coordinate on a line at the specified distance from its start.

Great ! I'll put it to work this week and report on time versus 8 for similar query when running for hours.

adamw


9,283 post(s)
#13-Apr-20 16:11

If you want the best performance, use GeomToCoordsLineSequence instead of many calls to GeomCoordLine with the same geom but different distances. It returns a table, which makes it slightly more complex to use, but you save a lot of unnecessary computations.

vincent

1,913 post(s)
#15-Apr-20 03:46

For my knowledge, is there any other syntax to use it than this ? :

SELECT * into [NewTable]

 FROM (

    SELECT SPLIT

      CALL GeomToCoordsLineSequence([Geom], 0, [Shape_Leng], 1)

    FROM [rivers])

BTW, is there any intrinsic Length field in 9 ?

And any way to auto-complete component name of field while composing query, like in 8 ?

Thank you.

Dimitri

6,064 post(s)
#15-Apr-20 07:06

BTW, is there any intrinsic Length field in 9 ?

Yes, that's done with computed fields in 9. See the Computed Fields topic, at the end (don't forget to read also the Euclidean and Geodetic sections) for 9 equivalents, or better, of Release 8 intrinsic fields.

And any way to auto-complete component name of field while composing query, like in 8 ?

Yes, but I think in a better way than 8. See the Query Builder topic. Drag and drop the drawing or table of interest into the lower right, Tables, pane, and then you can simply double-click a component name or field name to add it to the query. Saves a lot of keyboarding.

adamw


9,283 post(s)
#15-Apr-20 15:06

For my knowledge, is there any other syntax to use it than this ?

For SPLIT, yes, you can do this, for example (model code, not tested):

--SQL9

SELECT [mfd_id][rivername],

  SPLIT CALL GeomToCoordsLineSequence([geom], 0, 1000000, 1)

FROM [rivers];

This creates a table with multiple records per line: one for each coordinate in the sequence of line coordinates.

You can replace the big number I used for the end of the sequence with GeomLength([geom]) to cover lines longer than a million units.

You can also nest splits: SELECT ... SPLIT CALL <split1>, SPLIT CALL <split2> ... .

vincent

1,913 post(s)
#15-Apr-20 13:35

GeomToCoordsLineSequence can output 1 million records in less than 2 seconds. Wow.

vincent

1,913 post(s)
#15-Apr-20 13:53

Related question : how can I know the number of item in a component ? In 8, that was displayed at the lower right of the screen and was really useful.

GeomToCoordsLineSequence can output 1 million records in less than 2 seconds.

I may save up to 12 hours of processing per project compared to M8.

Dimitri

6,064 post(s)
#15-Apr-20 15:07

The number of records is shown in the Component pane.

adamw


9,283 post(s)
#15-Apr-20 15:12

The Component pane should show the number of records.

PS: Dimitri was faster. :-)

KlausDE

6,378 post(s)
#13-Apr-20 08:56

german UI file for version 9.0.171.3

Attachments:
ui.de.txt


Shutdown adjusts priorities: Do we really want to go back to where we came from?

Dimitri

6,064 post(s)
#15-Apr-20 11:49

A subtle, but far reaching, change in this build is that 2D curvilinear segments are now preserved in the new functions and transforms, so no more losing curvilinear segments when using tools like Scale.

3D curvilinear segments are replaced with 3D straight line segments, and 2D splines may lose some precision, but still, lots of progress here with curvilinear segments. That's all part of ongoing efforts to make curvilinear segments fully equal in all editing operations with conventional straight line segments.

adamw


9,283 post(s)
#22-Apr-20 09:14

Status update: we are planning to issue the next build at the end of this week. The main focus is on joining data into rasters.

adamw


9,283 post(s)
#25-Apr-20 12:11

Status update 2: we decided to extend what we are doing with joining data into rasters and add one more feature which we think will be very useful. This will move the build date slightly - our best estimate is Wednesday.

After this build we are planning to (a) quickly issue a public build, taking a few days to test for potential regressions and make minor adjustments whenever needed, then start a new series of cutting edge builds and (b) simplify / extend panes, followed by (c) adding registration, and finally by (d) adding improvements for labeling and editing.

Stay tuned. :-)

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