wrong coordinates

 

the coordinates in the red light camera for san franscisco are wrong, they sould be in the coordinates area of -122.402598 37.776157 instead they are listed as -77.10293 39.02247

I have sibmited a new list

??

What are you using to conclude that the RLC at Rockville Pike and Grosvener in Washington DC (-77.10293,39.02247) is the one at Bryant and 6th (-122.402598,77.776157 )in San Fransisco?

jgermann, I'm confused.

jgermann, I'm confused. Looking at the file, the RLC camera at 6th and Bryant, SF is -122.40252 37.77604. You have the Rockville, MD one correct.

--
Frank DriveSmart55 37.322760, -79.511267

japaro wrote:the

japaro wrote:

the coordinates in the red light camera for san franscisco are wrong, they sould be in the coordinates area of -122.402598 37.776157 instead they are listed as -77.10293 39.02247

I have sibmited a new list

The latest RLC file has the coordinats for Bryant and 6th St listed correctly as -122.40252 37.77604.

And that file is Redlight Cameras 2015-8-26 from 3 days ago.

--
Frank DriveSmart55 37.322760, -79.511267

wrong coordinates

Please enter those coordinates in google map and you will see and i am going there

wrong coordinates

poiEdit and mapquest and google map

@japaro

These are the fields being discussed from the latest "Redlight-Cameras.csv"

Quote:

...
line 106: -122.40252,37.77604,"RLC - Bryant & 6th","CA San Francisco poi-factory Aug26 15"
...
line 374: -77.10293,39.02247,"RLC - Rockville Pike & Grosvenor","MD Montgomery Co poi-factory Aug26 15"
...

In order to enter these coordinates into www.googlemaps.com, I must reverse the order of the fields because, like most software that uses coordinates, it expects the order "Latitude, Longitude" as its input.

(Note: I have never seen a good explanation as to why POI Loader requires the input order to be "longitude, Latitude", but that is the case and so all the POI files from poi-factory.com are designed with this requirement in mind)

If I enter "37.77604 -122.40252" (without the quotes), I get this URL: https://goo.gl/kZnKwr

If I enter "39.02247 -77.10293" (without the quotes), I get this URL: https://goo.gl/qCK1pl

