ThinkGeo.com    |     Documentation    |     Premium Support

Track Shape Quality

#1

I have a map where I'm using edit overlay and track shapes to allow the user to draw some simple shapes, such as doing a freehand drawing of a line from one corner of a building to another, drawing a circle around a building, etc.  If the user starts out with the building being rather small and then zooms in on the map significantly the quality of the resulting shape is poor.  This is true for circles as well.  Is there a way to boost the number of segments in the original shape when it is drawn so that when the map is zoomed in the user-drawn shape quality is better?  I tinkered with the drawing quality level of the edit overlay but it doesn't seem to change anything.  I searched the documentation and forum and didn't find any matches.


Thanks,


Allen



#2

Allen, 
  
   The simple answer is that I am afraid not.  The issue is that you are digitizing something at one scale, and then want it to be more precise at another scale.  This is just not really possible unless you do some extra work.  For example if you zoomed out to see the entire US and drew a polygon around it then it just makes sense that when you zoom into the street level that your polygon would not hug the state coastline because you draw it at such a high level. 
  
   Having said all of that there are ways that can help this which is some pre-processing and possibly snapping.  The first one is in our new editing system you can simply click on a editing shapes line and it will add a new vertex.  You can also double click it and it will remove a vertex.  Make sure you download the latest version that is just about 20 hours old.  Which this you can as you zoom in move the vertex, add new ones, delete ones and reshape the polygon.  The other thing you can do is some snapping which for now you have to do by hand but what is possible.  For example if you wanted to select the building with a circle then when the circle is finished you do a spatial query to find what building they drew the circle on and then modify the circle anyway you want.  The same goes if you expect them to click on a building corner, after they click you can then take that point and do a spatial query to find the closest vertex of the building and snap the point to that vertex. 
  
   If this is a bit difficult to grasp I suggest you give a call to support and we can better get an idea of what you want to do and offer more concrete options. 
  
 David

#3

David, 
  
 I appreciate the quick response.  In our situation the user might be looking at a city block or apartment complex, draw on the map, then zoom in on a single building.  By “oversampling” a little at the city block level we had hoped to maintain a better quality when looking at an individual building, but for users with more extreme scale changes it really wouldn’t help. For us it’s not likely that a user will draw at the state level, then zoom in on a single building, but for others this might be normal.  I certainly understand that.  This was not a showstopper; I was just asked to research if it could be done. The shapes the users draw are expected to be “quick and to the point” and only displayed for a short period of time.   Also, the users will only be able to draw the shape; they will not be allowed to do any editing beyond deleting shapes.  However we have some other ideas where we might be able to use the enhanced editing features you mentioned. 
  
 I’m glad to see the new version; it will be one of my primary tasks for the day to investigate.  It looks like there were a lot of changes to get familiar with. 
  
 Thanks, 
 Allen

#4

Allen, 
  
 OK. Let us know if you have anything:) 
  
 Thanks, 
  
 Ben

#5

Ben, 
  
 I have been working with Allen on this issue. OK, I tell Allen what I want it to do and he does it (excellent). 
  
 I think we should be able to draw shapes on the map with a vertex  tolerance we set. In the “old days”, ArcInfo used a weed tolerance which I think was the extent of the data/10,000. 
  
 Anyway, what we are trying to achieve is drawing notes on a map. Currently with the latest beta (not RC1) the resulting shape is too course. See the following examples: 
 onscenexplorer.com/videos/thinkgeo_mapnotes.wmv  
  
 Compare this to what someone has done with google (scribble): 
 onscenexplorer.com/videos/google_scribble.wmv   (see how smooth this draws!) 
  
 Screen shots of the results at: 
 onscenexplorer.com/videos/thinkgeo_mapnotes.jpg 
 onscenexplorer.com/videos/google_scribble.jpg 
  
 Now perhaps we are trying to get Thinkgeo to do something is was not designed to do, but I think it can do this. 
  
 Also, there is a big delay in our app when drawing, but this might be because it’s the trial edition. If you do something like this on your end, is it as fast as the google example? Our users will be using touch screen laptops with a pen stylus. 
  
 OR, is there a better way to do this with Thinkgeo than our method? 
  
 Thanks! 
  
  
  


#6

Ben, 
  
 Also, we noticed the “unlicensed” flashes a lot during the line drawing process, perhaps this is causing the delay in getting the mouse position, which makes the shape look course. Thoughts (besides buy the license)? We will purchase the license once it’s release is final.  
  
 John

#7

John & Allen,


Hopefully I can help you out with your problems!


1)      For the tolerance problem. I just want to make things clear by giving a simple example.


For example, when you drawing a circle or freehand in a very high ZoomLevel(let’s say ZoomLevel01), when you zoom into very low scale(let’s say ZoomLevel19 or ZoomLevel20), what you expected is still get a very high quality of Circle(or freehand) boundary?


You know, normally, a circle is in fact a Polygon which composes of 96 * 4 Points by default, when you zoom into very low scale, you of course cannot see the whole circle but only small amount of Boundary. This small amount of boundary may compose of only a few points. So this circle is some how “low quality” as you said.


I think one solution for this is to draw different resolution circles for different scales even thought I have not very thoughtful solution for this.


2)      I created a comparable demo to show the Edit delay, please have a comparison with your app effects.


Please let me know which version you are using by trying the following statement:



string versionString = WinformsMap.GetVersion();

