ThinkGeo.com    |     Documentation    |     Premium Support

BingMapsLayer Issue

#1

Hello,


I am having a couple issues with the BingMapsLayer. First is some of the QueryTools don't work like they do without Bing loaded. Like GetFeaturesTopologicalEqual and GetFeaturesIntersecting. Attached is a couple screenshots running the same code. You'll notice that the BING version does not pick up any of the cross streets.


Second, if you have the ScaleBarAdornmentLayer loaded while the BingMapsLayer is loaded it throws an error when the screen size is not maximized and you try to change the extent.


I have also uploaded a sample project to my FTP folder on your server if you need to take a look at it.


Thanks,


Jesse





#2

 Hello Jesse,


 
 Thanks for your post, and thanks for your sample, I did some test on it, but I can't recreate the problem you mentioned, please check this video screencast.com/t/UwmljvAD3Gt, I can get the query result and the ScaleBarAdornmentLayer working fine, can you upgrade to the newest dll version and have another try?
 
 Also you said the problem happened because BingMapLayer, it doesn't make sense, because BingMapsLayer is just like a background in this scenario, and everything you operate is just query the shape file, so with or without the bing map, the result should be the same.
 
 Let us know your queries.
 
 Regards,
 
 Gary

#3

Thanks Gary,  
  
 I updated to the latest build and the scalebar works now. However, I still get the same results when selecting roads. Could it be the Proj4ExtensionX86.dll that i had to put in th system32 folder? or one of those other dlls? If so how do I get an update of those dlls? I don’t see them available in the portal for download. 
  
 Thanks, 
 Jesse

#4

Hello Jesse, 
  
 So this problem happen when you add the BingMapsLayer into overlay, but working fine if you comment the BingMapsLayer, and you didn’t change any code, is this right? 
  
 If so, could you please make a video can show me? I hope I can find out some thing from your operate. 
  
 Sorry for the inconvenience, because I need know how to recreate the problem. 
  
 Regards, 
  
 Gary

#5

Gary, i don't change anything in code. i just have the little message box that shows when you run the project to load Bing or not. here is a video of how i get my results: screencast.com/t/Fn2Ruf9IZP


Is there a place i can go and download updates of the dll files that are put in the system 32 folder? or can you put them in my FTP folder?


Here is a screenshot of the ones i use: screencast.com/t/QLadDyFmSOiN


Thanks, Jesse



#6

Gary,

As a result of upgrading to the latest development dlls i am getting the following results.


Before upgrade I could zoom down to the extent shown and still see the Bing Imagery:


After i upgrade the dlls and zoom down to the same extent i get the following:


 



#7

Gary, 
  
 Another issue i am finding with the BingMapsLayer is the load time. Since i have upgraded to the latest dlls the time it takes to render is much greater. Zooming in that used to take 1-2 seconds per zoom not take 5-6 seconds. It doesn’t seem like the caching of the Bing imagery is working anymore. Is there something I’m doing wrong? 
  
 Let me know if these should all be separate forum posts. I’m putting them all under this one because they all seem to be related.  
  
 Thanks, 
 Jesse

#8

Hi Jesse, 
  
 The first issue you mentioned is caused by the projection’s inaccurate in .0.0000001, so we suggest you not to use the projection when doing the topology calculations. 
  
 The “No Image Available” issue has been fixed, please get the 6.0.148.0 or 6.0.0.148 and have a try. 
 I think the BingMaps loading time is depend on the network cause we didn’t make any changes on it. 
  
 Hope this helps you, 
  
 Edgar

#9

Edgar,


I am frustrated by these answers. I was sent a video of my project working correctly for you guys with the projection. So something is clearly different. If it works for you and not me then something needs to be updated on my side regarding other functionality. No one as answered my questions on how to get an update for the dlls you ship with your install that go in the System32 folder as well.


I realize that Bingmaps loading is dependent on their network. However, when I can load up my project using the 6.0 dlls vs. the 6.0.141 dlls and see a very noticeable difference between the loading times it tells me that it’s not the Bing network. It is also always slow. The purpose of the caching would be to speed it up after the first time you go to an extent but that is not the case. It always loads with the same slowness; were as the 6.0 versions speed up after you visit an extent on the second time. And if I then go remove the cached images it is slower.


Thanks for the fix on the “No Image Available” issue.


Jesse



#10

Edgar, 
  
 I just tested the fix for “No Image Available” and it works. Also, the slowness that was there is gone, so whatever fix that was applied for the “No Image Available” may have fixed the slowness? 
  
 I’m still waiting for a fix dealing with the projection since your suggestion of not using a projection is not an option for me.  
  
 Thanks, 
 Jesse

#11

Jesse, 
  
 You can find a setup package in the daily development build package named "Setup Unmanaged Dependencies 6.0.x.0.msi", run it then the dlls under system folder will be updated. 
  
 Glad to here the slowness went away, maybe the performance has something related to the zoomlevel. 
  
 The projection issue is not what we can control, because a coordinates will become inaccurate after the conversion, e.g. one point was converted to another projection, it lost some accurate, and then convert it back to the original projection, it lost some accurate again. In your case is : 
 //convert to external 
 line = layer.QueryTools.GetFeatureById(id)  
  
 //convert back to do the topology calculation, and the accurate has lost then the topology went wrong. 
 layer.QueryTools.GetFeatureIntersecting(line) 
  
 Regards, 
  
 Edgar