(I think these URLs will persist - I did the same entries in http://www.mapquest.com/ but I could not make the resulting URLs for the locations persist within this thread. I did get the proper display for these two points, however)

I apologize for being confused - what exactly are you saying is wrong with either either line 106 or line 374 of the latest POI RLC file?

co-ordinates

I know that the lat/lon i get on MapSource or MS Streets&Trips are different from the ones used in the POI files.

I am finding a number of RLC locations in my city to be in error, ie. non-existing, I notify POIfactory giving the line number of the csv file. I had come across one where one street crossed another street twice and the RLC file had the wrong intersection. I used the MapSource co-ordinates and other info to pass on to POIfactory and get the correct intersection posted.

Before I notify of a non-existing RLC, I take the time to make sure my info is correct by checking that intersection out on foot. All RLC locations here have a sign posted warning of a RLC at this location on all 4 approach roads.

In our case the housing and signage for a RLC may be there but apparently the actual cameras get moved around different locations.

--
Nuvi 2797LMT, DriveSmart 50 LMT-HD, Using Windows 10. DashCam A108C with GPS.

that's not true anymore

jgermann wrote:

In order to enter these coordinates into www.googlemaps.com, I must reverse the order of the fields because, like most software that uses coordinates, it expects the order "Latitude, Longitude" as its input.

POI Loader now accepts both the reversed LON/LAT and the normal LAT/LON. It's done that for a couple years now. I believe it started in one of the early 2.7.X releases.

--
Illiterate? Write for free help.

What's Wrong?

japaro wrote:

the coordinates in the red light camera for san franscisco are wrong, they sould be in the coordinates area of -122.402598 37.776157 instead they are listed as -77.10293 39.02247

I have sibmited a new list

Looking at the file, the RLC at 6th & Bryant (-122.402598,37.776157) is in San Francisco, CA. The RLC at Rockville Pike & Grosvenor (-77.10293,39.02247) is in Montgomery, MD. What's the problem? What am I not seeing?

Whoops

Box Car wrote:

...
POI Loader now accepts both the reversed LON/LAT and the normal LAT/LON. It's done that for a couple years now. I believe it started in one of the early 2.7.X releases.

I know I am taking a risk here - challenging Box Car - but this is news to me. I am using 2.7.3.0 (which is the latest version per Garmin)

Quote:

POI Loader for Mac, Ver. 2.3.0, as of Nov 20, 2013, Download
POI Loader for Windows, Ver. 2.7.3, as of Nov 07, 2013, Download
POI Loader Mac Legacy Version for Tiger and PPC, Ver. 2.1.0, as of Jan 30, 2009, Download

see http://www.garmin.com/support/collection.jsp?product=999-999...

POI Loader Help still gives me

Quote:

POI Loader assumes a .csv file utilizes the following format for each POI (brackets [ ] denote optional text):

,,["][@]["],["] [comment]["]

and the Garmin site, see
http://www8.garmin.com/products/poiloader/creating_custom_po...
says

Quote:

The longitude is listed first; then latitude, name and comment. The coordinates must be in decimal format (hddd.ddddd).

?

interesting

--
[URL=http://www.speedtest.net][IMG]http://www.speedtest.net/result/693683800.png[/IMG][/URL]

Coordinates

jgermann wrote:
Box Car wrote:

...
POI Loader now accepts both the reversed LON/LAT and the normal LAT/LON. It's done that for a couple years now. I believe it started in one of the early 2.7.X releases.

I know I am taking a risk here - challenging Box Car - but this is news to me. I am using 2.7.3.0 (which is the latest version per Garmin)

Quote:

POI Loader for Mac, Ver. 2.3.0, as of Nov 20, 2013, Download
POI Loader for Windows, Ver. 2.7.3, as of Nov 07, 2013, Download
POI Loader Mac Legacy Version for Tiger and PPC, Ver. 2.1.0, as of Jan 30, 2009, Download

see http://www.garmin.com/support/collection.jsp?product=999-999...

POI Loader Help still gives me

Quote:

POI Loader assumes a .csv file utilizes the following format for each POI (brackets [ ] denote optional text):

,,["][@]["],["] [comment]["]

and the Garmin site, see
http://www8.garmin.com/products/poiloader/creating_custom_po...
says

Quote:

The longitude is listed first; then latitude, name and comment. The coordinates must be in decimal format (hddd.ddddd).

The forum topic http://www.poi-factory.com/node/32154 gives info on switching the coordinates. PoiLoader version 2.5.4 to 2.6.0:

Added ability to specify a custom POI file's name
Added ability to handle swapped lat and lon values in CSV files
Fixed issue with multi-line CSV files not being read correctly
Fixed issue with extended ASCII characters in CSV files
Fixed issue with reading large gpx and csv files making the application unresponsive

--
Charlie. Nuvi 265 WT and Nuvi 2597 LMT. MapFactor Navigator - Offline Maps & GPS.

Reversal of LON/LAT

Back when Garmin announced this "feature" in 2011 for POI Loader 2.6.0, I sent Garmin support a question about it. I looked in my e-mail archive and I still have their response:

Quote:

Dear Alan,

Thank you for contacting Garmin International.

I would be more than glad to assist you with you question, and do apologize it took so long to respond to your intial inquiry. What this means is that if you mistakenly put in longitude then latitude the POI loader now has the ability to catch this and put it into the correct format latitude then longitude. Please let us know if you have any additional questions.

With Best Regards,

Angelique L.
Product Support Specialist

Garmin International
913-397-8200
800-800-1020
913-440-8280 (fax) Att: Angelique L., Associate #5789
www.garmin.com

Additional solutions may be found at http://www.garmin.com/garmin/cms/site/us/support/searchsuppo...

Original Message Follows:
------------------------
I have not received a reply to this support inquiry originally submitted on 1/28/11. I would like to use the new feature of POI Loader 2.6.0 where the .CSV file can list latitude first instead of longitude first. How do you indicate this to POI Loader 2.6.0?

Confirmation of email submission.

Not only was Angelique L. confused and got the rule backwards in her reply, her answer was not really the answer I wanted to hear. POI Loader apparently uses some type of algorithm to determine if your coordinates for LON/LAT are "reasonable" and reverses them automatically if it determines that they are not. From what I can tell, it does this line-by-line, and not for an entire file. I suspect this is based on the fact that if the absolute value of any coordinate is > 90, that value has to be the longitude. When both coordinates have absolute values < 90, many land based coordinates will put you in the middle of the ocean if you reverse them. So i would guess that POI Loader makes an assumption that your POI should be on land and reverses the coordinates if it falls out in the middle of the ocean. While that algorithm may work in most cases, I don't think it is 100% reliable and is a poor design IMO. It would be better to let the user specify the order with column headings, a preference setting or something similar.

--
Alan - Android Auto, DriveLuxe 51LMT-S, DriveLuxe 50LMTHD, Nuvi 3597LMTHD, Oregon 550T, Nuvi 855, Nuvi 755T, Lowrance Endura Sierra, Bosch Nyon

re: whoops

John,

We old timers know the POI Loader help file hasn't been touched in years and has been proven wrong (well, at least incorrect) several times. Charlie dug up the change logs and it appears it was done back with 2.6.0. That's about the time Turbo started working on EPE (actually I think it was a little after Turbo started the project.)

The ability to swap the two value positions is something I have never really tested. The few CSV files I load I do so unchanged. Virtually every other file is converted to GPX where I do specify which value is in which element of the file.

It's just one of those things no one has challenged and nobody really pays it much attention. Those that write CSV files place the coordinates in reversed order out of habit and those files I do which are posted as CSV have the coordinates reversed because that's the way EPE outputs them from my source file.

--
Illiterate? Write for free help.

Testing of coordinate reversal

I did a little testing of this back in 2011 when 2.6.0 came out by reversing the coordinates in a few lines of a .CSV file, then running POI Loader to see how it handled it. As I recall, it did a pretty good job of correcting the incorrect lines, but I didn't do extensive testing, and I couldn't figure out exactly how it knew which lines were wrong.

--
Alan - Android Auto, DriveLuxe 51LMT-S, DriveLuxe 50LMTHD, Nuvi 3597LMTHD, Oregon 550T, Nuvi 855, Nuvi 755T, Lowrance Endura Sierra, Bosch Nyon

Whoops!

Box Car wrote:

John,

We old timers know the POI Loader help file hasn't been touched in years and has been proven wrong (well, at least incorrect) several times. Charlie dug up the change logs and it appears it was done back with 2.6.0. That's about the time Turbo started working on EPE (actually I think it was a little after Turbo started the project.)
...
It's just one of those things no one has challenged and nobody really pays it much attention. Those that write CSV files place the coordinates in reversed order out of habit and those files I do which are posted as CSV have the coordinates reversed because that's the way EPE outputs them from my source file.

Well, I knew when I posted that I was probably going to wind up with egg on my face.

I was around in 2011 so if you are an old timer, then I must be one also. However, I do not remember the discussion on POI Loader's claimed ability to determine handle reversed coordinates. Knowing myself and having done considerable programming, I would have certainly wanted to comment on the situation where both lat and lon are positive (eg. Bosnia and Saudi Arabia, as alan wondered about).

BUT, it would seem that POI Loader is able to correctly swap reversed coordinates for the US.