I was able to export from another program DTED0 lat, long, elevation data and import to Manifold. The database shows all the fields are there correctly. If I zoom in I can see the elevation labels and they are correct. I'm trying to color the elevations as points and get a very weak looking map; e.g., the colors are not all filled in. There are 14641 objects in the import. Also tried to make points to areas and then color via Voronoi Approximation, but program froze or took too long. Would appreciate your suggestions. Thanks.

4.50 doesn't have raster image capability, so displaying DEMs and DTEDS in image-like styles takes some hacks. By default, these data sets are vector data (points) and so are displayed by default as single pixel point style. You can hack up an image-like display at any given zoom level as follows:

1) Set point style to be a solid black foreground square.

2) Increase point size until the solid black squares get big enough to fill in the gaps between each other.

3) Use autoformat in, say, six intervals to color each point by its elevation value.

This results in a pretty picture that looks great until you change zoom, at which time you need to re-size the points again.

Don't use the Voronoi tiling to make areas, because this is a huge calculation and ends up creating vast numbers of objects/inflection points to fill in all the gaps.  The system isn't freezing, it's just going real slow (let it cook overnight).

Instead, download the free Bonus package from the Products - Free Manifold Stuff page and use the Contour solver. This will create area contours that can be colored in and that will look great. It's how the contour maps (they call them "isolines") in http://www.manifold.net/images/gallery/stpete.html    were created from point data just like the DTED.

Thanks for the help. The contours work nicely. Is there way to auto-format them in color?  The ones I have are so complicated that its too difficult by selection. Thanks

Yes. The way to do this is

1) Create a new, blank layer. Until you click another layer tab, it will be the active layer.

2) Run the contour map solver as desired to create new areas. They will be created in the active layer.

3) The areas created by the contour map solver will be selected.

4) Open Results History and right-click on the histogram icon at the end of the contour map solver results. Choose Save to Field in the resultant pop-up menu and save the results to some suitable field.  [That icon is a "handle" for the data created in the solver run.]

The above procedure saves the heights used to compute each area into the specified field for that area. If we computed heights from an "Elevation" field in the points, we could use this same field, "Elevation", as the specified field for the areas. We now have the height of each contour area in that area and we can autoformat by that field.  Placing the contour map areas in their own layer is just good housekeeping and makes it easier to autoformat them by simply autoformatting all areas in the layer.

Suppose you have Area Z.  Completely contained in Area Z is Area Y.   There are points inside Y.  There are points inside Z that are not inside Y.    When the query to show all points within Z is given, all points,   both inside  Z and Y are selected.   I don't know if that is intended. On the one hand, it is correct, on  another hand (I suppose I can only have two) it is not correct.

I have just purchased Manifold 4.50 and immediately installed the latest service pack. In order to have a good look at the software I thought that I would load a fairly sizable Mid/Mif file that I need to process. The file sizes are: 50MB mif 20MB mid. I am running a dual 450 MHZ Pentium machine with 256 MB of RAM and the import process has been running for about 1.5 hours and has currently consumed about half of my CPU time and about 200MB of my RAM (more resources get consumed over time).  Is this kind of load time normal? 

You don't say what O/S you are running, but we assume the "dual processor" bit means you are running NT 4.0 or Win2K. Note that the nature of WinNT or 2K means you are not running more than one processor on any one process. The two processors will offload your system overhead tasks somewhat, but they will not divide in two any one process even if it is multi-threaded (as Manifold 4.50 is).

The time you experience strikes us as fairly normal. MapInfo mid/mif format is a fairly simple format, as is ESRI .shp and other older formats. If imported or exchanged into another simple format there's not much to do.

In contrast, Manifold .mfd/mdb format is a "precompiled" format. A large amount of one-time processing goes into creating the file when it is first imported. This time increases non-linearly as job sizes increases. The payoff is that subsequent usage within Manifold is much faster, especially when doing sophisticated spatial queries. Manifold makes the design decision that it's better to have a slower, one-time import so that actual usage (as occurs many times) is faster. It's one of the reasons that spatial work in Manifold is much faster than in MI or ESRI.

