Cross Streets

Well, I was surprised to see that "coordinate variance" seems to be in raw coordinates. You might consider converting this to miles and/or kilometers at the user's discretion. North-South this is easy, East-West a little more complicated because the degrees to miles calculation changes depending on how close to the poles you are. But you have a computer handy, it can do the calculation for you, so it should be a simple programming issue.

When you report the duplicate lines in the program window, you don't tell us both conflicting lines, just the line that error conflicts with. It might be nice to give both lines, in case one of the lines has data that the other lacks. And there seems to be no way to get this information out of the program, it would be nice if it were written to a file, or if it could be copied to the clipboard (but I was unable to do this).

At first glance it does look like the file that I wanted this for could stand some additional cleanup, but it is hard to tell for sure without knowing both lines that are in conflict.

If you do the coordinates to mileage calculation, it would also be nice when reporting conflicts to tell the user how far apart the coordinate pairs are.

I think that is a perfect idea. Please send me the code. Much thanks.

I have no problem writing all of the duplicate lines, I had that originally, but found it somewhat confusing when 2 lines were referencing each other. I also have writing the output to a file in my "todo" list, but I'd rather do a couple of more functional things before I start working on things that are niceties.

As far as doing the variance in miles, I can see how that would be useful. I'll put it on a request or todo list, but it's going to be pretty low. To me having a raw coordinate variance gives the user more granularity. I would be willing to put a info box showing that 0.025 ~ 1 Mile, or something like that.

I found this site, and could put something similar on the programs page.

http://www.offroaders.com/info/tech-corner/reading/GPS-Coord...

I don't think I was clear enough on what I was asking for. I would not want 2 output lines for 1 duplication. But as it is now the program prints a message when it finds a duplication, but it only says what line in the csv the duplication conflicts with, it does not include the current csv line that is causing the duplication. I would find it more useful if it reported both line numbers in one report ("line 520 duplicates line 301" type information) and if it gave either the coordinates or the computed distance in fractional miles, all the better.

Getting the duplicate list would be handy for anyone who wants to be sure other information is not being deleted in the new file. As it is any single line in the output window can be selected, but there doesn't seem to be anything that you can do after selecting the line. If the entire set of lines could be selected and cut to the clipboard, that would be enough to let a user capture the data. Otherwise a feature that writes the data to file during processing, or a menu item or button to write the window contents to a file after processing would be great.

I'm not sure why you feel that the user gets more granularity when working with raw coordinates, as long as you would accept enough decimal places after the "." then either format should be able to easily deal with numbers up to gps accuracy. Obviously either form needs to accept a decimal part.

A notation to help the user convert between degrees and miles may be better than nothing, but but .014 = 1 mile is only roughly true for one of the coordinates, the other varies depending on how close you get to the pole. You could give the user a more complex table of conversions based on where they are, but they may be doing a large POI set that covers a big area (large enough that the conversion could be significantly different between the morthern and southern locations), and since you already have the coordinates in the csv file you already know both the lat and long and could compute this directly rather than ask the user to deal with a table and make conversions.

It is really not that complex to do the math. I'm not a C# coder, but would be glad to write it up in C if that would be any help. My contact e-mail is active if you want to send me any guidelines (variable names and such) that I should code towards. I doubt that you could just plug it into your code, but it might save you some time to have code to work from. Or, if you can just call a function with 5 parameters (lat1, long1, lat2, long2, variance), I could write a C function that would return a logical result. Better yet, just pass me 4 parameters and let me return a mileage, that way you would have the distance between the points for the error report.

Doing it this way would not be the fastest, most efficient way to write the code. If I were writing it I would first test the difference on the longitude and see if it exceeded the user's variance (in miles). If it did then there would be no need to check along the latitude, compute the different factors for closeness to the pole, and a lot of squaring and square root calculations could be avoided. You would get faster code this way, since you don't really need to calculate the difference between the two points as long as you know it is greater than the desired threshold. And since for n points in a POI file you end up doing ((n-1)^2)/2 comparisons, keeping the comparisons efficent can be important for large POI sets.

I think having the specific information is helpful and useful but I do have another view on this.

