*NOW FIXED* Heading Errors in the MIO Camera Database

[M8TJT]

Just a little warning to MIO 3.2 users.

:D Endnote added by M8TJT 12/07/07
The PGPSW database is now more of a wondrous thing as M8TJT and MaFt have worked together to solve most of the directional 'errors' which in most instances are now less that 5 degrees, but NO GUARANTEES
Trevor :D

The PGPSW speedcam database is a wonderous thing, especially now that it's got camera direction data. This is thanks to MaFt, the rest of the PGPSW team and various other people who have spent a lot of time researching direction data etc.
The problem is, is that a statistically significant number of cameras have incorrect heading data, the magnitude of which will prevent the MIO (and, I presume, IGO) software responding to the camera, and not warning you of its approach.
Having found that a local mobile camera was no longer alerting me to its possible presence, I investigated and found that its database heading was 180 degrees on an E/W road (90 deg error). I subsequently checked the heading of about 50 other cameras, mostly with a database heading of the cardinal points, and compared the database heading with the road direction on which they are located. Of the 50 odd that I checked, I found that 13 of them probably had sufficient error to prevent my MIO alarming.
I have listed the ones that I found to be in error below.

The fourth column is the database heading, the fifth col is the 'number of ways' and the last column is my eyeball approximation of the azimuth of the road on which they are located. You will not that in some instances the error is as much as 90 deg. Elsewhere I established that the MIO 'acceptance angle' is about plus/minus 40 degrees, so most of these cameras will not alert when approached

-3.82661 56.75715 GATSO: @60 180 1 90
-4.10767 51.67552 GATSO: @30 180 1 100
-1.48854 50.90065 MOBILE: @0 90 2 110
-4.04594 50.39132 GATSO: @30 90 1 125
-1.87715 53.7417 MOBILE: @0 0 2 145
-1.4775 53.33252 MOBILE: @0 0 2 145
-0.2357 51.44692 GATSO: @30 0 2 145
-1.16881 53.54103 GATSO: @40 180 1 145
-0.12524 51.4924 GATSO: @30 225 1 195
-2.60419 51.25046 GATSO: @50 180 1 230
-3.9767 51.64114 REDLIGHT: @30 180 1 235
-3.24038 55.92924 GATSO: @30 270 1 235
-2.07437 52.5646 GATSO: @40 270 1 245

Now I know I only checked about 50 cameras of the 4427 cameras that have direction data and realise that checking and correcting all of them as necessary would be a mamoth job, so I think that I will be reverting to the excellent PGPSW non directional database and use sallyann's prog to enter my own direction data on cameras that I know. That is if I can still find her updater program.
What a shame!! Still, as I said some time ago, I'm a firm believer in 'No data is better than incorrect data'

@PGPSW. Is there any chance that you might be looking at the database for this type of error in the future, so that I can once again feel confident in the use of your direction data?

Trevor

[Sallyann]

Trevor,
I trust that you are submitting corrections for the errors you have found?
Some of are doing so whenever we find them!

Sal

[MaFt]

we constantly update the data when we get sent it - submit it and it'll be added!

[Sallyann]

I've today amended one that was 'only' 15 degrees out - still worth doing.
The problem of course is that the majority of users still have those obsolete GPS units that don't use direction information, and they seem content to keep getting alarms for cameras on the opposite carriageway or crossing roads. So they don't have any incentive to check or submit the correct bearings.
No doubt this will change one day when the rest of the manufacturers catch up.

Sal
(patronising - moi?)

[M8TJT]

@Sallyann and MaFt.
But how did the incorrect data get ointo the database in the first place?
Is no one checking the azimuth of the road against the submitted camera azimuth BEFORE adding the data to the database?
At 200 cams a day, it would only? take about 3 weeks to check them all, but how many more incorrect ones would be submitted in the mean time.
I'm prepared to check some out and submit changes in the form of a .csv (from Excel) if I could feel certain that incorrect data will not get into the database in future and someone else does some as well (obviously co-ordination would have to be done to avoid duplication of effort).
Trevor

[M8TJT]