A lot of RAM will be consumed during the import process for two main reasons: 1) the ability to abandon edits after the import is done effectively doubles the size of the memory image. 2) Manifold uses the Microsoft "Jet" database engine to manage the .mdb data file. That has many advantages but it also has the disadvantage that Jet expands memory usage a lot when creating temporary files incidental to import. Since the advantages of Jet are critically important during usage Manifold once again makes the design decision that Jet expansion during import is a "no brainer" price to pay to get the benefits of Jet during actual use.

Our advice:

1) Invest in RAM. RAM is cheap (our cost is well under a dollar a megabyte). You can install 512MB of RAM, buy Manifold and still spend over a thousand dollars less than MapInfo.

2) Scale up jobs slowly so you know what to expect from your particular system configuration. As systems switch from "in RAM" usage to paging from disk they will suddenly become dramatically slower. By scaling up the size of jobs you do you can see where this particular step-up occurs in your particular system. This will help you decide when it is time to get more RAM. The experience will also help you plan your activities so you set up long tasks to run overnight, etc.

A cautionary note:

If you are running Windows '95 or Windows '98 all bets are off.  Both operating systems have numerous bugs in the memory management system that prevent them from doing a good job with large memory.  In such cases, installing extra RAM does not mean that you will be able to use it.  If you want to take advantage of lots of cheap RAM the only sure-fire way of doing so is to use Windows 2000 or Windows NT.

 I am exporting Manifold objects to text files, for import into a different program.   The raw output format will need minimal formatting to prepare  for import, but I need the output to be formatted as Lat/long rather than long/lat. Right now the output is:

 I need it to be

We assume you are using the Write Text File solver. That's a hard-wired solver designed to get data out of Manifold in the simplest way possible, so it has no switches or options.

If you want to write objects from within Manifold to a text file in a way other than this, you could write a solver script to do it. This will require learning how to traverse objects and to write out coordinates, which is covered in the scripting tutorial in the Help file. However, this is such a trivial modification to the text file that is already created by a perfectly good solver that we suggest you write a tiny program to swap the values. You could use the existing solver to write out a text file, and then have your little program open that file and copy the contents to a second text file while swapping the order of lats and longs enroute. After all, the format is fixed so all the program has to do is to read in lines and swap the values, right?

If you don't have any other programming environment, you could always use the scripting capability within Manifold to write a solver, which is just a visual basic script, that opens a text file, reads it in and writes it out with swapped coords to a second text file.

It's unusual to write a solver that does nothing in Manifold but just opens two files outside of Manifold and moves characters between them, but hey... why not? There's plenty of documentation on how to open files and read and write to them in the Writing Solver Scripts book in the Help file. Any good book on Visual Basic Scripting will help you with the language if you don't know it already.

 I have Manifold 4.50 and am using data from the Manifold World CD.  I have a fast Dell Dimension with LOTS of memory, so that shouldn't have anything to do with my question.  For my dissertation, I'm doing analyses of the circulation of various archaeological artifacts across Spain, France, Germany, and  Belgium. However, despite having read the examples and background  information, I can't figure out how to merge the separate maps for those 4 countries into 1 map that I can use to perform spatial analsyses. When I  merge the maps, all but the one that I'm merging into (whether it's using a new layer or not) contains what appear to be elevation or transportation  lines or a combination of several layers. But then I can't add or  substract layers to any but the map I merged into. I need to be able to create and select MANY other layers and run analyses on them that cross  the country boundaries. What should I do, or what specific part of the  help section should I consult?

That sounds like a fascinating project! Your question relates to how separate maps are organized in Manifold, as well as how layers are kept organized in an .mws file even through the actual data is all grouped together in a single .mfd/.mdb file pair. For a review of the relationship between layers and Manifold files, read the Manifold Components book within the Introduction book in the Help file.

Manifold World provides base .mfd/.mdb files with .mws workstation files that arrange the data in the underlying .mfd/.mdb files in layers. If you open up the pre-built .mws files on that CD, you see a layer structure that is kept in the .mws. Within the originating .mfd/.mdb there are no layers... all the objects are all together. When you merge everything from the, say, France.mfd/France.mdb file pair into another map you end up with everything that appears as separate layers. To get only the boundaries from France.mfd/.mdb, you need to first open the .mws, select the boundaries, save them as their own map and then merge from that map.

A Manifold workspace can contain several maps. Each map is a separate .mfd/.mdb file pair and it can contain one or more layers. Within a Manifold workspace, each map is a separate world. This can be confusing because the layer tabs from different maps within the same workspace can be dragged left and right so that they are interspersed with layers from other maps.  Whenever you add a map to a workspace using "Insert Map" you are adding a new map to the workspace as a separate world.

See the "Adding a Second Map" example, which contains the important note: "Although layers from different maps may be intermixed in the same workspace, it is essential to remember that different maps are different worlds in Manifold."

To be able to work with information from different maps at the same time you must merge that information into one map.

Start with one map. Add information to that map from other maps using the Tools - Merge Data tool to merge objects and data from the other map. It is wise to use the layer structure to keep such stuff separate.

For example, suppose you want boundaries for Spain and France in one map and you are using the Manifold World data set.

1) Copy the France files from the World CD to your hard disk.

