Cross Streets

I can see where converting the coordinates to determine the cross streets would be useful, especially when the camera is under or near a freeway and the proximity alert goes off.

I expect that I would find it useful, as often the intersections are closer together than the trigger proximity.

Can your code only give the cross street, or could it perhaps be set up to give the full intersection (example: Main and Capitol)? If that can not be done then it would be nice to include the Camera ID, as the cross street may not be unique enough to find a POI in the file if it needs to be edited. If Miss POI does not want to make this change for the main file, would you be willing to provide the code so that we can update our camera files after we download them?

It sounds very interesting and would be especially helpful if it populated with the intersection streets, not just the cross street?

What is it written in? Would like to see it and look it over?

Knowing the street names would be great so I could watch for the street signs and verify that there are red light cameras in those areas. Please share if you would..

Be Well
Rayzers

I wrote it to say something like

"Main St & Michigan Ave"

Right now I didn't include any of the unique camera information, but I can put that in the comments to make sure we don't loose any of the info that Miss POI has kindly spent the time building up.

I wrote it in C#. It's pretty simple and crude at this point. It just queries a website that returns the cross streets in XML. I then parse the XML page and re-write the CSV. I can see that one of the first problems is going to be a speed camera that is on a highway. Since I'm just sending a HTML request with the coordinates it's always going to return the cross streets. The only way I can see around this is to embed something in the info to say it has no cross street and is on a highway.

I will see if I can find a way to post the executable here on the website or some other means.

Please post up a link to the app. I also would like to see the code if possible.

The idea of the street name announcement is great. The bong sound is ok but having street names will be cool. Good work grenvoy!

I agree... Great Work!

jb
Atlanta

Can't wait to have updated files.

Now with more and more intersections getting these cameras, I am running into multiple lights on the same street and they are triggering the first warning for the following intersection before I get through the current one. Trying to balance distance to avoid this with providing enough distance for a high-speed road was not working. Great idea. I would be interested in seeing the code too.

thanks for your effort

Great idea.

This would be a problem with speed cameras that are often on a highway or even a back road, but would not be an issue with red light cameras. I think the improvement this could make to the red light file is great and will be very welcome.

I would suggest, that with the full intersection name the screen is likely cluttered enough, but I would hope that rather than discarding Miss POIs custom designation for the camera that you move it to field 4 of the csv file, so it can still be easily found for reporting and updates.

I too hope that you are willing to share the source code. If you post an executable too that would be nice, but people are rightfully cautious of running new exes they find on the web and many may not take the precaution of running them in a disposable virtual machine to be safe. And others may even build on your work and surprise even you by building on your work if you open source it. And I really hopp that Miss POI considers replacing the current file with one that you have processed, it sure would be nice to have the downloaded red light file come formatted this way.

Jon and I have all the data, we just don't post it because we like to keep track of where our file is winding up on other sites. At this point it is very obvious if someone is reposting the file on a competing site.

We are going to have a meeting regarding this and if we decide that we are now comfortable having all the data shown we will just flip the switch that will list them when you download the file.

No special coding software needed.

Miss POI

I don't have much of a problem posting the source code. Like I said before it's not a very complex or rebust program. Just a couple hours of playing around to make the file more useful. Sorry I didn't realize I was reverse engineering what made the file easy to track on competing sites.

I told Miss POI that I would hold off on doing anything until they make a decision. Depending on what they decide maybe the program will become useless anyways.

This would be great news to me, and I'm sure others would like having this info on our GPS when truckin in the cities....

sounds like that could be a pretty useful method. but at times it could be confusing with all the street interestions and extra data on the screen.

