The panoramax=* tag is documented in the wiki since september 2023 as panoramax=UUID
By looking at taginfo, I see a lot of values that are not UUIDs but links to pictures or to viewer URLs.
This makes re-using these tags very complex as it is mixing different things :
linking database IDs (the original definition of this tag in the wiki) panoramax=81d806bc-cd3d-475b-8769-c0746f67f4cf
provide a URL to the picture itself
Should be image=https://panoramax-storage-public-fast.s3.gra.perf.cloud.ovh.net/main-pictures/81/d8/06/bc/cd3d-475b-8769-c0746f67f4cf.jpg
provide a link to view the object in the picture thru a web viewer (quite usefull for 360 ones)
Could be panoramax:view=https://api.panoramax.xyz/#focus=pic&map=19.04/48.8735278/2.2962318&pic=81d806bc-cd3d-475b-8769-c0746f67f4cf&speed=250&xyz=87.74/10.48/30
Iâve open a discussion on the wiki to create a panoramax:view=* tag to separate the first (and original) case with the other ones.
The image=* tag could be used for the second case as it is exactly its definition in the wiki.
The same principle could be extended to other street-level imagery platforms because it is the same mess⌠or a unique image:view=* tag could be used
Given that the second can be derived from the first (and vice-versa), while the third has additional details (and can be used to derive the other two) â why not just document that the web view link is the preferred form, and make code changes to editors (and a bot to fix up existing ones) to enforce this? What value do the other two forms provide over the third one?
@cquest your propopsition makes sense.
The database ID is enough to link to Panoramax data, but providing additionnal tags like image or :view is a good idea to keep the panoramax tag âcleanâ.
That being said, and while this ship has sailed, I always find it clumsy, useless, and a bit pathetic to add such external IDs in OSM.
This forces the next mapper to understand whatâs this external database and how it works when modifying an OSM entity .
What the hell is Panoramax ? Is this ID is still relevant after my modification or ⌠?
On could consider such external IDs like SEO spam.
In the present case (long live to Panoramax ! but) what is supposed tagged with such an ID?
The camera position ? What about several pictures from the same point ?
Or is it whatâs in the field of view ? How long can be the comma-separated list for the âMont Blancâ ?
OSM being a geo-database, standard tools (here OSM API and Panoramax API, why not Overpass) should be enough to link between the two databases, isnât it?
This should be demonstrated in the panoramax wiki instead of hoping human contributors will put a robust, machine-readable value to a tag.
I donât hold out much hope in that one, but if only we could, at least this one time, avoid useless cpu-cycle being spent by a future bot crawling the data to fix useless external IDs, mabe OSM would be better.
A photo of the object being tagged, similar to image and wikimedia commons tags.
At least for MapComplete uploads I believe it is not done by comma separation but using tags such as panoramax:1, panoramax:2. (I only know that from accidentally uploading a duplicate - I donât intentionally upload more than one photo per object).
In any case, I think if you look at what the tag is primarily used for, itâs mainly not for adding multiple views of Mont Blanc, but for mundane things like hiking guideposts and bicycle parking where one photo is usually enough.
Can you expand on how that would work? E.g. suppose I upload a photo of a hiking guidepost and a historical information board located close to each other. How would the APIs link each photo to the corresponding OSM object?
A picture that show the OSM object, like image=* tag and other ĂŽcture sharing tags.
Only one picture⌠a bit arbitrary. We donât need to have all pictures available listed here, just one to document the objet.
Panoramax has search capability to find all pictures possibly showing a location.
When Panoramax will cover the whole planet, this would be a possibility, but will still mean doing a search in Panoramax every time you want to know if a picture is available nearby without the guarantee that it is a good one.
This tag allows to select a picture that could be considered the âbestâ available, and curated by a human contributor.
So while doing it automatically can already be done, OSM contributors should subjectively rate/choose the âbestâ picture. Understand that I could find it suboptimal and a bit out of scope.
Guideposts were mentioned. Guideposts often need multiple pictures to show all sides and hands. Other objects may need multiple pictures for full documentation, if not a 360 degree pan shot (does that exist as a photo format? It should!). So I would very much like to see a better imlementation of multiple values for this attribute, better than the clumsy semicolons or tag numbering.
Regular 360 degree shots usually do not document one object, I think? Maybe an outdoor square or an indoor room?
the key panoramax doesnât give a hint about the type of values expected. If itâs meant to contain the panoramax id I would suggest panoramax_id=*.
I do agree that recording idâs of external services in there own OSM-keys should be limited somehow. I have a camelâs nose feeling about this, and Iâm not sure I would like the whole camel.
Agreed. That #1 is only valid use of Key:panoramax, as initially documented.
provide a URL to the picture itself
Should be image=https://panoramax-storage-public-fast.s3.gra.perf.cloud.ovh.net/main-pictures/81/d8/06/bc/cd3d-475b-8769-c0746f67f4cf.jpg
IMHO, that is inferior and wasteful variant of linking to that same picture which is also more likely to get out of date (I.e. if another cloud provider is selected or whatever). But if the mapper does that, I like wonât be bothered to convert it to the first form.
provide a link to view the object in the picture thru a web viewer (quite usefull for 360 ones)
Could be panoramax:view=https://api.panoramax.xyz/#focus=pic&map=19.04/48.8735278/2.2962318&pic=81d806bc-cd3d-475b-8769-c0746f67f4cf&speed=250&xyz=87.74/10.48/30
What would new key like panoramax:view be needed? Isnât it exactly what image=* is supposed to be used for? From mentioned wiki, it seems to match perfectly the definition of image=*:
URL or URI of a page containing the image alongside copyright information and other details
I see no reason what separate key like panoramax:view would bring compared to image, given that they are supposed to point to absolutely the same thing, but one (image) is already established and works for every destination URL, and other (panoramax:view) would be completely new (i.e. need implementing in all data consumers) and only artificially limited to point to only point to api.panoramax.xyz and nowhere else; but would otherwise be complete alias to the first one.
TL;DR:
keep using panoramax=81d806bc-cd3d-475b-8769-c0746f67f4cf to define UUID only
use image=https://api.panoramax.xyz/#focus=pic&map=19.04/48.8735278/2.2962318&pic=81d806bc-cd3d-475b-8769-c0746f67f4cf&speed=250&xyz=87.74/10.48/30 if you think that the benefits (defining the viewing angle of that pic - anything else?) outweigh the downsides (wastefulness, one-picture-per-tag only limitation; prone to breakage if URL format ever changes etc.)
Itâs very easy to recover the UUID, and I wrote a script doing this automatically in order to update those tags.
There is still a difference between panoramax=* and image=* tags:
panoramax=* needs to be transformed to actually access a picture file (it is an URI),
image=* directly provides a picture in return which can be re-used in a simpler way (it is an URL).
Maybe I wasnât clear enough when I wrote âprovide a link to view the object IN the pictureâ
We have more and more 360° pictures and having a way to point a viewer to focus on the OSM object in the picture seems more and more needed.
I agree, that when a picture is a close up of an object, that is quite useless.
Weâre also working on Panoramax side to attach tags to pictures, in order to describe them more in detail, like how they have been shot, and also what is inside the picture which will allow to link back to OSM or Wikidata, etc.
Yes but his is already used for years with image, wikimedia_commons, mapillary⌠tags.
And this another point (See tag image Unresolved issues).
For defibrillators, water point⌠two pictures are usually needed.
A close view of the object.
A wider view to see the object in situation.
Yes, we could need to add one or two pictures to see all destinations.
Agree two, but currently the multi-values separated by semicolons is the best solution for me.
I hope that one day the OSM API will managed real multi-values for a tag .
panoramax tag give access to pictures metadata, other images resolution, and several Panoramax instances (unlike image tag).
You were, I understood that part (that full URL allows for zoom/angle that just UUID does not). What is confusing to me is what exactly would be the difference between:
IOW what is expected difference in behaviour for data consumers when the key differs (image vs. panoramax:view) but when the value of the tag is exactly the same?
This is a link to open a viewer that can be used by a human, not a link to a picture file that can be processed by some code.
Maybe Iâm wrong considering that the image=* tag should only be used to link to a picture, but the situation regarding all image relating tags is that it is unclear what you would get behing the link.
Having different tags where we can provide a picture URL or a viewer URL seems important to me to make reuse of these tags easier.
That why I see 3 kinds of needs (and thus tags):
image picture URL, linking to an image file, the oldest and most generic tag
id based tags, pointing to another database (panoramax=, mapillary=, etc)
image viewer URL, linking to a way to display the picture or a part of it to a human (something that would work in an iframe).
The xyz parameters are specific to one viewer (here the Panoramax default viewer, some other may appear in the future).
Other viewers may use differents ones, computed in a different way.
Thatâs why I consider they should only appear in a full URL to a viewer, because they are dependent on the viewer, and shoudl not be mixed with the id in the remote picture catalog.
Yes. That is one of the 3 ways the image=* is supposed to be used according to its wiki documentation, namely âURL or URI of a page containing the image alongside copyright information and other detailsâ.
Maybe Iâm wrong considering that the image=* tag should only be used to link to a picture
Yes, I would say that interpretation is wrong.
Not only by wiki definition, but also actual taginfo usage shows wide support of that usage; e.g. there are very many instances of things like:
which do not contain âOnlyâ image, but are instead HTML+JS+CSS (+ eventually JPG image). In fact, were I a betting man, Iâd wager that they are likely in majority compared to those that just link directly to binary .jpg picture.
Key:image - OpenStreetMap Wiki lists three types of values that can be pointed to by image=* tag, but how to handle them is mostly left as an exercise for the reader.
In any case; it is not specific to links to panoramax full-URLs, but to pre-Panoramax situation as well; Panoramax existence does not change that problem. Iâd guess that most apps handle it by opening it in a web browser / webview and letting it handle whatever might be behind (e.g. https://osm.org, https://overpass-turbo.eu/, OsmAnd via osm.org webview) if they intend to support most current usages.
I agree with that observation of three different types; it is just that in my opinion (as detailed above) first and third usage are currently being accomplished by the sameimage=* tag (both in documentation, and in practice). While theoretically there would indeed be some benefit in trying to separate them, that:
would be better accomplished by proposing new raw_image=* tag, which is just like your first use case of image=* (i.e. is guaranteed to always point only directly to raw image/jpeg binary); and having existing image=* cover the rest (as is does today). That would cover all use cases (compared to panoramax:view=* idea which would presumably only be for panoramax and then weâd also need mapillary:view=*, somenewtech:view=* etc.)
to work, would likely require bots to be involved who would check image=* and raw_image=* tags and move things automatically between them (leaving image=* for complex stuff, and moving direct links to raw images to image_raw=* tags.
would not be very productive â apps would need to support both image and image_row tags; and they can already have that same functionality today by simply looking at MIME type of returned content from URL - i.e. is it image/jpeg (or other picture type they support - png, gif, svg, tiff, webp, avif, âŚ) or something else which they donât (like e.g. text/html) and handling that in the same way.
TL;DR: I think having image=* continuing to support both âdirect-to-jpegâ URLs as well as âindirect-jpeg-somehwere-in-htmlâ URLs is sufficient and covers panoramax use case of 360picture+zoom+angle as well, so no new panoramax:view (or similar) tag is needed.
.
because direct URLs to Panoramax, Mapillary, Commons⌠should be strongly discouraged.
