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


9,415 post(s)
#29-Aug-20 16:35

9.0.172.5

Here is a new build.

manifold-9.0.172.5-x64.zip

SHA256: bade7c98522df4ba422c838e66e854ecb73305f51cef032697565a7adce97774

manifold-viewer-9.0.172.5-x64.zip

SHA256: b9f9e04d54e92f81a9b36846d51188ef338c0fe9ab686c514f2503cd40ffa935

adamw


9,415 post(s)
#29-Aug-20 16:36

Select Templates

(Geometry fields) Search - supports a new part: radius = the radius of the minimum enclosing circle, useful for ranking geometry values by size.

(Text field) Search - supports new parts: url scheme / url host / url port / url user / url password / url path / url extra parts.

Transform Templates

(Geometry fields) Overlay - performs a topology overlay on a pair of drawings: identity / intersect / union / update. The result drawing includes fields from the source drawing (with same names) as well as fields from the overlay drawing (with names altered according to the specified pattern, by default 'Overlay {name}'). Both drawings can be restricted to the selection.

(Tile fields) Viewshed - computes viewsheds: visible area from all / visible area from any / visible count / visible level from all / visible level from any. Z values for view sources can be taken from a numeric field or directly from geometry values (the default). If Z values are taken from a numeric field, they can be counted relative to the raster (on by default). There are options to specify refraction (the default is 0.13), minimum / maximum angle (the defaults are -90 / 90, angles are always in degrees), radius (the default is 0 = no limit), and whether or not to use datum curvature (the default is not to use). View sources can be restricted to the selection.

(Geometry fields) Split - supports a new split into operation: cuts = splits geometry values into parts using areas or lines in a different drawing. Both drawings can be restricted to the selection.

(Geometry fields) Copy - supports a new part: radius = the radius of the minimum enclosing circle, useful for ranking geometry values by size.

(Geometry fields) Compose - composes a geometry value: point / point with z / circle / rectangle / segment / triangle.

(Date fields) Compose - composes a date value from year / month / day.

(Date fields) Arithmetic - performs an arithmetic operation: add time / subtract time / time after / time before. Add time / subtract time add the specified amount of time units (day / week / hour / minute / second / millisecond) to the original date and return a new date value. Time after / time before measure the difference between the original date and the second date and return a numeric value in time units.

(Numeric vector fields) Compose - composes a vector value: new / rearrange values. New composes a new vector from numeric values. Rearrange values rearranges values in the existing vector, setting a specific value to '(none)' clears it to 0.

(Tile fields) Compose - composes a tile value: new / rearrange channels. New composes a new tile from numeric values or single-channel tiles. Rearrange channels rearranges channel values in the existing tile, setting a specific channel to '(none)' clears it to 0.

(Text fields) Compose - composes a text value: geojson / gml / wkt / url / url from base and relative.

(Text fields) Copy - supports new parts: json named value / json array value / gml geometry / gml coordinate system / geojson geometry / geojson coordinate system / wkt geometry / url scheme / url host / url port / url user / url password / url path / url extra parts.

(Numeric fields) Limit - limits a numeric value: limit both / limit minimum / limit maximum.

(Tile fields) Limit - limits values of a specific channel in a tile: limit both / limit minimum / limit maximum.

Queries

GeomOverlayTopologyXxx functions for union / update overlays allow the source drawing to be empty and compose the result from the overlay drawing.

GeomOverlayTopologyXxx functions for identity / union / update overlays allow the overlay drawing to be empty and compose the result from the source drawing.

TileViewshedMakeXxx functions take an additional parameter for the channel to use.

TileViewshedXxx functions take an additional parameter for the Z field to use. If the name of the Z field is a blank string, the functions use Z data stored in geometry values.

TileViewshedTilesXxx functions return an indexed table to allow joins.

New functions: TileViewshedArea / Par - compute visible area for a single observer.

New function: GeomToCuts - splits a geometry value into cuts with an area or line.

TileFlowDirAccumXxx functions take an additional parameter for the channel to use.

New function: GeomRadius - computes the minimum enclosing circle for a geometry value and returns its radius.

New function: GeomRadiusGeo - maps a lat/lon geometry value to meters using the scale near its center, computes the minimum enclosing circle and returns its radius.

New function: CoordMeasureRadius - computes the radius of a geometry value using specified measure.

New function: StringJsonArrayValue - parses a JSON array and returns the value with the specified index, as a string.

