ThinkGeo.com    |     Documentation    |     Premium Support

A routing result looks off

#1

Hi there,


Please take a look at the screen shot below. I'm using World Map Kit, implementing exactly as the sample that comes with the WMK.


You can see main streets that go East and West look fine, but you see two roads for each the main street that goes North and South. As a routing result, it becomes to look like you need to drive a little side street, which actually is the main street (you can confirm if you look that up from different zoom level).


What can we do to solve this issue?


BTW this screen shot is for area around CA 91601.


Thanks,


Kaori


 

20101229_off_layer_3.png640×568 116 KB



#2

Kaori, 
  
 That path is probably the shortest route which is the default when you build routing index, if you want to let route go major road you may choose the fastest route, so that you need to build another routing index, the detail you can look at our HowDoI sample "Building Routing Data", it shows how to build "ShortestPath", "FastestPath", "OneWayRoad" and "OptimizeHighway", and also you can set different weight to make the result different. 
  
 Thanks 
 James

#3

Sorry I probably didn’t explain clearly. 
  
 The routing path itself is not the issue. The problem is the local street layer and the major street layer are slightly off in horizontal direction. The map in this picture is showing the major streets “doubly”, with white one and yellow one. The purple routing path is on the white major street in the picture (and that makes the vertical route “look” like going on a side street, but it’s correctly on the major street if it’s zoomed in). 
  
 Hoping you understand the issue. Let me know if you have a question.

#4

Kaori, 
  
 I check the data, it is originally a little shift like that, so this data may not good for routing, you can try to modify the data and combine them together and remove the duplicate roads which are a little shift with each others. 
  
 Next week I will discuss with Johnny to think a better way. 
  
 Thanks 
  
 James

#5

Hi Kaori, 



Thanks for reporting the issue, I think that should be the WorldMapKits displaying error. We compared it with GoogleMap, just as you have mentioned, both of the vertical road should be major road and are rendered with same style. I have submitted the issue to WMK team, we will provide the solution here as soon as possible, no later than tomorrow afternoon. 



Thanks, 

Johnny 

 



#6

Thanks a lot Johnny, I’m looking forward to hearing from you again.

#7

Kaori, 
  
 I found the reason is that some free way line shapes are marked A40 cfcc, we can modify data to let them to A10 which is the same as Highway looking. 
 I have made a little tool to let you can update the world map kit data. Please send email to support@thinkgeo.com to request it. 
  
 Let me know if you have questions. 
  
 Thanks 
 James 


#8

Actually I’m not really sure if that would solve the issue because those doubled roads are mostly ‘major streets’, not freeways. 
  
 But I’ll give a try on the tool anyway. Thanks.

#9

Kaori,


Maybe it should be major streets, but Google shows to free way, and I also attached the world map kit after update, now two line of roads are the same style.



Capture1.PNG589×561 72.3 KB


Thanks


James



#10

 Hi, let me please make sure if we are on the same page. At this point (for now at least), a style of streets may not be the biggest issue. The problem is that I can see two lines for a same exact street. I put comments on the images.


Hoping this is what you are taking care of.



You can compare how the major street layer and the local street layer are slightly shifted.




#11

 Hi, thank you for the tool, I just got it and ran it. Yes, it seems to have improvements regarding Freeways, but the major road issue still remains. Please refer my previous post for the detail.


As far as I see, this is happening all over the CA data.


Here's the screen shot after I ran the tool. We can still see those doubled lines.




#12

 


Kaori,
 
Yes, that’s a new problem, the same exact street shows as two different styled lines. The reason is that the same street is existing in two .shp files, CAlkaA40.shp and highwaynetwork2_1b.shp. they shouldn’t be rendered for the same zoomlevel, so that we need to update the rendering logic to remove either of them can solve the problem, but it may looks not good, our world map kit data is based on “cfcc” which breaks each roads to different type, such as A10, A20, A40, A70… normally, A10 represents highway, A20 represents major road, A40 represents local road, A70 represents street. But for this area, A40 contains many different type roads, such as freeway which is actually should be rendered look like highway because Google do like it, and major roads which we render as yellow color which is the same with the records in highwaynetwork2_1b.shp, also the local roads which we render as white color, and some other type of roads. All of them have the same value which is “A40” at column “cfcc” in .dbf file, the only different is that there is a column “Fetype” in .dbf file which represent feature type in .dbf file which, such as “fwy” represent freeway which maybe the highways, “ave” represents avenue which maybe the major roads and the others maybe the local roads.   
 
