Proposal talk:Relation:enforcement

Various thoughts and questions

Well done Lulu-Ann for the move to a relation model, but does it makes us oblivious of way reversals? I hope it does but I'm not sure. I wonder if way reversal techniques vary from editors to editors. For instance, do some simple change the order of the points in the way definition or do they actually move points around? I suspect it's the former in which case we're good, but if it's the later I fear it's gonna be complicated to debug. Pov 14:29, 2 December 2008 (UTC)

Yes, I indeed needed to have no direction arrows used. You can not do that with relations because there can be more than one relation on the same place demanding different direction arrows. --Lulu-Ann 18:14, 2 December 2008 (UTC)

Also, nowhere in the spec do I see how to express the restriction value. For instance in case of the maxspeed check, is it done by using the attached way's maxspeed attribute or did I miss an extra attribute/value in the relation which is used to express the actual value?

Pov 14:29, 2 December 2008 (UTC)

If there is a restriction value like in maxheight, then it shall be repeated in the object (tunnel) and the device. If there is an individual value like for maxweight of heavy goods vehicles, we could invent some non numeric value like "vehicle-dependant", but this always causes discussions, so I left it out. --Lulu-Ann 18:14, 2 December 2008 (UTC)

Why use a specific key for the value like maxheight and not a more generic value key? Is it to be able to combine different values like this ?

type=enforcement

enforcement=maxspeed,mindistance

maxspeed=70

mindistance=50

This would enforce a max speed of 70 km/h and minimum gap of 50m between vehicules

Why maxheight? Because maxheight occurs. It's a generic as possible, I even used the same term already in use. --Lulu-Ann 10:19, 4 December 2008 (UTC)

Yes, it's needed for combination of different enforcements in one place. But as there can be several diffenrent maxspeed enforcements at one set of traffic lights to different directions, the comma-separated enforcement is unfortunately not sufficient. --Lulu-Ann 10:19, 4 December 2008 (UTC)

It should be semicolon separated list for XML syntax. Besides, there are places where max-width occurs, same also with boggy weight (applies for trucks with boggy wheels), shaft weight weight, unit weight (for instance both the lorry and the trailer the lorry pulls can be 10 ton) or total weight (the lorry with trailer cannot exceed 15 ton). For weight limitations you might see a combination of all these. Actual sign I have seen: Max weight 12t, shaft weight 3t, boggy weight 5t. --Skippern 10:44, 4 December 2008 (UTC)

Yes, I totally agree that there should be different tags for shaft weight, boggy weight and over all max weigt. But this should be subject of the maxheigt restriction discussion, not of the enforcement, so let's discuss it there. As soon as more access restriction tags exist that might be checked in a traffic enforcement, we can simply add the examples here. --Lulu-Ann 10:26, 7 December 2008 (UTC)

Lulu-Ann I totally agree it's not enough for multiple directions, but more than a single type of check can be done by the same radar in the same direction, that's the kind of use I though for the comma separated values. Like in a tunnel they can check both your speed and the length of the gap (this is what I was thinking about for the example I wrote).

So for instance maxspeed value would be put in the device node? Why not in the relation? Or should it be left out and rely on the maxspeed value of the way (in that case, which way)? Whatever the alternative is, I would appreciate if it was clarified where the maxspeed value should be specified. I've tagged numerous speed cameras with relation tags type=enforcement, enforcement=maxspeed, maxspeed=maxspeed value together with the nodes from, to and device. --Erik Lundin 01:35, 11 January 2009 (UTC)

Maybe it is possible to make difference between static enforcements and temporary enforcement e.g. Neustadt a. Rbge B6 is a point where sometimes there are mobile speed enforcement and on the road Mecklenheider Strasse, Hannover there is an static speed enforcement in both directions. Btw. @Lulu please take a look on the Mecklenheider if I have created my first relation in the right way. :) --Marco.horstmann 16:20, 29 December 2008 (UTC)

Far too complicated ?

Why you don't stay with the simple tagging of nodes/ways ? Why is it so important to know if the speed camera is controlling speed in one way or both ways ? Are we still in geographic data or more developing tools to bypass speed limits ? -- Pieren 17:16, 3 December 2008 (UTC)