Any more questions just let me know.


Thanks.


Yale



#8

Yale, 
  
 Thanks for the discussion on the effects of scale on the quality of a line. I’ve been in GIS/mapping for over 20 years and understand this very well. The issue is when a line is drawn at a particular zoom level, it should look “good” at that zoom level.  
  
 I played around a little more with our test app. If I draw a shape VERY VERY slowly, the shape is much better. Therefore, it seems the track shape is getting mouse positions based on time. The slower I move the mouse the more shape I get, the faster I move the mouse the less shape I get. 
  
 I would expect I can draw at a “quick” pace and have the resultant shape be a close representation of what I drew.  
  
 Version: MapSuiteCore:3.1.124,Evaluation;DesktopEdition:3.0.304 
  


#9

John, 
  
 Thanks for your post! 
  
 So your idea is that in very low scale, when you draw a shape with quick mouse move, then the quality of the tracked shape is very poor, Right? 
  
 If so, I want to make sure one thing is, this only happened when you track a freehand.  
  
 This reason is somehow depends on the Microsoft Mouse Move event, we cannot change its behavior. Let us say that for any control, when you mouse moves faster, it’s “precision” for this mouse captured event fired will be somehow worse. 
  
 Please let me know your ideas. 
  
 Thanks. 
  
 Yale 


#10

Yale, I’m sorry but I disagree with your assessment.   I’m trapping the Map.MouseMove event in order to display the mouse’s lon/lat position in the status bar.   That data is updated incredibly fast.   However, when I track a polygon, freehand, etc, with the track overlay, I don’t get vertices inserted into the shape nearly as fast.  I experience what John has described.    Effectively, when you are consuming the mouse events to update the track shapes physically and on the screen, many mouse move events are lost during the processing.   This is not a Microsoft issue.

#11

All, 
  
 Just to let you know that I’ve the same issue with 3.0.335. 
 Track shape is so slow that vertices are not where the user really clicked. 
  
 Regards 
 Patrick.

#12

Ted & Patrick,


 Thanks you all for your posts and great ideas!
 
Things are being much more interesting now! I made a very simple demo to test the MouseMove event raised by Microsfot. My basic idea is I move my mouse from a predefined routine: lower left Point of Map control to Upper right Map control and record the event count of Mouse Move, I tested 2 ways I move my mouse: Fast and slow.
 
If I move my mouse slow from lower left to upper right, I always got 500~600 events raised.
 
While if I move my mouse fast from lower left to upper right, I always got 150~200 events raised.

void winformsMap1_MapClick(object sender, MapClickWinformsMapEventArgs e)
 {
     MessageBox.Show("Count = "+ count.ToString());
     count = 0;
 }

int count = 0;
void winformsMap1_MouseMove(object sender, MouseEventArgs e)
{
   count++;
}

Attachment contains the project for this test, any idea or comments will be appreciated.


Any more questions just let me know.
 
Thanks.
 
Yale

858-Post5783_Demo.zip (10.6 KB)

#13

Yes, I agree with this.   My contention is that if you were tracking a line in this same manner… ie, moving from lower left to upper right at the same speed, you would find that the number of mouse move events is significantly reduced.   Or, if you do a freeform shape, you will find that the number of vertices in the resultant shape is significantly less than the number of events you get when only trapping the MouseMove event without tracking.

#14

All, 
  
 Thanks for your posts and ideas! 
  
 We have found the root of the problem and solved it, it is somehow our potential bug, and it will be available in next release. 
  
 If you want temporary version for this fix, let me know! 
  
 Let me know if you have any problems! 
  
 Thanks. 
  
 Yale 


#15

This is great news.   Yes, I would like an intermediate build.

#16

We’ve been discussing ways around this issue, but if this has been fixed it will save me some time.  I would like the temporary version as well.   
  
 It was good to see some civilized disagreement and ThinkGeo’s willingness to listen, wasn’t it? 
  
 Allen

#17

Same for me, thank you.

#18

Ted & Allen & Patrick,  
  
 We will send you a Temporary version (3.0.348) package to you tomorrow. 
  
 Thanks again for all your great ideas and discussions! 
  
 Any more question just let me know! 
  
 Thanks. 
  
 Yale 


#19

I did not get to try the temporary buld before 3.0.362 became available.  It appears to me that things are more responsive, but I'm not very good at drawing letters and shapes with a mouse, so I'm not 100% sure.  Has anyone else gone back to check on this? 


One thing I did notice is that frequently pieces of what I initially draw are lost, as shown here:



This is what I am doing: Draw a horizontal line across the map surface.  Put the mouse cursor on the horizontal line and click, then draw a "U" or "V" shape downward and then back up to the horizontal line.  As can be seen above, more times than not the downstroke part of what I draw is missing until near the bottom of the symbol.  Maybe someone else can try this to see if they have the same result. 


Thanks,


Allen


 


 



#20

Allen, 
  
 We also notice this is a potential problem. 
  
 Now we provided 2 ways to solve this problem: 
 1) When you start track a shape, you have to wait sometime before your Mouse Move, that is to say, after MouseDown wait 500 ms and then MouseMove, then the tracked “U” or “V” will be much better. 
 2) We will provide you with a fixed temporary version as soon as possible if you are very urgent in this fix. 
  
  
 Let me know if you have any other questions. 
  
 Thanks for your reporting. 
  
 Yale