ThinkGeo.com    |     Documentation    |     Premium Support

Adding / Inserting records to SQL database

#1

Hi,


I've seen this gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/21/aft/6019/afv/topic/Default.aspx and the and the track and edit shapes example - but feel I may be missing some basic understanding here.


I want to be able to retrieve, add new objects and edit existing objects in a SQL database in a multi user environement.


Overall appraoch



        
  • I'm happy displaying the polygons.

    •     
  • I can select a polygon clicking with the mouse - highlight it and return its ID

    •     
  • To edit it I was planning on copying a selected polygon to the TrackOverlay layer and then edit here before copying it back to the main layer and saving - is this sensible ?  the posting above seems to copy all objects into the TrackOverlay layer - is that sensible with 1000's of objects.  I was worried that that would double the memory required.

    •     
  • Adding a new record is similar - write to the TrackOverlay layer and then copy to the database layer


Is this a sensible approach ?  Are there alternative methods ?


Multiuse issues


gis.thinkgeo.com/Support/Dis...fault.aspx


David explains in the aboe thread how generally all the spatial objects are held in memory until a commit is applied - so presumably I / the user will have control over this - and I can see this is a sensible way to go a lot of the time.  The potential risk here if much editing is going on is that a record may be updated by another user before I commit - presumably SQL server controls this in the normal ways - the issue of course being that drawing a new shape is potentially significantly more time consuming than editing a record.


As SQL Server implements row level locking - presumably there is a risk that I might get a conflict if another user has simply edited a text based portion of the record ?  I'm jsut wondering if anyone has practical experience of this and possible good methods (e.g. if you get a conflict do a field by field comparison - and force an update of just changed fields - or keep the spatial objects in a separate table to reduce the risk ?  I'm open to any good suggestions !


Editing interface


Using theTrackOverlay (is there another way to edit ?) - I can draw a new polygon / edit the nodes of an existing one.  I've discovered I can add new nodes by clicking and dragging on the line.  Deleting nodes is by double clicking on a node (this discovered from a throw away comment in a forum post - is there some documentation I've missed somewhere?)



        
  • Are there other "magic" keys / methods e.g. for undo / copying / merging objects etc - or do I need to dvelop this myself

    •     
  • I've discovered I can still use the zoom in box whilst editing - which is nice - but can I zoom out ?


Sorry for all the questions!


Best wishes



#2

James, 
  
 Thanks for your post. 
  
 Hope my following answers can give you some help even thought it may not complete. 
  
 Overall approach 
 I think we can achieve this, I think you do not need to consider SQL server as a very special data source, just think it as the same way as Shape file, try to do it in shape file and the others is almost the same. 
  
 Editing interface 
 I think the magic keys can be implemented by our self, we already have an sample for this: 
 code.thinkgeo.com/projects/show/cancelingtrack 
  
 Any more questions just feel free to let me know. 
  
 Thanks 
  
 Yale 


#3

Yale,


Thanks for the reply - I'm sure what I'm after is possible - but I was hoping for some guidance as to whether I was approaching it the best way.


1) Specifically - all your edit examples seem to use the TrackOverlay - is this the only place I can do edits ?


i.e. if I want to edit an exisitng polygon in a layer - do I need to move that polygon to the TrackOverlay layer to edit and then put it back at the end (this seems to work - but I was wondering if there was a better way). The sample example dealing with editing doesn't seem to give an example of editing a real object - just ones created on the fly - hence my slight confusioon.


2) As for "magic" keys / actions - I'm aware that I missed the drag zoom box initially, only found the add new node beacuse it was similar to other software I have used - and only found the delete node by double click because of a forum post.  I'm wondering if I have missed some overview documnet describing such things (the only help I have found was auto generated describing classes etc).  If there isn't such a document - it seemed likely to me that there may be other "out the box" functionality taht I was simply unaware of ?


