ThinkGeo.com    |     Documentation    |     Premium Support

Buffer Issue

#1

 


 


Hello,


I am running into an issue I have had before (and probably always) with the buffer function. I am not sure if it is the limitation of the extension being used (if any) but it does not take much for me to cause Out of Memory exceptions or in general long wait times to return the buffered shape.


If the project is paused during the 'hang' the line focused on is the shape.buffer function. The geometry being buffered is not even a very complicated one, but that is a little besides the point. I have figured out a way to throw a rolling progress bar during this process to allow the users to understand the process is underway but I have no way to exit the buffer request if it takes a certain amount of time or offer the user a choice of whether to wait or not. I think this is very necessary when we are talking about a relatively simple buffer taking forever...


Just for some background, the process entails taking a users selection of various parcels (typically abutting one another) and unioning them ,and then applying the buffer to the shape returned from the union. The union is ALWAYS instant and the buffer is always the culprit. It's worth noting that the buffer can handle certain small value requests but something like 250 feet will sometimes cause a problem depending on the input geometry.


I am attaching a picture of the selected parcels that would act as the unioned input shape for buffering so that you may have an idea of how relatively simple the geometry is. The parcel highlighted in red is treated as all of the yellow ones. Also, I am running on a Quad Core with 4GB of ram so for my machine to basically run out of memory from a buffer is rather odd and I imagine end users PC's will exception much sooner due to their memory resources being lower. This has been an issue with the buffer since I started using Map Suite so it is not new behavior, but it is the current observed Achilles' Heel in our otherwise highly stable and high performing application so anything we can do to resolve this would be great.


I would like to see the ability to perform these buffers without any issue at all, but if that is beyond Map Suite's control, at least I would like ideas on how to abort this operation if it exceeds a certain amount of time. Is this possible?


By the way, stability in the past few component releases have been rock solid. Great job!


Thank you!


Dim shapeBuffer As BaseShape = shapeUnion.Buffer(BufferDistance, 8, BufferCapType.Square, 2, 1)


 


1392-seleted_parcels_for_buffer.jpg610×599 148 KB
 



#2

Nelson, the Net Topoogy Suite (NTS) buffer is very week, and very problematic.   It has caused us no end of grief over the last two years.    I contracted with on of the SharpMap developers to improve it, and he did, but it is not the version of NTS that ThinkGeo uses.   And it still has problems.   So I have just taken delivery of an incredibly fast solution that I contracted from a machine tools software developer.    I will be testing it some this weekend, and have a better report.  
  
 It is a tool that, like you, we use for querying existing features.    The penalty that we pay for its performance is that if you buffere out by 10 meters, and back in, you may not get exactly the same object you started with.   But for one-way buffers that are used for temporary queries or other analysis… it is well suited. 
  
 There are no third-party dependencies.   It accepts WKT or WKB inputs.    If it pans out, I’ll share it with the ThinkGeo community. 


#3

Nelson,


Could you provide us the WKT for the target shape which will make out of memory excpetion happen when buffering operation excuted? We will ty some investigations on it.
 
Any more quesitons just feel free to let me know.
 
Thanks.
 
Yale

#4

Ted,


Thanks for your help and kindly contributions in MapSuite community, that did help us understand better in NTS.
 
Yale

#5

Nelson,


I removed your post and I am going to add the WKT as a file attachment.  I had the admin up the attachment size. :-) Below are the other details on what your wrote.


 


From Neslon:


Here is the WKT of the selection after having a union done to it. This is the input shape that is then buffered by 260 feet. It took about 30 minutes to force the exception on my computer with mem use on the process at around 1.2GB. Here is an image of the selection and the exception.


 


David



1402-PolygonWKT.zip (428 KB)

#6

Nelson & David,


I am sorry to that the Wkt is not a valid wkt, following code will shows it:

StreamReader sr = new StreamReader(@"c:\Post6545\PolygonWKT.txt");
string wkt = sr.ReadToEnd();
MultipolygonShape polygonShape = (MultipolygonShape)BaseShape.CreateShapeFromWellKnownData(wkt);

 
If you want, youcould use the following code to save the wkt:

Feature selectedFeature = new Feature();
string selectdWkt = selectedFeature.GetWellKnownText();
StreamWriter sw = new StreamWriter(@"c:\Post6545\wkt.txt");
sw.WriteLine(selectdWkt);
sw.Close();

 
Sorry for the inconvinience.
 
Thanks.
 
Yale

#7

Nelson, 
  
 Maybe I screwed up the WKT when I copied it out.  Could you please e-mail support with the WKT and have them forward it to Yale?  Sorry Nelson! 
  
 David

#8

I think it became messed up when I inserted the photo. I'll email the WKT as even zipped its a little over 500kb.



#9

 


Nelson,
 
I have recreated your problem exactly as you said with you wkt sent from your email.
 
