Hi,
A few problems with the current approach:
1) When several things pass over the same bridge (eg,
highway=secondary, highway=cycleway and highway=footway; or even just
two independent lanes), renderers currently draw multiple bridges.
2) In areas where structures (buildings, paved areas, piers,
Am 01.02.2013 um 00:01 schrieb Michael Kugelmann :
> On 31.01.2013 12:06, Martin Vonwald wrote:
>> I'm looking for some alternatives to map tunnels and bridges that
>> contain several ways. I'm not really happy with the proposed relation
> -1
> The current method is used and well established sinc
On 31.01.2013 12:06, Martin Vonwald wrote:
I'm looking for some alternatives to map tunnels and bridges that
contain several ways. I'm not really happy with the proposed relation
-1
The current method is used and well established since years and for my
point of view works fine. So I clearly di
2013/1/31 Tobias Knerr
>
> I think you are overlooking several problems. To start with,
> building:part cannot do arcing structures - like many bridge decks. They
> can also not easily to structures that become wider or narrower towards
> the top - like some bridge piers.
>
Anything more complic
Am 31.01.2013 18:14, schrieb Malcolm Herring:
On 31/01/2013 15:17, Martin Vonwald wrote:
As you already need to
split the roads at the edges of the structure, because you need to add
the layer (and bridge) key within the structure, there are already
nodes present - just connect them with the OSM
On 31.01.2013 18:39, Philip Barnes wrote:
> Not splitting the way for every bridge will make tagging a lot easier.
Won't anybody think of the poor renderers? :(
Until now we could rely on the assumption that every way is *either* on
the ground *or* above the ground. Which is pretty helpful imo.
On 1/31/13 12:53 PM, Richard Welty wrote:
On 1/31/13 12:39 PM, Philip Barnes wrote:
+1
Not splitting the way for every bridge will make tagging a lot
easier. Often when things such as speed limits on long sections of
road, bridges get missed and then often the cause of extra routing
instructi
On 31.01.2013 17:31, Janko Mihelić wrote:
> I read a bit about 3D buildings, and it's pretty compatible. Here is an
> article about simple 3D buildings:
>
> http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
I think you are overlooking several problems. To start with,
building:part cannot do
On 1/31/13 12:39 PM, Philip Barnes wrote:
+1
Not splitting the way for every bridge will make tagging a lot easier. Often
when things such as speed limits on long sections of road, bridges get missed
and then often the cause of extra routing instructions if a reference tag is
missing.
it will
+1
Not splitting the way for every bridge will make tagging a lot easier. Often
when things such as speed limits on long sections of road, bridges get missed
and then often the cause of extra routing instructions if a reference tag is
missing.
Phil (trigpoint)
--
Sent from my Nokia N9
On 3
On 31/01/2013 15:17, Martin Vonwald wrote:
As you already need to
split the roads at the edges of the structure, because you need to add
the layer (and bridge) key within the structure, there are already
nodes present - just connect them with the OSM way of the structure.
Why do you need split
On Thu, Jan 31, 2013 at 5:13 PM, Peter Wendorff
wrote:
> For data consumers supporting the new it follows: If there's no bridge-area
> (e.g. man_made=bridge) defined, but there's a bridge=yes, I have to assume
> an error, I might report that as such and/or I should fall back to assume a
> bridge-
I read a bit about 3D buildings, and it's pretty compatible. Here is an
article about simple 3D buildings:
http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
Here is a picture that shows the concept of building:parts:
http://wiki.openstreetmap.org/w/index.php?title=File:Minlevel.svg&page=1
2013/1/31 Martin Vonwald :
> In my opinion this is a rather obvious approach therefore I'm not
> surprised that someone already came up with it earlier. But I am
> definitively surprised that we don't have any documentation in the
> wiki for it.
there are real examples, e.g. these two:
http://ww
Am 31.01.2013 16:57, schrieb Janko Mihelić:
Well, having building=bridge and bridge=yes isn't two features. First
one is "the" feature (bridge) and the second one is the road with an
attribute (it is on a bridge). They are redundant, but I wouldn't call
them duplicated.
They are duplicated if
For Mapnik it might be even more simple, but I'm not sure.
Currently Mapnik as far as I know draws the following (in order):
bridges:
1) bridge-casing
2) highway-casing (is that rendered on bridges currently?
3) bridge-fill
4) highway-fill
5) highway-label
we now propose to add the bridge-area. I
2013/1/31 Tobias Knerr
>
> It will not be possible for every way on top of the bridge to share
> nodes with the outline.
>
You are right, it's a bit more complicated than what I described.
2013/1/31 Pieren
>
> Bad idea. I like the principle "one feature, one OSM element". Solve
> rendering is
On Thu, Jan 31, 2013 at 4:17 PM, Martin Vonwald wrote:
> I would not do that. I would keep the bridge=xxx tags for backward
> compatibility.
Bad idea. I like the principle "one feature, one OSM element". Solve
rendering issues in the rendering toolchain.
Pieren
On 31.01.2013 16:24, Janko Mihelić wrote:
> I even drew it:
> http://i.imgur.com/uk5RXjL.png
>
> So, a renderer could find out if a road that has the tag bridge=yes is
> connected to a way that has a tag building=bridge on both ends. If it
> is, it doesn't render the black lines on left and right
I even drew it:
http://i.imgur.com/uk5RXjL.png
So, a renderer could find out if a road that has the tag bridge=yes is
connected to a way that has a tag building=bridge on both ends. If it is,
it doesn't render the black lines on left and right of road. That's why I
think it's better not to remove
2013/1/31 Malcolm Herring :
> Martin,
>
> Maybe I am missing something from your proposal.
No proposal - just ideas ;-)
>I had understood it to mean
> that bridges should be mapped as distinct features, separate from the ways
> that pass over and under. Therefore, "bridge=..." tags on the ways w
On Thu, Jan 31, 2013 at 3:51 PM, Malcolm Herring
wrote:
> Maybe I am missing something from your proposal. I had understood it to mean
> that bridges should be mapped as distinct features, separate from the ways
> that pass over and under. Therefore, "bridge=..." tags on the ways would
> become r
Martin,
Maybe I am missing something from your proposal. I had understood it to
mean that bridges should be mapped as distinct features, separate from
the ways that pass over and under. Therefore, "bridge=..." tags on the
ways would become redundant and remove the ambiguity and messy rendering
2013/1/31 Malcolm Herring :
> On 31/01/2013 13:44, Martin Vonwald wrote:
>>
>> * =bridge : this is the tag we should decide one. I guess
>> the value "bridge" is unchallenged.
>
>
> -1
> If the primary tag is bridge=, then why do we need the above tag at
> all?
The key "bridge" is currently used t
On 31/01/2013 13:44, Martin Vonwald wrote:
* =bridge : this is the tag we should decide one. I guess
the value "bridge" is unchallenged.
-1
If the primary tag is bridge=, then why do we need the above tag
at all?
___
Tagging mailing list
Tagging@o
2013/1/31 Pieren :
> On Thu, Jan 31, 2013 at 2:44 PM, Martin Vonwald wrote:
>
>> * =bridge : this is the tag we should decide one. I guess
>> the value "bridge" is unchallenged.
>
> My 2 cents:
> - area=bridge
> - area:bridge=yes
> - man_made=bridge
> - amenity=bridge (I'm joking)
All fine, but t
On Thu, Jan 31, 2013 at 2:44 PM, Martin Vonwald wrote:
> * =bridge : this is the tag we should decide one. I guess
> the value "bridge" is unchallenged.
My 2 cents:
- area=bridge
- area:bridge=yes
- man_made=bridge
- amenity=bridge (I'm joking)
Pieren
__
On 31/01/2013 13:44, Martin Vonwald wrote:
* bridge= : use this tag just like it is used at the moment. If
the value would be "yes" it should be optional.
Again, borrowing from IHO, they define the following bridge types:
fixed
opening
swing
lifting
bascule
pontoon
drawbridge
transporter
foot
On 31.01.2013 14:06, Martin Koppenhoefer wrote:
> 2013/1/31 Tobias Knerr :
>> http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae79b9.jpg
>
> I wouldn't call this a "bridge", it is a vault, but the "bridge" (or
> viaduct) if you wanted to map it would (IMHO) be the structure
Am 31.01.2013 14:44, schrieb Martin Vonwald:
In my opinion this is a rather obvious approach therefore I'm not
surprised that someone already came up with it earlier. But I am
definitively surprised that we don't have any documentation in the
wiki for it. I see a lot of bridges with many ways run
In my opinion this is a rather obvious approach therefore I'm not
surprised that someone already came up with it earlier. But I am
definitively surprised that we don't have any documentation in the
wiki for it. I see a lot of bridges with many ways running over it
(two footways, two cycleways, two
2013/1/31 Pieren :
> On Thu, Jan 31, 2013 at 2:06 PM, Martin Koppenhoefer
> wrote:
>>
>> I wouldn't call this a "bridge", it is a vault, but the "bridge" (or
>> viaduct) if you wanted to map it would (IMHO) be the structure as a
>> whole, not just a single segment.
>
> Instead of "building=bridge"
On 31/01/2013 12:37, Martin Koppenhoefer wrote:
drawing the outline seems a good approach as it permits to group
visually (and topologically) different carriageways running over the
same bridge (as opposed to two parallel bridges).
This is approach is used by IHO for marine chart data. Where a
On Thu, Jan 31, 2013 at 2:06 PM, Martin Koppenhoefer
wrote:
>
> I wouldn't call this a "bridge", it is a vault, but the "bridge" (or
> viaduct) if you wanted to map it would (IMHO) be the structure as a
> whole, not just a single segment.
Instead of "building=bridge", you might choose "man_made=b
2013/1/31 Tobias Knerr :
> On 31.01.2013 13:24, Janko Mihelić wrote:
>> I like building=bridge.
>
> Not a good choice imo. According to a recent discussion, mappers might
> want to use that tag specifically to map buildings built into bridges -
> like these:
>
> http://ampelmann-restaurant.de/conte
On 31.01.2013 13:24, Janko Mihelić wrote:
> I like building=bridge.
Not a good choice imo. According to a recent discussion, mappers might
want to use that tag specifically to map buildings built into bridges -
like these:
http://ampelmann-restaurant.de/content/images/1a162245ce191485484b155c6eae
On 31.01.2013 12:06, Martin Vonwald wrote:
> I'm looking for some alternatives to map tunnels and bridges that
> contain several ways. I'm not really happy with the proposed relation
> [1]. Is there any other approach for this? I'm asking myself why don't
> we simply map the outline of the bridge/t
2013/1/31 Martin Vonwald :
> Hi!
>
> I'm looking for some alternatives to map tunnels and bridges that
> contain several ways. I'm not really happy with the proposed relation
> [1]. Is there any other approach for this? I'm asking myself why don't
> we simply map the outline of the bridge/tunnel (t
2013/1/31 Martin Vonwald
> Hi!
>
> I'm looking for some alternatives to map tunnels and bridges that
> contain several ways. I'm not really happy with the proposed relation
> [1]. Is there any other approach for this? I'm asking myself why don't
> we simply map the outline of the bridge/tunnel (t
Hi!
I'm looking for some alternatives to map tunnels and bridges that
contain several ways. I'm not really happy with the proposed relation
[1]. Is there any other approach for this? I'm asking myself why don't
we simply map the outline of the bridge/tunnel (the latter may be more
difficult to obt
40 matches
Mail list logo
