Select to view content in your preferred language

Polyline and Point Feature allignment

1002
7
06-22-2010 02:00 PM
JohnPolkinghorne
New Contributor
I work for a company that does an advanced version of Google Street View. We have vehicles that take panoramic camera pictures every 10 meters and creates a point shapefile that represent each day of driving. Each point shapefile can have 10,000+ points in 10m intervals representing where the vehicle took pictures in the target area that day. I also have a polyline shapefile that represents every road in the target area. To ensure we have complete coverage of a target area we look at the point file and polyline file and see which roads do not have camera data overlaid on top. It would take forever to look at every road because we have thousands of kilometers of data. Is there any way to use ArcToolbox to see which polylines do not have corresponding camera points? I can clarify the situation if needed.

Thanks for any help!

Here is a screen shot that might explain better the situation. The green dots are the capture points and the blue lines are the roads.




Jack
Tags (2)
0 Kudos
7 Replies
KatharinaDubach
Frequent Contributor
I think you could solve this by a simple "Select by location" query:
Select all roads that overlap points (with a reasonable buffer of some 10 m or so, since roads tend to be several meters wide and there surely are some errors in your road data and the GPs-points of your vehicles.)

Depending on your road data you may have to split the data into segments first, so you can see which parts of a long road have been covered.

Hope this helps.
0 Kudos
JohnPolkinghorne
New Contributor
I've tried this method but it doesn't work quite right. I put in different buffer levels (1,2,3,4,5 meters) and it selects roads that haven't been driven. I think it's because an intersecting road that hasn't been covered could be within the buffer zone. I talked to an ESRI representative that told me about a point to line script to convert the points but it needs to have a sequential numbering system to know which points form a line (which we don't have). I'm not sure what else to do... Any other thoughts?
0 Kudos
KatharinaDubach
Frequent Contributor
I see. I was sort of guessing the intersections could spell trouble...

Do your photos have time stamps? You could probably use those to create sequential numbers and move on from there.

Going back to the inital idea with the select by location, I was also thinking if there was a way to distinguish roads that have one or two overlaps (from intersections) from roads that have dozens or even hundreds of overlaps...


... different idea again: create a feature class of all the intersections (points) then do a select by location of all your photos within 10 or 20 m of those intersections. Revert the selection and export those as a new feature class. This excludes all photos that are (too) close to an intersection.
If you do the select by location that was my first idea, you should get the desired result...

Hope this helps.
0 Kudos
JohnSobetzer
Honored Contributor
You might see if running an erase of your roads with the buffer gets you the info you need.  Or if you don't have the erase tool run a different overlay and query your results for areas without overlap.
0 Kudos
KatharinaDubach
Frequent Contributor
Picking up on Johns idea: create a buffer around your points, then do a select by location, selecting all roads that are completely within the buffer, finally inverse the selection. Now you should be left with all roads selected that have only partly been photographed or not at all - with the possible exception of some very short road pieces that fall within the buffer tolerance.

This should defiietly get you started!
0 Kudos
NobbirAhmed
Esri Regular Contributor
" ... see which roads do not have camera data overlaid on top" - could you elaborate what would be the logic of 'see'ing? I mean how can I instruct a program to 'see' the way you see? From the previous posts I guess: if a point is within a certain distance from a line then that point covers the section of the road. The problem arises when a point is 'close' to two or more lines. See the screen-shot below where I have three streets meeting at a junction and our gps point is almost equally away from the junction.

[ATTACH]1507[/ATTACH]

This point is within the buffer distance (say, 3 meters) - which road should I assign it to? Kathi wrote '... roads tend to be several meters wide and there surely are some errors in your road data and the GPs-points of your vehicles' - how do you reconcile these two issues with your selection criteria?
0 Kudos
KatharinaDubach
Frequent Contributor
Nobbir, what you say is correct, but I think you haven't quite understood the problem. Look at the screenshot in Johns first post: It should be clear that there are roads that have been photographed and others that haven't. In the absence (I assume) of any kind of list stating which roads haven been covered and which not, John wants to use GIS to filter the roads according to photo coverage so that he can find "holes" in his coverage and plan further photo routes accordingly. Call that process "filter" or "see, which ones" or "selection process" or whatever you like.

You have hit the point that photos near (or at) road junctions are the tricky ones and it's definitely not clear which road segment they should be assigned to. But if you think of the process - you drive along a road and take photos every 10 m, obviously also taking shots on or near intersections - I think in this case it's irrelevant which road you assign the intersection shot to. I would simply exclude those and concentrate on the ones that one can clearly assign to one single road segment.

To account for the above-mentioned uncertainty in GPS points and road data I suggested to use a reasonably-sized buffer for the selection process. Yes, it's all about translating an idea or action from everyday life that seems quite simple into a GIS environment. Whether you use the "correct" terminology (if it exists) to describe your problem is in my eyes quite secondary. But to translate the issue into a GIS concept in a correct manner is the critical part - and the part that makes working with GIS interesting.
0 Kudos