Re: Traffic sign direction tagging..

classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Anton Klim
Missed the point when direction= suddenly became a no go for traffic sign mapping. 


28.09.2018, в 3:51, Bryan Housel <[hidden email]> написал(а):

Hey Tagging List!

While reviewing a pull request to add Traffic Sign presets to iD, I came across a tagging issue with how traffic sign directions are tagged.
The details are here https://github.com/openstreetmap/iD/pull/5333 and relevant guidance on the OSM wiki is quoted below:

Traffic sign as a separate node
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
Create a separate node beside the road at the position of the actual sign... You can use the `direction=*` tag to describe the facing orientation of the sign by using an angle or cardinal direction.

^ This is ok!  iD supports `direction=*` and will even render a view cone at higher zooms so mappers can see which direction it points.

Traffic sign along a way
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
Create a new node within the relevant way next to the sign... You can use `traffic_sign:forward=*` to specify that this sign affects vehicles moving in the same direction as the OSM way. The opposite direction can be tagged with `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used to describe the affected direction. But its common meaning has changed to Relative to Geographic North.

^ This is the problem.  The wiki says we are supposed to do something like `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to be based on a "toplevel" tag like `traffic_sign=*` not `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many of their tags have this issue too, where they put a value in the key part, and so we can’t turn it into a preset).

So instead what we’ve decided to do is:  Support a tag `traffic_sign:direction` which works exactly the same as the existing and well supported `traffic_signals:direction`

iD already has support for  `traffic_signals:direction=forward/backward`

To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`

Thanks,
Bryan

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Marc Gemis
I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).
On Fri, Sep 28, 2018 at 9:26 AM Anton Klim <[hidden email]> wrote:

>
> Missed the point when direction= suddenly became a no go for traffic sign mapping.
>
>
> 28.09.2018, в 3:51, Bryan Housel <[hidden email]> написал(а):
>
> Hey Tagging List!
>
> While reviewing a pull request to add Traffic Sign presets to iD, I came across a tagging issue with how traffic sign directions are tagged.
> The details are here https://github.com/openstreetmap/iD/pull/5333 and relevant guidance on the OSM wiki is quoted below:
>
> Traffic sign as a separate node
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
>
> Create a separate node beside the road at the position of the actual sign... You can use the `direction=*` tag to describe the facing orientation of the sign by using an angle or cardinal direction.
>
>
> ^ This is ok!  iD supports `direction=*` and will even render a view cone at higher zooms so mappers can see which direction it points.
>
> Traffic sign along a way
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
>
> Create a new node within the relevant way next to the sign... You can use `traffic_sign:forward=*` to specify that this sign affects vehicles moving in the same direction as the OSM way. The opposite direction can be tagged with `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used to describe the affected direction. But its common meaning has changed to Relative to Geographic North.
>
>
> ^ This is the problem.  The wiki says we are supposed to do something like `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to be based on a "toplevel" tag like `traffic_sign=*` not `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many of their tags have this issue too, where they put a value in the key part, and so we can’t turn it into a preset).
>
> So instead what we’ve decided to do is:  Support a tag `traffic_sign:direction` which works exactly the same as the existing and well supported `traffic_signals:direction`
>
> See https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> iD already has support for  `traffic_signals:direction=forward/backward`
>
> To keep things simple, we'll do the same thing for traffic signs:
> `traffic_sign:direction=forward/backward`
>
> Thanks,
> Bryan
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

SimonPoole
In reply to this post by Anton Klim

I actually mentioned the issue in Milano.

Essentially traffic_sign, traffic_sign:forward and traffic_sign:backward need to be treated as "object" tags as things are now.

See pages 29 and 30 https://drive.google.com/open?id=1LVmZIaEvd1K7mYVqDLnrhC5-jHLHy0lQ

And I should note that iD has "plot" as such a key which is equally mysterious, but I couldn't quite convince myself to include in the list.

Simon


Am 28.09.2018 um 04:51 schrieb Bryan Housel:
Hey Tagging List!

While reviewing a pull request to add Traffic Sign presets to iD, I came across a tagging issue with how traffic sign directions are tagged.
The details are here https://github.com/openstreetmap/iD/pull/5333 and relevant guidance on the OSM wiki is quoted below:

Traffic sign as a separate node
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_a_separate_node
Create a separate node beside the road at the position of the actual sign... You can use the `direction=*` tag to describe the facing orientation of the sign by using an angle or cardinal direction.

^ This is ok!  iD supports `direction=*` and will even render a view cone at higher zooms so mappers can see which direction it points.

Traffic sign along a way
https://wiki.openstreetmap.org/wiki/Key:traffic_sign#As_part_of_a_way
Create a new node within the relevant way next to the sign... You can use `traffic_sign:forward=*` to specify that this sign affects vehicles moving in the same direction as the OSM way. The opposite direction can be tagged with `traffic_sign:backward=*`. Formerly the `direction=*` key has also been used to describe the affected direction. But its common meaning has changed to Relative to Geographic North.

^ This is the problem.  The wiki says we are supposed to do something like `traffic_sign:forward=US:R1`, and we can't really do that. A preset needs to be based on a "toplevel" tag like `traffic_sign=*` not `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark? many of their tags have this issue too, where they put a value in the key part, and so we can’t turn it into a preset).