There are two choices and both of them only render A40 doesn’t render highwaynetwork2_1b.shp at certain zoomlevel, probably zoomlevel 15-16:
1.       Render A40 as a single style, no matter what really fe-type is, so that all roads will look the same but no duplicate line shape.
2.    Use ValueStyle to allow you to match data in the dbf column value to show different style based on it. We have a sample in HowDoI sample to show how to use ValueStyle.
 
You already have the code for render in WorldMapKitRenderLayer.cs, and also you have WorldMapKit data which include CAlkaA40.shp and highwaynetwork2_1b.shp files, so that you can modify the rendering logic by yourself, first you can use MapSuiteExplorer to display them to know what I said above and then update code at WorldMapKitRenderLayer.cs file, if you have problem with coding, please let me know, please don’t send code directly on the forum, you can send email to support@thinkgeo.com and let him forward to me.
 
Thanks,
 
James

#13

Hi James, thank you for working on this. 



I'm still in the process of understanding the methods. Let me ask some questions. 



Regarding 2), you mean ValueStyle should be determined by FeType column? But as you mentioned in your post, a type "Ave" can be either major and local street, so as "St", "Way", "Dr" , or "Rd", etc (almost everything other than "Blvd"). So then how would you make the rules other than by manually identifying those major roads all over in CA? 



Also, as long as A40 contains all the major roads, how would it be possible to make the fastest routing index from that? 



Kaori



#14

 Sorry there was a typo in my sentence, "you mean ValueStyle should be determined by FeType column?"


------------------------------------------------------------------


Kaori, 



No, I mean set ValueStyle for “FeType” colum, I don’t think there is a column called “FeStyle” in world map kit data, maybe there are many different values for FeType, so you need to add as many as ValueItems to cover all types, of course you can set “ST”, “Way”, “Dr” to the same style. 



As we talk about FeType, even A40 are all major roads, but it still has different type, such as Fwy, Ave, St… so that you can make different FeType to different weight, when we calculate route, it depends on their weight. But the best way is combine all kind of cfcc line shapes together, From A10 to A70. 



Thanks 

James 


------------------------------------------------------------------


Please patient with me, I still don't get it. So are you saying if the FeType is "ST" in A40, for instance, it should be drawn as a major street? But so many non-major street are also marked as "ST" in dbf. Or do you mean I should change the value so that it can distinguish like St_Major and St_Local? If so, it would be unrealistic to look at one street by one street in CA (probably all over the USA), wouldn't it?


BTW I'm not also sure what you meant by "even A40 are all major roads", because A40 currently contains both major roads and local roads..?



#15

Kaori,


I think the ValueStyle is not like you think, it set styles just depends on value, not change the value, did you look at the sample code in our HowDoI sample which I mentioned at last reply. If you want I can write some sample code according to A40 data and then you can easy to integrate to your application.

You said "Also, as long as A40 contains all the major roads, how would it be possible to make the fastest routing index from that?" So I said "even A40 are all major roads", I just want to follow your thought and try to think what you want to do, if there is a misunderstand, please forgive me. So did you try to build fastest routing index as my suggestion?


Thanks,


James



#16

 Well, I have tried and here is a test layer that makes all "St" features in A40 into red lines. So as it shows, it turns to both major and local roads becomes red. So then, where would it go from this point? Simply looking at an existing value of FeStyle column wouldn't distinguish if it's a major road or a local street? Or am I going somewhere wrong?


Sorry "A40 contains all major roads" doesn't mean 'only'. It means "A40 contains all major roads WITH all the local roads together". (I thought it was given factor that A40 has all the local roads.)




#17

Kaori,


I think use FeType with ValueStyle may not a good choice for WorldMapKit data, but it’s a good example to let you know how to render it by using MapSuite API, right now you have already had the roads shp files data and the rendering code, so you could easily to control the result. To avoid duplicate roads, you can adjust styles setting for certain zoomlevels. To make the same shape files render different features, you could use ValueStyle, ClassbreakStyle or your own CustomStyles. And also you could add your own shp files together or other type of data, such as GeoDatabase, S57, etc.
 
Indeed, GoogleMaps use different raw data to render map, our raw data is from Tiger data which release by Census, good news is that the new version of Tiger data have been released recently, we will consider to process it to upgrade our WorldMapKit, hope the new data can fix this problem. If there is not a better way to solve the problem, you may use solution#1 temporary.
 
Thanks,
 
James