The simple tagging was not working and did not find enough votes, therefore the proposal was abandoned. If you think doing it without relations is good, you can propose your version and we will see if it gets more votes. Please add a section how to tag my examples with your method, to check if it can handle them all. Thanks. (There is a great demand for maps and routings systems showing radar traps, and this is the map for everything. The traps will be in this map earlier or later. What I want to do is care for a good data model.) --Lulu-Ann 10:45, 4 December 2008 (UTC)

Seconds that, besides most of this have no significance for the rendering, though the height and weight limits can be used for routing of specific vehicles, just the same way as access and restrictions would apply. To know the nodes where signs are placed is irrelevant, and the same goes to know the nodes where other systems are put in place to stop such vehicles before the actual restriction starts. The important is that the truck driver is given the route to bypass the restriction, not to tell him where he will be fined if he tries to ignore the restriction. --Skippern 18:09, 3 December 2008 (UTC)

I disagree on the rendering, of course a heavy goods vehicle driver might be interested to print out a map with height and weight limits, not only to use a routing software considering them, so there will probably be a height-and-weight-limits-map soon.--Lulu-Ann 10:45, 4 December 2008 (UTC)

To put the nodes for the "from"-role on the node where the sign is located is just a recommendation. I know a street with a tunnel under the Mittelland-Channel near Gifhorn, Germany, where the sign is several km away from the tunnel, because there are simply no crossings where you could leave the road. There it makes sense, that the routing software warns you before you are entering the street, and not when you are breaking at the tunnel. Indeed the sign is the actual restriction, saying "maxheigt 4m applying in 5 km, open for higher vehicles if destination is before the tunnel". Btw, a maxheigt will not usually cause a fee but a broken truck, so "ignoring" is not really the cheap alternative. Of course a good routing software will not guide you into the street, but if you would try to leave the recommended route to take street you guess might be shorter, you would not have the warning about the hight shown on your routing device when you enter the street. As we need the "from" node anyway, we can also put it at the sign. --Lulu-Ann 10:45, 4 December 2008 (UTC)

Fine, don't use it! But it certainly is useful to some. And if it's legal to map those and use them in conjunction with a device which can warn you if you're traveling at excess speed for instance, I certainly don't want to be deprived of my right to use such a device because of moral judgment. Plus the “too complicated” argument doesn't stand, the simple tagging of nodes has been abandoned because it was too fragile. This is the way to go. Reread the talk page of the traffic enforcement tag n if you're not yet convinced.

First of all, I objected to the Traffic enforcement tag as suggested (cant remember if I voted though). I have no problem with tagging speed cameras or other fixed enforcements, the same applies for restrictions. What makes this suggestion too complicated isn't tagging of the actual speed camera, but the amount of nodes and ways to tag for instance a height or weight limited part of the road. It shouldn't be necessary to tag the node where the sign is and the node where you will be stopped if you ignore the restriction. BTW: Some countries have outlawed use of units that can warn about radar controls or speed cameras, but that is entirely a different discussion. I would like to have a unit that gives me a simple warning if I approach a speed camera too quick. But the relation doesn't need to know where the "electronic speed surveillance" sign is put up, only where the camera is and what part of the road it uses for measuring the speed. --Skippern 21:06, 3 December 2008 (UTC)

