Thread: iGO Speedcam (DISCUSSION)

🌍 The Geopolitical Trap in Navigation: Why Speedcam Databases Are Split Differently and What It Means for Drivers
When we download a fresh speed camera (Speedcam) database for our GPS navigator, we rarely think about the logic behind splitting files by country. It seems simple: if you are driving to France, you download the France file; if you are going to Spain, you grab Spain.
In reality, however, database creators use two completely different approaches to sorting files: the driver-oriented (practical) approach and the geopolitical (official) one. If you happen to download a "geopolitical layout," you are in for some massive surprises.
Let’s break down the difference and look closely at the second, much more confusing approach.

Approach #1: Driver-Oriented (The Logic of Common Sense)
This approach is made by people, for people. It is based entirely on geography and road connectivity.
If you are driving through Europe, you don’t care who historically owns certain overseas territories. You just need a single file containing the radar data for the places you can physically reach by car. That’s why driver-oriented databases often group files into regional packages: Central Europe, Scandinavia, or the Balkans. This is convenient, logical, and saves your navigator's memory.

Approach #2: Geopolitical (The Logic of Bureaucrats and the UN)
This is where things get bizarre. The second approach strictly follows official state structures, international law, and colonial history. Databases are sliced strictly according to legal state ownership, completely ignoring what part of the world the territories are actually in.
If you download a database built on this geopolitical principle, be prepared for the following "surprises":

🇫🇷 France with global "tails": When downloading the France file, you get more than just the radars around Paris or Marseille. The creators pack coordinates from overseas territories into the exact same file: Réunion Island (Indian Ocean), Martinique and Guadeloupe (Caribbean), and even French Guiana (South America).

🇬🇧 The UK and Gibraltar: Would you expect Gibraltar to be in the Spain file since it sits at the very southern tip of the Iberian Peninsula? Think again. In a geopolitical layout, it is hard-linked to the United Kingdom.

🇳🇱 The Netherlands in South America: Along with Amsterdam and Rotterdam, your navigator will be forced to load cameras from the Caribbean islands of Bonaire, Sint Eustatius, and Saba.

🇺🇸 The US and Guadeloupe (Brand Confusion): Due to the quirks of international classifications or mapping errors, American databases sometimes include unexpected Caribbean points that are legally or economically tied to the region.

🇺🇦🇷🇺 Ukraine and the Crimea: The sharpest political knot. Depending on the source of the database (international, Ukrainian, or Russian), Crimea can end up in completely different files. If you drive there, you risk getting zero radar alerts if you downloaded a file from the "wrong" jurisdiction.

⚠️ What You Need to Know If You Download a Geopolitical Layout
Bloated file sizes. You might wonder why a file for a seemingly compact European country weighs so much. It is because it contains thousands of points located 10,000 kilometers away from Europe. Your navigation system has to digest tons of "data junk" that is completely useless for your actual road trip.
The risk of missing radars at borders. Traveling through Europe by car and crossing, for example, from Spain into Gibraltar, you risk going "blind." If you only have the Spain map or file active, Gibraltar's cameras won't trigger—because they are hidden inside the UK file.
Time zone and encoding conflicts. Navigators sometimes lose their minds trying to match the operating hours of speed cams (like public transport lanes) in Paris with those on Réunion Island. The time difference is several hours, yet the file is exactly the same.

🏁 The Bottom Line: A Real-World Example
None of this is just theoretical talk. Anyone who downloads popular custom radar builds faces this exact problem.
If you have downloaded files split by country under the Hungarian title >>>>>"Országonkénti bontásban"<<<<< by the uploader Cserrobi (also known as Sunnyside Navi), you got exactly this geopolitical layout with all its flaws and quirks.

