Dissolve doesn't seem to work

7190
8
05-15-2013 05:57 AM
deleted-user-h2MwrUDd3vgt
New Contributor III
I've been trying to dissolve a street file for a couple of days now, and it doesn't seem to respond. I've tried several different approaches to running it and none of them seem to work, so I'm thinking there's a bug with the geoprocessing tool itself. I originally tried to run it on a moderately large line feature class (roughly 1.3 million records) via a python script by splitting it up into regions. I dumped each region into a separate shapefile and it works for the majority, but then hangs when it gets towards the end of the file. I also tried running it on as few as 5000 records and let it run for more than 12 hours and it only says that it's dissolving, but gives no indication of status. I've tried running it with both a feature class and a shapefile as input and output, and it results in the same hung process. Has anyone else experienced this?
0 Kudos
8 Replies
RichardFairhurst
MVP Honored Contributor
I've been trying to dissolve a street file for a couple of days now, and it doesn't seem to respond. I've tried several different approaches to running it and none of them seem to work, so I'm thinking there's a bug with the geoprocessing tool itself. I originally tried to run it on a moderately large line feature class (roughly 1.3 million records) via a python script by splitting it up into regions. I dumped each region into a separate shapefile and it works for the majority, but then hangs when it gets towards the end of the file. I also tried running it on as few as 5000 records and let it run for more than 12 hours and it only says that it's dissolving, but gives no indication of status. I've tried running it with both a feature class and a shapefile as input and output, and it results in the same hung process. Has anyone else experienced this?


I have never tried a file that large, but I have dissolved street polyline files with about 125K records in under 15 minutes, so your test with 5,000 records failing after that long indicates there is some kind of data corruption.  When you say it works for the majority in your region dissolves, I assume you mean they all look like they are dissolving based on the messages you see, but none actually dissolves in the end.  Is that correct?  Or do you mean that several regions actually dissolve but the regions you process last fail?  Also, does the tool ever stop processing on its own with the creation of an empty output, or do you always have to interrupt the processing due to it stalling out?

Were these regions processed as exports to new files before dissolving or as dissolves of selection sets/definition queries of the original file? Try the repair geometry tools on your original data (make a backup) and if you have not already made a test on an exported subset, do the export of a small set of records (your 5,000 case) to a new feature class for a dissolve to determine if the file itself is the problem.

I also assume other files unrelated to this street file dissolve for you.  If you haven't tested that you should.  A more widespread failure to dissolve than a single feature class and its derivatives would indicate that the problems possibly could be occurring in your ArcMap installation.  Anyway, it is far more likely to be the data source that is the problem and not the geoprocessing tool itself unless all attempts to dissolve fail regardless of the sources tried.

Anyway, more information about the things you have tried and what the various results you have gotten have been would be useful.
0 Kudos
ChrisSnyder
Regular Contributor III
The performace of the Dissolve tool is dependednt on the complexity of your data. The real issue is that the Dissolve tool must hold the entire output dissolved geometry in RAM all at once, and once it's done dissolving, then it'll write it out to disk. The larger/more complex the feature, the more RAM required, and if neccessary, the more behind the scenes tiling that must be donein order to keep the rAM usage under control. So basically, Dissolve performace is largely dictated by the number of verticies in your input layer. One of the worst examples is a large stream or road layer - and an even worse example is the buffer of such a layer (since the buffers have even more verticies than the input!).

One trick I have learned is to "tag" the features you want to dissolve with some sort of "region-based" unique id, and then specify this field value in the Dissolve. An easy example:

1. Create a fishnet that covers the entent of your dissolve layer.
2. Using a spatial join, tag your street features with the ID of the fishnet polygon.
3. In the Dissolve tool, specify this ID field as one of teh dissolev fields.

Make sure your fishnet is sufficiently small.
0 Kudos
ChrisSnyder
Regular Contributor III
Another caution is to make sure your input features have a relatively small vertex count... For example, it'd be a bad thing to try and dissolve three road segments that are each composed of 1,000,000 verticies, since the feature that would need to be held in RAM (prior to writing to disk) would be composed of all 3,000,0000 verticies (so 6,000,000 x and y coordinate values).

So I'll amend my sugested work flow:

1. Create a fishnet that covers the entent of your dissolve layer.
2. Dice the input layer (maybe a vertex limit of 10k verticies)
3. Using a spatial join, tag your diced street features with the ID of the fishnet polygon.
4. In the Dissolve tool, specify this ID field as one of the dissolve fields.

Recognize too that the output may not be 100% completely dissolved using this method, but pretty close.
0 Kudos
DaleHoneycutt
Occasional Contributor III
Something is amiss here.  You shouldn't be running into memory problems if you're dissolving streets unless an individual output street, when dissolved, contains many hundreds of thousands of vertices (typically, problems occur with millions of vertices).  This seems unusual to me because most street features typically have very few vertices.  Are you dissolving streets for an entire country?  For more information on this, see the blog post Dicing Godzillas.  Excessive number of vertices, as described in the blog post, typically occurs when dissolving many intricate polygons into one big Godzilla polygon.  The blog post shows you how to calculate the number of vertices you're dealing with so you can anticipate problems and get an vertex limit for the Dice tool.   If you suspect you're dealing with too many vertices, you can get the vertex count as described in the blog and make decisions based on this.

I hate to throw this out here, but have you checked the geometry using Check Geometry tool?
0 Kudos
deleted-user-h2MwrUDd3vgt
New Contributor III
Thanks for all of the input. I think that this is an issue of bad data. Even though I've been running tests on subsets, those subsets have all been derived from the original dataset. I tested on a separate street file and was successful. I'm in the process of recreating the dataset and if I'm successful, I'll be sure to post the results. Thanks again for all of the help and input.
0 Kudos
DaleHoneycutt
Occasional Contributor III
Good luck.  I spoke with a colleague and he says he isn't aware of many issues with dissolving lines.  However, he did say that when problems occur, it's when you're dissolving with no attributes (there are no dissolve_fields).  When there are no dissolve fields, everything is dissolved into a single feature.  My mental model of dissolving streets is that you're typically choosing a dissolve field like STREET_NAME or ROAD_TYPE, and the result features are therefor not problematic from the standpoint of vertex count. 

One final question: are you using Dissolve or Unsplit Line?
0 Kudos
MarkBoucher
Occasional Contributor III
Try putting the layer on your local drive and not on the network drive. I've solved memory and other error issues this way.
0 Kudos
cesaroliveros
New Contributor

try Check Geometry. Every time a geoprocessing tool does not work i find this solves my problem. You can easily check if your data has problem when there are negative values in Shape_Area field

0 Kudos