Things overlay: Allow adding vertex features

[westnordost]

Use case E.g a bollard, a bicycle barrier, a lift gate are all "things", but they can't be found in the things overlay because they ought to be placed as vertices of a way.

Proposed Solution Allow adding such features with the same UI as in the building overlay (addresses snap to building outlines). The difference is, that for certain features, they can only be added ad vertices of ways, so the OK button must be disabled/hidden when that feature type is selected and the crosshair is not on a way. Also, this'll probably need some extra code, as e.g. bicycle barriers should not be placeable on any way, but only paths, footways etc. but the iD editor presets don't have a field for that (AFAIK). (That would be a useful feature request for iD editor presets, though... 🤔)

[westnordost]

As a non-programmer but openstreetmap aficionado, you can help with some research:

• check out the iD editor presets. Does the iD editor only allow placing e.g. bicycle barriers on paths etc.? If it does, is there maybe some field for that in the iD editor presets? If it doesn't, it could be worth opening a feature request over there, as the info on which ways a feature can/should be a vertex would be worthwhile to share between all the editors that use iD editor presets

• which "things" should only be added to ways? I.e. which new features should the user be able to add when this feature request is implemented? (Also check out the iD editor presets, look for features that denote that they can only/also be placed as vertices on ways)

[matkoniecz]

If it does, is there maybe some field for that in the iD editor presets?

https://github.com/openstreetmap/id-tagging-schema/blob/6a6ca249825aa8b4597cd71f68289372c6e5e83b/data/presets/highway/passing_place.json#L4

    "geometry": [
        "vertex"
    ],

note: something may be allowed both as vertex and as standalone point

and bicycle parking actually has quite wide range, see https://github.com/openstreetmap/id-tagging-schema/blob/6a6ca249825aa8b4597cd71f68289372c6e5e83b/data/presets/amenity/bicycle_parking.json#L21-L26

    "geometry": [
        "point",
        "vertex",
        "line",
        "area"
    ],

though for bicycle parking for example I feel that while showing ones on lines is fine, we should not glue them to lines

BTW, we did some magic with vertex - see https://github.com/streetcomplete/StreetComplete/issues/5549#issuecomment-2017383454 https://github.com/streetcomplete/StreetComplete/commit/8964ca67aff6b43a1d4efbfad79027caf731930a but it should not cause problems here, I think

[mnalis]

though for bicycle parking for example I feel that while showing ones on lines is fine, we should not glue them to lines

Yeah, it should be noted that iD works opposite of SC:

• in SC we first choose the feature in the overlay, and then very wide snapping happens (or not) depending on the Thing selected while scrolling the map
• in iD one first adds the generic (empty) node with only very tiny snapping (see below), and then the list of allowed features is shown depending whether that node is a point or a vertex

Thus, while id-tagging-schema "geometry" helps a lot, it would probably need either:

• same overrides in SC to avoid such unwanted behaviour (like snapping bicycle parking on ways). While user could avoid it with zooming in enough, assumption is that most won't, and it would result in adding most bicycle parkings on the ways (which is - while possible - definitely very rare compared to the standalone node), or