I see no problem here, as the node for "from" is needed, the position at the sign is optional. Also the place where you are stopped is optional, it only applies if you are stopped (Automatic road blocking at Elbtunnel, Hamburg, Germany. I have picked examples of maximum complexity to show the possibilities of this model, not to make everything mandatory. I will add "optional" and "mandatory" information. --Lulu-Ann 10:45, 4 December 2008 (UTC)

Ok, sorry I misunderstood you and sorry if I sounded a bit harsh then. I reread all the parts of the proposition and while I think that the spec is fair in terms of the amount of information it requires for all the enforcement, it's overkill for the maxheight one. Clearly it's redundant with the way tagging that should already be enforced by routing software and rendered in maps. This could eventually be used to render an additional sign in front of the way but that's pretty much it. Things are different as far as speed and stoplight enforcement, for example, goes. Those don't preclude your use of the way, you won't get stuck in the tunnel or under the bridge if you ignore them. Pov 00:45, 4 December 2008 (UTC)

Same misunderstanding here: Things are optional. --Lulu-Ann 10:45, 4 December 2008 (UTC)

I took the freedom to add an alternative example of a speed camera relation. If we only have one direction in each speed camera relation, than locations where both (or several) directions are covered from one location will be full of relations. Too many relations might make maintenance of the map difficult. --Skippern 10:51, 4 December 2008 (UTC)

When thinking of traffic enforcements, I do not care so much about the camera that takes a picture of me if I drive too fast; rather, I want to know which part of the road is monitored. So what I really need is just a tag for a part of a way and a given direction. In order to tag a part of a way for a given direction, the relation type segmented_tag was proposed. Anything that is intended with the relation type enforcement can be achieved the segmented_tag plus a key enforcement attached to that relation. The advantage is that segmented_tag, if it becomes approved, will likely get more supported by the editors than a special relation type like this one. --Mink 00:42, 5 January 2009 (UTC)

Speed Camera

If one post with speed camera (or otherwise one node covering several cameras), why divide it into several relations? One relation can surely handle several measuring points for one camera? Only reason to put up more than one relation would be to indicate different speed limits. --Skippern 23:56, 3 December 2008 (UTC)

The point of using a relation instead of tagging a node was to have a non-ambiguous, robust way of expressing the direction that enforcement applies to. So, multiple directions = multiple relations, even though the camera location may be unique, the direction they check isn't. Pov 00:45, 4 December 2008 (UTC)

I see no problem in the following approach:

• • • Type:Enforcement
    • Enforcement:Speed camera
    • Maxspeed:60 (60kmh)
    • Camera:Node
    • From:Node
    • From:Node
    • From:Node

This will allow one post with cameras cover three roads/directions with a speed limit of 60kmh. I see no point in breaking this up in 3 nodes. If the speed limit on the third road was 40kmh, than of course that would have to be a different relation. --Skippern 10:07, 4 December 2008 (UTC)

This is a misunderstanding I guess. There shall not be 3 nodes for one camera post, there shall only be 3 relations. --Lulu-Ann 14:59, 5 December 2008 (UTC)

This is fine by me, I didn't understood what you meant but the example clarifies it and I certainly agree this is simpler without being abiguous. Only concern I have is with Lulu-Ann's example #3, the camera node should be part of the way, otherwise determining the direction will be problematic. Maybe we could use an optional syntax that is only used when mapping the precise location of the device on the side of the way. Let's try some asciiart...

W-------f----#----E

Device enforces speed for vehicles traveling from west to east.

f = tag|relation|from

# = tag|relation|device

W-------f----t----E
             #

Device enforces speed for vehicles traveling from west to east.

f = tag|relation|from

t = tag|relation|to

# = tag|relation|device

What do you think? Pov 14:13, 4 December 2008 (UTC)

I'll support putting the speed camera as a node on the way. There is no reason to put it as a separate node unless the distance from the road is significant. --Skippern 14:33, 4 December 2008 (UTC)

I agree, of course the cam can be placed on the road! I have changed the examples. --Lulu-Ann 14:59, 5 December 2008 (UTC)

I kind of disagree with your wording and example 3b here. Don't get offended by the wording, I'm just using the standard RFC one. Cam MUST be placed on the way OR the to part of the relation MUST be on the way if the Cam is next to the way. Otherwise it's not possible to determine the direction. Pov 17:09, 5 December 2008 (UTC)

You are totally right. I will try to add an example to show why this is needed and add the combination "either the divide is a node on the way or the to-role is mandatory". --Lulu-Ann 10:03, 7 December 2008 (UTC)

I was checking the page after the rename and noticed that example 4 doesn't contain a "to" relation while the camera node isn't on the street, it's an error, right ? Even though the camera is for both directions, this only means there should be TWO relations which that camera is a member of, not that the "to" part should be skipped. Pov 17:36, 21 January 2009 (UTC)

You are right! I have corrected this. --Lulu-Ann 16:02, 23 January 2009 (UTC)

As far as multiple directions cam goes, why forbid a single relation with multiple from? I agree this doesn't work for complex situations and the spec MUST cover those case, but as long as it's not ambiguous then it only complexifies things for what will probably be most of the cases anyway. I'm afraid that if we force complexity for the sake of data "beauty", people will not use the spec anyway. Pov 17:09, 5 December 2008 (UTC)

Why allow to have several "from" roles in one relation? The proposal DOES cover the case, it sais: Have two relations. (See example 4). I will start a new headline to collect the pros and cons. --Lulu-Ann 11:16, 7 December 2008 (UTC)

"Multi-Enforcements": Separate relations vs. Several "from" node is one relation

Pro several relations

• The data model stays normalized.--Lulu-Ann 11:16, 7 December 2008 (UTC)
• This is in line with other relation data models, where several relations occure at the same place accidently. Nobody would request to have different bus routes in the same relation, just because they accidently share one common bus stop. --Lulu-Ann 11:16, 7 December 2008 (UTC)
• If more information is added later, there is no need to split up formerly united enforcements. (Expample: Maxspeed cam taking photos in 2 directions, initially added as one relation with two "from" nodes. Later the two different maxspeed values shall be added, the splitting up gets neccessary anyway) ... THIS variant is easier to maintain! --Lulu-Ann 11:16, 7 December 2008 (UTC)
• The case of several enforcements at one place is not very likely. I estimate a maximum of 3% of the enforcement places in central Europe will have more than one "from" roles and therefore more than one relation (Even less in lesser developed countries). It is not efficient to force rendering and routing software programmers to add the supporting of several "from" roles in one relation. --Lulu-Ann 11:16, 7 December 2008 (UTC)
• If used in a routing software: If you approach a device, you are only interested in the icons that represent the device from where you are coming. If there are several "from" nodes in the picture frame you are shown, it will look confusing and you will be shown irrelevant information. --Lulu-Ann 11:16, 7 December 2008 (UTC)

Pro several "from" roles in one relation

Irrelevant arguments on Pro several "from" roles in one relation

• There might be few users who are overburdened to differenciate when more than one relation is displayed in their editor at the same place. (This is not relevant, nobody is forced to add relations, nobody is forced to use an editor to highlighting all relations in the same color. This is also not relevant, because it is not an issue of traffic enforcement, but of relation mapping in general. Even much more relations at one place occur at bus station, on bicyle lane where several touristic routes go along etc, etc... <<irony on>>I am awayting the day where this is realized and such unnormalized relations for that are requested on those pages... making the already existing rendering algorithms for bicycle maps worthless and malfunctioning.<<irony off>>)--Lulu-Ann 11:16, 7 December 2008 (UTC)
• Lazy mappers save clicks: mark the second "from"-node, add a new relation, enter the type of the new relation: 'Type e-n-f-o-r-c-e-m-e-n-t, hit enter', enter the type of the new relation: "Type m-a-x-s-p-e-e-d, hit enter", mark the second "device"-node, add it to the relation: "Click 'add to relation', choose relation (usually no click because of good preselection), hit enter'. Argh, I will have to remove the first action, because it is needed in BOTH cases...
  --Lulu-Ann 14:31, 8 December 2008 (UTC)

(<<irony on>> Whooohoo! This is really an argument. Btw, dear reader, how many multi-enforcement devices are in YOUR personal INITIAL mapping district? Is is worth to type an answer sentence of 50 characters here to argue, or will that bring you into a typing character deficit, als there is no occurance? <<irony off>>)--Lulu-Ann 14:31, 8 December 2008 (UTC)

I guess you have a point as far as lazy mappers forcing upon us bad practices: the spec shouldn't condone them. You also have a point in that relation edition complexity, in both JOSM or potlatch, is only a shortcoming of the editor not of the relation model and we should promote relation usage even though it's harder to enter than regular tags as of now. Only thing I'm partial on is your use of irony. With hotblooded users commenting, this could very well fuel the starting flame war. I wish we could use irony, but the debate was heated enough already. Pov 17:13, 7 December 2008 (UTC)

Unless enforced in ALL editors, this will be broken by lazy mappers (including me, I admit), and as long as Lulu-Ann is willing to search up all such broken relations and fix them, go ahead and enforce this. --Skippern 08:23, 9 December 2008 (UTC)

Relevant arguments on Pro several "from" roles in one relation

• ???

Recommended bypass

Where height or weight restrictions exists on a major highway, recomended bypass roads are often signed, such that goods vehicles over the weight limit, or vehicles which is higher than the restriction can safely bypass the restriction. Usually this restriction is physical (The tunnel is only 4 meter high, so you will not be able to pass with your 4.2 meter high load). The bypass road could be a relation that allows the vehicles to pass safely and re-enter the highway on the other side of the restriction. --Skippern 10:23, 4 December 2008 (UTC)

That's a good idea, but I guess it does not belong to the traffic enforcement but to the traffic restriction, so let's discuss it there. --Lulu-Ann 14:59, 5 December 2008 (UTC)

Aim for rejection

User:Lulu-Ann, are you aiming for a rejection of this proposal? We are still in draft, and if you have read anything I have written, than we need to simplify a lot with this proposal to get it more user/survey/software/maintenance-friendly. The reason I put in the alternative speed was to show you and anybody else how this could be simplified easily. Call it example 3 if alternative isn't good enough. If you cannot let input improve the proposal, than my vote will be no. --Skippern 11:14, 4 December 2008 (UTC)

No, I am not aiming for a rejection. You want to simplify the model, but I think that a model needs to be complex enough to reflect reallity as we can not change reality to fit to out models. I have explaned, added examples and given reasons for my model, and I have get rid of some misunderstandings. If you want want another proposal, go ahead, make your own. I will modify my model only in a way that it is still working for the next 20 years. You want it user/survey/software/maintenance-friendly. I want it functioning. Offering possibilities to simplify the model does not help, if then cases occur where there the simplifying needs to be forbidden because otherwise it's not clear what was meant anymore. I would be happy if you would not be so rude, I have not only read all your comments, I am even pretty fasts on answering all of them, so don't get personal, please. --Lulu-Ann 14:46, 5 December 2008 (UTC)

Your examples are confusing and complicated, easier examples are necessary, my alternative suggestion did not interfere with any of your examples, and showed two things, first how the relation could be simplified, and two, how it can be used to cover multiple relations. By rejecting to combine multiple directions in one relation will only serve one purpose, and that is to add to the clutter. Many areas are already becoming cluttered, and I am just about to start thinking of a way to merge relations without damaging the content. Maintenance is my reason for wanting to merge relations that way. Don't misunderstand me, I do not wish to put different types of functions into one relation, a speed camera and a red light camera should still be two relations, even if the same camera is used for both purposes. Your argument of still working for the next 20 years falls short on me, obviously you know little about software and maintenance. The software will work just as fine or bad with both our approaches, and leaning towards one or the other of the approaches will not break the code. I am sure that the program can handle one more for loop to read all the directions or measure points in one relation, just as it does with other relations. Just see how route and multipoligons are handeled. --Skippern 15:06, 5 December 2008 (UTC)

I refuse to aswer as I don't want to get offended any more. I am a software professional developing databases for over 10 years, and I guarantee my model is working fine. I don't need the vote of one person who thinks that the data quality gets better with each byte saved and who can not stay polite even after being reminded to it. --Lulu-Ann 15:59, 5 December 2008 (UTC)

Known countries, where the dynamic use is forbidden

• France

Relying on a dictionary and babelfish, again, the law seems to use "à déceler la présence", for which verb there's not only the meaning "to detect" but also "to reveal" or "to indicate" - one can not detect something one already knows but if indicating is also in the meaning of the verb in this context it's quite obvious. It's wordplay but your lawyer should know how to do that. Unfortunately the law continues with (since 2003) "or of making it possible to withdraw itself from the observation" - so even a router making a route to avoid speed cameras could be claimed to be forbidden equipment - if pursued by the officials in power. Alv 07:13, 9 December 2008 (UTC)

First sentence, "déceler la présence" is very clear if you search the word déceler in a dictionary. "déceler" : "Dévoiler ce que quelqu’un cache intentionnellement." (reveal what somebody intentionally hid). But even if it's not clear enough, "dévoiler" (reveal) : "Découvrir une chose qui était cachée, secrète." (To uncover something hiden, secret). We certainly don't do that. Location is known beforehand and if you pass a radar not in the DB you won't be warner, hence, it doesn't uncover stuff. Second sentence is "perturber le fonctionnement d'appareils, instruments ou systèmes" which is not ambiguous at all. It means tampering with/jamming radars. Third sentence is more subtle, "de permettre de se soustraire à la constatation desdites infractions": "to avoid being controlled while driving too fast". But this isn't our case, we wouldn't prevent people from being fined if they drove too fast. We would only remind them the speed limit, which they can fail to respect and then be fined.

All in all the law is pretty clear and our use legal. Not only that, but like I said there's already a lot of databases and devices that remind you of the presence of radars anyway, and nobody ever claimed they were illegals.

• Germany [1]

Actually "enforcement measures"; Since the next clause further defines that to "especially disturbing or indicating speed enforcement (radar detectors and laser disturbers)", it might be debatable (unless already tested in court) that only detecting the radars by technical measures is forbidden. At least the Finnish legalese "on devices hindering speed enforcement" is written with equal wording and no one has claimed that the information, nor the use thereof, on static cameras could be illegal. My dictionaries are somewhat vague on the word "anzeigen", which is it more akin to in this context: "to reveal", "to detect" or "to indicate"? The answer might be in the preparatory documents for that law. ("to predict" wouldn't make sense in that context). Alv 08:06, 4 December 2008 (UTC)

"Anzeigen" means "to indicate". --Lulu-Ann 11:09, 4 December 2008 (UTC)

• Switzerland [2] and [3] --Jeff42 13:26, 5 December 2008 (UTC)

That seems like a clear case, unless someone contests in court - even the ministry's interpretation of the law could be deemed wrong. Wording seems equal to the German and Finnish law so it's still interpretation. Alv 13:02, 6 December 2008 (UTC)

[4] and [5] --Thomas1904

Multiple enforcements

One quick question: since most of the devices that check for drivers not obeying traffic lights also check the speed, we need a way to map multiple enforcements. I guess enforcement=maxspeed;traffic_signals will do it? --Eimai 14:30, 8 January 2009 (UTC)

No, use two relations. See pros and cons above. --Lulu-Ann 16:33, 12 January 2009 (UTC)

Renderer

Hi there, can anybody set up a renderer for this, please? --Lulu-Ann 14:37, 14 January 2009 (UTC)

I'm please to show my first try do render speed camera positions on a slippy map: http://freeroute.fr/enforcements.htm. Data are updated from the OSM database on a manual basis (don't try to see your changes dynamicaly :-)) --Marcussacapuces91 10:30, 16 May 2009 (UTC)

