Subscribe to this thread
Home - General / All posts - M9 Edit - Merge - Merge drawings converts curves to straight lines
scandalxk72 post(s)
#09-Jun-21 18:02

I have a .dwg with many layers. It comes from an architect, and so far as I know it originates in AutoCAD. I need to use it in M9 as a single drawing. I import it into Manifold, open the Map, select Edit - Merge - Merge Drawing... , change the drawing name to Merged Drawing, leave all the other settings as default, check that all of the layers are included, and press Merge.

It seems to work, but then I notice that some (but not all) curves have been straightened during the Merge. See attached project, containing the relevant features from the Merged Drawing and the same features from the merge source.

I've tried again, first converting the .dwg to AutoCAD2000, just because you had to with M8. It makes no difference.

What am I missing?

Note: the original .dwg is about 2.5MB but importing it to M9 results in a 70MB project, hence stripped down version uploaded here.

Attachments:
Forum Merge Drawings Project.map

tjhb
10,094 post(s)
#09-Jun-21 21:51

Interesting! (I confirmed with your sample data. I made sure that the source coordinate system was used for output--same result.)

My guess is that Manifold is running GeomNormalize over source data as it does the import. If so, perhaps there are good reasons for that, but overall it may not be helpful.

How many layers do you have? SQL will be doable--but if there are many layers then a script would be useful.

scandalxk72 post(s)
#09-Jun-21 22:10

Thanks for replying. There are 113 layers.

tjhb
10,094 post(s)
#10-Jun-21 01:34

OK, 113 layers definitely need a script or add-in.

But first, it is clearly worth a feature request to alter this behaviour.

Secondly, how far can you get, for your specific current data and workflow, by using GeomLinearlize before merging? That will also remove curves, but depending on your settings can be much better than the default used by Merge Drawings.

I don't know whether there is a Transform corresponding to GeomLinearize. If there is, I can't find it. What category would it be in?? (I have just wasted 15 minutes looking.)

Frankly I hate searching through the Transform subcategories for what I need. Hate it.

The subcategories are not named stupidly, certainly not; but they are named arbitrarily, and with apparently zero attention to their underlying SQL functions.

(The SQL functions also have categories. Why do we need to learn and remember both groupings? No good reason.)

I think this was a really unfortunate design decision. It reduces usability, the opposite of its intent.

I think we were better off with (yes, really long) lists of transforms that directly mirrored their underlying SQL functions.

And FFS, why change names??? Everything that matches in usage and logic, should also match in name.

The only good reason to change names, is that SQL is for intelligent people, and Transforms are for stupid people. That is obviously not true in practice, and far from good as a matter of design.

The result for me is that, almost every time, I wind up thinking bugger it, I will just use SQL thanks.

scandalxk72 post(s)
#10-Jun-21 10:35

Thanks tjhb. I'll put in a feature request then.

As we are doing some landscape design, and at this stage only making suggestions for tree planting which will likely change as the design advances, I can continue with the crudely straightened lines for now. I don't need to do anything else yet, but for the final versions it would be good if I could retain the curves.

Thanks again.

Dimitri


7,413 post(s)
#11-Jun-21 09:58

I don't know whether there is a Transform corresponding to GeomLinearize. If there is, I can't find it. What category would it be in?? (I have just wasted 15 minutes looking.)

Frankly I hate searching through the Transform subcategories for what I need. Hate it.

"Use The Force, Luke." Don't search manually.

Here's what you could do:

1. Open a drawing.

2. In the Transform pane, choose the Geom field to get a list of templates that work on geometry.

3. In the filter box, enter the word "curve" (it's a reasonable bet something that changes curves into lines might have something to do with the "curve" word.)

4. That reduces the templates list to just two templates: Clean, and Copy.

5. Hovering over the Clean template you get a tool tip with "Normalize / remove or convert curves / ..."

6. Picking the Clean template, there's an Operation to "convert curves to lines."

When I read your post I did it quicker than the above, to find the right template. I first picked the Geom field and then I moved the mouse over the list of templates to see what the tooltips said about the various templates. It took just a few seconds to zero in on Clean as the right template.

It's true that people who have learned the Transform and Select panes will find them much easier than people who haven't learned them. For example, I generally go straight to the transform I want, because almost always I know the one I want. But I often use the filter button as well to find rarely-used templates. It works great for that.

I think that's true of any system that has very many geoprocessing tools or whatever in some hierarchy of commands. They pretty much all have some sort of filter box or search box to narrow down the hunt to just one item. There would be the same need for a filter box if it was just a hierarchical list of SQL functions.

You might be able to find your way around such a list, because you know the functions and maybe the hierarchy very well, but most people don't have in memory a list of functions that tells them GeomLinearize is what they want, so they'd be using a filter box or search tool to find a specific function.

For example, when I need to find a particular SQL function, I usually just visit the appropriate SQL Functions user manual page and then do a Ctrl-F to call up the browser's search box, to find what I need. I then copy the name (or part of it) and paste it into the Query Builder's filter box in the Command Window so I can use it with a double-click.

I think we were better off with (yes, really long) lists of transforms that directly mirrored their underlying SQL functions.

And FFS, why change names??? Everything that matches in usage and logic, should also match in name.

That assumes Transform templates all are powered by one underlying SQL function, which they can mirror in the name of the Transform template. But that's not true. Transform templates often involve multiple underlying functions, with a lot of other SQL in addition. It's not a 1 to 1 association between Transform templates and low level SQL functions.

Transform templates are bundled to reduce the number of clicks in higher level workflow, and to make it easier to re-cycle as much of an existing choice as possible in repetitive use of transforms.

That dramatically increases the speed and convenience of applying transforms in real life work, because real life work often involves a sequence of similar operations. Not having to set up each of those similar operations from scratch is a real time saver.

You can get a hint of that in examples like this one, where repeated use of a transform builds a JSON string.

scandalxk72 post(s)
#11-Jun-21 14:32

Dimitri's post leads me to try using the convert curves to lines operation on the individual layers before carrying out the merge. So I did, with the default values of curve limit 50, tolerance 0. I then did Edit - Merge - Merge, and it works perfectly: I now have a Merged Drawing with "curves" (actually 51 straight lines between control points) just like I had in the individual layers.

So this suggests that Edit - Merge - Merge Drawings... imposes the convert curves to lines function before carrying out the actual merge, but with a curve limit of 0, so you get one straight line from one end of the formerly-curved section to the other. I've already submitted a suggestion that the behaviour of the merge function should be changed. Maybe, now I understand more about it (or think I do), I should suggest that the Edit - Merge - Merge Drawings... operation should include an option to set the curve limit to be applied before the drawings are merged. This would be particularly helpful in the case where you would otherwise have to convert curves to lines in 113 separate drawings, or write a script to do so (which I have not the technical knowledge to do).

I expect I have missed something. What is it?

Dimitri


7,413 post(s)
#11-Jun-21 15:30

If you have 113 separate drawings, and you use Edit - Merge to merge them, so long as they don't get reprojected the curved segments will remain. They'll even remain if the reprojection is only a shift and rescale.

If the destination coordinate system for the merge result is a) different from all of the drawings being merged or b) different from some of them, any of the drawings being merged that have to be reprojected will have their curved segments replaced with straight segments.

rk
621 post(s)
#11-Jun-21 15:00

If you create Data Source (not Import or Link) you have the option to 'Merge layers'.

Do the curves survive that?

Attachments:
merge_dwg_layers.png

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