The Root Cause of Fake Toll Booth Alerts: Free Drive vs. Planned Route
There is a fundamental misunderstanding among some users regarding how the iGO core engine handles speedcam detection. Tampering with internal parameters like speedcam_maxdistance_from_road or manually duplicating data points (cloning) is a counterproductive approach that breaks database integrity and causes lag.
The issue with Toll Booths triggering false alerts on tollways while you are just passing by on the main highway is a structural limitation of Free Drive Mode, not a database or skin bug.
Here is how the algorithm actually works:
1. Free Drive Mode (Chaotic Vector)
When you drive without an active route, iGO functions like a basic radar scanner. It calculates a simple proximity/radial corridor based on your current speed and immediate heading vector. Because toll booths on exit ramps are physically located just 10–15 meters away from the main highway lanes, the core engine captures them in its visibility cone. Without a predefined path, iGO cannot guess whether you will stay on the highway or take the exit. Therefore, it has no choice but to throw a generic alert. Tightening the distance parameters to 10m or less will only result in missed legitimate speedcams on complex curved junctions due to standard GPS latency.
2. Planned Route Mode (Navigation Corridor) — The core philosophy of iGO
iGO was engineered from day one as an "A-to-B" navigation software. The moment you activate a planned route, the engine switches to high-level trajectory filtering. It builds a precise, locked navigation corridor along the road graph segments.
• The system pre-calculates every single turn and maneuver along your path.
• If a toll booth is located on a junction ramp that your active route does not take, the engine automatically filters out that point because its fixed azimuth or road segment ID does not match your active trajectory corridor.
Conclusion:
There are no shortcuts here. You cannot expect absolute precision from a passive map-viewer in Free Drive mode on multi-level European junctions. Duplicating points or tweaking the sys.txt variables creates database bloat and false alerts on intersecting roads. If you want seamless, bulletproof filtering without false positives, simply run an active route. Let the software work the way it was designed to.

Originally Posted by AnthonyGreek

I have two questions about speedcams if anyone could help me understand.

speedcam_maxdistance_from_road is used to ignore a speed camera alert if the camera is located farther away than the selected distance when passing it.

This parameter is important, for example, when driving on an expressway alongside a secondary road with a speed limit of 45 mph, while the expressway itself has a speed limit of 80 mph.

If a speed camera installed on the secondary road, configured to detect speeding above 45 mph regardless of direction, is located less than 10 metres from the expressway, iGO will issue a speeding alert on the expressway whenever you exceed 45 mph, even though you are well below the legal speed limit of 80 mph.

When a speed camera is located at the intersection of two crossing roads, and is therefore less than 10m from both roads, the correct use of directional mode will determine whether the camera is announced and whether the correct speed limit is applied.

For example, consider a speed camera located on a secondary road crossing over an expressway on a bridge. If the camera is intended to monitor traffic on the expressway, it should be configured with a speed limit of 80 mph and oriented in the direction of the expressway. If it is intended to monitor traffic on the secondary road, its orientation should be offset by 90 degrees and its speed limit set to 45 mph.

What remains to be verified in this example is whether a camera located on the bridge, configured and oriented to monitor the expressway, but positioned more than 10m from the expressway while still being located on the secondary road, will ultimately be announced by iGO or ignored.


It is therefore preferable not to tamper with this parameter, as its default value represents a reasonable compromise that works in most cases.

The same applies to speedcam_max_angle, which some people unnecessarily increase. Instead, it would be sufficient to adjust the directional angle of the few affected speed cameras to improve detection. Alternatively, problematic speed cameras could simply be cloned, assigning each clone the most appropriate angle and placing them opposite each other at the beginning of each curve, with each one oriented according to the direction of the road.
It should be noted that a value of 20° for this parameter already represents a lateral distance of 200 m from the intended direction at a distance of 1 km, which is more than sufficient for a speed camera positioned less than 10 m away.

It is also important to be aware of a certain reality: a speed camera positioned 10 m from the road with a detection angle of 20° will be only 27.5 m away from you when it leaves the visibility cone. In that case, the alert will have sounded long before that point—or, visually, you would have to be extremely short-sighted not to see it.

speedcam_snap_distance literally means "speed camera snap distance." Its value may indicate that, below the selected distance between the speed camera and the vehicle, the camera will no longer be announced because it is considered too close to have any meaningful influence on the driver's behavior, taking reaction time and braking distance into account.

