Add panoramax=* universal field

[mnalis]

Description, Motivation & Context

This PR adds panoramax=* universal field which contains UUID of the photo in Panoramax.

Panoramax is FOSS decentralized federated map of geolocated street-level pictures. Its function is similar to Facebook's Mapillary (which has universal mapillary=* already in id-tagging-schema) or Google StreetView, but with emphasis on being fully open-source stack and allowing decentralization.

(i.e. Panoramax is alternative to Mapillary/GoogleStreetView in much the same way as Mastodon is alternative to Twitter/X, thus more aligned with OpenStreetMap premises).

Related issues

Closes #1334

Links and data

Relevant OSM Wiki links:

• https://wiki.openstreetmap.org/wiki/Key:panoramax
• https://wiki.openstreetmap.org/wiki/Panoramax

Relevant tag usage stats:

Current usage (as of the creating this PR) is 1583 uses, and taginfo shows a fast growing curve.

Checklist and Test-Documentation Template

Read on to get your PR merged faster…

Follow these steps to test your PR yourself and make it a lot easier and faster for maintainers to check and approve it.

This is how it works:

1. After you submit your PR, the system will create a preview and comment on your PR:

   🍱 You can preview the tagging presets of this pull request here.
   If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.

2. Once the preview is ready, use it to test your changes.

3. Now copy the snippet below into a new comment and fill out the blanks.

4. Now your PR is ready to be reviewed.

## Test-Documentation

### Preview links & Sidebar Screenshots

<!-- Use the preview to find examples, select the feature in question and **copy this link here**.
     Find examples of nodes/areas. Find examples with a lot of tags or very few tags. – Whatever helps to test this thoroughly.
     Add relevant **screenshots** of the sidebar of those examples. -->

