Overlay for street furniture (etc.)

[westnordost]

I figure there could be an overlay with which one could add (delete, move) street furniture, i.e. benches, waste baskets, bicycle stands, trees, hydrants, maybe even traffic signs, single lanterns etc.

The most difficult of this overlay would be to think of all those POIs that could be collected. And at the same time not... open a can of worms. Certainly, much more so than for shops, there is an inexhaustible number of things that could be added. So, we'd need to come up with a reasonable guideline what should be able to be added with this overlay and what not (either deserving an own overlay or not displayable+addable at all). Of course, only things that can be added with this overlay are also shown on the map.

Anyway, I think maybe the (long) initial phase we could do collaboratively:

https://docs.google.com/document/d/1tcLm0EDWoCBdkq1N0pKebtksJcF2vMtUgKc9h96fuF0/edit?usp=sharing

Contributions welcome! As far as I know, there is no comprehensive list of "street furniture" in the wiki, so we'd need to dig through it ourselves. Digging through the iD presets may help, too.

[westnordost]

Sorry, I only shared the document as viewable, not as editable. Made it editable now.

[peternewman]

Will these also allow NSI presets of them, so you can e.g. add an Amazon Parcel Locker, rather than just a Parcel Locker?

Likewise the hybrid BT telephone/wifi/advertising screen things that are popping up all over the UK (and I can never remember what tag to use for them)?

I thought this previously got discounted, but I'm certainly in favour of it for things like defibrillators etc. Also for postboxes it will neatly enable the follow on quests for ID, collection time etc.

[westnordost]

Will these also allow NSI presets of them

of course

[mnalis]

While I like the idea of being able to map everything from SC, I have some doubts about efficiency of doing so the current way.