So instead what we’ve decided to do is:  Support a tag `traffic_sign:direction` which works exactly the same as the existing and well supported `traffic_signals:direction`

iD already has support for  `traffic_signals:direction=forward/backward`

To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`

Thanks,
Bryan



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Bryan Housel-2
I actually mentioned the issue in Milano. 

Essentially `traffic_sign`, `traffic_sign:forward` and `traffic_sign:backward` need to be treated as "object" tags as things are now.

Let’s just do `traffic_sign=*` and consider the others an unfortunate mistake that can go away.


See pages 29 and 30 https://drive.google.com/open?id=1LVmZIaEvd1K7mYVqDLnrhC5-jHLHy0lQ

And I should note that iD has "plot" as such a key which is equally mysterious, but I couldn't quite convince myself to include in the list.

Not sure.. I just checked and iD don’t have `plot=*` as a key value, so maybe there’s an error in whatever process you used to gather the data.. 

The “toplevel” key values in iD are really just the names of all the folders here: 

Thanks, Bryan


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Kevin Kenny-3
In reply to this post by Marc Gemis
On Fri, Sep 28, 2018, 5:34 AM Marc Gemis <[hidden email]> wrote:
I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).

Me, too - I went around my neighbourhood last year adding them. OSMand does indeed recognize them.

Describing what a driver might see when approaching a turn would be an effective use of traffic_sign, but 'node near the way' is pretty useless for routing. For maximal detail you'd need both, but if you're only going to add one, the highway=stop is far more useful.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Philip Barnes


On 28 September 2018 17:31:18 BST, Kevin Kenny <[hidden email]> wrote:

>On Fri, Sep 28, 2018, 5:34 AM Marc Gemis <[hidden email]> wrote:
>
>> I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
>Me, too - I went around my neighbourhood last year adding them. OSMand
>does
>indeed recognize them.
>
>Describing what a driver might see when approaching a turn would be an
>effective use of traffic_sign, but 'node near the way' is pretty
>useless
>for routing. For maximal detail you'd need both, but if you're only
>going
>to add one, the highway=stop is far more useful.
+1
although also mapping the signs is useful for debugging.

OSMand also warns of traffic calming, toll barriers, level crossing, pedestrian crossings and enforcement cameras.

Phil (trigpoint)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Johnparis
Thank you for this, Bryan. One small favor: could you add a "Change direction" button like you have for one-way streets? It makes it much easier if I guess wrong :)



On Fri, Sep 28, 2018 at 6:58 PM Philip Barnes <[hidden email]> wrote:


On 28 September 2018 17:31:18 BST, Kevin Kenny <[hidden email]> wrote:
>On Fri, Sep 28, 2018, 5:34 AM Marc Gemis <[hidden email]> wrote:
>
>> I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
>Me, too - I went around my neighbourhood last year adding them. OSMand
>does
>indeed recognize them.
>
>Describing what a driver might see when approaching a turn would be an
>effective use of traffic_sign, but 'node near the way' is pretty
>useless
>for routing. For maximal detail you'd need both, but if you're only
>going
>to add one, the highway=stop is far more useful.
+1
although also mapping the signs is useful for debugging.

OSMand also warns of traffic calming, toll barriers, level crossing, pedestrian crossings and enforcement cameras.

Phil (trigpoint)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

SimonPoole
In reply to this post by Bryan Housel-2



Am 28.09.2018 um 18:07 schrieb Bryan Housel:
I actually mentioned the issue in Milano. 

Essentially `traffic_sign`, `traffic_sign:forward` and `traffic_sign:backward` need to be treated as "object" tags as things are now.

Let’s just do `traffic_sign=*` and consider the others an unfortunate mistake that can go away.
There are a total of 37'000 forward / backward variants that would have to be migrated to  traffic_sign + a suitable sub tag, not an awful lot in the grand scheme of things, but needs to be done.



See pages 29 and 30 https://drive.google.com/open?id=1LVmZIaEvd1K7mYVqDLnrhC5-jHLHy0lQ

And I should note that iD has "plot" as such a key which is equally mysterious, but I couldn't quite convince myself to include in the list.

Not sure.. I just checked and iD don’t have `plot=*` as a key value, so maybe there’s an error in whatever process you used to gather the data..

Sorry, just confusion on my hand: I was actually referring to allotments=plot with allotments as the "top-level" key (the plot bit is what I remembered, but it is still a one off top-level key).

Simon


The “toplevel” key values in iD are really just the names of all the folders here: 

Thanks, Bryan



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Philip Barnes


On 28 September 2018 22:14:03 BST, Simon Poole <[hidden email]> wrote:

>
>
>Am 28.09.2018 um 18:07 schrieb Bryan Housel:
>>> I actually mentioned the issue in Milano. 
>>>
>>> Essentially `traffic_sign`, `traffic_sign:forward` and
>>> `traffic_sign:backward` need to be treated as "object" tags as
>things
>>> are now.
>>>
>> Let’s just do `traffic_sign=*` and consider the others an unfortunate
>> mistake that can go away.
>There are a total of 37'000 forward / backward variants that would have
>to be migrated to  traffic_sign + a suitable sub tag, not an awful lot
>in the grand scheme of things, but needs to be done.

Not all give ways have a sign, some are just give way markings painted on the road.

Phil (trigpoint)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Paul Johnson-3
In reply to this post by Philip Barnes


On Fri, Sep 28, 2018 at 11:58 AM Philip Barnes <[hidden email]> wrote:


On 28 September 2018 17:31:18 BST, Kevin Kenny <[hidden email]> wrote:
>On Fri, Sep 28, 2018, 5:34 AM Marc Gemis <[hidden email]> wrote:
>
>> I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
>Me, too - I went around my neighbourhood last year adding them. OSMand
>does
>indeed recognize them.
>
>Describing what a driver might see when approaching a turn would be an
>effective use of traffic_sign, but 'node near the way' is pretty
>useless
>for routing. For maximal detail you'd need both, but if you're only
>going
>to add one, the highway=stop is far more useful.
+1
although also mapping the signs is useful for debugging.

OSMand also warns of traffic calming, toll barriers, level crossing, pedestrian crossings and enforcement cameras.

Also stopped warning of rumble strips, which is annoying since they're almost impossible to spot in advance in Oklahoma, as most of them are unpainted and, depending on the vehicle really try to wrest control of the steering away from motorists or introduce harmonic oscillation (aka speed wobbles) in two wheeled vehicles in the worst case, and really give you a good jumpscare at best.

I honestly miss getting "Attention: Rumble strip" out of Osmand.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Paul Johnson-3
In reply to this post by Bryan Housel-2


On Fri, Sep 28, 2018 at 11:09 AM Bryan Housel <[hidden email]> wrote:
I actually mentioned the issue in Milano. 

Essentially `traffic_sign`, `traffic_sign:forward` and `traffic_sign:backward` need to be treated as "object" tags as things are now.

Let’s just do `traffic_sign=*` and consider the others an unfortunate mistake that can go away.

I'm still against using forward/backward on nodes, it really feels like a hacky way to avoid using a relation (up there with using ref=* on ways to describe routes), which would disambiguate things without being so brittle just because a way reversed, and handle more complex situations like "right turn permitted without stopping" sign below a "stop" sign, or allow a data consumer to be able to display a diagram indicating which ways a stop applies to (handy if you encounter, say, a six way intersection with a four way stop).

I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Graeme Fitzpatrick
In reply to this post by Philip Barnes


On Sat, 29 Sep 2018 at 02:58, Philip Barnes <[hidden email]> wrote:
OSMand also warns of traffic calming, toll barriers, level crossing, pedestrian crossings and enforcement cameras.

Phil

Do you have an example of a pedestrian crossing that OSMand warns you of, as I don't see (or maybe just don't notice?) crossing warnings, so I'm wondering if they may be tagged somehow differently?
 
Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Graeme Fitzpatrick
In reply to this post by Paul Johnson-3



On Sun, 30 Sep 2018 at 08:58, Paul Johnson <[hidden email]> wrote:

I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

Maybe because people don't understand how to use them properly (I know I don't?), so they're scared of them?

Some very simple, easily found, instructions / guidelines would be handy.

Thanks

Graeme 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Kevin Kenny-3
In reply to this post by Paul Johnson-3
On Sat, Sep 29, 2018 at 6:58 PM Paul Johnson <[hidden email]> wrote:
> I'm still against using forward/backward on nodes, it really feels like a hacky way to avoid using a relation (up there with using ref=* on ways to describe routes), which would disambiguate things without being so brittle just because a way reversed, and handle more complex situations like "right turn permitted without stopping" sign below a "stop" sign, or allow a data consumer to be able to display a diagram indicating which ways a stop applies to (handy if you encounter, say, a six way intersection with a four way stop).
>
> I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

I agree with you that we need to design relations for the complex
cases such as what you describe, but I've no problem with the 'hacky'
approach as well - on the principle of 'make simple things easy and
complex things possible'. JOSM (and from what I understand, iD, but I
rarely use it) handles directional nodes on ways fairly competently,
detecting that the mapper is reversing a way that has such nodes
attached and asking what to do about them.

As far as the aversion to relations goes, I think a big part of it is
simply that the downstream support just isn't there.  The tools do
multipolygons fairly well, but that is the only relation that is
really handled well. A bit part of that is that once OSM data has been
through a stock osm2pgsql, there are no relations any more.
Multipolygons become first class objects, and all other relations are
handled at best by devolving their tags upon their components.

(The rest of this message is off the topic of stop signs.)

You raise the issue of ref=* on ways, and why we still use it. That's
a clear case where we use it because the downstream systems can't do
route relations.  I've been trying to help with this - at least to the
extent of trying to revive Phil! Gold's route relation processing. My
version is at https://github.com/kennykb/osm-shields, and you can see
one rendering with shaped shields based on relations at
https://kbk.is-a-geek.net/catskills/test4.html?la=42.7440&lo=-72.4830&z=11.
That link is chosen to illustrate an area that intermixes 'tag on way'
with 'tag on relation'. Unfortunately, my time is limited, so the
project has stagnated for a few weeks.  I've not given up, though; the
next task will have to be to generate a pull request to adapt
osm2pgsql optionally to preserve relations, with two new tables to
track them.

Alas, I don't have much hope that the pull request will be accepted.
I've asked the upstream developers several times if they could
possibly review the proposed functionality (I've at least a draft at a
formal proposal -
https://github.com/kennykb/osm-shields/wiki/Proposal:-add-route-tables-to-osm2pgsql)
so that I can know whether I'm entirely wasting my time. I've heard
nothng but silence.

This silence is understandable. The developers are very, very busy,
with much more urgent issues to address. I've not yet advanced the
idea far enough to merit their attention. But at some point, I will
have to conclude that further advances will simply cost me too much in
time and money to be worth risking, because a likely outcome is that
when I do get someone's attention, the whole idea will be dismissed
out of hand.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: My "weirdly unnatural aversion to relations"

Bryan Housel-2
In reply to this post by Paul Johnson-3
On Sep 29, 2018, at 6:56 PM, Paul Johnson <[hidden email]> wrote:

I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

From my own perspective as the main developer on the main editor for OSM, the reason I don’t like relations very much is because:
- every type of node basically works the same.
- every type of linear way basically works the same.
- every type of polygonal area basically works the same 
- every type of relation is an edge case that requires special code in order not to break.  

Relations are also problematic because they are unbounded.  Want to make a boundary relation with a million child ways?  This is allowed.  Want to ensure that all those ways are connected?  It may take minutes to download them all.  

They’re almost even a security threat.  I’m willing to bet a black hat could design and upload a relation that would destroy OSM.. Or at least, crash every piece of software in the stack that we rely on:  mapnik, osmium, and any editor that tries to touch it.  

Anyway, I’m not totally against them, but every one of them is different and I can't spend weeks or months supporting every kind of relation or public transport schema people dream up unless it’s super critical for building a useful map (like turn restrictions).  They are really best for features that can not be mapped any other way.

Thanks, Bryan


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: My "weirdly unnatural aversion to relations"

Joseph Eisenberg
Would it be helpful if there were several simpler database primitives for several of the simplest types of relations?

I know people have already talked for years about adding a true area object (which now we imitate with closed ways)

Could we also have a linear feature made up of ways only? This would include the current route and waterway relations. Would something like this be helpful, especially if there were a  limit to how many ways could be included?

Could multipolygons be specifically defined, perhaps as a type of area?

I do think it is strange that any random collection of nodes and ways can form a relation. And the ability to make relations out of other relations is also confusing.

But it would be quite helpful to be able to make relations from smaller relations, in the simpler cases of a Lake with an island inside (multipolygon in a multipolygon), or a long highway made of shorter routes, or a long river made of shorter waterway relations.

-Joseph

On Sun, Sep 30, 2018 at 12:01 PM Bryan Housel <[hidden email]> wrote:
On Sep 29, 2018, at 6:56 PM, Paul Johnson <[hidden email]> wrote:

I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

From my own perspective as the main developer on the main editor for OSM, the reason I don’t like relations very much is because:
- every type of node basically works the same.
- every type of linear way basically works the same.
- every type of polygonal area basically works the same 
- every type of relation is an edge case that requires special code in order not to break.  

Relations are also problematic because they are unbounded.  Want to make a boundary relation with a million child ways?  This is allowed.  Want to ensure that all those ways are connected?  It may take minutes to download them all.  

They’re almost even a security threat.  I’m willing to bet a black hat could design and upload a relation that would destroy OSM.. Or at least, crash every piece of software in the stack that we rely on:  mapnik, osmium, and any editor that tries to touch it.  

Anyway, I’m not totally against them, but every one of them is different and I can't spend weeks or months supporting every kind of relation or public transport schema people dream up unless it’s super critical for building a useful map (like turn restrictions).  They are really best for features that can not be mapped any other way.

Thanks, Bryan

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: My "weirdly unnatural aversion to relations"

AlaskaDave
I'm surprised to learn that a major developer has reservations and concerns about OSM relations. I don't like them much either. Small ones like simple riverbanks and lakes containing islands are okay but when they get large, they're difficult to understand and nearly impossible to debug. There are myriad tools to "assist" the debugging process but which tool is best to use and when? And how does the tool itself work? I've got a "polygon is not closed" error that I must've inadvertently caused on a big riverbank relation in Alaska. When I go into the relation editor and ask it to "jump to the error", it highlights an entire, many miles long riverbank. This is not helpful at all. For the moment I'm stuck. I have much I want to accomplish in my Mapping Alaska (as I call it) project. Debugging an obscure error in a large relation slows me down horribly.

I'll be following this thread to see if I can learn more about how to deal with them.

Dave



On Sun, Sep 30, 2018 at 10:28 AM Joseph Eisenberg <[hidden email]> wrote:
Would it be helpful if there were several simpler database primitives for several of the simplest types of relations?

I know people have already talked for years about adding a true area object (which now we imitate with closed ways)

Could we also have a linear feature made up of ways only? This would include the current route and waterway relations. Would something like this be helpful, especially if there were a  limit to how many ways could be included?

Could multipolygons be specifically defined, perhaps as a type of area?

I do think it is strange that any random collection of nodes and ways can form a relation. And the ability to make relations out of other relations is also confusing.

But it would be quite helpful to be able to make relations from smaller relations, in the simpler cases of a Lake with an island inside (multipolygon in a multipolygon), or a long highway made of shorter routes, or a long river made of shorter waterway relations.

-Joseph

On Sun, Sep 30, 2018 at 12:01 PM Bryan Housel <[hidden email]> wrote:
On Sep 29, 2018, at 6:56 PM, Paul Johnson <[hidden email]> wrote:

I honestly don't understand why, ten years since it's introduction as OSM's third basic primitive, there's still this weirdly unnatural aversion to relations, even though they're quite a powerful primitive in our toolbox.

From my own perspective as the main developer on the main editor for OSM, the reason I don’t like relations very much is because:
- every type of node basically works the same.
- every type of linear way basically works the same.
- every type of polygonal area basically works the same 
- every type of relation is an edge case that requires special code in order not to break.  

Relations are also problematic because they are unbounded.  Want to make a boundary relation with a million child ways?  This is allowed.  Want to ensure that all those ways are connected?  It may take minutes to download them all.  

They’re almost even a security threat.  I’m willing to bet a black hat could design and upload a relation that would destroy OSM.. Or at least, crash every piece of software in the stack that we rely on:  mapnik, osmium, and any editor that tries to touch it.  

Anyway, I’m not totally against them, but every one of them is different and I can't spend weeks or months supporting every kind of relation or public transport schema people dream up unless it’s super critical for building a useful map (like turn restrictions).  They are really best for features that can not be mapped any other way.

Thanks, Bryan

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: My "weirdly unnatural aversion to relations"

Frederik Ramm
In reply to this post by Bryan Housel-2
Hi,

On 30.09.2018 05:00, Bryan Housel wrote:
> From my own perspective as the main developer on the main editor for
> OSM,

... fsvo "main editor" ;)

> I’m willing to bet a black hat
> could design and upload a relation that would destroy OSM.. Or at least,
> crash every piece of software in the stack that we rely on:  mapnik,
> osmium, and any editor that tries to touch it.  

Relation 7066589 came close. (And no, you won't be able to access its
history through the web site, it will time out.) See
https://github.com/openstreetmap/osm2pgsql/issues/713 for background -
osm2pgsql had to be patched as a result.

> Anyway, I’m not totally against them, but every one of them is different
> and I can't spend weeks or months supporting every kind of relation or
> public transport schema people dream up unless it’s super critical for
> building a useful map (like turn restrictions).

The idea that turn restrictions are "super critical" but public
transport relations are not is valid, but subjective; I hope that, as
the ID editor matures, it will attract a healthy and diverse team of
main developers so that decisions about what is important and what isn't
are not a single person's any more!

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Traffic sign direction tagging..

Paul Allen
In reply to this post by Graeme Fitzpatrick
On Sun, Sep 30, 2018 at 2:23 AM Graeme Fitzpatrick <[hidden email]> wrote:

[relations]

Maybe because people don't understand how to use them properly (I know I don't?), so they're scared of them?

I thought I was the only one. :) 

Some very simple, easily found, instructions / guidelines would be handy.

I've only used a couple of types so far.  You're right, the instructions are scattered around the different
type of relation and so not easily found.  They're also not (generally) written with the newbie in mind,
so not easily understood.  But the problem is that the different types of OSM relation, like your
real-life relations, are all different, do different things and behave somewhat differently.  What you're
asking for is similar to the job interview question "Describe yourself in a single word" (my answer is
"indescribable") except it's closer "Describe all your relatives in a single word" (my answer is
"related").

Oh, and never forget that this is OSM.  So you'll find one person saying that relations of type A, B
and C are not only valid but also vital whilst any other type of relation is an abomination and another
person saying types A, B and C are unnecessary abominations and all other types are valid and
essential.  For example, super relations solve several distinct problems and are, at the same time,
an unnecessary abomination with no conceivable use cases (I thought of a nifty use for them that
would be useful to me but they are so despised by so many people I'm scared of even mentioning it).

Right now I can't think of a way of improving the documentation in the way you (and I) would like
because the relation types differ so much.  All that comes to mind is a page saying that "relations
relate things" with a list of the different types and a one-line description.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: My "weirdly unnatural aversion to relations"

Tomas Straupis
In reply to this post by Frederik Ramm
On 30.09.2018 05:00, Bryan Housel wrote:
> From my own perspective as the main developer on the main editor for
> OSM,

  This is way too exaggerated. While iD is most visible, most data is
created not by iD. And it is not always possible to advice novice user
to use iD. For example iD only supports new "Russian water tagging
scheme" (everything blue is natural=water), so if a country had made a
decision to stick with original "standard OSM water scheme" (with
landuse=reservoir|basin|etc waterway=riverbank) it is impossible to
use iD as it does not support standard OSM water scheme. Note that
Russian water scheme never reached the standard water scheme in
popularity even with iD pushing for it.

  Same goes with "contact:*" scheme and probably a number of other
tagging schemes.

--
Tomas

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234