Archive for February 2010

Handling OS MasterMap Change Only Updates with SDF

 

A number of people have asked me if it’s possible to handle OS MasterMap COU (Change Only Updates) with Map 3D. I have often advised that it is best to get your GIS department to deal with it! Failing that there are some third party apps that can manage this for you.

However, if Map 3D is your only platform and you haven’t the budget for more software, there is a workflow that you can use. This method will work if you have got your OS data in SDF format. The COU files from the OS are in the same format as the MasterMap .gz files – so you can import them into Map 3D. The image below shows the original OS data connected via SDF, and the red imported COU .gz file on top. Here you can see a lot of the polygons have been changed. Often it’s only the attributes that have changed, so don’t be alarmed if it seems like everything has changed!

image

The first step is to export the COU data into a new SDF file, and then connect to it. Make sure you have at least exported the TOID attribute with the polygons.

With both your original file and the COU data connected, you can create a table join between the two data sets. Select the original OS data layer in Display Manager, and then call up the attribute table. From the Options button at the bottom of the table you can Create a Join..

 

image

In this example we will select the COU data source for the Table to join to, and match the TOID fields from both data sets. Make sure you select the “Keep all record on the left” option.

image

With the data from both sources joined, you can easily see from the table which items have been updated. You might be tempted at this stage to try and filter the data to show all the records that match the COU file and then select the data to delete it.

image

However, if you try this you’ll probably get a message like the one below – it is very slow checking out a lot of features in one go, and it’s not the best way to handle this.

 

image

Instead, we can select the layer with the joined data in Display Manager, and export to a new SDF file. Connect to this new SDF file. This will give us a new data source with the fields from both tables included. Notice in the image below we have the original TOID field, and the joined COU TOID field.

image

Notice that some of the COU TOID fields have Null values – these represent the polygons that haven’t changed. We now need a way to isolate these. We can do this by using a query to filter the data. Select the layer in Display Manager and right click, then select Query to Filter Data. (Note that you could also do this as you connect to the data using a query to add to the map).

image

The query condition I used was NullValue("Cambridge COU|TOID", ‘0′) = ‘0′

The NullValue part is a conversion – if the property (in this case the attribute field ‘Cambridge COU|TOID’) is a Null value, then it will return the second portion which is a text value of ‘0’. I can then test to see if this matches ‘0’ to filter the data set to show only those polygons where the field is empty.

image

The map will now show the data you need to keep – the polygons that haven’t been updated in the COU. The image below shows the queried data together with the imported COU data in Map 3D.

image

The final step is to export the layer again as a new SDF file, and then export the COU data to the same SDF, choosing the append option.

image

You now have the unchanged OS data combined with the COU data in a new SDF file.

Finding unconnected beams

clip_image002

Many of you may find that while creating beams, sometimes the beams are unconnected. This can cause problems with 3D snapping and also cause the analytical model to become erratic and not behave sensibly.

The main problem is trying to find the offending beams. One easy fix is to use the course level of detail and structural usage. Below is the same framing layout in a course view. Notice that Revit Structure can distinguish between Primary members, secondary members and tertiary members. Also you can see that the beam with the very thin line has not auto detected the structural usage. This is due to it being unconnected. Quite difficult to spot!

 

clip_image004

 

If you use object styles and set the Other sub category to a garish colour such as Magenta then you can instantly see any offending beams.

 

clip_image006

image

Short but sweet!

LawrenceH