#12

Edgar, 
  
 I don’t understand what you’re saying here. Is this a solution to my problem or are you saying I’m out of luck and can’t use your querytools if I have reprojected a shape to the BingMaps projection?  When I reproject to the BingMapsLayer more than half my lines don’t intersect anymore? I don’t do any type of converting in my code when running the QueryTools i simply set the projection when the layers are loaded.  
  
 Also, why do the cross streets in the video Gary sent me work for you guys but not for me. Did you modify my project I sent you? 
  
 Jesse

#13

Edgar, 
  
 I just ran a little test where I exported a shapefile in the BingMapsLayer projection. I then hooked it up to load on top of the BingMapsLayer as normal but did not set a Projection because it was already projected. Now all the Intersecting lines show up. 
  
 This tells me that there is something wrong in the QueryTools when a layer has a Projection set to something other than its own. 
  
 Is there any way i can get a fix for this ASAP? It is holding up the release of our new product with Bing Maps.  
  
 Thanks, 
 Jesse

#14

Jesse,
 
Here is what our SpatialQuery do with projection(any projection, not only Bing) in your scenario:
1. Convert the queried feature to the original value.
2. Do the topology calculation with the original shape file data.
3. Convert the results to the projected value and return.
 
And here is a simple scenario like what you’re facing: a shape file contains one record( point1 (100.9999999, 100.9999999) ), id is 1, and the layer has a projection, so if using the GetFeatueById(1) it will return a projected point, let’s assume it’s point2 (20000.9999998,20000.9999998), now it has lost some accurate, and then do the spatial query, SpatialQuery(point2, Intersects),  like I said above, the method will first convert point2 to the original value which should be point1, but as the accurate lost, it might be converted to point3 (100.9999997,100.9999997), so the result is not intersecting.
 
Then you said you test it with a projected shape file, it works well, here is the reason: the projected shape file contains one record point2 (20000,9999998, 20000,9999998), and GetFeatureById returns the same point cause there is no projection, and the spatial query will go correctly cause there is no more accurate lost.
 
So I think there are two solutions for you:
1. Use the projected shape file, and do not set the projection.
2. Add the converted features of the shape file to an InMemoryFeatureLayer and do the queries with it, it works like the projected shape file, but it’s not a good option if the shape file is too big.
 
You’ll receive an email with the modified code of your sample which is working fine with the InMemoryFeatureLayer.
 
Hope it helps,
 
Edgar

#15

Edgar, 
  
 I have tested out the code sample. For the small shapefile I had sent with my sample project it works ok… it’s slower, but works. 
 However, I loaded it up with one of my county wide shapefiles and the speed for loading the whole shape into a memory feature layer takes too long. 
 Also, the difference between querying the shapefile vs. the memory layer is very great. Selecting various streets without your code takes maybe 1 second to get the results and zoom to the shape. When I change it out to use the memory layer it jumps to 6-10 seconds per street. 
 This work around will not work for the bulk of the shapefiles we deal with.  What else can be done here? Has anyone even looked into the possibility of fixing this within the control? If you’re aware of inaccuracies in the control when a shapefile is projected can’t you then accommodate for them in the querytools?  
  
 Thanks, 
 Jesse 


#16

Jesse, 
  
   I’m jumping in to try and help with this.  I have a good solution to this that should not slow things sdwn at all and be accurate.  I first want to discuss the issues with projection.  As Edgar mentioned when we convert projections there may be some precision issues because we are dealing with floating points and projections have various decimal locations between them so math seems to make the values wander a bit.  Traditionally this is handled by cluster tolerance where points that are very close are actually treated as the same point.  This process is relatively slow and not normally done in real-time.  We are working on a topology engine that includes cluster tolerance but it is not done yet and not integrated into these processes. 
  
 We normally use on the fly projections when we want to view something but always do calculations in the native unit system.  If we use the same projection over and over then we would project the file and use it as the native projection.  My suggestion is for you to perform your query tools operations on another layer that is in its native projection.  If your first layer is open read-only then you can easily create another layer that accesses the same shape files.  You could, for example, show the data using one layer that is projected using the projection class then have a user click on the map.  You next find the FeatureId in the projected layer and then query that feature ID in the native layer.  Next you do your query tool operation on the native feature layer and get the result.  After you have the result you can take the resulting feature ids and query them for highlighting in the projected layer.  In this solution everything is at full speed an should be even faster as there is no projection getting in the way of the spatial operations. 
  
 David

#17

David, 
  
 Thanks for the response. It seems like the solution will work but would be an effort to put in place right before our release.  
 Do you have a timeline/release date for the update to the topology engine? I’m trying to determine if I can get away with disabling Bing in my project for the screen that does all the topology querying for now until the updates are in place. I just don’t want to make a bunch of changes that I’ll need to change back once the topology engine is updated. 
  
 Thanks, 
 Jesse

#18

Jesse, 
  
 We’ve worked on the new topology engine for a while, but the cluster tolerance is a big one that will cost a lot of time, so it’s hard to say the timeline/release date, but the most probably date is before the next release, as it’s updated, we’ll let you know. 
  
 Regards, 
  
 Edgar