Currently it takes 4 clicks just to switch an overlay in SC (see https://github.com/streetcomplete/StreetComplete/issues/4686). It takes 2 clicks (or 1 doubleclick, if you wish) to switch from SC to EveryDoor (using android recents action) which allows me to add such POIs quickly (and already supports full range of ID presets).

It is even worse if one assumes that mappers often needs to switch back to overlay they were using previously (which is quite painful in SC, and the main reason why I use them very little, but that is story for another day). That is at least 10-12 clicks to add a missing wastebasket I've noticed during e.g. mapping shops. Does not sound like I'd be using that functionality much if that barrier is not reduced significantly.

Perhaps (at least for adding new POIs), it can be added to long-press action? SCEE fork already does that (long press and choose Add POI), so perhaps that code might be reused. It allows to add mentioned wastebasket in as low as 4 clicks (if it is in recents list) regardless of an overlay I was using (and without disturbing it).

---

In related news, I'd suggest scraping changesets made by Every Door and OsmAnd, in order to see which POIs were added most often, to help build that list of "POIs that people like to add".

[westnordost]

Do you really have to post in three issues to make your point? Anyway, to clarify and I thought you knew,:

While I like the idea of being able to map everything from SC, I have some doubts about efficiency of doing so the current way.

This is not what SC overlays are designed for, they are about enabling users to map comprehensively one aspect (per survey) without worrying about other aspects. It is ofc most inefficient when you try to map everything on one survey, switching between overlays all the time. If you want to map everything at once, better use a standard editor.

[Un1matr1x]

note: added the emergency-stuff to the google-doc ~ hope I did it the right way

Anyway, I think maybe the (long) initial phase we could do collaboratively:

maybe just use a shorter inital phase and add other requested "furniture" one the go?

Currently it takes 4 clicks just to switch an overlay in SC (see #4686). It takes 2 clicks (or 1 doubleclick, if you wish) to switch from SC to EveryDoor (using android recents action) which allows me to add such POIs quickly (and already supports full range of ID presets).

and I hate to switch apps because on my mobile device the app in the background is more likly to be closed and shut down and the constant restarts of the apps consumes more battery than one app thats in the foreground & I have more productiv time than just stand there and wait for another app to start

[Elefant-aus-Wuppertal]

Here in North Rhine-Westphalia, street furniture is usually positioned after a high-resolution orthophoto (10 cm) (with nearly no or vanishingly small offset!!!).

Of course, this is never possible for all properties, but for most (those that are not indoors) it is.

For something so small in SC, how should it be ensured that mappers don't move it using another aerial photo with offset or, especially, without using an aerial photo at all?

Even with the orthophoto, you sometimes only see pixels at the highest zoom levels. Lower zoom levels often offer more perspective in the overall view. On a cell phone, I imagine it all pretty pixelated.

Will aerial photos even be used as backgrounds in StreetComplete?

[westnordost]

Will aerial photos even be used as backgrounds in StreetComplete?

This is not planned. There is however no strong reason against this but if it is implemented, it should be kept in mind that a best-effort should be done to properly align the aerial imagery with reality and ideally (I think there is some public database about this somewhere), the best aerial imagery available be selected automatically.

[Elefant-aus-Wuppertal]

ideally (I think there is some public database about this somewhere), the best aerial imagery available be selected automatically.

Yeah sure, I think iD indeed does have something like this already, at least in certain areas.

[Elefant-aus-Wuppertal]

This is not planned.

But then how to ensure that mappers don't just move objects around "at will"? In iD, at least the orthophoto pops up as the first, preset background in NRW.

But if there is no aerial background at all? It will probably end up in a chaos...

[westnordost]

The user's GPS location and its precision is shown on the screen, as well as an OSM-based map. Also, for the overlay, all elements that can be added with the overlay are shown as well. So, if an unmapped bicycle parking is just left of a bench, the user has plenty of points to orient himself even if the GPS location is off due to some interference such as high-rise buildings (or indeed the whole area has been mapped with an offset, as often happens)

[Elefant-aus-Wuppertal]

Phew :-(

But isn't it the case that you have to zoom in a lot to see everything?

Errors are already happening with the double recycling containers, which are next to each other in OSM (but still at a certain distance!) and are overlooked.

How is that supposed to be when there are seven benches, five waste_baskets in between and I don't know what else are standing next to each other.

[Elefant-aus-Wuppertal]

Hmm ok

[westnordost]

I don't know, how does it work in iD and JOSM, where additionally to the things you can add, you have all sorts of other geometry being displayed on the map? Somehow, editors are able to place five waste baskets in between seven benches, also with aerial imagery that only reveals that there is a line of something lined up on that plaza.

[Elefant-aus-Wuppertal]

Honestly, I have the feeling that you can work more precisely with the mouse than with your finger on the smartphone display.

I don't know if it's just me, but in iD and JOSM you can also hide things that "disturbing" you in order to map "more space-free" and to be able to see the details on the aerial photos better.

The display alone is much larger.

How exactly the users map ultimately depends, without an aerial photo, primarily on their "desire" to look closely.

And looking closely is already a kind of problem. I know, I know, now it comes back that SC is not to blame. Yes, I see.

But why did we fight for so long with municipal administrations etc. for the release of high-resolution orthophotos, for example?

there was a lot of people's work involved in that!

I just think it would be a shame if good data in the form of well-placed things were then lost.

[westnordost]

Are you using this app at all? You don't place POIs or move POIs with your finger in this app.

[westnordost]

I just think it would be a shame if good data in the form of well-placed things were then lost.

Also, why should users of this app move well-placed things elsewhere, given the information they have available?

Also, please create a new discussion for this, this is really off topic in this ticket. (refer to this ticket by typing "#" and then the ticket number, then a link will be automatically be created and displayed here in this ticket)

[Elefant-aus-Wuppertal]

I'm really excited to see what comes out of this.

If I notice anything concerning the positioning-topic, I will report back (in a new thread, as requested).

I was just wondering why objects that are next to each other are already being overlooked.

Maybe a few people are "too lazy" to zoom in closer, or are unaware ot that.

[mnalis]

This is not what SC overlays are designed for,

While that may well be what the designer intended, I can only say I what I use SC overlays mostly for:

• to verify and correct suspicious (or known recently changed) tagging found on the ground
• to get around the limitation when SC quests are asked on less elements then I'd want it to
• to make sure area is fully mapped (related to above, as a missing quest might mean it is tagged, or it might just mean SC decided quest should not asked that before some prerequisite quest, or too close other element, or something else)
• (truly very rarely) to go out and map only one specific aspect

they are about enabling users to map comprehensively one aspect (per survey) without worrying about other aspects.

Is there a use case envisioned when user would like to go out to comprehensively map "any useful POI except shops"? While I have only myself to judge from, I can see myself wanting to map only shops (less work), and I can see myself wanting to go map all POIs (shops+street furniture), but I cannot really imagine myself wanting to map all "street furniture" POIs but without shops.

It is ofc most inefficient when you try to map everything on one survey, switching between overlays all the time.

Yes, it is. I don't know if you've seen "long press + Add POI" suggestion above; I happen to think it would help in all cases (both when people use overlays "as designed", and when they use them "as useful")

If you want to map everything at once, better use a standard editor.

You mean Vespucci when you say "standard editor" or? Because, Vespucci is even more clunky and less ergonomic for that purpose than constantly changing SC overlays (you need to click and edit every way, and remember what attributes you checked on which ways. After a short while, it starts to feel like playing chess against yourself in your head).

I sometimes do use OsmAnd for verifying part of points (1) and (3) above (for example lit, surface, cycleway overlays) which saves part of the trouble, but that only works if I haven't been editing that area recently (at least in last 15 minutes or so)

[Elefant-aus-Wuppertal]

I have the following questions about moving street furniture what would interest me and what we might need to think about:

• Will users be able to move object which are part of a way, e. g. a post_box which is mounted to a wall? Because that also has an impact on the way then.

• What are we going to do about objects which have a source:position or a check_date:position tag? -Will we delete source:position and/or update check_date:position if an object is moved?
  
  
  How do we deal with disused: and abandoned: objects?

Can we also display something like this in the overlay?

If users are given the opportunity to enter street furniture (like e.g. vending_machines), users may overlook objects that have already been mapped as disused or abandoned if such objects are not displayed in the SC overlay.

Examples:

1. https://www.openstreetmap.org/node/253514694/ This payphone looks perfectly fine from the outside. But it has no dial tone, so it cannot be used. Therefore it is recorded as disused:amenity. But you would have to pick up the phone to find out. There

2. https://www.openstreetmap.org/node/6925573573 This machine looks perfectly passable from the outside, except that it has a bit of rust. That's the problem. Because it is not usable. But you can't see that from the outside. I imagine that if the abandoned: object doesn't show up in SC, the next user will come along and add the machine - not seeing that it's already mapped as abandoned.

I don't mean to ask SC users to check if objects are working, just for compatibility if someone has already checked that they are not working.

[Helium314]

Will users be able to move object which are part of a way

Moving is only allowed for free-floating nodes

What are we going to do about objects which have a source:position or a check_date:position tag? -Will we delete source:position and/or update check_date:position if an object is moved?

Currently nothing is done, only the node is moved. Though it would make sense to remove them, or maybe update check date (but iirc SC is supposed to use check date as little as possible, and remove it if data was changed).

[westnordost]

The hint regarding disused:* and abandoned:* is useful. One solution might be to display any POI with these prefixes the same as if they were not disused or abandoned and when tapping on them, there will be a prominent hint that this POI is e.g. disused.

[Elefant-aus-Wuppertal]

I'm happy you're this opinion, too.

[mnalis]

The hint regarding disused: and abandoned: is useful. One solution might be to display any POI with these prefixes the same as if they were not disused or abandoned and when tapping on them, there will be a prominent hint that this POI is e.g. disused.

Would it be possible that icon changes if disused/abandoned? (e.g. overlay red "x" over the original icon or something)

[westnordost]

No, not within tolerable effort.

[matkoniecz]

https://github.com/streetcomplete/StreetComplete/discussions/5201 mentions hunting stands, not sure about this one

[CartoonFan]

I got this issue recommended to me (from #5253) for wanting to add storm inlets to the app. Does that seem in-scope for this issue?

[matkoniecz]

I think that storm inlets is going a bit too far.

I am already dubious about natural=tree nodes in this overlay.

[mnalis]

I think that storm inlets is going a bit too far.

for adding in OSM at all, or just in StreetComplete?

I am already dubious about natural=tree nodes in this overlay.

Well, to me it would seems OK to support anything that exists in iD presets (i.e. what EveryDoor micromapping mode does). That being said, inlet=kerb_opening is not currently present there, which might be prerequisite for support.

natural=tree nodes are important though (to be put around amenity=bench nodes to indicate which benches are actually usable in the hot summer). I guess each micromapper has their own reasons, which I guess is why ATYL has been a significant contributor to success of OSM)

[matkoniecz]

for adding in OSM at all, or just in StreetComplete?

StreetComplete, in this specific overlay. Maybe StreetComplete in general

Well, to me it would seems OK to support anything that exists in iD presets (i.e. what EveryDoor micromapping mode does).

Post boxes are blocked by https://github.com/streetcomplete/StreetComplete/issues/4916 - see https://github.com/ideditor/schema-builder/issues/94

Some of POIs would require level tagging support and/or problematic because only some specific case is covered and it could encourage bad tagging.

For implementation the plan is to have specific listing of allowed features. EveryDoor style of everything-except has some problems with maintainability

Current listing in upcoming PR is:

fun isStreetFurnitureFragment(prefix: String? = null): String {
    val amenities = listOf(
        "bicycle_parking", "bicycle_rental", "bench", "longer", "bbq", "grit_bin", "toilets",
        "public_bookcase", "give_box", "clock", "bicycle_repair_station", "charging_station",
        "parcel_locker", "telephone", "drinking_water", "vending_machine",
        "atm", "waste_basket", "trolley_bay",
        // "post_box", "letter_box", - blocked by https://github.com/streetcomplete/StreetComplete/issues/4916
        // waiting for response in https://github.com/ideditor/schema-builder/issues/94
        // man_made = street_cabinet and street_cabinet = postal_service
        // is also disabled to avoid bad data being added
    )
    val p = if (prefix != null) "$prefix:" else ""
    return ("""(
        ${p}amenity ~ ${amenities.joinToString("|")}
        or (${p}amenity = recycling and recycling_type = container)
        or ${p}leisure ~ picnic_table|firepit
        or ${p}man_made ~ water_tap|obelisk|cross|monitoring_station|flagpole|carpet_hanger|planter
        or ${p}tourism ~ viewpoint|artwork
        or (${p}tourism ~ information and information ~ guidepost|board|map|terminal)
        or ${p}historic ~ memorial|monument|wayside_shrine|wayside_cross|boundary_stone
        or ${p}highway ~ milestone|street_lamp|emergency_access_point
        or ${p}emergency ~ fire_hydrant|life_ring|phone|defibrillator|siren|lifeguard|assembly_point|access_point
        or ${p}advertising
        or ${p}leisure = pitch and sport ~ table_tennis|sport=chess
        or ${p}natural ~ tree
        or ${p}man_made = street_cabinet and street_cabinet != postal_service
        )""") // tourism=artwork and later from https://docs.google.com/document/d/1tcLm0EDWoCBdkq1N0pKebtksJcF2vMtUgKc9h96fuF0/edit
}
val IS_DISUSED_STREET_FURNITURE_EXPRESSION = """
    nodes, ways, relations with
      ${isStreetFurnitureFragment("disused")}
""".toElementFilterExpression()

val IS_STREET_FURNITURE_INCLUDING_DISUSED_EXPRESSION = """
    nodes, ways, relations with
      ${isStreetFurnitureFragment()}
      or ${isStreetFurnitureFragment("disused")}
""".toElementFilterExpression()

[ERYpTION]

Is there anyway to add translations for the street furniture available in the things overlay? Currently it is a mix of translated and untranslated items.

[HolgerJeromin]

see https://github.com/streetcomplete/StreetComplete/blob/master/CONTRIBUTING.md#translating-the-app

and https://github.com/streetcomplete/StreetComplete/blob/master/CONTRIBUTING.md#id-presets

[ERYpTION]

Yes, however I can't seem to find the untranslated strings in the POEditor or the iD presets on Transifex. For instance 'Rubbish bin' and 'Recycling Bin'. Maybe I just don't know how to do search?

[HolgerJeromin]

perhaps someone was faster than you? What language is this about?

[ERYpTION]

Danish. Even if someone else translated it in the meantime, I think I should be able to find the string.

[matkoniecz]

Transifex errors for me - tried reporting it at https://community.transifex.com/t/there-was-an-error-connecting-to-server/3881

[mnalis]

Transifex errors for me

• I thinks that this part is related to which langues you've registered as translator for.

  • e.g. for me HR works just fine finding Reciklažna kanta for Recycling bin: https://app.transifex.com/openstreetmap/id-editor/viewstrings/#hr/presets?q=text%3ARecycling
  • while for me DA throws There was an error connecting to server error -- but only after (correctly?) showing several results with Genbrug - like Genbrugsbeholder for Recycle bin: https://app.transifex.com/openstreetmap/id-editor/viewstrings/#da/presets?q=text%3ARecycling

Yes, however I can't seem to find the untranslated strings in the POEditor or the iD presets on Transifex. For instance 'Rubbish bin' and 'Recycling Bin'. Maybe I just don't know how to do search?

• Well, I can find Recycling Bin in Transifex, see above. Can you show screenshot what it says for you @ERYpTION when you search for it?

• as for the missing Rubbish bin, I think it cannot be found as that itself is en-GB translation. Original en text is Waste Bin (found that by manual grepping under app/src/main/assets/osmfeatures/default).

  Searching for that Waste Bin, I can find it both in Croatian (as Kanta za smeće) and in Danish (as Affaldscontainer) (although Danish throws that error after showing me the result, but as mentioned before that is likely because I'm not registered as Danish translator)

[ERYpTION]

Sorry you're right, the strings are there. It seems I was searching in the wrong place (OSM / Presets). In 'iD Editor / Presets' I found both Recycling Bin and Waste Bin.

However, I'm still not sure why I am seeing 'Rubbish bin' in the Things overlay in SC? I translated 'Waste Bin' 1 year ago.

[matkoniecz]

However, I'm still not sure why I am seeing 'Rubbish bin' in the Things overlay in SC? I translated 'Waste Bin' 1 year ago.

Is your phone set to be in Danish? Have you overrode language setting in StreetComplete?

EDIT: See below, translation seems to be just missing. "bin" as property was translated, amenity=waste_basket label is not translated.

[matkoniecz]

https://github.com/search?q=repo%3Astreetcomplete%2FStreetComplete%20Affaldscontainer&type=code finds something in https://github.com/streetcomplete/StreetComplete/blob/372723228972ff038311abf209ff20180f3d7122/app/src/main/assets/osmfeatures/default/da.json#L442

But note that amenity/waste_basket seems not translated, see https://github.com/streetcomplete/StreetComplete/blob/372723228972ff038311abf209ff20180f3d7122/app/src/main/assets/osmfeatures/default/pl.json#L5772 where it is translated.

[matkoniecz]

In general, Danish is listed as having 3 391 strings to translate, including 2028 in iD presets. See https://app.transifex.com/openstreetmap/id-editor/language/da/ where presets are listed as only 65.36% translated.

So I would actually expect about 1/3 of things to be missing translations. Help with translating remaining ones would be helpful! Also people using iD would benefit.

[ERYpTION]

In addition to the SC translation (in POeditor) I already regularly do iD preset translations prioritizing translating the most used things on the map.

Regarding 'Waste bin / Rubbish bin': My phone is set to Danish as language 1 and English as language 2. In SC language it set to system language. So I suppose it could make sense that an English (en-GB) translation would show up if there is not a Danish one available.

Don't understand your point about amenity/waste_basket not being translated. Where would I find this in Transifex? Anyway this is not a massive issue worth you spending a lot of time on trying to explain it to me. I just figured I would ask if it was some simple mistake I was making.

[matkoniecz]

text:'trash can' should find it. Unable to get to da texts, checked with Polish ones.

In general, going down to 0 in "Untranslated" would be best but will take significant effort.

[ERYpTION]

I translated 'Trash can' a couple of weeks ago so will probably be corrected in SC soon.

I have now changed my phone language 2 to en-US. Hope that makes it less confusing finding the strings.

Thank you for your help!

(Yes, getting to 0 untranslated in Transifex will require a lot of work. It is also probably not possible since some things don't have a Danish translation.)