There are four main parameters in sys.txt that affect speed camera detection:

speedcam_snap_distance=50 ;; Speed camera snap distance
speedcam_maxdistance_from_road=10 ;; Maximum distance from the road (route)
speedcam_max_angle=28 ;; Visibility cone = 2 * max_angle
speedcam_max_lookahead=500 ;; (1000)

One could say that speedcam_max_angle would represent the field of view, while speedcam_max_lookahead represents the maximum hyperopia and speedcam_snap_distance the minimum myopia at which a text is no longer readable, speedcam_max_angle.

Excessive or inappropriate modification of these values can interfere with predictive detection and the operation of other alert parameters. The most obvious example would be reducing speedcam_max_lookahead to 100 m when we know that laser speed cameras can detect vehicles from more than 1,000 m away.



In iGO, min_frc is most likely related to FRC = Functional Road Class.

FRC is a hierarchical classification of roads: motorways, expressways, main roads, secondary roads, local streets, etc. Whether a higher or lower numerical value represents a higher road class depends on the mapping system being used, so caution is needed when interpreting the exact numerical value.

The min_ prefix generally suggests “minimum FRC class” or “minimum FRC.”

In the context of speed cameras, navigation, or route searching, min_frc could therefore be used to define the minimum road class to be taken into account.

In the case of alerts in particular, one might want them to apply only to certain types of roads. This parameter appears to be mainly present in [speedcam_category:3], which defines section speed cameras, so its use may differ from the definition given above.

An iGO document explicitly identifies **FRC = Functional Road Class** in the section devoted to route calculation. Some discussions indicate that `min_frc` plays a role in determining whether the road speed is used, depending on its class: the value of `min_frc` would be related to the value assigned to `use_road_speedlimit`.

FRC 0 → motorway / major road
FRC 1 → very important road
FRC 2 → important road
FRC 3 → main road
FRC 4 → secondary road
FRC 5 → local road
FRC 6 → residential road
FRC 7 → road of very low importance

A specialized iGO discussion also indicates that `min_frc` works in conjunction with `use_road_speedlimit`, and that `min_frc=-1` is used when allowing the speed provided by the map to be used.

The most consistent interpretation is that `min_frc` is used to determine **from which functional road class iGO may use the speed limit provided by the map**, rather than simply determining whether the speed camera should be displayed.

Speedcam: Theory and Practice. Inside the Databases, iGO Core Physics, and the Collapse of "Armchair Theory"