New constants: INT8MIN / INT8MAX / UINT8MAX / INT16MIN / INT16MAX / UINT16MAX / INT32MIN / INT32MAX / UINT32MAX / FLOAT32MIN / FLOAT32MAX / FLOAT64MIN / FLOAT64MAX - minimum and maximum values for various numeric types. There are no constants for INT64 / UINT64 because computations in queries are performed predominantly in FLOAT64 which is not big enough to store these constants.

Other

CUDA support is updated to CUDA 11, the GPGPU.DAT file includes modules compiled for compute capability 6.0 (TITAN and upper-level GeForce GTX, see CUDA GPUs).

SQLite is updated to 3.32.3, V8 to 8.4.371.23, ICU to 67.1.0.0, Visual C++ runtime libraries to 14.27.29016.0.

Geocoding servers of different types for the same provider are merged together. Creating a data source for a geocoding server allows editing URLs for all services supported by the server.

Geocoding server for Here is updated to support the latest version of the API (v7).

Geocoding servers for Bing / Google / Here / MapBox / MapQuest / Yandex support search services (Search / Search Circle / Search Rectangle) that allow locating features near a lat/lon location with a filter string (typically used to limit results to restaurants, ATMs or something similar, the syntax depends on the server).

(Fix) Reading GDB data forces coordinate systems with no axes specified explicitly to XY even if the corresponding EPSG coordinate system is YX.

Parameter reports in template queries are cleaned to report date values without #...#, numeric vector values without CAST, UUID values without CAST, expressions without extra parens, field names without [...], channel choices without translation ('channel X' instead of 'X'), result choices without translation ('(same field)' instead of the field name).

End of list.

Mike Pelletier


1,800 post(s)
#29-Aug-20 17:28

The new GeomToCuts looks helpful with what I'm doing now! Any chance you could write a quick query to show how it works?

Mike Pelletier


1,800 post(s)
#29-Aug-20 19:17

Ah, see now that it is in a Transform as well. That allows seeing it in a query. Good. Was hoping though that it could be used to update the selected geom with newly cut transforms rather that creating a new table. Same with the Merge transform. Maybe with a query?

Mike Pelletier


1,800 post(s)
#29-Aug-20 20:07

Here's a project with a drawing area, another drawing with a line used to cut the area. The query cuts the area but the portion of the query (at the end) that removes the original area won't delete the original area. Any ideas?

Attachments:
cutter.map

adamw


9,415 post(s)
#31-Aug-20 09:12

You can use something like this:

--SQL9

 

-- code generated by Transform pane

 

