Subscribe to this thread
Home - General / All posts - Using Radian to edit Manifold 8 project
dwatling

132 post(s)
#10-Jul-17 15:35

Is it possible to use Radian to edit a Manifold 8 project and save the changes without migrating the Manifold project to Radian? (ie. Still want to open and work on the project with Manifold.)

I have tried both creating a data source and linking to a Manifold project. When I save the Radian project the * next to the Manifold link/data source goes away (I have also tried to first right-click > save the linked data), but the changes don't get saved in the Manifold project and when I re-open the Radian project they are not saved there either.

adamw


7,903 post(s)
#10-Jul-17 15:52

Is it possible to use Radian to edit a Manifold 8 project and save the changes without migrating the Manifold project to Radian?

No.

You can migrate data to a database and share it from there. Or you can migrate data to files like SHP and share those.

You can also use the ODBC drivers. If you connect to a Manifold 8 data source from Radian, the data is going to be read-only, but if you go the other way around and connect to a Radian data source from Manifold 8, the data is going to be read-write.

When I save the Radian project the * next to the Manifold link/data source goes away (I have also tried to first right-click > save the linked data), but the changes don't get saved in the Manifold project and when I re-open the Radian project they are not saved there either.

Heh. I agree this looks weird.

What happens is this:

The moment you save a MAP file in Radian, it becomes unusable from Manifold 8, it uses a new format. So we are trying to protect the user from losing the ability to access data from Manifold 8. So if you open a MAP file created by 8 in Radian and try saving it, we pop up the Save As dialog suggesting to save to a new file so that the old file is still available. So when popping up a dialog is infeasible (in linked data sources), we fail the save.

However, while the entire chain is perhaps logical, the end result for linked data sources looks weird. We will think about what we can do here, thanks for the note.

dwatling

132 post(s)
#11-Jul-17 07:49

Thank you for the explanation.

artlembo

3,048 post(s)
#09-May-18 15:05

I've been searching the forum for a while on this topic, but haven't found any update to Dave's question. Is it possible, or will there be an update that allows us to take the results from 9, and copy a drawing/table into an 8 project?

Why? Two reasons:

1. There are some things that 8 does that 9 doesn't (i.e. cartography)