Cool, thanks a lot! --Lulu-Ann 19:57, 16 May 2009 (UTC)

http://latlon.org/tc but it does not support relation yet. Kos32 09:20, 23 November 2010 (UTC)

Routing software

• Add software here that already supports traffic enforcement.
  • OsmAnd
  • ...

Average Speed Cameras / "section control"

How does everyone suggest these be tagged? - they use ANPR (Automatic Number Plate Recognition) to calculate the average speed of a vehicle over a distance of 200meters to 10km, and are a very common form of speed camera here in Nottingham, and also common in roadworks on UK motorways http://en.wikipedia.org/wiki/SPECS_(speed_camera) has a smidgen more info -- Kevjs1982 21:05, 17 February 2009 (UTC)

Hi, I am already aware of the fact that "section control" is not yet covered by the proposal - I missed it because it is not in use in Germany. I think that we could use enforcement=average speed and start_device, end_device on nodes ? Any comments on that? --Lulu-Ann 13:48, 18 February 2009 (UTC)

My comment: it's quite frequent in Italy (known as Tutor here). I was at first thinking of using the regular "maxspeed" scheme, tagging the whole section which is surveyed as "device".

Then again: the monitored sections here in Italy can be quite long, usually on motorways, often with multiple ramps within the section. In this case it's important that the stretch of the way on which the limit is enforced is tagged as such, and the direction in which the limit is enforced (not a problem on motorways, but the system may just as well be used on other types of roads).