I personally use both the Red Light and Speed Alerts as a reminder, not for avoidance. I don't need to know exact locations and which corners. No one should be running red lights -- ever, so the "bong" should be enough of an alert to remind us to stop (or not speed). (I do like the feature if it will eliminate the alerts as we go along a highway and the intersections underneath have cameras).

However, more information is usually better. We just need to be sure to use it for "good" and not "evil"!

Some more thoughts on this issue:

Since the lat and long conversion factors are different, if you do advise the user of the conversion, then you likely would want to let them input different variances for each. This seems needlessly complex, and still does not address the issue of what a user would input for a POI set covering a large area. For example, if you were checking a POI file of the hot night life spots in Salt Lake City you could use just one value for the latitude and get pretty good results. But if you are checking a POI file for Starbucks in North America, the latitude could be as low as 25 degrees (or even 19 including Hawaii) and over 49 degrees for the 48 states, and as high as 71 degrees if you include Alaska (no offense to Canada, which will also get into the higher latitudes). Just what conversion factor would a person use if they were checking a national file? By comparison, the computer already knows the latitude of each set of points, so it can do this conversion automatically.

If it would help, let me offer the following formulas that I would use in doing the conversion:

ymiles = 68.98 * abs((lat1-lat2))
avglat = (lat1+lat2)/2
xmiles = 69.27 * cos(abs(avglat)) * abs((lon1-lon2))
miles= = sqrt(ymiles*ymiles + xmiles*xmiles)

Formulas given in degrees, if radians are needed it is assumed the programmer makes the conversion. The absolute value (abs) is taken to allow for negative lat and long values, and to allow the comparison to be done in either order.

While I appreciate your enthusiasm and the time you have put into thinking about this, I don't know that my motives for writing this program are clear.

I don't disagree with anything you are saying in that they would make the program better. But to me, this program is playing around, I'm getting more familiar with the language, and hopefully something useful can come out of it in the meantime.

If this was commercial software that I was charging people for, I would do this in a heartbeat, but I'm doing this for fun in what little free time I have. In my opinion the program gives the necessary granularity as it currently is, and having variance in miles would be adding complexity for no functional gain. I'm not saying I won't ever do it, just I'd rather play around and do more useful things like convert from \n to < br >. It boils down to I wrote this program because I wanted this functionality, and I will happily continue to take suggestions to improve it.

By all means, do what you want and you feel will give you the most enjoyment and the best experience with the language. You did solicit suggestions, those were mine.

While you have your own priority and others likely have theirs, my priority would be:

1) Put both conflicting line numbers on the same error line, can't really track conflicts without this.

2) Provide some way to output the conflicting line information.

3) Deal with the variance in miles. I'm sure the program would still be of use without this, but actual distance is what users should care about, not a coordinate system where X and Y are different measurements. Anyway, I posted the calculations needed, so if you get interested in doing math in C# the ground work has been done for you.

4) Any BR cr/lf issues.

I updated the file tonight. I've had it close for a couple of days, I just hadn't had the time to try to get it good enough to upload.

Make sure you save off the old one before downloading this new one. I haven't had the time to test it that I would have liked, but the situations I tested it worked fine.

It will now convert from the text style newline to the HTML style newline. It will not convert from HTML to text style yet.

It will create a log file for what duplicate lines it has found. It will also list the line the 2 lines that are duplicates.

It worked for me.

I suggest that you try it against the data here:
http://www.poi-factory.com/node/10042

You'll find that some data is truly duplicated (lines 60 and 61 for example). I also saw a number of locations that seem to be separate locations (even after refining the variance). Running against real world data will provide good feedback on issues like knowing how far apart the variance is, as well as seeing how the program behaves while processing. I'm inclined to think that maybe writing the new file is not the proper approach; in most cases these "duplicate" points will need to be checked manually, both to determine if it really is a duplicate and if so to determine which of the pair to remove.

The written conflict log is indeed handy, gives a good way to go back and do those checks.

I have the first beta test file up on the site now for Active members. Once we work out the kinks I will post it for subscribing members. If you are a subscribing member and would like to be part of the beta testing , send me a note and I will send you the file.
This week’s zip file now contains 3 files, the two original and the new file (named “Redlight-Beta” ) containing cross roads. The new cross roads file does not contain the identifying code that the other files do.
If you are using the new file make sure you don’t have the old version loaded or you will get double alerts.
The street names are shortened to take up less space on the GPS screen. This was done automatically by dropping directions and street types (e.g., E 54th AVE -> 54th). Some did not turn out so well, and I will need to go back and manually fix these.
I would like to know how the new file looks on your unit and if you had any trouble loading it.