2) Open France.mws

3) Select all the France boundaries.

4) Save the selection as a map. Let's call it "MyMap". [this creates a MyMap.mfd and MyMap.mdb]

5) Do likewise with the Spain files. Save the selected Spain boundaries as "Spain_bounds" .

6) Create a new workspace by opening an existing file, in this case "MyMap" .mfd/.mdb.

7) Rename the default layer tab to "France".

8) Create a new blank layer called "Spain."

9) Use Tools - Merge Data to import objects and data from "Spain_bounds".

10) Save the workspace as "MyMap.mws" Saving the .mws saves the constituent .mfd/.mdb file so that it will now contain both the France boundaries it started with as well as the Spain boundaries lines that were merged into it.

This is a way of chopping the France boundaries out of the France.mfd/mdb/mws in the "World" set, and chopping the Spain boundaries out of the Spain files. We then create a "MyMap" that has both France and Spain boundaries in one .mfd/.mdb file.

When I digitize a nautical chart into Manifold and it was created in Tranverse Mercator, can I default through the options for  lat/long origin and false easting & northing? I wasn't sure if it would still be accurate. For a NIMA chart I am using it looks like all I can find out about the projection  is that it's in Tranverse Mercator.

(This is a 4.50 reply, since 5.00 can digitize from scanned images.) It's a complex topic, depending on how you are digitizing it.

Paper charts shown in "UTM" projection usually have graticule lines/scales printed on them that allow any point on the chart to be measured to a latitude/longitude location. If you are digitizing the chart by measuring many individual points and then creating points at those locations in Manifold, here is how to proceed:

1) Create a new blank geographic map in Manifold where the width in longitude degrees and height in latitude degrees is big enough to represent the geographic area covered by your paper map.

2) Measure the latitude and longitude of points on the paper map that will be used to draw lines and areas in a "connect the dots" fashion. Make the measurements using graticule scales printed on the paper map.

3) We would suggest creating an Access table for the points. Create the table with headings like "Item", "Point", "Latitude" and "Longitude".

4) Suppose we want to digitize the state of Utah. Beginning at one corner, measure the lat/lon of each point that defines the shape of Utah.

5) Enter these points into your Access table with the Item for each being "utah" and the "point" being "1", "2", "3" and so on to number each point that was measured in step 4). Note the latitude and longitude for each point. Do the points in sequence, either clockwise or counter-clockwise. Repeat the first point used. That is, if you have 10 points that mark the corners of Utah, add an 11th point that is the duplicate of the first point, so the points make a "connect the dots" traversal from the first point back to the first point.

5a) Remember to record the latitudes and longitudes as decimal lat/longs, with figures like 38.4849 for a North latitude. Use a - sign for south latitudes and West longitudes. This may be a hassle if your paper map is marked in degrees, minutes and seconds graticules. Program a scientific calculator to do the conversion or write a Excel spreadsheet to do this.

6) Do this for each line or area you wish to measure. Use the same "Item" designator for each. So, for Nevada you'd put "Nevada" in the "Item" field for all the points you measure for Nevada.

7) Import this Access table into Manifold as a coordinate-coded database. You now have a geographic map of all the points you measured.

8) To create Utah, select all points where "Item" = "utah". Use the make lines from points solver to make a line that goes through all the utah points. This is why you duplicated the first point at the end of the sequence, so that the line makes a closed figure from the starting corner all the way around Utah and back to the beginning. If all you want is boundary lines, you can do this for all the "Items" you've measured."

9) To create area objects select the Utah line and run the "Make areas from nonintersecting lines" solver.

There are faster and more elegant ways of doing the above using either .mdb files or text files, but the above process is pretty simple and easier to get right.