Introduction
As an active contributor and moderator for the OpenSpeedCam (OSC) database, I see the backstage of speedcam file creation every single day. After analyzing the architecture of various custom releases (including the popular Spanish La Radio BBS and the German POIbase packages), I have come to a paradoxical conclusion: the vast majority of speedcam databases are created with a total lack of understanding of the actual iGO core navigation engine algorithms.
The creators of these releases constantly attempt to fix structural data errors using "config crutches," completely breaking the software's native logic. In this article, we will analyze how a primitive approach to data ruins navigation, how the iGO core actually handles tracking physics, and why pure theory fails when facing real-world Big Data.
Part 1. Database Anatomy and the "Omnidirectional Alert" Trap
Approach #1: Corrupted File Headers and the "Roadside Effect" in BBS
A few years ago, while auditing a massive speedcam release, I discovered a critical flaw. Due to a basic syntax error — using a semicolon ; in the header row of the text file — the navigation parser automatically reset all directional radars into omnidirectional alerts (Direction 0, Angle 360).
Instead of fixing the converter script's syntax, the database authors offered users a "genius" workaround:
Artificially tighten the maximum alert distance from the road graph in sys.txt (speedcam_maxdistance_from_road).
Physically shift the coordinates of the points in the text file deep into the roadsides on opposite sides of the highway.
Why is this method a technical absurdity?
The core law of GPS navigation and map-matching algorithms dictates: for a stable, reliable alert, the object's coordinates must sit exactly on the road graph segment (the vector axis).
When data hobbyists force coordinates out into fields and roadsides to "separate" directions, the navigation engine begins to chaotically snap the point to either the left or right lane due to standard GPS signal drift. On multi-level junctions or parallel collector roads, the navigator simply goes blind.
Approach #2: The PocketGIS Legacy in POIbase
Another market giant — the German POIbase — also provides an official export option into the iGO format. But what is the catch?
The entire POIbase architecture and its point placement algorithm were historically designed for a completely different software — PocketGIS.
The PocketGIS standard utilizes a very specific method: camera azimuths are artificially "stretched" around curves, aiming the vector ray directly at the estimated entry point of the curve. While this works for the native PocketGIS engine, when this raw data array is blindly dumped into speedcam.txt for iGO, the vector orientations immediately clash with the Hungarian software's trigonometry.
Approach #3: Ignoring iGO Trigonometry and the 20-Degree Limit
During audits of third-party databases, I discovered that the source data completely fails to comply with iGO's maximum critical entry angle. By default, the iGO core has a hardcoded limit: the visibility cone of a directional speed camera is strictly 20 degrees relative to the road graph segment.
Since regular drivers report points on the fly using mobile apps (with an inevitable 2-to-3-second human reaction delay), the speedcam azimuths in these databases end up with massive deviations from the road axis — averaging 38–39 degrees. With default iGO settings, a vehicle will pass such a radar in complete silence: the software simply drops the alert because the point falls outside its narrow 20-degree operational sector.
To instantly protect users from fines and compensate for this inherent crowd-sourced chaos, I previously introduced a software-level solution — widening the predictive field of view via the configuration file:
ini
[warning]
speedcam_max_angle=30
This parameter is not an "unnecessary modification." It is a vital mathematical dampener that holds the radar inside the navigator's field of view on long curves, bends, and complex junctions.
Part 2. The Collapse of "Armchair Theory" Facing Big Data
When presented with the 30-degree angle solution, "armchair theorists" immediately step onto the stage. Their logic sounds beautiful, but only inside a vacuum:
"Widening the angle to 30 degrees is an error! The navigator might trigger a false alert from a parallel side street. You must strictly stick to iGO's factory 20 degrees. And to prevent radars from disappearing on curves, you just need to manually find those problematic points, fix their azimuths, or clone them to create multiple duplicates at the entry of every single curve!"
Now, let's step down to earth and look at real engineering practice.
A modern speedcam package for Europe contains anywhere from 50,000 to 150,000 rows of data. Theory seriously suggests that a regular user, before every trip, should open a 100,000-line text file in Notepad, manually verify every single coordinate against the road graph, and manually write down "fans" of cloned duplicates.
Artificially duplicating points inevitably leads to Database Bloat. Navigators (especially weak Android head units or legacy WinCE devices) begin to choke during cache parsing, while overlapping radar cones from cloned points trigger a nightmare of false visual and audio alerts on crossing roads.
I have a legitimate question for these "tradition keepers": where were your theories for the last 8 years? For seven years straight, custom builds for massive forums (including the French msieurlolo) were delivered to users with completely wiped azimuths (total omnidirectional chaos). For another year, the databases were stripped of directions entirely. And the theory remained completely silent. Armchair theory only knows how to write poems about "tuning the orchestra" in the comments section. Engineering practice takes this chaos and normalizes it via automated algorithms.
Part 3. iGO Core Physics: Navigation Corridor vs. "Radar Detector" Mode
Another common argument used by theorists revolves around complaints regarding false alerts (e.g., Toll Booths triggering on main highway lanes). This happens due to a fundamental misunderstanding of the iGO core engine physics, which operates in two completely different states.
State #1: Free Drive Mode (The Passive Scanner)
When you drive without an active route, the navigator turns into a basic radar scanner. The iGO engine does not know your future path (whether you will take the next exit or stay straight). Therefore, the program is forced to build a primitive radial-vector search corridor based entirely on your current instantaneous speed and heading vector.
If a Toll Booth on an exit ramp is physically located 10–15 meters away from the main highway lanes, the Free Drive engine will inevitably capture it inside its visibility cone and throw a generic alert. Attempting to "cure" this by tightening the distance parameter to 10 meters or less is a critical mistake. Due to standard GPS latency, a navigator with such restricted values will simply miss real speed cameras on high-speed highways.
State #2 & Conclusion
When an active route is set, iGO switches to a precise navigation corridor, automatically muting points on unused ramps. The text details parameters like speedcam_max_angle=30 for curve compensation and speedcam_snap_distance for segment mapping. Users can choose omnidirectional workarounds, the angle adjustment in sys.txt, or professional normalized databases like Mod AF.

