tordans left a comment (openstreetmap/openstreetmap-website#6399)
Thanks for your reply, @gravitystorm!
> So let's see some use-cases, and figure out a better option.
The idea behind this change is to make it very easy for editors and OSM apps to
**share mapping-related preferences**.
The current limit of 255 makes it very hard to use the API for this use case.
There are a few apps that work around this limitation by splitting values into
multiple keys. But this is very error-prone and only works well for one app.
The advantage of the shared user/preferences data is, however, that all apps
can access them, so sharing should be easy.
**Use Case Examples:**
* **Shared custom background layers:**
In GoMap I can set up custom background layers. In iD I can do the same. In
MapRoulette I have settings to set up custom background layers as well. All
those are stored separately. (And most editors have similar features.)
My goal is to create a schema that apps can use to read and write to this
user-specific list of background layers. I started with a draft on this in
https://github.com/tordans/editor-settings-schema under "layers-schema".
The character limit should be high enough to allow for at least 10 of those,
so a limit of ~5k or ~10k would be ok.
* **Shared custom presets:**
In GoMap I can create custom presets, and iD is planning to add those in the
future. Other editors already have custom presets. The user/preferences could
be the place where we share those between editors.
I started with a draft on this in
https://github.com/tordans/editor-settings-schema under "presets-schema".
The character limit should be high enough to allow for at least 50 of those,
so a limit of ~30k or ~50k would be ok.
* **Shared custom fields:**
This is similar to the shared presets but adds fields to presets; the story
is the same as above.
* **Shared custom data layers:**
In GoMap I can upload custom data (GPX, GeoJSON) that I can use to review
OSM data. For example, a list of custom TODOs of places that I need to survey
and what to look at. In iD I can use similar files as an external data source.
This feature could evolve in two ways:
Either as a list of sources where the data needs to be stored somewhere and
the apps download them. This is what is described in
https://github.com/tordans/editor-settings-schema/blob/main/data-layers-schema/README.md.
The character limits should be similar to "Shared custom background layers".
But it might be better to think about it differently and use the preferences
to store the actual GeoJSON or GPX file that the editors can then load right
from the API. In this case, being able to store a GeoJSON of 1MB would be nice,
and editors would only download it when the user requests it—same as any other
external data store / URL.
Those use cases are only examples, and the linked drafts I wrote are just to
get the discussion started.
The potential and strength of this API is that it is shared between apps, and I
am looking for ways to make using it easy and start the collaboration between
editors to use it to share settings.
I talked with @k-yle about how we could create a wrapper for the current API to
make it easier now for at least JavaScript-based apps to use the API with the
current limits:
https://github.com/osmlab/osm-api-js/issues/32#issuecomment-3660625648. It
would be possible. However, before we go down this road, I wanted to first try
this PR.
**What is the right limit?**
* I started this PR with 10k because that is what we use elsewhere (e.g. blog
posts).
* I then updated it to 1,000,000 after talking to Kyle.
* Above are some other estimates, if we want to look into small numbers. The
max is ~50k. So maybe setting it to 100k is a compromise?
The important part is: Even a bigger limit that still might be too small will
require all apps to handle edge cases and communicate them to the user. So
either we all need to implement an edge-case splitting approach, or communicate
some hard-to-understand "you have too many presets, we cannot store this much,
delete some…" message to users, which will be bad UX and a lot of work.
The idea of the 1,000,000 is not that editors will store this much data, but
that we have a limit that we will never hit, so it does not get in the way …
while still setting some ground rules.
I am very open to other numbers here!
@tyrasd mentioned that he might be able to get some data from his Overpass
Turbo Short URL service, which would be a real-world use case that uses the
workaround ATM.
**What apps could use this feature or use it already?**
The user/preferences API is used for different purposes:
* Store UI state (for a specific app)
* Store mapping-related preferences (but for now just for one specific app)
* Other
>From @1ec5 in
>https://github.com/openstreetmap/openstreetmap-website/issues/6297#issuecomment-3223310244
> An incomplete list of current usage based on a cursory GitHub search:
>
> - MapComplete: favorites, themes, some other preferences?
> - Overpass Turbo: [saved
> queries](https://github.com/tyrasd/overpass-turbo/blob/3abf31b358eead177d3c130f85e696f5306c0569/js/sync-with-osm.ts).
> - Go Map!!: https://github.com/bryceco/GoMap/issues/599, replaced with iCloud
> in
> https://github.com/bryceco/GoMap/commit/7bfcb5f08e0b922038901bafe80efb050d4de778
> - Also,
> [Rapid](https://github.com/facebook/Rapid/blob/d4254643373b2ebd1076e10bcba11fed380fa3c4/modules/services/OsmService.js#L713)
> and
> [Vespucci](https://github.com/ltog/osmeditor4android/blob/92602d243a8debb703eb6ab8a0c96d3fe55a0d15/src/main/java/de/blau/android/tasks/MapRouletteApiKey.java#L57)
> use this API to communicate with the [MapRoulette
> backend](https://github.com/maproulette/maproulette-backend/blob/c888df5e045b83f3d8f4210b0e2ade2905b2c343/app/controllers/AuthController.scala#L250)
> via a MapRoulette API key.
Some of this data is not relevant for my idea of sharing data between editors.
Settings like "is the Mapillary layer on" in iD are likely something that only
iD will read and write (this feature is on the roadmap), given that I might not
want to see this layer in Go Map all the time. But in the end, those decisions
are up to the editors.
Classic preferences like this will be easy to store within the current
key-value limits. However, apps like iD would have an easier life if iD could
just write a full config object with all maybe 50 settings instead of handling
50 separate key-value tags.
**How do those apps handle the current limitation?**
AFAIK, MapComplete and Overpass Turbo are the only apps that write more than
simple key-value pairs to the API.
AFAIK, both use a custom way to split values into separate key-value pairs and
re-join them later.
(My idea in https://github.com/osmlab/osm-api-js/issues/32 was to extract this
logic into a shared helper.)
**Why is this relevant now?**
Go Map recently added more features that I would love to be able to reuse in
other editors. iD has features on the roadmap for all the described use cases,
and it would be great to be able to store them using this API. StreetComplete
and Every Door both use (part of) the iD Tagging Schema, and it would be great
to be able to share custom presets with users of those apps. This will remove
some pressure from the tagging-schema project to support presets that are
relevant for only a few users or only relevant for a local community.
So IMO it is the right time now to make it easier for all those apps to
collaborate.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/6399#issuecomment-3720199953
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/6399/[email protected]>
_______________________________________________
rails-dev mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/rails-dev