Notice that we are ignoring the "UTM" projection of the paper chart. If the graticule lines are printed in latitude / longitude coordinates we can ignore the visual appearance of the chart that's conferred by the UTM projection and simply use the chart as a measuring device to read coordinates directly in geographic latitude / longitude coordinates.

I have Manifold 4.50 and am using data from Manifold World cd for my archaeology dissertation. I'm about to start plotting archaeological sites with known lat/long coordinates, but I have a couple questions so  that hopefully I don't have to start all over!  First, is there a way to enter points by typing in their lat/long coordinates, rather than attempting to position the cursor in exactly the right spot? I searched the Help section using as many different relevant words as I could, but I didn't find an answer to my question. 

This is surprisingly tricky. Enter a point freehand by clicking on the approximate location where it is to be and then edit its coordinates. See "Editing Coordinates that Define an Object". We would use the following steps:

1. Choose a field that's a handy identifier for each point ("Name", "Sample Number" or whatever)

2. Turn on Instant Data

3. Insert a point by clicking the location it is to appear. Fill in the identifier in the Instant Data dialog.

4. Do the above for the various points that are to be added. When done, turn off Instant data.

5. Select all the points just entered. Open Table View on the Selection.

6. Within Table View, you can now edit the coordinates of each point to the exact values desired. The identifying field helps you keep track of which point is which in the table.

If you want to do this without an identifying field, just enter the point, select it, open selection table view and then edit the coordinates of the one record that appears in the table.

Another, batch, approach: create an Access table (or, for that matter, a simple text file table in .csv format) that lists all the points to be added and then import the coordinate-coded database. See "Creating a Coordinate Coded File with Access". This batch approach is probably the best method when more than a handful of points need to be added at given locations. In fact, it's quite likely you already have some sort of geocoded list of points/coordinates at hand in some text file, Access database or Excel spreadsheet.

Second, I need to change the projection from geographic to metric-based so that I can perform various spatial analyses and calculate basic km distances between sites and other features. I plan to use either the Lambert Azimuthal Equal Area or the Albers Equal Area Conic (my research area is basically Spain, France, Germany, and Belgium, with the outlying little countries to fill in gaps), although I'm not sure yet which would be better. I have already created a new workspace that displays MANY separate maps I created for the country boundaries, hydrography, and elevation.

Very Important: begin by making copies of *all* .mws, .mfd, .mdb files involved. Put the copies in a separate folder so you have something to restore if you make an error.

When I enter sites and project the map, in what order do I  need to do that? Should I have projected the original country maps before  I created new maps of boundaries, etc.? If what I've already done is

It doesn't really matter. Once you project anything in the workspace, all the maps that are in that workspace will also be re-projected to match that projection as well. That is a permanent change in the .mfd/.mdb files that are involved.

If you go from lat/lon to LAEA or AEAC you can always re-project back to lat/lon. The only issue is that there will be a slight loss of accuracy every time the data is re-projected from one projection to another.

O.K., should I project the workspace/map before I plot the sites or after, or does it matter? The vital thing in the end is that I be able to do spatial analyses (e.g., nearest neighbor, buffer zones, possibly network stuff) on sites and areas (representing raw material sources) across country boundaries. 

Our advice is to keep an archival set of all files in lat/lon. This is the originating form of the data for most data. Enter your sites, etc, in lat/lon. Keep it all in one directory called "original". Every now and then when you need to work with your data in projected form (either for computing distances or for presentation purposes), copy the whole works from the "original" folder into a "projected" folder, and then open the .mws in the "projected" folder and re-project it as you like. Then, do your computations or prepare your presentation materials. This is slightly tedious and uses a bit more disk but it is pretty foolproof.

Another possibility is to recall that no changes to an .mfd/.mdb ever occur *until* the .mws involved is saved. So, you could open up the unprojected .mws (and thus all the .mfd/.mdb maps it contains) and re-project it into the desired projection, do the computations and then.... without every saving the .mws ... close the workspace without saving. The next time you open that .mws all it contains will still be in lat/lon. This is a more intermediate approach because it is very easy to hit that "save" button out of habit.

Both of the above issues change in the upcoming Release 5.00. Coordinates may be edited in a more direct way. Maps can be re-projected dynamically without changing the underlying data, etc. It's neat.