The from/to roles serve the main purpose of defining the direction in which the limit is enforced - if we can accomplish that in a different way, that would make them redundant. (As for warning the driver - it is better to have the software figure out where to start doing that, rather than hard-code that into the map.)

Therefore I can think of two different options:

* Split the way at the first and last camera and add the relevant section(s) to the relation. Use e.g. enforcement; on a two-way road, use enforcement:forward or enforcement:backward if only one direction is monitored. The from/to roles would not be needed for these cases.

* Tag each camera separately and add each to the relation, the role could be e.g. device. This still requires the from/to roles, unless the cameras are sorted (high potential of error), with an indication of whether the enforcement is one-way or two-way.

The first one has the advantage of being easy to map (I admit to being lazy - that's why I studied computer science and not, say, law or medicine ;-), while the second one is more precise: Suppose the following stretch of motorway:

===A==#=====#==B==#=====#==C===

Vehicles which get on the motorway at ramp B will not be subject to enforcement on the stretch between the ramp and the next camera. All other traffic will.

So it boils down to the the single question: Is the extra precision offered by the second option worth the extra effort and increased error potential it implies? Despite being a precise guy, at the moment I tend to favor the first option. --Stanton 21:03, 12 March 2011 (UTC)

To do

• Define value for section control
• Define value for signs "speed control ahead" without permanent device:

• Define value for toll control bridges (Germany, DE:Mautbrücken)

--Lulu-Ann 20:01, 16 May 2009 (UTC)

Well known measure area

What do you think about the following proposition for temporary measure area :

opening_hours=unknown --Marcussacapuces91 20:47, 25 May 2009 (UTC)

I suppose it would be better to use a new tag "hours". Kos32 09:19, 23 November 2010 (UTC)

What do you mean by "temporary measure area"? A preferred place for temporarily setting up a speed camera/laser device etc.? I was wondering about the same. Consider also that, for some fixed boxes you may have seen, the camera inside may be removable. Authorities may have more boxes than cameras and move cameras between boxes at will - so not all fixed devices are active at all times and thus may be "temporary" as well. I know of at least another case in which the camera is occasionally turned around to monitor the opposite direction.

My approach would be to introduce an extra tag to distinguish between fixed installations, preferred locations for temporary enforcements and (optionally) mobile devices in fixed boxes. E.g. setup=* with possible values being permanent, temporary or variable. For the "rotating" camera I would use two relations (one for each direction) and tag either as setup=variable. --Stanton 21:33, 12 March 2011 (UTC)

Device node position

It is said:

Choose a node on the highway from where the vehicles checked come from. If there is a sign "radar controlled" or "traffic signals ahead" put the node where the sign is, if there is no sign, estimate a sensible distance where a driver would need to be warned of the object if driving with allowed speed. Make this node a member of the relation with the role "from".

But I think the mapping should show the exact place of the device. It is up to the driver or to the software to use direction and speed information to take the location information into account.... Would you change the location of a tunnel of 3 meters height so as to allow the truck driver to stop before the tunnel entrance ? As it is said in the foreword of the page: Why? - Because we want to reflect reality.

I update the page as said. Please tell if you disagree Matclab

There is another node for the "device" role than for the "from" role. Please read again. You don't want to drive 3km into a road that ends in a tunnel that you can not pass, you want your navigation device to warn you when you enter the street, not when you crash your hgv. --Lulu-Ann 12:27, 19 August 2009 (UTC)

<math>Formel hier einfügen</math>

bus lane enforcement?

We have a section on one of the main roads entering the city where lots of drivers were using the bus lane even when they weren't turning right at the intersection, and random enforcement wasn't effective enough, so they installed a fixed camera. After finding nothing previously used, I used enforcement=bus_lane for that. Does it exist anywhere else? Alv 11:34, 14 November 2011 (UTC)