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
"underground" is an attribute in local government databases of roads around
here: for earthquake purposes the
major arterial routes have priority for utility undergrounding. Thus it it
even possible to robottag huge swathes, subject to the usual concerns about
robotagging.
On Wed, Aug 28, 2013 at 12:11 PM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:
> Il giorno 28/ago/2013, alle ore 20:34, Bryce Nesbitt
> ha scritto:
>
> > We have lots of geometry that follows roads: sidewalks, bike lanes,
> cycleways, contraflow cycleways, kerbs. Why not power?
> I can f
2013/8/28 Martin Koppenhoefer
>
> I'd not use man_made tower for power towers, no need to pull them all
> there.
>
We don't want to pull power towers in man_made from power=*
power=tower isn't proposed for deprecation yet.
The fact is we need power=* for other features which can be found on the
ref: http://en.wikipedia.org/wiki/Pack_station
I assume it should be tourism=something but what the "something" is is not
obvious.
Nothing shows in the wiki or taginfo that I can see or "outfitter" or
"pack_station", etc.
>From Wikipedia, it seems this might be a regional name but the hints on
w
Il giorno 28/ago/2013, alle ore 20:34, Bryce Nesbitt ha
scritto:
> We have lots of geometry that follows roads: sidewalks, bike lanes,
> cycleways, contraflow cycleways, kerbs. Why not power?
I can follow your argument ("who's gonna do all that dumb work of tracing power
lines in large ru
Il giorno 28/ago/2013, alle ore 20:15, François Lacombe
ha scritto:
> +1 Martin, it would make the model simpler.
>
> * man_made=tower + tower:type=utility
>
> * man_made=pole
>
> I don't think there something smaller, do you ?
I'd not use man_made tower for power towers, no need to pull
How about a lightweight version of this, for the rather common situation
where the power infrastructure follows the roads, and the mapping won't be
detailed due to lack of micro-mapping energy? Think miles and miles of
rural highway... are you planning to trace each road? Can't you map a lot
more
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
+1 Martin, it would make the model simpler.
* man_made=tower + tower:type=utility
* man_made=pole
I don't think there something smaller, do you ?
*François Lacombe*
francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
2013/8/28 Martin Koppenhoefer
>
> 2013/8/28 John
We've established:
1. There are all manner of vehicles that may have trouble getting
through the chicane
(bikes, trikes, tandems, trailers, wheelchairs, canoe trailers,
trail-a-bikes, land-rover baby strollers, etc.)
2. No simple geometry measurement determines what will fit (
ht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Volker
Am 28.08.2013 18:43, schrieb Volker Schmidt:
> 1) the precision measurement of the barrier?
the mapper
> 2) the precision measurement of the bicycle?
the cyclist
Unfortunately this is the only real solution. All other solutions with
a s
And who is doing in your opinion:
1) the precision measurement of the barrier?
2) the precision measurement of the bicycle?
3) how does the routing work? You have to give it the paramaters of the
bike & trailer?
This is simply not practical. We need a more pragmatic approach
Volker
On 28 Augus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's depends on the geometry of the barrier.
# ... pole
- - ... bar
1.
##
quiet easy, width between two poles is enough
2.
#-#
#-#
you'll need the space to the left/right and the distance between the
two parts
3.
##-#
|
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
Am 28.08.2013 13:21, schrieb Martin Koppenhoefer:
> 2013/8/28 Peter Wendorff
>
>> bicycle:trailer=no would say "it's not ALLOWED to cross this barrier
>> with a trailer" - and that is simple but wrong.
>>
>
>
> -1, as this is a new key it would probably not be defined to be an
> access-restrict
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 John Sturdy
> For that, I'd suggest man_made=pole with power=yes and telephone=yes,
> or something like that (maybe "communication" instead of "telephone",
> as telephone lines are also used for ADSL etc).
>
I don't think every single node has to get these attributes, it should be
suf
2013/8/28 John Sturdy
> Yes, even if you micromapped the whole geometry, it's hard to tell how
> large an object you can get through the restrictions --- see
> http://en.wikipedia.org/wiki/Moving_sofa_problem for an open
> mathematical problem related to chicanes!
>
You could solve it graphica
2013/8/28 Peter Wendorff
> bicycle:trailer=no would say "it's not ALLOWED to cross this barrier
> with a trailer" - and that is simple but wrong.
>
-1, as this is a new key it would probably not be defined to be an
access-restriction but to be the physical possibility. Simply don't put it
on th
In many cases (as shown on the web page) cycle barriers are not designed to
> make the rider dismount, just slow down. The bicycle=dismount should be
> used when there is an actual requirement to get off, such as a sign saying
> so or some steps.
>
> Here in Padova, Italy, these cycle barriers are
On 27/08/2013 19:36, Volker Schmidt wrote:
I am particularly interested in tagging cycling routes, including the
national long-distance cycling network Bicitalia in Italy.
In Italy cycle paths are frequently de facto blocked by chicane-type
bicycle barriers.
So my tagging is typically a node
On Wed, Aug 28, 2013 at 1:35 AM, James Mast wrote:
> But what if the pole has both telephone and power on it? ;) That's what's
> common here in my neighborhood. I can look out my front door and see a pole
> with both of them using it.
For that, I'd suggest man_made=pole with power=yes and telep
Good point James,
We just have to use tower:type=power;communication;whatever for these
situations.
*François Lacombe*
francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
2013/8/28 James Mast
> But what if the pole has both telephone and power on it? ;) That's what
On Wed, Aug 28, 2013 at 10:45 AM, Volker Schmidt wrote:
> BTW the barrier business is also of interest to wheelchair users
And push-chair / baby buggy users... so probably best not make the
tagging for such things cycle-specific.
__John
___
Tagging m
"bicycle:trailer=no would say "it's not ALLOWED to cross this barrier
with a trailer" - and that is simple but wrong."
You have a point there.
What I want ideally is the equivalent of "width" (which I can measure) and
not of "max_width" (which is written on an official road sign).
But on a cycle
On Wed, Aug 28, 2013 at 1:58 AM, John F. Eldredge wrote:
> One can tag the maximum width that can fit through, given zero length, and
> can tag the maximum length that can fit through, given zero width, but a
> trailer that has BOTH the maximum length and maximum width will not fit
> through. You
On Wed, Aug 28, 2013 at 1:10 AM, Bryce Nesbitt wrote:
>> It's hard to set a value for them because they are depending on each
>> other. ;)
>
> bicycle:trailer=no might lead to bicycle:tandem=no, and a lot of
> really fuzzy tags of limited predictive value.
Another minority cycling group is triker
Am 28.08.2013 10:35, schrieb Volker Schmidt:
> Thanks for your useful comments, which essentially reflect the reasons for
> which I brought up the issue. Objective criteria are difficult to define.
> In particular max_width and max_length are useless because they are linked
> variables.
>
> Locall
Thanks for your useful comments, which essentially reflect the reasons for
which I brought up the issue. Objective criteria are difficult to define.
In particular max_width and max_length are useless because they are linked
variables.
Locally here things are relatively easy. Basically all of the b
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
37 matches
Mail list logo
