ThinkGeo.com    |     Documentation    |     Premium Support

Inheritibg from BaseShape

#1











Hi Guys,


Our previous GIS software had an additional couple of properties for a basic shape object called Tag and TagPointer.  These were just objects so could be used for any old thing.


You guys do not have this, so I thought I would inherit from the BaseShape and create a new  PointShape and MultilineShape and add the properties we used to have,  easily done, can now add our new shape objects to the featuresource.


The problem I have is getting them back out again, Feature.GetShape() seems to return the BaseShape not the inherited Shape that was added.  


How do you get back the shape that was actually added?


Regards


John








#2

Hi Guys, 
  
 I now understand why this does not work, I had missed the point that the Feature stores the shape as WKB, nothing more and as the Feature is a structure and can’t be inherited from I need to do some more thinking… 
  
 John 


#3

John, 
  
   I see what you mean.  If you use your own kind of shape quite a bit is for you to add a extension method to the BaseShape called something like ToTagBaseShape().  In this extension method you would check the type of the shape and then create your own kind of shape with the Tag property and then get the WKB from the current shape and use it as the basis for the new shape.  I think in this way you can get what you want.  An example would read like “TagLineShape line = feature.GetShape().ToTageBaseShape()”  In the end the “line” variable would be your TagLineShape that inherits from LineShape but has the “Tag” property.   
  
   Maybe another easier way I didn’t think of would be to create a static method with a signature like  “TagBaseShape ToTagShape(Feature feature)” and in this way you would not call the “feature.GetShape()” anymore but call the “ToTagShape(feature)”. 
  
   Yet another thing we could do would be to add a Tag property.  I know Tag is kinda lame and a holdover from VB back in the day but it is really useful to have a free property sitting there of type object.  It add a very easy extension point that I think has some merit. 
  
 What do you think? 
  
 David

#4

Again… jumping in on another thread… 
  
 David, the issue I would have with your proposal is that assume I have a base shape, which has an objects in its tag.  Then I give that shape to a feature.  When I get the shape back from the feature the tag reference would be gone.   Unless the Feature holds a reference to a shape object, rather than just the WKB array, there is no way to have the tag of a shape survive the round trip through a feature, so while adding a tag is an action that I would like to see, it doesn’t solve the problem described here, does it?

#5

Ted, 
  
   Always a pleasure to have you jump in. 
  
   There is no way I know of to make the Tag jump from the Shape to the Feature or vice versa.  If we added a tag to the Feature and BaseShape then it could of course because we could code it that way.  I think that there could be another approach.  We could add the ColumnData property to the BaseShape.  This is really where extra data is supposed to go anyway.  On the Feature we have the ColumnData property which is just a dictionary of string,string.  You can use this for anything you want.  The reason we didn’t have this on BaseShape is that we imagined BaseShape to be used for some high level GIS methods like buffer etc.  We could extend the ColumnData to is and then when you go back and forth we can make that jump around. 
  
   In retrospect we should have made ditched feature and just had BaseShape and its children.  We still could have stored the core data in arrays of double that would be just about as efficient as WKB or just used WKB and write a custom iterator when you try and walk the points and parts of a polygon to give you a feel like the data is really there in the collection.  This would have been better however that is hard to change now and we had our reasons for Feature.  Mainly  we wanted something very lightweight so that for the standard drawing scenarios we would never use BaseShape and keep everything as Feature which being a structure is very efficient and clean.  We traded quite a bit for that though… 
  
 David

#6

Hi David,


As you will have seen from Ted's response, we need something that will survive the round trip.


I appreciate your comments about ColumnData, however I seem to remember reading somewhere that, ignoring the boxing and unboxing issues of saving objects as strings, the garbage collector can become confused about the status of an object.


Just imagine aShp.Tag = new SomeObject().  The object exists and the Tag has a reference to it.  If you created the object and boxed it to a string, then I'm guessing the garbage collector might be unaware that the object is still in scope?


I appreciate that Tag is old fashioned but to get round the problem we are maintaining a dictionary<string,object> to keep track of the data we need 'attached' to each point, line etc.


Regards


John


 



#7

John, 
  
   Let me propose the Tag property on the feature and base shape and see where it goes.  I should know something soon. 
  
 David

#8

Hi David, 
  
 Thanks for that, I hope it makes it. 
  
 I would like to be added to the list for the next update or is that going to everybody? 
  
 Regards 
  
 John

#9

John, 
  
   We will most likely do an interim build and distribute it just to you.  The code will be in for the main release but I can get you a DLL pack that is updated to help get this in your hands more quickly. 
  
 David

#10

Hi David, 
  
 Thanks for that, I’m knee deep in the editor at the moment so the additional event you were talking in another thread about will be handy. 
  
 Regards 
  
 John

#11




 


John,


We will send the temporary package to you today or tomorrow by email.  We will send it to the account you registered and please contact support@thinkgeo.comif you have any issues.


 


Thanks,


Ben




#12

Hi Ben, 
  
 Thnaks for that, I’ll give it a try.  For the moment we are back with V2. 
  
 Regards 
  
 John

#13

John, 
  
 Hope this package bring you back to V3. Let me know if you have any issues. 
  
 Thanks, 
  
 Ben.

#14

Hi Ben, 
  
 At the moment, the chances of us moving to version 3 are slim to none.  We may revisit it when the much vaunted next beta comes out however with the chronic overlay drawing speed issues in V3, what we have done in 2 just does not seem possible in 3. 
  
 Regards 
  
 John

#15

John, 
  
 The next release will change a lot.  For example in 3.0.199, the overlay cannot be refreshed separately(only except DynamicOverlay) and whatever changes you make, you need to refresh all the overlays to take effect.  In the upcoming version though, each overlay is independent, can be drawn, cached separately. It’s bad to hear you go to V2 and I hope the next release Beta 3 will take you back.  
  
 Thanks, 
  
 Ben

#16

Hi Ben,


That's good to hear, will be interesting to see if it does speed things up, I've been playing a little, have a look at gis.thinkgeo.com/Support/Dis...fault.aspx


Regards


John


 



#17

OK, John. I will check that one.