On Aug 28, 2013 8:17 AM, "Pieren" wrote:
> But another point is traffic signals where a bicycle can ignore red
> light stop when he is turning to right (right-hand traffic). This is
> allowed in some coutries, sometimes only with a specific road sign. I
> don't know how it is tagged currently.
T
That's right, even in the best case scenario (mapping them at their
actual locations and expressing their impact on roads using
relations), we'd still end up with approximated delays for routing
which may be completely unrelated to the resulting, emerging traffic
patterns. So mapping the lights at
On Wed, Aug 28, 2013 at 7:57 AM, Fernando Trebien <
fernando.treb...@gmail.com> wrote:
> However, routing would double count traffic lights in two-way roads
> (as in Kytömaa's counting), though guessing the direction by proximity
> to the intersection should be accurate here in about 99% of the ca
Am 28.08.2013 15:16, schrieb Pieren:
> But another point is traffic signals where a bicycle can ignore red
> light stop when he is turning to right (right-hand traffic). This is
> allowed in some coutries, sometimes only with a specific road sign. I
> don't know how it is tagged currently.
I know
I've been inclined to combining traffic lights
(highway=traffic_lights) and pedestrian crossings
(crossing=traffic_lights), since they usually form a single "stopping"
structure. The traffic light node then represents the "stop position"
of the cars, even if the light itself is placed in the middle
On Wed, Aug 28, 2013 at 3:01 PM, Martin Koppenhoefer
wrote:
> (to reduce traffic in certain areas). Routing algorithms would have to know
> all phases of the traffic lights for a perfect result.
About the "green wave", it could be modelized with another relation
(or super-relation) grouping of t
2013/8/28 Kytömaa Lauri
> I won't be saying anything about the discussed
> alternatives at this time, but just wish to point
> out that "this intersection is controlled by signals"
> when used only on the intersection nodes, can't
> be straight away used as a constant time penalty
> for each such
On Wed, Aug 28, 2013 at 1:39 PM, Kytömaa Lauri wrote:
> I'd be happy to see someone explain here how their
> router does something more complex with the
> highway=traffic_signals nodes.
When I check OSRM, it seems that at the moment, a node tagged with
"highway=traffic_signals" is detected and
Pieren wrote:
>was placed on the intersection node itself.
>routine engine where routes with traffic signals
>are penalized.
I won't be saying anything about the discussed
alternatives at this time, but just wish to point
out that "this intersection is controlled by signals"
when used only
2013/8/28 Pieren
> I misunderstood your case. I think in editors like josm, when you
> change the direction of the way, you are prompted for the tags which
> could be changed. I guess the same could be done for the child nodes.
> The mapper would have to decide which node/tag is affected or not
>
On Wed, Aug 28, 2013 at 9:02 AM, Peter Wendorff
wrote:
>> First, this can controlled by a QA tool and fixed.
> Fixed?
> What's wrong with that?
> It's a totally valid mapping situation, as long as the idea with
> direction on nodes is (as it is yet) not the common tagging proposed,
> e.g. because
Am 27.08.2013 17:38, schrieb Pieren:
> On Tue, Aug 27, 2013 at 5:15 PM, Peter Wendorff
> wrote:
>> It's more reliable to guess the direction by
>> nearest-distance-to-next-intersection than to rely on any mappers to
>> keep that up to date, especially with iD making it extremly easy (which
>> is g
> Date: Tue, 27 Aug 2013 23:35:45 +0200
> From: pier...@gmail.com
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Micro mapping traffic signals
>
> On Tue, Aug 27, 2013 at 11:22 PM, Vincent de Château-Thierry
> wrote:
>
> > This only deals with single
On 27.08.2013 16:02, Pieren wrote:
> My proposal:
> - when micro-mapping the traffic lights, use a different tag than
> "highway=traffic_signals" which should be reserved for the "simple,
> old" fashion way of mapping the intersection itself.
> - create a new tag for the micro-mapping of each indiv
On Tue, Aug 27, 2013 at 8:15 AM, Peter Wendorff
wrote:
> It's more reliable to guess the direction by
> nearest-distance-to-next-intersection than to rely on any mappers to
> keep that up to date, especially with iD making it extremly easy (which
> is good) to change a ways direction.
But... tha
Le 27/08/2013 23:35, Pieren a écrit :
On Tue, Aug 27, 2013 at 11:22 PM, Vincent de Château-Thierry
wrote:
This only deals with single traffic light mapping and will not solve the low
scale rendering issues (how to put a single icon for multiple traffic
lights) and the routing through multipl
On Tue, Aug 27, 2013 at 11:22 PM, Vincent de Château-Thierry
wrote:
> This only deals with single traffic light mapping and will not solve the low
> scale rendering issues (how to put a single icon for multiple traffic
> lights) and the routing through multiple synchronised traffic lights.
It's
Hi,
Le 27/08/2013 16:31, fly a écrit :
Stop using forward/backward on nodes but use an relation similar to
turn-restrictions for traffic_signals and enforcement.
I agree, turn-restriction scheme is quite similar and could be a good
start at least for single traffic light mapping.
From, via
On Tue, Aug 27, 2013 at 5:15 PM, Peter Wendorff
wrote:
> It's more reliable to guess the direction by
> nearest-distance-to-next-intersection than to rely on any mappers to
> keep that up to date, especially with iD making it extremly easy (which
> is good) to change a ways direction.
This was al
It's more reliable to guess the direction by
nearest-distance-to-next-intersection than to rely on any mappers to
keep that up to date, especially with iD making it extremly easy (which
is good) to change a ways direction.
nodes should NOT depend on the direction of any way they belong to.
Second
On 27.08.2013 16:40, Pieren wrote:
> On Tue, Aug 27, 2013 at 4:31 PM, fly wrote:
>
>> This should go into a proposal first.
>
> I'll waste my time on a wiki proposal if I see major concerns here. In
> the other case, the wiki will follow.
>
>> Forward/Backward do not work on nodes !
>
> Of cou
Seems like this would be better done as a relation. Also, still seems this
has yet to be resolved for anything other than a 4-way stop, and to a
lesser extent (due to the nature of being usually placed on ramps, or in
neighborhoods as an all-way control) give_way (though still unresolved for
two-w
On Tue, Aug 27, 2013 at 4:31 PM, fly wrote:
> This should go into a proposal first.
I'll waste my time on a wiki proposal if I see major concerns here. In
the other case, the wiki will follow.
> Forward/Backward do not work on nodes !
Of course it works and applies in some other tags. The node
Thanks for this report, Pieren.
This should go into a proposal first.
Forward/Backward do not work on nodes !
You need a relation or use ways.
Stop using forward/backward on nodes but use an relation similar to
turn-restrictions for traffic_signals and enforcement.
cu
fly
On 27.08.2013 16:02, P
Hi all,
If you did not notice, the OSM routing fans [1] are just pushing the
sub-tag "traffic_signals:direction" in the wiki:
http://wiki.openstreetmap.org/wiki/Traffic_signals
http://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
This is trying to fix one old issue in OSM. The tag
"h
25 matches
Mail list logo