2. There may be a large amount 8 legacy code (i.e. queries) that to recreate in 9 would be daunting (and in some cases impossible because some functions don't yet exist).

But, 9 is perfect for preparing really large sets of data, distilling them down, and sending them over into 8 for anything else that is necessary.

The ODBC connection adds a complexity I'd rather not deal with.

dchall8
436 post(s)
#09-May-18 16:37
But, 9 is perfect for preparing really large sets of data, distilling them down, and sending them over into 8 for anything else that is necessary.

Wait! What? How do I send my brand new merged DEM files to M8? I missed that part somewhere.

artlembo

3,048 post(s)
#09-May-18 18:20

you can use the ODBC connector to connect 8 to 9, and then bring it in that way. I want to take something from 9, and move it to 8. Yes, I could do it the other way too, but for various reasons I don't want to elaborate (too long of an explanation), and would prefer to drag a 9 component into an 8 [data source].

tjhb
8,009 post(s)
#09-May-18 20:28

Perhaps a minimal way to do it might be to add a Manifold 9 command or API function to copy a Manifold 9 component or object into Manifold 8 clipboard format.

Then leave it to the user to open a Manifold 8 session, click Paste, and do Save.

(Both operations could take a long time for anything big.)

That’s probably something that could be done with an add-in now, if someone were really keen to do it—as long as they could figure out the Manifold 8 clipboard format, or if Engineering were prepared to release its spec.

I would probably rather that Manifold spend its own time on filling out features in Manifold 9.

And although I haven’t done it (I should try it out), the ODBC route seems inherently more efficient than Copy and Paste (or drag-and-drop I think). Besides, it’s already written.

artlembo

3,048 post(s)
#09-May-18 20:51

yes, I think you are right on two counts:

1. time is better spent filling out missing features in 9

2. it is probably more efficient to use the ODBC route

my only issue is the workflow I currently have:

a. read in an EPANET .inp file and prepare it as geometries

b. get the data into Manifold 8 format

c. run a sh**-load of Manifold 8 queries and export out the results

(a) is truly impressive. 9 really shines in this.

(b) would be so nice if 9 could create the data and simply pop it into 8. I hate the thought of running something in 9, saving it in 9, opening up 8 (and, setting up the ODBC parameters beforehand - it can't be done on the fly) and then having 8 read the file in 9. Yuck!

(c) this is where your point about filling out the missing features 9. 9 is so much more efficient, it is really great. But, at the moment, I can't rewrite my queries because a number of things are missing.

thanks for the insights.

tjhb
8,009 post(s)
#09-May-18 21:20

I might shoot you an email about (c), to know more about the subject matter of the queries and what is missing.

Maybe we could collaborate on filling in some holes with Manifold 9 script functions (C# and/or IronPython), and share the important parts here.

Just a thought at this stage Art.

adamw


7,903 post(s)
#10-May-18 15:51

Art, there are multiple things we could do here, but we don't want to be spending any time on them, however easy they seem to be initially. Because as you say, we'd rather spend that time on 9. Especially because things of that nature tend to start easy and then they might easily grow. Ie, if we just do copy / paste of entire drawings from 9 into the Project pane of 8, then we know there will be requests to copy / paste into the drawing / map window of 8 = partial components, and requests to copy / paste the other way around, and requests to do the same with images, etc, etc, etc - and we get that these requests will stem from real needs but the end result will be us spending time working on workflows that are limited right from the beginning by the amount of data that 8 can handle and the flexibility that it has. We'd rather be spending time fulfilling the needs directly in 9. We try to carry over features from 8 every series of builds.

Until we have all you need in 9, let's try to make your current workflow better.

What if you set up a single ODBC data source and then just replace the MAP file referenced in that data source? That way, you'd work with the MAP file in 9, then close 9, open 8, open a MAP file in 8 and that would refresh existing linked components with new data automatically. It would be easy to bring new components using Database Console as well, because if there is just one data source and it has already been defined, this does not take too many clicks.

Alternatively, maybe create a script for 9 to create a DSN file for the current MAP file, then link that in 8? Using the DSN file saves quite a number of clicks in setting up the data source in clients. If necessary, creating the data source for Database Console in 8 could also be done programmatically via UI scripting. The script could, for example, take all DSNs in a specific folder and create a data source for each. Importing and linking components can also be done from a script, even without UI scripting, see the DataSource object. You can, for example, use a single script to link tables / drawings with specific names and copy / paste that script around, changing the name of the source MAP file at the top of the script, then running it to create all linked components in one go with no user intervention. We can help creating such a script.

Alternatively, maybe just share data using SQL Server or PostgreSQL?

artlembo

3,048 post(s)
#10-May-18 16:56

Well, I have a quick answer to what you've written above. Remember that run a sh**-load of Manifold 8 queries I spoke about. Well, while sitting up and watching basketball last night, I rewrote all of them! 9 is very powerful, and I'm guessing that my SQL statements are only 1/4 of what they were before. Really great. If a query is 8 has a complexity of, say "80/100", redoing the command in 9 makes the complexity more like "50/100" - in other words, a 9 query is more efficient and simpler than an 8 query.

Just a couple of other things:

1. One thing I had to do is determine the raster value that is associated with a vector. Since 9 doesn't have that capability yet, I created contours, and found which contour interval the geometry was in - that was sufficient for my needs.

2. The only criticism I would have is that without any intellisense, text highlighting, or meaningful error reporting, it took longer than it should have. I do hope you guys work on that soon - it will make life a lot easier.

3. While initially taken aback by the mfd_id, indexes, etc. (mostly because 8 took care of that), I found it simple enough to just keep copy/pasting ALTER TABLE... ADD INDEX... statements after running a query. So really, it isn't that much of a burden. I suppose when writing things freeform it gets annoying, but when standing up an SQL script, it isn't too much bother to ALTER tables, or CREATE DRAWING.

So, the final takeaway for me was that 9 was easy enough to recode. I think that I will start looking over some old 8 projects and see what 9 can't do, and then send a note to tech. But, I'd say 85% of what I do is just about there. Off the top of my head (and, I know you'll want more specifics), I'd say 9 should have:

a. cartography

b. network analysis (aka business tools)

notice the list is getting shorter...

adamw


7,903 post(s)
#10-May-18 17:27

Perfect!

Do send notes on missing things, they are useful.

And yes, highlighting and intellisense are going to be brought back. We have higher priorities right now (eg, cartography has a way higher priority), but yes, we will bring both these features back, with improvements.

dchall8
436 post(s)
#09-May-18 23:18

Doesn't it seem odd that you can export a drawing to every big name format except to Manifold 8?

adamw


7,903 post(s)
#10-May-18 15:57

Wait! What? How do I send my brand new merged DEM files to M8? I missed that part somewhere.

For rasters, you have to use export / import.

For vectors, you can use ODBC, this provides a direct read-write link (to any data source supported by 9, not just to MAP files).

dchall8
436 post(s)
#10-May-18 18:16

I can export the DEM to any of a number of raster file types, but they come into M8 as a non georeferenced image. A DEM would have an attached projection and Z values. Do any of the file types keep the proper projection and Z values with them? Ideally I would export to a .dem format.

I exported to a .jpg and to a .tif. In each case I got a companion file called *.jpg.mapmeta (or *.tif.mapmeta). These contain the projection data, but when importing to M8, the projection does not automatically come in. I imported the hillshaded .jpg and verified the projection. I used the .mapmeta file to fill in the blanks and the image registered perfectly, so there's that good news. The resulting file with only the .jpg and link to Google Satellite imagery is 1.7 GB, so I may be a little too large for M8 on this computer. It seems to hog all the remaining RAM to run. It could very well be if this merger of 240 DEM files into one DEM would be unmanageable in M8 in any case.

When I try to import the .tiff file I get an error, "Can't open file," so I'm not sure what is going on there.

Attachments:
M9 Raster Export File Types.jpg

adamw


7,903 post(s)
#11-May-18 16:19

We might improve things here by (a) exporting a PRJ when exporting common raster formats (we are already doing that for SHP, for example, can absolutely extend to rasters), and (b) not using BigTIFF if the raster size is small enough (that's most likely why 8 cannot read the TIFF, it doesn't support the BigTIFF variation).

Thanks for the note.

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