Confusion can be minimized by using a custom audio alert and custom icon, in most cases you would not even need to read the text. But in the cases where you get an alert and really wonder which intersection the alert is for, seeing the street names could be much better than a cryptic designation. I would suggest dropping street or avenue and just go with the street names to keep strings shorter, and I would move the cryptic designation to field 4 (I don't think it will be needed on-screen if you have the intersection name).

After thinking about it some more I have posted the program on a file sharing site. For now I don't want to give out the source code, so I'm sure some people might not be comfortable downloading the program an running it, but I thought I would at least share the executable for now.

The way I see this is a best of both worlds. Miss POI doesn't have to open up her file so everyone has all the details, but people who are active here and read this will be able to get a more useful file if they choose to.

http://www.4shared.com/dir/12695636/f117fa3c/POI-Manipulatio...

It's crude, but for the most part it should be self explanatory. Select the file you want to convert, put what you in the name of the file it will create and hit convert. When it's rolling well it can do about 2-3 per second. It uses the internet to get the cross streets so it will need access to the web.

After reading the thread about RT retiring his software because of criticism, I'll give this simple disclaimer. Use at your own risk, if you don't feel comfortable running it, don't. If you think it could be better I'm open to suggestions. If you don't like it, feel free to delete the copy you download.

Sounds like a great idea, but the download link is broken.

WOW works perfectly,, lots of fun. Very smart and useful,,,many thanks!

I'm not having any problems with the link. Is anyone else?

Did you click the link or cut and paste?

If people are having problems I can try another site to host it.

I did have a problem with the link in that when I finally got to the actual download link and clicked on it, I was looped back a screen and had to try again. Not sure why, but it worked fine the second try. I was only clicking, not cutting and pasting.

The program ran fine. I ran it in a virtual machine running a beta of Windows 7 (nothing against you, just careful about what I run from strangers). I was surprised by how small the program was considering normal Windows bloat. It ran fine, and had no problems with Windiows 7 (doesn't run under Win 98 though).

I did notice that the resulting file adds a true line break in field 4. I wasn't sure if this would be a problem or not, as my nuvi (and as far as I can tell most nuvis) want the < br > breaks rather than true line breaks. But the resulting CSV file with line breaks didn't cause any apparent problem, the line break seems to be ignored and field 4 displays as one long line. If you chose to release the source I expect that I would go back in and make it output the < br > form of line breaks for myself, but it's not worth the trouble of editing all of the file to manually replace the line breaks.

I just converted the red light file, did not mess with the speed camera file.

Thanks very much.

Jon and I decided we will start including cross streets in the file, and I would like to get some suggestions on the best way to format column 3.

Examples for discussion:
RLC - Main St & Simpson Pkwy
RLC – SR510 & Blue Mountain Rd
SC 55 MPH – Highway 18 W

Ideas/possible issues:

- Keep short enough to fit well on the screen

- Consider formatting speed cameras so POI Loader sets speed alerts

- Keep things easy to convert to TomTom or Magellan (Magellan needs unique names)

- Any ideas on how to handle RLC / SC combos?

After we come up with a good format, I can make test files for some general maintainers who want to assist in the problem solving process.

After it's well tested, I will start publishing the weekly files in the new format.

I want to know what your thoughts are.

Miss POI

For the combo cameras, perhaps R-SC or S-RLC. R-SC only adds one character.

It's a PITA, but in your examples, SR510 & Blue Mountain Rd can be further shortened without loosing any info to SR510 & Blue Mtn Rd which I believe fits with the USPS abbreviations.

I'll have to play with the new gadget (Genavoy?) put out for adding cross streets to see what works on my 3.5 inch Garmin screen.

I'm sorry that the text wasn't displayed on separate lines, I guess I'm a little confused as to what the GPS expects.

According to the Garmin CSV file format page on this site,
http://www.poi-factory.com/garmin-csv-file-format

One would "simply insert a carriage return (enter key) where you want the lines to break."

If I edit the file in Excel as described, Excel inserts a "newline or \n" character not a "carriage return or \r". I have tested both ways with the program, If I manually look at the POI it appears that the lines are separated with both a newline and a carriage return.

I will gladly change the output of the file, but it seems to be a mute point since it will be included in the base file now.

It is not a big deal, as the file does work. See this thread for more details on what each nivi model expects:
http://www.poi-factory.com/node/19757
Sadly Garmin wasn't consistent in what they do here.

The bottom line is that most models expect a <br> rather than a true line break to put a line break on screen. And I find it simpler to make the files with the <br> rather than the true line break, as it is simpler to replace all <br> with a true cr/lf if needed than to go back the other way (since there are other real line breaks in the same file).

But other than not breaking the long line into two as apparently you intended, this is working great.

I'm really pleased you are going to include the actual intersecting names of the roadways that will be involved:)) For a few months last year I was trying to keep up with your file by actually looking up the co-ordinances of each file, then deleting your code and inserting the street names in their place. Also I did this for the state of Illinois only and deleting the other states as I dont travel that much. After the second month I gave up on all that work and just starting keeping the file as the POI Factory set it up, so I'm glad for the new info.

Oddly enough I used the same abbreviation RLC (red light camera) before the two intersecting streets and usually put them in Alpha order, i.e. Maple & Oak. I also never used the designations of Street/St Road/RD Boulevard/blvd,and others, because since I would hear the alert I would briefly look at the unit, see the cross streets and then look back to verify that upcoming location through my windshield. Having the file included St, Rd ,Blvd etc., in my view really is not necessary and could in fact lengthen the time it takes view the info on the GPS. My mind knew what name/names to look for, and since it was coming up I felt having the added info that it was a street, road, or whatever really didn't matter to me. Since a RLC is always at crossroads with a traffic light, I don't think its going to be without signs letting you know what the names of the roadway/roadways are coming up. A_user's suggestion about US postal abbreviations is a good suggestion also.

Less time reading, more time scanning you driving field of vision.

I could not agree more -- short and sweet is the way to go.

That is the first that I had heard of the Nuvi using the < BR > syntax rather then standard cr/lf. I find it odd to use HTML syntax in a CSV file, but all the same I have updated the program to use this, this way if anyone wants to use it before the official updated file is released they can.

Thanks. I assume it's the same link as the old file.

Yup, same link. I'll probably leave it up until the new RL file is published.

In NYC we do not have speed cameras (yet), so I cannot offer any solid suggestions on those.

For red lights, it's my personal experience that it is more important to know the street and direction then which corner.

For an example, if the camera is located in the West bound lane, then only traffics heading West bound needs to be concern about the camera, which corner really does not matter because it will effect all of the west bound traffic. The cross street is also secondary.

I do not know how easy it will be, but maybe the street format can be as follows:
Main St (E), Northern Blvd

The format will take the form of street followed by the direction of traffic the camera is capturing, followed by the cross street.

This may help the driver to determine if they should be extra careful or not based on the first street name and direction of travel.

jc

I would find it useful as I have had the alert go off and I looked all over for the camera, only to find it was a block or two away at the next light. Short and sweet would be the simplest to read and understand. Thanks!!!

strange issue: I just tried the new version of the program with the same input file that I used before, on the same virtual machine that I used before. It ran, but only produced 6 output lines. Then it stopped, reporting that it had processed 6 lines and was done.

Also, I'm not sure if this is going to be an issue or not. I noticed that the break in those 6 lines is done with a capitalized BR and not a lower case br. I'm not sure if the case matters, maybe it does not, but the references I had seen always called for lower case br.

Sorry I had the test flag set. When I'm trying to test the output I only have it print out 6 lines, that way I don't have to wait 10-15 minutes to see the output. The updated file should do the entire file.

The link that you posted by RT referenced and example CSV that showed the < BR > being upper case, I just went with the example that RT referenced.

http://www.poi-factory.com/node/19698

Let me know if it doesn't work.

thanks to everyone, this cross street idea is a great one and thanks to Miss POI for making future changes in the output

Sounds like a great idea, especially for the red light cameras at intersections. One problem that I come across quite often with the speed cams here in Phoenix (on freeways) is that regardless of which side of the road I am on, I get the warnings. If the direction of travel was included in the warning bar (for example: Speed Camera 65mph I-10 Westbound), that way if I was traveling Eastbound I would know to disregard the warning... IT WOULD BE ABSOLUTELY INVALUABLE!!!!

Is there a way to add this? An abbreviated "WB" or even just "W" would be awesome! Thanks in advance.

Yes, I have most of that information in the file, so it should show up.

Miss POI

I just converted the last version of the speed camera files using grenvoy's gadget and will do a little testing this afternoon. With the intersections I will be able to get you some speed limit data for streets in my neighborhood as well. So having cross street information will do a lot toward making the base file more accurate and helpful as well.

Sounds great, I appreciate that.

Miss POI

That seems to have done it, processed the entire file. POIs loaded into the gps now have the intended line break on the screen (no problem with the case of the BR). I'm not near a red light but looking forward to the next time that I drive through an area where they are.

Thanks again.

Adding cross streets will make the files much more useful. I understand why you hadn't in the past and agree with your viewpoint, however, I am glad you have found a path forward to allow this information to become available!

I did run grenvoy's program, and it created cross streets for me in just over 12 minutes.

I think a naming convention / strategy will be very helpful, keeping the string length as short as possible, without loosing important information.

Part of the reason I wrote the POI Cross Street program was to play around with C# (historally I'm a C++ programmer). That being said I wanted to keep playing around and so I wrote a program that will find duplicate entries similar to the POI Verifier. It prompts for the file, variance, if it should delete or just note, and if it should create a new file or overwrite the old.

Before I clean it up at all, would anyone be interested in this? I know that RT shared a version of POI Verifier that will verify, but he had said that the duplicate finder was not part of it.

Just let me know, if there is interest I'll clean it up and post it, if not I'll just keep playing around.

I was not able to get the cross streets in this week's update, it will take some programing to get it working.

Miss POI

I would be interested in trying it, I expect others would be as well.

I have cleaned up the program enough that I feel it can be useful.

http://www.4shared.com/file/88553842/bf19931a/POI_Modify.htm...

I know it has some issues with multi-line entries. Meaning if the file is formatted with one field that is split across 2 lines it will not work.

Let me know if you would like to see anything added. I'm thinking I'm going to fix it so that it can handle a file with carriage returns. I'm also thinking I might add a way to convert a text line feed to the HTML line feed .

I'm interested in trying the proximity thing. I know the file that had a problem with this issue has been cleaned up and the problem has likely been resolved, but it will be worth checking just to be sure.

Will want to run the same test against anything that I contribute too, just to be sure. CR/LF to <br> would be nice, and <br> is the form that my model nuvi needs, but I expect others might want <br> to CR/LF, since most csv files seem to be in <br> form.

It shouldn't take me too much time to get the program able to read multiple lines. It's just a matter of thinking about the most generic way.

Thanks so much for taking the time to do this for the community! I will try it out soon...