I did some investigations on this and I found a very interesting way to go around it:
StreamReader sr = new StreamReader(@"C:\Documents and Settings\wuwenlong\Desktop\WKT\WKT.txt");
string wkt = sr.ReadToEnd();
sr.Close();
BaseShape baseShape = BaseShape.CreateShapeFromWellKnownData(wkt);
 
This will throw the out of memory exception.
BaseShape bufferedShape = baseShape.Buffer(400, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
 
While if I buffer it two times:
 BaseShape bufferedShape1 = baseShape.Buffer(200, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
 BaseShape bufferedShape2 = bufferedShape1.Buffer(200, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
           
And I buffered it 4 times:
BaseShape bufferedShape1 = baseShape.Buffer(100, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
BaseShape bufferedShape2 = bufferedShape1.Buffer(100, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
BaseShape bufferedShape3 = bufferedShape2.Buffer(100, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
BaseShape bufferedShape4 = bufferedShape3.Buffer(100, 8, BufferCapType.Square, GeographyUnit.Meter, DistanceUnit.Feet);
 
Both of them works fine and the result seems identical. Attachment contains the result.
 
Just want to let you know my findings.
 
Thanks.
 
Yale

1411-BufferResultPictures.zip (294 KB)

#10

Nelson, can I get this WKT, to see if our new routine solves the issue?   It is looking good on our own set of problem WKTs.   You can just give permission for ThinkGeo support to put it in my ftp folder, if you want.   Or e-mail to tmacy@mapshots.com.   Or if you prefer not to, that is fine, too!

#11

Ted, 
  
   I don’t think it is a problem as Nelson had posted the WKT to the forum in the first place.  It would be better to get the go ahead from him though since you bring it up.   
  
 Nelson:  What do you think, just give is the word and we will release it to Ted. 
  
 David

#12

Ted, 
  
 I went ahead and forwarded the file. It is a very uninteresting WKT and will not reveal the secrets of our company.  ;) 
  
 David, 
  
 Thank you for respecting confidentiality but you are 100% correct in assuming that since it was posted in the forum, it is ok for public viewing, use, etc. There was just a snag in the size limitations. 
  
 Yale, 
  
 Your observation is pretty interesting. Unfortunately, we let the user buffer by variable distances and so I think it would be very difficult on our end to somehow come up with reasonable divisions of their total amount. I am just worried about across-the-board dividing of buffer requests into quarters or eighths and so on. Not for accuracy reasons as much as for the unknown factor. What if we pick a value that when divided by 4 is still too large to be processed effectively by NTS? To what end would I need to be dividing the total value?  
  
 These are really important tools for our users. 
  
 Thanks all.

#13

Nelson, 
  
   Do did you send the file to Ted then or do you need us to do that?  I didn’t quite get the meaning of your first sentence.   
  
   On the security side of things it is really important for us.  We ask users send us data all the time and they only way they do it is knowing they can trust us to keep is private. 
  
 As Ted was saying the NTS stuff is pretty good but it is not without issues.  The NTS guys themselves didn’t have a good system for compatibility so many if the things that Ted had them put in really screwed us.  I think there was some other problem with the changes that I can’t recall.   
  
   We will look into if there are any new versions and also see how receptive the NTS team is to working with us on this.  We don’t have the expertise in house and use NTS for the buffering. 
  
 David

#14

Guys, 
  
   Some recent interesting news from NTS.  It looks like their 2.x branch is not more stable and better then their 1.x branch.  I think we use 1.7.? so maybe we can test out the new 2.x stuff.  Anyone have any inside info on this?   
  
 groups.google.com/group/nettopologysuite/browse_thread/thread/2c68e515018355d5 
  
 David

#15

He sent it to me.

#16

I forwarded the file his way, David. 
  
 So I am still a little lost in all of this… Is there any proposed way for me to handle when NTS is on the verge of eating all of my memory resources due to this 260 foot buffer?  
  
 I do need a way to at least allow the user to decide if they want to wait for this excessively long process to continue or choose to abort. Waiting for an out of memory exception can take 10 minutes and the user will have already assumed his application has ‘frozen’ which I can’t help but believe is unacceptable.  
  
 Even if I decide on always dividing by 4 or some other random number (which I have big reservations about doing as a solution) there is no guarantee I still will not run into this issue and so it seems no matter what, I must handle this potential scenario. 
  
 Any thoughs? Thanks. 
  


#17

David,


Just want to let you know that we could not find the latest version 2.x as you mentioned in its project website:
code.google.com/p/nettopolog...loads/list
sourceforge.net/projects/nts/
 
The latest version is still 1.7.3_RC2 which was used currently.
 
Thanks.
 
Yale

#18

Yale, 
  
   The 2.11 & 2.0 code is a branch inside their source tree.  Their article talks about how that is really the way of the future and that they will probably be integrating that with the trunk at some point soon. 
  
 David

#19

Nelson, 
  
   Did you ever find out what the polygon you have looks like when you visualize it?  Let me know or if you are busy also let me know and I will try. 
  
 David

#20

Sorry, David. Very caught up at the moment however I did just now visualize that WKT.