Discussion
Loading...

Post

Log in
  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
lianna
lianna
@lianna@micro.webgarden.click  ·  activity timestamp last week

Panoramax question

I always wanted street-level imagery to be a bigger thing in #OpenStreetMap data. Not 360-degree road images like Street View, but photos of points of interest.

I always felt queasy about #Mapillary because of its proprietary nonsense and that feeling was confirmed when it was sold to Facebook/Meta.

Now the next big thing is #Panoramax and apparently it's FOSS and federated and all.

I'm just wondering how it works. It still relies on a single centralised "meta" instance apparently. That's also the link that we'd add to #OSM data.
If that goes down, is sold, or gets compromised, isn't the whole thing for nothing? If an instance shuts down, does it just take down all data ever contributed? Are photos backed up across all instances?

  • Copy link
  • Flag this post
  • Block
Yrrusajywo
Yrrusajywo
@Yrrussaj@piaille.fr replied  ·  activity timestamp last week

@lianna ping @cquest if you are able to answer :)

  • Copy link
  • Flag this comment
  • Block
Panoramax
Panoramax
@panoramax@mapstodon.space replied  ·  activity timestamp last week

@Yrrussaj @lianna

The "meta" instance is just collecting the catalog of pictures available on all the federated instances. It is currently hosted by @osm_fr and we plan to create a Panoramax foundation (non for profit association) to host it independently.

Anybody can setup a meta catalog, the code is FLOSS too.

If an instance shuts down or is unreachable, the pictures it is hosting are not available.

We do backups of small instances, large ones have to take care of that.

  • Copy link
  • Flag this comment
  • Block
Panoramax
Panoramax
@panoramax@mapstodon.space replied  ·  activity timestamp last week

@Yrrussaj @lianna

Cross-backup between instances to get at least one copy would mean each instance must at least offer the same amount of backup storage for the others than it is using for its own content.

For many small instance this is too expensive as storage is really the main challenge in such a project.

That's also why we opted for a decentralized approach, to keep each instance small enough to be sustainable.

  • Copy link
  • Flag this comment
  • Block
lianna
lianna
@lianna@micro.webgarden.click replied  ·  activity timestamp last week

@panoramax @Yrrussaj I understand, thank you for replying. :)

I'm just wondering how useful this is for OSM in the long term, since the panoramax=* tag is a hard link.

If, say, there'll be an instance focusing on the German territories, and it shuts down after a couple of years for some reason, will all OSM apps suddenly lose all volunteer data about Germany accumulated over half a decade?

And even if it was backed up and restored somewhere else, we'd need to change all hard links from the old instance to new, working ones.

I am not sure, but wouldn't a UUID approach per-picture similiar to Wikidata be a better idea than hard linking a single host? That way you could have multiple, distributed sources for the same image just based on its identifier, at least.

  • Copy link
  • Flag this comment
  • Block
Panoramax
Panoramax
@panoramax@mapstodon.space replied  ·  activity timestamp last week

@lianna @Yrrussaj

Well, the panoramax=* originally proposed on the wiki is only the UUID of the picture, a query on (any) meta-catalog will give all details about it.

In the future, the meta-catalog could also take care of availability on a backup when the original instance is down or dead.

There's still a lot of thing to build together !

Any external link in OSM is subject to the long term availability of what's on the other side. This applies also to wikipedia/wikidata and other sources.

  • Copy link
  • Flag this comment
  • Block

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances
Bonfire social · 1.0.1-beta.35 no JS en
Automatic federation enabled
Log in
  • Explore
  • About
  • Members
  • Code of Conduct