3) SQL server - OK - I accept once the data is displayed editing is no different from shapes - apart from the multi user issue (which I think does need to be handled - as thats one of the main reasons people are moving data to geodatabases).  I can probably handle this by setting a lock when an object is moved to the TrackOverlay layer - and holding it until it is written back.  We've done this before with other systems.


Best wishes


 



#4

James,


Thanks for your reply.
 
 


        
  1. About the Edit using EditInterativeOverlay instead of TrackInterativeOverlay, these two interactive overlays are very similar while there are different somehow. TrackInterativeOverlay are responsible for tracking shape, following samples shows how to extend it to customize your own behaviors.


code.thinkgeo.com/projects/show/customtrackline
 
      While the EditInterativeOverlay are responsible for edit shapes, following project  
      Is showing how to extend it:
code.thinkgeo.com/projects/s...rectangles
 
      I think this is the most convenient way to deal with edit using    
      EditInterativeOverlay because all the edit logics (Drag, Resize, Add or Delete    
     nodes) are encapsulated in it. I am afraid we have to use it in this way if we want   
     to avoid those complicated logics.
 
Even though, we still can enhance it or change its behaviors by rewriting our own EditInterativeOverlay, we exposed couple of methods out to be overridden, for more details you could have a look at the project obove.
 
I remember I made a sample in this discussion form showing how to edit a existing polygon in the shape file, while I did not find it here, if you want, we can try to re-make it or I will try to search more.
 

        
  1. About the magic keys, I do not think you missed any in the default way, while, you could add many more “magic” keys or “magic” behaviors by your own codes, and the sample code use “Esc” to cancel the tracking is a simple demonstration for this.


 

        
  1. I agree that the lock should solve the multi-user problem; I am afraid this is the common and suggested way to deal with it.


 
 
Any more questions just feel free to let me know.
 
Thanks.
 
Yale

#5

Thank Yale,



If you had an example of how to add / edit records in an existing shape file - that would be great - as that is basically what I was wanting to do (though from SQL)



I'm afraid I'm getting tied up with TrackOverlays and EditOverlays without really understanding what they are / what the differences are.  Its just that all the edit examples I've seen seem to relate to this.



I gather from various posts that what you don't have any documentation that describes how all the bits slot together - and broadly how you should approach things (if this does exits - please point me at it!) - I think this would help someone getting started enormously.  I wouldn't have thought it had to be overkill - but 10 pages or so (perhaps a bit more with screen shots) - and referring to examples when appropriate - would I think be a great help to someone getting started.  I suspect you guys suffer from being so close to it that you find it difficult to understand how someone just starting struggles to get their head around it.



The examples are great for the detail - if there is one thats close (though I do worry that I may be approaching something the wrong way - simply because there is an example to start from) - and the replies to this forum are always prompt - but I feel guilty and a bit stupid asking questions which I sort of figure I should be able to find my own answers to.


P.S. I assume you know that posting in these forums doesn't work from google chrome - keeps catching me out !



Thanks 

James



#6

James,


I am glad to show you that following post are talking about how to retrieve/edit/save back shapes both from SQL server and shape file. Take a look at the following posts if you are interested.

gis.thinkgeo.com/Support/Dis...fault.aspx

gis.thinkgeo.com/Support/Dis...fault.aspx

gis.thinkgeo.com/Support/Dis...fault.aspx

gis.thinkgeo.com/Support/Dis...fault.aspx

gis.thinkgeo.com/Support/Dis...fault.aspx


We probably need to enhance the documentations to make it complete and easy to understand.


Any more questions just feel free to let me know.


Thanks.


Yale

 



#7

Hi Yale,


Thanks - I've seen most of those thanks.


I have it mostly working - in that reading and writing to a SQL table is fine - the bit I'm struggling with is the actual interactive editing.


I can do this fine on a layer thats not linked to the database - but how to put it all together.