FUNCTION SplitFunc(@geom GEOM, @split GEOMTABLE AS (

  SELECT [value] FROM CALL GeomToCuts(@geom, @split, 0)

END;

 

VALUE @system NVARCHAR = ComponentFieldCoordSystem([Drawing Table]'Geom');

VALUE @systemCut NVARCHAR = ComponentCoordSystem([cut]);

VALUE @conv TABLE = CALL CoordConverterMake(@system, @systemCut);

VALUE @cut GEOM = (

  SELECT GeomMergeLines(GeomConvertToLine(CoordConvert(@conv, [Geom])))

  FROM CALL Selection([cut], TRUE) WHERE NOT GeomIsPoint([Geom])

);

 

-- replacement code

 

  -- split geometry into parts, put result into table named 'temp'

SELECT SPLIT CALL SplitFunc([Geom], @cut) INTO [temp]

FROM CALL Selection([Drawing Table], TRUE) THREADS SystemCpuCount();

  -- delete original geometry

DELETE FROM CALL Selection([Drawing Table], TRUE);

  -- insert parts from 'temp'

INSERT INTO [Drawing Table] ([Geom])

SELECT [value] FROM [temp];

  -- delete 'temp'

DROP TABLE [temp];

The query still tries to cut the selected areas with the selected lines, I left it as it was - so before you run it, select some areas and lines.

As regards doing this automatically, we do consider adding this as an option. We will first allow splitting and merging for editing tools and then revisit the transforms.

Mike Pelletier


1,800 post(s)
#31-Aug-20 15:16

Thanks Adam but on first run it fails with "Cannot delete record". Second and each additional run, it fails with "Cannot add record". No changes show up in the Drawing.

Also, appreciate the consideration on making transforms add/delete records where possible.

adamw


9,415 post(s)
#31-Aug-20 16:52

You probably didn't select any areas.

I altered the query to work on all objects, try it:

--SQL9

 

-- code generated by Transform pane

 

FUNCTION SplitFunc(@geom GEOM, @split GEOMTABLE AS (

  SELECT [value] FROM CALL GeomToCuts(@geom, @split, 0)

END;

 

VALUE @system NVARCHAR = ComponentFieldCoordSystem([Drawing Table]'Geom');

VALUE @systemCut NVARCHAR = ComponentCoordSystem([cut]);

VALUE @conv TABLE = CALL CoordConverterMake(@system, @systemCut);

VALUE @cut GEOM = (

  SELECT GeomMergeLines(GeomConvertToLine(CoordConvert(@conv, [Geom])))

  FROM [cut] WHERE NOT GeomIsPoint([Geom])

);

 

-- replacement code

 

  -- split geometry into parts, put result into table named 'temp'

SELECT SPLIT CALL SplitFunc([Geom], @cut) INTO [temp]

FROM [Drawing Table] THREADS SystemCpuCount();

  -- delete original geometry

DELETE FROM [Drawing Table];

  -- insert parts from 'temp'

INSERT INTO [Drawing Table] ([Geom])

SELECT [value] FROM [temp];

  -- delete 'temp'

DROP TABLE [temp];

You can just open the MAP file and run this text, the area should get split into two.

Mike Pelletier


1,800 post(s)
#31-Aug-20 17:36

Hmm. Same problem. Also, before I did have the area selected.

I'm running the latest portable version, with all options set to default.

tjhb

9,409 post(s)
#31-Aug-20 18:15

Before any run, [Drawing Table] must not be empty, and there must not already be a table named [temp].

Can you check?

Mike Pelletier


1,800 post(s)
#31-Aug-20 20:40

Thanks Tim. Removing the Temp table solved the problem for the second query. The one that doesn't use selected objects. It doesn't help Adam's first query and yes there are drawing objects to cut. No matter, I can live without the selection method for now.

tjhb

9,409 post(s)
#31-Aug-20 22:10

In the first version, it requires a selection in both the target drawing and the cutting drawing.

Is that it?


It would be nice to add a couple of little inline script functions to a command sequence like this. One could test mfd_root for the existence of a given component (viz. a table named [temp]) and delete it if it exists; another could return a table representing just the selection in a drawing/table if there is a selection, otherwise the whole table.

Those would be easy to reuse. A nice exercise.

Mike Pelletier


1,800 post(s)
#31-Aug-20 23:53

Wish it was that easy but no I selected both. I assume then it is working for you?

tjhb

9,409 post(s)
#01-Sep-20 00:38

Yes. Works for me with a fresh version of your file, using 9.0.172.5. No problems at all.

Mike Pelletier


1,800 post(s)
#01-Sep-20 17:49

What the heck. Doesn't work on my laptop either. By selecting, I mean Ctrl click on the objects.

Maybe it just works south of the equator :-)

Dimitri


6,206 post(s)
#30-Aug-20 07:31

" Was hoping though that it could be used to update the selected geom with newly cut transforms rather that creating a new table "

That's always an issue with transforms that create a different number of result objects than the number of input objects, and not in a 1:1 correspondence. When you create a different number of result objects you change the number of records in a table. There are many possible ways to handle that, but one of the least confusing is to simply create a new table, and then to make it easy to use that new table by automatically creating a new drawing for it.

Example: Start with a drawing that has one area. That's a table with one record, and one geom. OK, now split the area into two areas. You now have two records and two geoms. If you put the results back into the same geom, what you create is a single multibranched area object, which is not usually what people want to do with a split.

Example: Start with a drawing that has hundreds of areas for the state of Maine, one for the contiguous mainland and hundreds more for islands and various cut-off peninsulas. That's a table with hundreds of records and geoms, one for each object. Merge : areas (dissolve) them into one object. You now have one record, and geom, for Maine.

You could, of course, arrange all such transforms that increase the number of objects to not create separate objects but to create separate branches. All such transforms could allow you to save the result into the same field, a "split into branches" in place. But then when you want to separate those branches out into separate objects you're back to creating a new table. It just kicks the can down the road to the next step.

Would it be possible to create transforms that operate in place on the same table, adding and deleting records? Sure. But that raises very many issues that, depending on your preferences and on the details of what you are doing (a hundred objects in a map project? A billion objects in the remote DBMS that's chock full of triggers, constraints, and dependent queries your IT department guards with zealous righteousness?), might be simple to resolve or might require intricate interfaces.

Given that Manifold prefers to present a single interface that always works, instead of a hundred special case interfaces, to date the resolution has been to simply create a new table when the results create a different number of objects.

That's going to have to change sooner rather than later, because right after the current campaign of new UI and new select/transform capabilities wraps up, will appear features like more extensive interactive editing where splitting objects in place within the same drawing, and merging two areas into one in place, will be part of the show. That will mark one of those crossings into new territories, like crossing a stream called the Rubicon that back in the day was so small nobody today even knows where it was, that may appear to be a small step but which involves the resolution of some very big issues.

I'd expect that for simple cases simple default rules will be possible, and it could be that we'll see examples of some operations that are available in simple cases which won't be available, or which will be significantly different, in complex settings.

Mike Pelletier


1,800 post(s)
#30-Aug-20 16:13

To be clear my thinking was that the transform should be able to add or delete records in the table, rather than say creating multi-branched objects. This option would get used often I would think. Creating a new table is doable but a lot more steps. On the other hand, I'd much prefer Mfd press on to other things, especially if transforms could be readily made into queries that can do the job.

RAR61 post(s)
#29-Aug-20 18:19

The new build manifold-9.0.172.5-x64 is great!

Would it be possible to preserve the orientation of the cut line please?

I am attaching the inconsistent line direction after using Cuts.

Thank you!

Attachments:
Cuts Results.jpg

apo109 post(s)
#30-Aug-20 19:19

This problem is still existing in M8 also as send to tech@Manifold. But it will have to be solved because cutting road network with the direction based on the digitization sequence might inject inconsistencies in the network for road optimization.

+1 for this suggestion

adamw


9,415 post(s)
#31-Aug-20 09:15

We will do this in the future, yes. We have this in the set of planned enhancements to geometry functions.

RAR61 post(s)
#31-Aug-20 11:56

That will be much appreciated.

Would it be possible as well to be able to cut lines with points please?

Thank you Adam!

adamw


9,415 post(s)
#31-Aug-20 12:16

We'll look into adding this.

RAR61 post(s)
#31-Aug-20 17:54

Thank you Adam!

tjhb

9,409 post(s)
#29-Aug-20 22:40

Would it be possible to consider renaming the new GeomToCuts function as either GeomToParts or GeomToSlices?

While 'cut' certainly can refer to the result of a cutting operation (as for meat, hairstyles, a deck of cards, fabric, a shady deal, or a wound), it is mainly the action or means. 'Part' and 'slice' are more general for the result of division, and probably less brutal here. ('Share' would be wrong because we are not setting proportions explicitly.)

For the same reason, naming the transform operator 'cuts' is entirely apt. That is what they do.

Dimitri


6,206 post(s)
#30-Aug-20 06:20

It's hard to find a word that does not a) have an unwanted connotation or b) is so generic it does not usefully name the result.

"Slice" has too many meanings in database and data access. "Part" also tends to be used for the obvious constituent parts of an object, often as a synonym for "branch," like the islands or holes of an area, and it doesn't obviously mean the result of a cutting operation.

In this particular case, the word should mean the result of a completely arbitrary division, and it can't be something already in use, like "segment." Ideally, it should be a short word. Words like "portion," and "fragment" come to mind. But "portion" tends to be about food, and "fragment" has some unwanted connotations about possibly being an incomplete apportioning.

"Cut" is at least neutral (could be a cut of fabric, a road cut, a cut in video editing, or a cut of meat). It's short, it doesn't have other meanings in GIS, and it is a reasonable word to use to describe either the majority result of something or a leftover shard.

I'm personally not in any way tied to the word, but I can't think of anything better.

tjhb

9,409 post(s)
#30-Aug-20 06:38

‘Part’ could be used in any of the other ways you mention, yes, but as far as SQL9 is concerned, it isn’t.

‘Cut’ is not neutral. As a noun it is ugly. (That may be why it is not often used in this sense. By the way the senses you mention for video editing and for roading are not really this sense, they are the act or means. For roading the result is a cutting.)

‘Segment’ would be not quite correct, ‘section’ literally correct but perhaps too often used.

Please reconsider simple ‘part’. Unless you have another more important use for that word.

‘GeomToCuts’ is really not a happy term. Please just don’t!

tjhb

9,409 post(s)
#30-Aug-20 07:00

To be very obvious:

‘I cut/slice/divide/tear/break this into two parts.’ That is the most natural expression. Or to be slightly more mathematical, assuming something having linear extent, into sections. (Segments at a pinch.)

‘I divide this into two cuts.’ That is simply not good English, with the only exception of meat. (And then it means something more than simply parts—it means cuts, such as flank versus brisket.)

Not geometry. (You can cut geometry, or make cuts in or through geometry, but you can’t divide geometry, or most other things, into cuts. Wrong word.)

Dimitri


6,206 post(s)
#30-Aug-20 07:52

"That is simply not good English," Well, we're back to whether something is good English or an acceptable Americanism. :-) And even that is a higher standard than technical pseudo-English.

I don't particularly like "cuts" as a noun either, but it is a noun, and not just for meat. In the US, for example, the noun is "road cuts" and not "road cuttings". There's also a "hair cut", although I agree with you that as in the case of meat there is an implied sense of some sort of specific style to it.

"Parts" would be ideal if it wasn't claimed by ESRI's strong binding of "part" to "branch", where multibranched areas are called "multipart polygons". ESRI explicitly uses the word to mean "branch", as in differentiating "singlepart polygons" from "multipart polygons." So if you call the thing "part" you'll have millions of people who have been trained in ESRI thinking you mean splitting into branches.

So, sure, if it wasn't for the incontrovertibly significant influence of ESRI-speak, I'd choose "part" over "cut" in a heartbeat. As it is, it's not such a clear call.

My own feeling is that it is up to the Manifold community. What most people want is the way it should go, as this is an easy thing to change, especially in the next couple of weeks.

Mike Pelletier


1,800 post(s)
#30-Aug-20 16:03

Some other options: division, subdivision, split, partition, piece, portion

tjhb

9,409 post(s)
#30-Aug-20 21:41

GeomToPieces seems good (nearly as good as GeomToParts, which Dimitri explains may collide with ESRI usage).

Another approach might be to give up the 'To' naming pattern for this case, and use a verb not a noun. GeomDivide or (why not?) GeomCut seem perfectly good to me.

mdsumner


4,223 post(s)
#31-Aug-20 02:17

GeomCutToPieces gets my vote haha


https://github.com/mdsumner

adamw


9,415 post(s)
#31-Aug-20 09:26

We discussed and we will likely rename this to 'parts'. GeomToParts, Split into: parts, Split with:, Split with selection only. The conflict with 'multipart geometry' as used in ESRI products is unfortunate, but we think 'parts' is still the best here.

Thanks for the notes.

JoeyD2 post(s)
#18-Sep-20 09:44

I take it from some posts that Manifold 9 currently cannot georeference images, but work is ongoing to implement it. Any idea when this might surface in the cutting edge version?

Dimitri


6,206 post(s)
#18-Sep-20 18:05

That's up for the next series of builds after the current select/transform/previews get wrapped, so soon. My guess is about a month.

adamw


9,415 post(s)
#29-Aug-20 16:37

What's Next

We are working on the preview for selects and transforms and on various small improvements to the UI, many inspired by forum feedback.

We are looking to issue the public build in two weeks, give or take. We might have an intermediate cutting edge build before that.

The build is mostly localization-ready. There are a couple of strings that are going to change, but nothing major.

Enjoy!

adamw


9,415 post(s)
#07-Sep-20 12:41

Status

We are planning to issue 172.6 in about a week. The main focus is on previews for the new panes, plus we are going to have a number of improvements all around.

adamw


9,415 post(s)
#21-Sep-20 10:47

Status Update

We have not yet been able to complete works on the previews. The main challenge with the previews is how to make the template produce a useful result without performing the transform in full. We use a variety of techniques to do this. After changes to the Select and Transform panes we have to adjust or rewrite most of this code and some of the changes have been quite tricky. We are also aiming to provide previews for a number of templates that have not had any previews before, this adds work as well. On the good side, we have already added a number of features to the previews that will make them noticeably better than they were before - they are faster (can now use multiple threads, couldn't before), you have more control over them, eg, they only appear if you explicitly call for them (no wasting time computing something you might not need) and they no longer update themselves as you edit parameter values (no wasting time re-computing something that isn't final), etc. It isn't just about previews either, we have already added a couple of features unrelated to the previews and we will likely add a couple more. :-)

We think we will be ready to issue 172.6 near the end of this week, at most right after the weekends. If there will be any significant changes to these plans, we will communicate them.

tjhb

9,409 post(s)
#21-Sep-20 14:01

I think it is amazing that previews ever work. And not only that, but that they also seem to work. (Like justice.) Even when there is screeds and screeds of complex data!

If in following builds they are sometimes slow, everyone will assume that is for a good reason. Especially if preview is switched off by default. That is a welcome addition in itself, yes.

First, the possible. Then...

Mike Pelletier


1,800 post(s)
#22-Sep-20 19:06

This is probably not a useful suggestion, but I imagine people would be happy to have previews slowly roll out over time if it meant sooner implementation of other improvements that are next in line.

BoldItalicUnderlineStrikethroughSuperscriptSubscriptInsert Bullet ListInsert Numbered ListInsert ImageInsert LinkRemove LinkInsert Horizontal RuleInsert HeadingInsert SubheadingInsert TextInsert QuoteInsert CodeRemove Formatting
Insert Symbol SmileWinkGrinBlinkBlushOh, My!HuhSadAngryPh34rSleepCool
Link URL: Text Raw HTML




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