Have now checked road az of 125 cams in lattitude 50 with database az of less than 180.
Found 32% error g/t 10deg
17% error g/t 20 deg
10% error g/t 30 deg
8% error g/t 40 deg
4% error g/t 60 deg
@MaFt.
I have this data in an excel spreadsheet (converted from *.csv to *.xls) based on the latest PGPSW .asc file with my az data in an extra column and another col with notes.

I will do some more when I recover from my boredom.

In what format could you use my data?

I intend to get it into the correct format to allow Sally's prog to update my version of the PGPSW database.

Trevor

[MaFt]

csv is fine - 5 columns:

lon, lat, camera id, heading, direction*

direction being 'one way' or 'reversible'

the 'incorrect' data got in from incorrect submissions. the maps do not always match reality exactly so you can't always just 'look' at the map to see what it should be. also, old cameras did not use to have the heading field so were left blank - we can't just guess which side of the road it it so left them blank. also, the poi capture utility automatically includes heading data but there are various factors that can affect it such as signal strength, whether the car is perfectly following the line of the road or swerving a bit or overtaking etc etc.

yes, i could spend 3 weeks sorting out the heading of every single camera in the database but then that would leave me with a back log of over 1,000 support emails, and probably about 3,000 camera submissions. it would also mean that there would not be a database release for around 6 weeks.

unfortunately it's not a massive priority for me - while i do want to get the headings as up to date as possible for mio and drivesmart users, when you look at the percentage of the downloads from the last release (5.055) that were for units using heading it is only 0.5%...

basically, submit them (as sallyann and a number of others do) and they'll get added.

MaFt

[M8TJT]

@MaFt

[MaFt]

[M8TJT]

MaFt
No problem.
Iv'e now checked out 450 cams in the SE. That's over 10% of the total that you have direction data for . Most of the cams between 51N and 52N and east of 0E were remarkably accurate.
Trevor

[Andy_P]

I don't understand how you can "check" all these without visiting them.
If you are just looking on Google Maps or whatever, how do you know which direction the camera is pointing???

[M8TJT]

Andy_P2002
Firstly, in most instances, the PGPSW database azimuth of the camera is either on the az of the road or only a few degrees off.
Secondly, I have made a couple of assumptions listed below.

I have made the basic assumption that any person putting the data into the database via the Google map input mechanism is not deliberately trying to input the wrong data, but has just not got the az as accurate as it could be. Because of this I am assuming that the 'general direction' is correct. For for example, if a road runs NW/SE (315/135) and the PGPSW database entry is say 180 for a cam on it, then I am working on the fairly safe assumption that the actual az of the cam is 135 (not 315). If the PGPSW database gave an az of around 45 or 225 degrees for the same cam, I would suggest that it be made 2 way as a reasonable deduction of its az cannot be made.

The direction data for the MIO has to be within about plus/minus 40 degrees of the actual az of the approach road to the camera, or else it does not alarm, so it would not alarm for the 180 deg example above. Of the cameras that I have checked, the vast majority are within these limits, however there are exceptions. The largest errors seem to be when the PGPSW database az is one of the cardinal points, caused, I assume, by someone travelling down a road at, say, 135 deg and inputting 180 in the database because they were travelling in an approximate southerly direction.

In cases where the direction of the camera is obviously wrong but cannot easily be deduced from the road az and the PGPSW database camera az such as a cam at or near a cross roads with its az being between two of the road azimuths, I am going to include these in a separate file, and make the suggestion that they are made either 2 way or that the direction data be removed thus making it an omni directional camera until someone confirms the actual azimuth. This should ensure that the MIO alarms to a cam that the az is fairly obviously wrong but a reasonable deduction of its actual az cannot be made.

The method that I am using to establish the road direction, is by looking up the camera to find the part of the road that it's on, setting my MIO to north up, and then using a protractor with a rotatable cursor to find the alignment of the road. This method agrees favorably (better than a couple of degrees) with using a piece of nav software that gives the bearing of one point from another given the lat/long locations of both, but is much quicker.

When I submit my data to PGPSW, it's up to them whether they use it or not, but I certainly will.

Hope this explains it to your satisfaction.
Trevor

[MaFt]

sounds good to me,

cheers

MaFt

[M8TJT]

@MaFt
Thanks for the vote of confidence.
Now done 917. How sad is that?
Trevor

[Sallyann]

Good work Trevor. Keep it up.

Sal

We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?.
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!