Hi,
I've got a procedure that tests if any point features in an in memory feature layer collection are near to a line shape that I specify. The procedure seems to work great most of the time, but when the line is oriented exactly 0 or 180, the query results sometimes misses 1 of the points that should be included.
Can you please investigate?
Thanks,
Damian
Hi Damian,
You are not alone, struggling with the same problem, it also occurs if it is 090 or 270!
John
Thanks John,
Glad to see someone else out there can confirm the issue. Let’s hope for a speedy resolve.
Hello Damian,
Thanks fo your post, could you please provide your test feature wkt or wkb(including the lineshape and pointshape) to me that I can recreate it?
I appreciate your help.
Regards,
Gary
Hi Gary,
Attached is a test project to simulate the results.
When the program runs, it loads the line and points from 2 shape files in the data subdirectory. The line is oriented 0 degrees and the points fall along the line as can be seen in the map.
In the tool strip area, there is a text box that allows you to change the search distance of the GetFeaturesWithinDistanceOf function. After you set the value, click the button saying "Get All Points On the Line".
With 1000m default search, you will see 1 of the points is not found. If you set it to 500m, you will find 2 points not found. If you set it to 250m, you will find 6 points not found. When the search is big enough (~1250m), you get all features returned.
It is definitely an error with the method as you can quickly scan the debug output of the converted features of each InMemoryFeatureLayer and see that they have identical X coordinates and that all Y coordinates for the points are inside the line Y coordinates. Sorry the test code is full of reprojections, but in my project I do a lot of converting to UTM from spherical mercator and I wanted it to be as close to my project as possible.
This only happens when you are at exact line headings of 0, 90, 180 and 270.
I am using 6.0.0.149.
Regards,
Damian
ThinkGeo_ZeroHeadingError.zip (48.7 KB)
Hello Damian,
Thanks for your sample, this is a bug about precision, the lineshape you are using, they are almost heading 90 but not exactly 90 degree, like:
Start Point: 529212.589195103 9692095.21456987
End Point: 529212.589195107 9733095.21456987
You can see their X coordinate just has a little difference.
Now we have fixed this bug and you can get newest dll 6.0.236.0 and have another try, we don’t synchronize to release branch immediately so please use development branch temporary.
Let us know if you still have the problem.
Regards,
Gary
Hi Gary,
I think there is an issue with the distribution site. The daily production builds have 6.0.0.236, but on the development builds there is only 6.0.235.0.
At any rate, the 6.0.0.236 production build did not fix the issue. Maybe your changes did not make it in this version?
Regards,
Damian
Hello Damian,
Sorry for the inconvenience, our auto build package about development branch failed yesterday(6.0.236.0), the one you are using is release branch(6.0.0.236), so as I said above "Now we have fixed this bug and you can get newest dll 6.0.236.0 and have another try, we don’t synchronize to release branch immediately so please use development branch temporary. " the release branch didn’t change, you can try today to get 6.0.237.0 or later(if failed again, you can wait 6.0.238.0).
We will try to make the build successful today.
Regards,
Gary
Hi Gary,
Now I’m really confused. Why is the Production build number higher than the development build number. Doesn’t that suggest that the production code is more up to date than the development??? Right now, the site has 239 for production and 238 for development.
If that’s not the case, then how am I supposed to know when my bug fix is included in the production build so I can deploy my solution??? The FAQ does not address this.
I confirm that 238 development does fix the issue, but the 239 deployment does not.
Regards,
Damian
Hello Damian,
Sorry for the inconvenience, so we have development branch(6.0.xx.0) and release branch(which you call it production and the version number is 6.0.0.xx), in the normal situation they should be the same number and build the new version everyday, but sometimes because network problem, build problem or some fix cause the problem that one branch will failed, this is why you have seen the release branch version 6.0.0.239 but development branch only 6.0.238.0(this time the reason is the network delay, so release branch upload finish first, if you can check your helpdesk now you will find out that 6.0.239.0 is ready for download)
And for our bug fix mechanism, once we have fixed a bug, if we can confirm it without any doubt, we will synchronize to the release branch immediately, otherwise we will wait user's response or double check after several days. So for this situation, you have to use development branch temporary.
Another situation is we have added some new feature, avoid to have the breaking changes, we only apply it in the development branch and never synchronize to release branch until next public release(7.0 next time)
For your problem now, we have synchronize to the release branch today, so you can choose either development branch or release branch after 6.0.240.0(6.0.0.240)
Let us know if you have any queries.
Regards,
Gary
Hi Gary,
I’m still waiting for release to update in the customer portal. It says 6.0.0.228 right now which is really off. I’m not in too big a rush to get this fix, but I wanted to make sure someone knew it’s been messed up for quite some time now.
Regards,
Damian
Hi Damian,
I just checked the daily builds for your account and a 6.0.0.242 version is available. Please let us know if you have any issues accessing it.
Hi,
Somewhere along the line, this error has gotten back into version 7.0. Can you please take another look at this?
Regards,
Damian
Hi Damian,
May I make a confirmation with you? Is the problem "DailyBuildProblem" or the "FunctionalityBugProblem"?
Waiting for your further information.
Best Regards
Summer
Hi Summer,
It’s the functionality issue regarding precision. The GetFeaturesWithinDistanceOf returns inaccurate results when at 0/90/180/270 degrees. You can use previous attached project with current production libraries to confirm.
Regards,
Damian
Hi Damian,
Thanks for your further information, now we are looking into it, it might need a little time before we figure it out.Would you pelase wait a little while. Anything new will be updated here immediately.
Best Regards
Summer
Okay, thanks Summer.
Hi Damian,
Thanks for your waiting, we have fixed this problem would you please get the latest dll package 7.0.117.0 or 7.0.0.117 and try it again?
if you have any more question , please feel free to let us know.
Best Regards
Summer
Thank you Summer. I can confirm that the fix works.
BR,
Damian
Hi Damian,
Great to hear it is sorted out, if you have any more question, please feel free to let us know.
Best Regards
Summer