<!-- FYI: What we will check:
     - Is the [icon](https://github.com/ideditor/schema-builder/blob/main/ICONS.md) well chosen.
     - Are the fields well-structured and have good labels.
     - Do the dropdowns (etc.) work well and show helpful data. -->

### Search

<!-- **Test the search** of your preset and share relevant **screenshots** here.
     - Test the preset name as search terms.
     - Also test the preset terms and aliases as search terms (if present). -->

### Info-`i`

<!-- **Test the info-i** for your fields and preset and share relevant **screenshots** here.
     The info needs to help mappers understand the preset and when to use it.
     [Learn more…](https://github.com/tordans/id-tagging-schema/blob/main/CONTRIBUTING.md#info-i)
 -->

### Wording

- [ ] American English
- [ ] `name`, `aliases` (if present) use Title Case
- [ ] `terms` (if present) use lower case, sorted A-Z
<!-- Learn more in https://github.com/openstreetmap/id-tagging-schema/blob/main/GUIDELINES.md#2-design-the-preset -->

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[mnalis]

🍱 You can preview the tagging presets of this pull request here.

Tested, and seems to work fine! (i.e. I can search for panoramax in iD and that tag, and clicking on its external view opens up Panoramax map with the specified image; also info button works fine and leads to appropriate wiki)

[Coehill]

@mnalis You rock! :D

[tordans]

I wonder if we should take this opportunity and look into how we can improve the Usability for those fields…

• Should we maybe group the in their label as both "Street level imagery"? Eg ""Street level imagery: Panoramax"
• Is "reference code" a good term, when we use ID or Key elsewhere? Maybe "Identifier (ID / Key)?
• Do both wiki pages do a good job to explain how to retrieve this key to be added to this field? Eg. a user in iD that does not know this already, how would she learn how to get from iD to the key?
• Double check if the wiki pages are clear on only one key per image (no Semicolon usage, right?)

Mapillary: Wiki, Wikidata item
Panoramax: Wiki, Wikidata item

---

On the general question of when / if to merge this: I don't see a reason why not other than other image street level image services are out there and they did not ask, yet. — But given this is a global key, I would like to wait for a +1 from another co-maintainer.

[Coehill]

I wonder if we should take this opportunity and look into how we can improve the Usability for those fields…

* Should we maybe group the in their label as both "Street level imagery"? Eg ""Street level imagery: Panoramax"

* Is "reference code" a good term, when we use ID or Key elsewhere? Maybe "Identifier (ID / Key)?

* Do both wiki pages do a good job to explain how to retrieve this key to be added to this field? Eg. a user in iD that does not know this already, how would she learn how to get from iD to the key?

* Double check if the wiki pages are clear on only one key per image (no Semicolon usage, right?)

Mapillary: Wiki, Wikidata item Panoramax: Wiki, Wikidata item

On the general question of when / if to merge this: I don't see a reason why not other than other image street level image services are out there and they did not ask, yet. — But given this is a global key, I would like to wait for a +1 from another co-maintainer.

I like the idea of street_level_imagery:panoramax=id since it's clearer and self-documenting.

Imo, "picture identifier" is ideal since it reflects the Panoramax UI:
I have updated the wiki accordingly.

I have also updated the wiki with instructions on how to retrieve the picture identifier in Panoramax.

@PanierAvide can you please comment on whether it is expected for panoramax=* to only store one picture ID with no semicolon usage? My guess is yes. If so, we can add the line to the wiki: "Each image only has one picture identifier, so panoramax=* may only contain one UUID value. Multiple values are not permitted."

[PanierAvide]

My two cents on the topic :

• We already expect any OSM tag for Panoramax ID to have potentially many values separated by semicolon (as well as having suffixed tags like panoramax:front=*).
• Grouping in terms of UI all street-level providers in iD seems good, but having an OSM tag like street_level_imagery:panoramax=* seem over-engineered, regarding history of contact:*=* and so on.

[tordans]

@tyrasd What are your thought on …

• Renaming this and the Mapillary field to add some grouping (by wording) eg Street level imagery: Panoramax
• Making the fields for Mapillary and Panoramax an array of strings, separated by semicolon by default
  • This part would likely require changes to the "add this mapillary image to the object" button we introduced in Add a button in the mapillary image photo viewer to "add the current image id as field to feature" iD#10046
  • So we should make this a separate step, but still the question on if remains

[pietervdvn]

panoramax (without street_level_imagry-prefix) has been used for about a year now and has 15K uses nowadays (but this is my fault, as I moved about 10K images to panoramax and MapComplete adds about 50 pictures every day).

Using street_level_imagery has no usages right now, so I don't see the point introducing this.

Another thing to keep in mind: a panoramax-hash is 37 characters long. This means that at most 6 images are supported because of the 255 character limit in OpenStreetMap.

MapComplete instead uses panoramax, panoramax:0, panoramax:1, ... to add an arbitrary amount of images. Even though having more then 6 images is rare, there are 8 entries which have it already.

[mnalis]

@tyrasd What are your thought on …
Renaming this and the Mapillary field to add some grouping (by wording) eg Street level imagery: Panoramax

Using street_level_imagery has no usages right now, so I don't see the point introducing this.

@pietervdvn I don't think the intention was to introduce a new street_view_imagery=* key, but instead to somehow semantically / visually group multiple street-level imagery tags (i.e. panoramax=*, mapillary=*, etc.) into the same (collapsable?) group in the UI.

While generally that might be a good idea (especially if the amount of such street-imagery keys were to grow) , I personally don't think it is quite necessary at this time, so should not be blocking this PR.

Making the fields for Mapillary and Panoramax an array of strings, separated by semicolon by default

That sounds like a good idea to me (as multiple values are documented to be allowed there), but implementation of that (if accepted) is likely (again) going to be separate PR implementing this feature for all streetview-alike keys, so should not be blocking this panoramax-oriented PR.

Over 99.8% of the panoramax=* (an very similar percentage for mapillary=*) keys are single-value, so I'd suggest not letting the perfect be the enemy of the good here - so let's merge this PR (while we wait to some volunteer to support remaining 0.2% of the cases - probably too complex for me, though)

[mnalis]

• Is "reference code" a good term, when we use ID or Key elsewhere? Maybe "Identifier (ID / Key)?

I'm fine with both @tordans. I'd just suggest keeping it the same for both keys. "Picture identifier (ID / Key)" sounds reasonable to me. If you prefer, I can change both panoramax=* and mapillary=* description in this PR (or make separate PR afterwards which changes both, after this one is merged, if you prefer not to intermix those)?

• Do both wiki pages do a good job to explain how to retrieve this key to be added to this field? Eg. a user in iD that does not know this already, how would she learn how to get from iD to the key?

• Key:panoramax wiki states "To retrieve this key, select an image on the map in Panoramax. Then, click on the Picture Metadata button at the bottom-right of the screen. The first row displays the picture identifier in the format of a UUID with a button to copy it. ", so that sounds understandable to me.

• Key:mapillary wiki states "To retrieve this key, open the Image details (⋯) menu and click Advanced options. Then copy the image key. For example, the tag mapillary=277755748254846 references the image in https://www.mapillary.com/app/?pKey=277755748254846. " which also sounds good to me.

I've not seen any opposition for this PR in several months (only likes), so I'd say it is good to go.
If there are any other blockers, please let me know, so I can try to help (to the best of my ability) to push this PR forward. Thanks!