THE PERFECT CROSSROAD.
As an experiment, I have cleared SCDB of redundant alerts. This is the most challenging camera database to work with because it is neither adapted nor designed for iGO in the first place, despite having an export option named "iGO OEM." SCDB is exceptionally well-tailored for various other navigation software that utilizes the POI principle; it even includes data for the end points of average speed check zones. Unfortunately, when exported to iGO, the end of a zone turns into the start. Alerts trigger everywhere—even if a camera is on the opposite side of the road and facing oncoming traffic. At crossroads, notifications usually pop up both before and after the intersection. All of this thoroughly exhausts drivers. The idea to purge the database of these false positives came from @HansGans09. You can now test this version under the name iGO SCDB Mod Big Fix AF. he database has been cleared of duplicates ofwithin a 20-30 meter radius wherever possible. However, the database's core principle remains unchanged, meaning the omnidirectional (360-degree) alert behavior is still there.

P.S. Starting from October 10, 2026, all versions of the SCDB database under the AF Mod are published exclusively in a modified form, with duplicate and redundant alerts completely removed.

Clarifications regarding mobile radars in France within the OSC database.

@pat68

There are several technical and practical reasons why mobile speed cameras in France have disappeared from the OSC map:

1. Mobile radar export filters. [Only registered and activated users can see links. ] are applied incorrectly, and the files are then published on various forums marked as "mobile radars included." However, almost all mobile cameras are deleted during the export process. As a result, there are practically no mobile cameras left in the speedcam.txt file. If mobile radars from the OSC database are exported this way, the navigator simply has nothing to display. Special thanks for this goes to Cserrobi, who does not hold a certificate to publish the OSC database but still creates OSC threads.

2. The RedAlert legacy. The mobile camera data for France is very old, accumulated over many years since the days of the RedAlert service. Because of this, the data volume has bloated significantly. With such an uncleaned database, the navigator will beep almost continuously. From a practical standpoint, it is easier to understand that mobile patrols can be anywhere, and constant alerting about old, inactive cameras does more harm than good.

3. Modern realities (autonomous trailer radars). Today in France, the "mobile" cameras are autonomous radars on trailers. Previously, they were mainly used in roadwork zones, but later these trailers began to be installed everywhere.

4. They are not on the OSC map because I deleted them from the database. "Check-box delete Type 5 France: mobile radars - 15995"

What mobile radars in the OSC database look like now:
• In the OSC data export, these trailers go into the speedcam.txt file as iGO Type 1 (standard fixed cameras).
• In my speedcam.txt Mod AF files, these trailers are iGO Type 5 (17).
Trailers in the OSC database appear as Type 1 on the map. For example, in SCDB, it is the exact same situation—trailers are Type 1.

OSC edits:

before making any corrections on the map, you must understand one important thing. We split speedcams by directions if there is a single camera, like in this case, and it is pointed in one direction. The VB encoding is specifically designed to warn about such radars: when you approach a speedcam that controls the oncoming traffic, it triggers a "rear radar" warning (code 59), while the oncoming traffic flow receives a warning with code 32. These two points represent 2 distinct alerts. Merging them into a single point with two alerts — "in the rear" — is a gross violation of the VB code logic. After such edits, a code 59 warning (rear radar) will be falsely triggered from both directions.

Spoiler: +

If you do not understand these principles, it is better for you not to make any changes to the OSC database. Since you do not understand the principle of separating radar directions, your edit has resulted in deleting the oncoming direction ("in the face") and turning the rear direction into a two-way alert.

Read carefully FAQ, especially for m.LOLO.

Code:

Please Login or Register to see the links