Show example images for "bicycle_parking"

[wtimme]

As a mapper, I want the "bicycle_parking" values to show example images, so that I can map the tag without consulting the wiki

How it could look

For this example, I've used the assets from StreetComplete. Furthermore, I've sorted the values by

• has image and
• alphabetically by name

For me personally, having these images would help with tagging.

[tordans]

I would love to have example images for surface as well. Also in iD.

IMO, the ideal place to store this data are the Tag-Wikidata-Objects in the OSM Wiki.

With this, the images could even have a lang-attribute to allow different default images per region.

AFAIK the Wikidata system is basically ready for this, but not used in this way, yet. (I think I can also dig up more conversation in the iD Repo about this, if requested/interesting.)

[matkoniecz]

IMO, the ideal place to store this data are the Tag-Wikidata-Objects in the OSM Wiki.

Why? This makes app fragile to damage from edits to data items (and note that as watchlisting data items is broken, it means that oversight over them is lower than over OSM Wiki) and as soon as multiple data users will have conflicting needs it will be tricky to choose what goes into an image field.

I see no benefit over either using images from wiki pages or manually selected ones (with search started from images used on wiki pages).

It would also require program to pull images from data items, monitoring what changed etc.

Disclaimer: I really dislike data items for multiple reasons.

[wtimme]

Hey @tordans, thanks for the feedback!

For now, I suggest we hand-pick the images ourselves instead of relying on the OSM Wiki. That allows us to control the size/dimension of them, and leaves everything in our control.

I would love to have example images for surface as well.

As far as I know, StreetComplete groups the different surfaces, which allows users to more easily find the value that they are looking for.

• Paved
  • ASPHALT
  • CONCRETE
  • PAVING_STONES
  • ...
• Unpaved
  • COMPACTED
  • FINE_GRAVEL
  • GRAVEL
  • PEBBLES
• Ground
  • DIRT
  • GRASS
  • SAND

Looks like a good approach, and we can reuse their images.

[dieterdreist]

sent from a phone

On 6. Sep 2020, at 21:49, wtimme notifications@github.com wrote:

For now, I suggest we hand-pick the images ourselves instead of relying on the OSM Wiki. That allows us to control the size/dimension of them, and leaves everything in our control.

the media wiki software has an API to query the images in specific dimensions

just as a datapoint, it doesn’t prevent us from handpicking the images

[wtimme]

@tordans, here's a quickly hacked version of example images for surface.

By the way, I noticed that StreetComplete seems to support more values for the surface tag than Go Map!!, for example cobblestone. Does someone have an idea how to proceed here - ignore them, or add support for the missing values into Go Map!!?

[matkoniecz]

for example cobblestone

Strictly speaking it is https://wiki.openstreetmap.org/wiki/Tag:surface%3Dunhewn_cobblestone (cobblestone is used for both sett and true cobblestone, so for "actual, true cobblestone" unhewn_cobblestone value is used)

[bryceco]

surface tag values come from taginfo, so if cobblestone doesn't appear it's because it's below 1% of values.

[matkoniecz]

https://taginfo.openstreetmap.org/keys/surface#values - then from important surfaces sand is also missing, maybe wood can be also considered as important (for wooden bridges / walkways).

[TheAdventurer64]

What about surface=acrylic?

[wtimme]

What about ’surface=acrylic?’

Thanks for the suggestion! At the time of writing, this key/value combination is only used 1264 times, so I don't think it makes sense to have assets shipped for this, given that they'd rarely be put to use.

[wtimme]

@bryceco, would you be willing to merge images for "surface" and "bicycle_parking", with the assets compiled into the app?

[bryceco]

Yes. Ideally we would support built-in imagery with a fallback to pull images from the wiki when available. Built-in only is fine initially, just keep the other half in mind.

[pqhf5kd]

@wtimme, what is the file size of the assets you have selected for "surface" and "bicycle_parking"? iPhone Storage reports that Go Map!! currently consumes 25 MB on my phone, 18.1 App Size and 6.8 MB Documents & Data.

The 6S and original SE base models came with 16GB, and the 7 with 32GB.

Should you consider making the assets an optional download?

[matkoniecz]

The 6S and original SE base models came with 16GB, and the 7 with 32GB.

25 MB is 0.16% of 16GB (or 0.23% of initial free space). As, I understand - taking 5 photos (by default: Still Photo + Live Photo) will consume more memory, if phone decided to take also HDR versions just two photos will be enough to take more space.

Should you consider making the assets an optional download?

That increases complexity, configuration space, required testing, introduces more moving parts that can break and so on.

[pqhf5kd]

The 6S and original SE base models came with 16GB, and the 7 with 32GB.

25 MB is 0.16% of 16GB (or 0.23% of initial free space). As, I understand - taking 5 photos (by default: Still Photo + Live Photo) will consume more memory, if phone decided to take also HDR versions just two photos will be enough to take more space.

That was my point. The current app is small, which is great for older phones and locations with poor internet. Adding photos may rapidly increase the size of the download and install.

[wtimme]

Thanks for voicing your concerns!

I don't have the images at hand at the moment, but they are available via the StreetComplete repository.

Providing the assets as optional downloads sounds good as well. We then need to figure out where to host them, and how we make sure that they are available in the (more or less) correct sizes.

[dieterdreist]

sent from a phone

On 26. Oct 2020, at 09:05, wtimme notifications@github.com wrote:

Providing the assets as optional downloads sounds good as well. We then need to figure out where to host them, and how we make sure that they are available in the (more or less) correct sizes.

I have never used it, but maybe it could work with this: https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/

[bryceco]

Images like that can easily be low-quality and low-res without losing their purpose, and shouldn't be more than 10-20KB each. See this 19KB image for example: https://upload.wikimedia.org/wikipedia/commons/thumb/4/49/Scotland_Kinlochewe_SingleTrackRoad.jpg/299px-Scotland_Kinlochewe_SingleTrackRoad.jpg