Thanks,
Miss POI

Count me in!

I'll beta test it for you.... got a nuvi 760, in case you need to know.

The beta file looks very good on the 770. I find the location information quite useful. Of course, if we could add the direction of the camera it would be even better.

Note that there are still duplicates between it and the speed camera file. How should I report the ones I find (not quite sure which file they should be in though)?

The beta file looks great, much more helpful than the camera codes.

My preferences follow:

Extra spaces to a minimum -
RLC:Main St & Simpson Pkwy
RLC:SR510 & Blue Mountain Rd
Setup for POI Loader -
SC@55 MPH:Hwy 18 W
SC@100 KPH:Somewhere in Canada
I think the space after the speed digits is necessary.

It would be nice if the street names matched those on the Navteq/Garmin maps, e.g. Hwy 18, I-30 E, etc.

The problem with combos is that if you are traveling under the speed limit, you won't get a redlight camera alert.

Maybe it would be best to separate them and have an entry for both the redlight camera and another for the speed camera with alert speed.

Illinois is going through legislation right now to allow all redlight cameras to also be speed cameras. This could make things more complicated if there are many more combo cameras.

This should be helpful in both identifying the known ones, weeding out any errors and adding in new ones.

Thanks, very much appreciated!

I downloaded the 3/18 version with no problems. Having the intersection name is just great (in my opinion).

My only suggestion would be to change the text so the street names are in mixed case - e.g.
Change "RLC - DIXIE & STEELES" to
             "RLC - Dixie & Steeles"

My personal preference has been to display cross streets. In the past I've edited the ones in my area, added the cross streets and tweeked the location (using GeePeeEx Editor).
This beta version saves me, somewhat. I've noticed some locations will have the Highway # as well as the Named version of the road. Example: Hwy 174 Wilshire Blvd and Newton Dr.
It's still an easy edit. Everything looks and works as advertised on my C550. I haven't had any problems with it.

I have been using the cross street converter program since February and it worked great. Since about a month ago it stops converting after 2 items are completed. Is my program corrupted and if so, where can I download it again. Or is something now being inserted into the camera download to prevent it from working. Anyway it is very useful in a congested area. I thought that eventually the cross streets would become part of the camera download since it so useful and would require only one conversion rather than every user doing a conversion. Thanks.

I would like to be part of the beta testing project. I use my GPS constantly and have been using a GPS for a long time starting with the Garmin GPS II, which almost everyone thought was magic when they saw it.

Just download the camera file, the beta is included.
It amazing how people confuse magic for technology.

The red light file I download idenitifies intersections by code # only, and no intersections are listed by streets either on gps or .cvs file when opened in excel. My cross street converter downloaded 2/14/09, which worked great for months, has not worked for past month. It stops and freezes up after 2 items are processed. Is there anyway of getting a replacement from a link on this or any other site you know of?

If you send her an email it will get acted upon much quicker.

How do I get the beta evry week ?
I'm not sure what is an Active member and how your points work.
until now I sent you 9 Redlight locations
county club & william lehman Aventura FL
" " & 199 st " "
199 st & biscayne (US 1) " "
191 st & " " " "
ne 163 st & 18 ave Miami "
ne 10 ave & miami beach blvd " "
ne 151 st & biscayne (US 1) " "
miami garden& 2 ave " "
federal hwy & hallandale beach blvd Hallandale "
Also 2 locations to remove

yay~ thank you so much for contributing.
its really nice to have communities like this here

The following is taken from the FAQ file (emphasis added):

Becoming an active member is completely free.

You automatically become an active member when you've made posts in at least 3 of the last 5 weeks. Activity includes uploading POI files and/or posting in the discussion forums.

The weekly posting periods run Monday through Sunday (Eastern timezone). Active member status is updated once each week (on Monday mornings).

If timing of your first post is lucky (Saturday or early Sunday), you can become an active user in just a little more than 2 weeks.