• we could do (like in iD) very fine (just a few pixels) snapping sometimes. Perhaps that might work for SC, but still would need either:

  • a manual override do we want "greedy snapping" (as in entrances in address overlay, or adding a crossing on the road, where we absolutely do want to end up on the way) or a "very fine snapping" (i.e. only adding bicycle parking on a way if it is extremely close to it, but as a standalone node in majority of the cases)
  • alternatively, we could try to auto-detect (probably most complex initially, but avoids exception-handling now and in the future as id-tagging-schema grows):
    • if the Thing being added is only a vertex, then do a "greedy snapping" (like when adding entrances in Address overlay)
    • if it is only a point, then never do any snapping nor inserting into way (like currently all Things in Things overlay behave)
    • if it has both a point and a vertex, then do a "very fine snapping" (like in iD, only few pixels wide). Alternatively in this case, we could also disable snapping/inserting into way altogether (like it was "only a point" in case above) -- that would simplify things and avoid uncommon scenarios like bicycle parking on a way (but might also break other cases that we haven't though about yet).

[westnordost]

You misunderstood, read again: My first point was about limiting to which ways a certain vertex feature preset should snap to. E.g. A barrier=cycle_barrier should snap only to footpaths etc, but not e.g. buildings. entrance vertices should snap to buildings, but not to power lines, etc...

[mnalis]

E.g. A barrier=cycle_barrier should snap only to footpaths etc, but not e.g. buildings. entrance vertices should snap to buildings, but not to power lines, etc...

There are those issue(s) for iD:

• https://github.com/ideditor/schema-builder/issues/96

(if that is what you meant)? Most of them however do not seem to be actively worked on AFAICT.

[mnalis]

My first point was about limiting to which ways a certain vertex feature preset should snap to. E.g. A barrier=cycle_barrier should snap only to footpaths etc, but not e.g. buildings

That is not supported in iD currently, see https://github.com/ideditor/schema-builder/issues/96.

E.g. you can currently add barrier=cycle_barrier to building=yes closed way in iD (which is obviously a bad idea, so should be prevented in StreetComplete - and suggestion how to do that safely was in my original comment).

You misunderstood, read again:

Well, my comment was mostly about other question, i.e.:

which "things" should only be added to ways?

And my answer was boiling down to "only those marked as geometry:vertex and without geometry:point in id-tagging-schema" (with expansion on alternatives, problematic issues and suggestions how to handle them).

---

But I am unsure what specific you would want help with? I can grep the id-tagging-schema for vertex, maybe hand curate the output for the ones I think are useful, and add to ways (with what tags) I think it make sense to snap them to.

But that only makes sense if you think my first suggestion (SC having hand-curated list of snapping / inserting into way) makes sense. If you think we should wait for iD to make changes first (in those linked ticket), then perhaps other course of action is preferable.

[goldfndr]

For bollards in particular, please allow them not to be placed as a vertex of a way, e.g. when they're acting as crash barriers for a fire hydrant or street cabinet (especially utility=power) or building entrance. Please see Zverik/every_door#501

[jonpsp]

Similarly for kerbs - kerbs and bollards shouldn't normally be where two ways cross.

[westnordost]

But I am unsure what specific you would want help with?

@mnalis Well, since there is a ticket already, people could

• think of how it would make most sense to include this information in the iD tagging schema (in what structure) and make concrete suggestions in this ticket - ask the maintainer whether a PR that would add a field with information (like that) would be accepted
• on a positive reply, start working on that
• and even when such PR is still WIP, someone could already work towards this field being parsed by https://github.com/westnordost/osmfeatures

[davidpnewton]

Similarly for kerbs - kerbs and bollards shouldn't normally be where two ways cross.

Kerbs certainly can and in many cases should be where two ways cross. If there's a pavement that transitions to a road crossing at the edge of the road then that will almost always have a kerb node associated with it. If the edge of the pavement/edge of the road are mapped out as areas then that automatically creates a need for a kerb node where two ways cross.

As for bollards? I've certainly created standalone nodes with bollard tagging to represent the actual, physical bollards.

[RubenKelevra]

Maybe I misunderstood the request, but isn't that feature is already implemented in SCEE?

[mnalis]

Maybe I misunderstood the request, but isn't that feature is already implemented in SCEE?

Yes, it is known that SCEE has insert into way functionality.

In fact, this ticket stemmed from the discussion at https://github.com/streetcomplete/StreetComplete/issues/6180#issuecomment-2751404625 and below - but wants to implement that for SC in a cleaner UI (e.g. like door in address overlay), and generic way significantly less troublesome for newbies (i.e. only inserting correct nodes into correct ways - like postbox on building walls, or crosswalk on highway, but not postbox on highway)

[mnalis]

If there's a pavement that transitions to a road crossing at the edge of the road then that will almost always have a kerb node associated with it.

That is technically when "two ways touch" (i.e. one ends and another starts), and not where "two ways cross". It should be technically possible to distinguish (i.e. "when a node is a member of two or more ways, is it a first or last node of all of them?")

If the edge of the pavement/edge of the road are mapped out as areas

Uh, I'm unsure of what you think here, can you give an example of such node on the map @davidpnewton ? Are you talking about area:highway=*? Those would be rare and too complex to handle IMHO (if both a pavement and a road are aditionally mapped as touching areas, then kerb there would likely also need to be mapped as an area or at least a way, and not as a simple node).

As for bollards? I've certainly created standalone nodes with bollard tagging to represent the actual, physical bollards.

That should already be addressed, as barrier=bollard can already be both point and a vertex in id-tagging-schema