I think basically I don't really understand the differences between:



        
  • My SQL layer

    •     
  • TrackLayer

    •     
  • Edit Layer


The code I sort of have working seems to involve copying from my sql, to track to edit - do the edit - and then reverse the copy process.


Is this really the way to do it ? Whats this doing to my memory useage? Is it really duplicating the object each time or just inheriting in some way.


I can see this works OK ish for a single object - but one of your examples shows copying all the objects from a sql layer to a track layer - if my SQL table contains 100,000 complex polygons - this doesn't sound a good way to go ?


<We probably need to enhance the documentations to make it complete and easy to understand.<we understand.="" to="" easy="" and="" complete="" it="" make="" documentations="" the="" enhance="" need="" probably="">></we>


I would agree ;-)


Thanks



#8

J, 
  
   I think the idea is that you typically do not want to edit 100,000 shapes at one time.  That kind if thing just isn’t what I think anyone would want to do.  Instead what we recommend is that the user selects what they want to edit.  Maybe a spatial query based on what they clicked one, draw a box around etc.  Next we move just those items into the edit system do they can be manipulated and then you move them out when finished and commit them to your layer.  Maybe what you are anticipating is a way to wrap all of this together to make it more seamless and hide the details from you.  We typically try and write the pieces and parts then use them to build up more complex functionality.  If we build to high then less and less people find it useful and they are back to piecing it together themselves.   
  
   We have had enough feedback on this to put together a higher level editor I think that would ferry this data around for you.  We could even have one that as you move the extent it moves the features into the edit system automatically so you get the feeling of editing everything.  Once you leave if the feature has changes we could keep a copy of it around for committing.  If you did not change the feature then we throw it away of keep some kind of rolling cache.  There are so many ways you could build this kind of thing up and we are really looking for some concrete cases.  Once we get those we can start building.  One downside of building too high for us is that people want all kinds of different things.  They may like a temporary storage medium to allow users to have transactions across days or weeks.  They may retrieve it from SQL but them store transactions in shape files.  All kinds of possibilities. 
  
   One a quick technical note:  Typically the shapes are not that large and are usually in feature form which means at the core is just a byte array of well known binary.  They are fairly compact and since they are structures and on the stack they clean up very easily and don’t put too much pressure on the garbage collector.  Also just to clarify something, the track interactive overlay is for drawing new shapes and the edit interactive overlay is to edit shapes you already have.  From reading your post I think you know that but wanted to just say it to be sure. 
  
 David

#9

Thanks David,


I think I had just about got to the point of understanding that track is for new and edit is for changing existing - though it took me a while to piece that together.


I agree entirely that is not sensible to move 1000's of shapes to an editing layer - but was slighlty confused as Yale pointed me at an example which looped through all the fetaures and moved them across to the edit layer - but I guess maybe that was an example of a small layer.


As you say - you could easily move features to edit as the user pans around - provided they were at a sensible zoom level - and also agree that providing you keep a cap on the number of shapes moved in any one go - memory useage should be lightish - with WKB objects.


In fact seeing as we are looking at SQL 2008 primarily on potentially quite large datasets I'd probably be happy with a system where a user selects and existing object for edit (which means I can set locks on the record in the database etc at that point).


Sorry for all teh questions - but with limited documentation is been a slight challenge putting together the bits - and the determing what cahcing , or SQL access or editing etc actually does / doesn't do.


 



#10

James, 
  
 Thanks for your response. 
  
 I think David’ idea mentioned above is quite right. The samples I point you out is somehow did not consider carefully edit from a quite large data source. 
  
 Now, I think your understanding on TrackInterativeOverlay and EditInterativeOverlay is quite close. The other system related while different is edit system, which is not a concrete layer, it can be considered as a set of operations on the data source, basically it composes of 3 steps: BeginTransaction, Edit(Add/Delete) and EndTrancaction.  
  
 Any more questions just feel free to let us know. 
  
 Thanks. 
  
 Yale