Custom mapping modes for POIs

[mfbehrens]

This editor can become the standard surveying tool for any applications if custom poi filters (like POIs and micromapping) will be implemented. You specify in street_lantern mapping? No problem, you just write or download a custom POI filter and only the relevant POIs get shown. Same would apply to outdoor climbing spots, botanical gardens, hiking guide posts and actually anything you imagine.

Other example would be field HOT OSM mappatons. You get a special preset for this mapaton which just shows anything you should survey and many more.

These custom presets could be definded as json, yaml, overpass statement or anything you currently use to specify which POIs get shown on the map.

Maybe there could be an additional button "Add more mapping modes" which leads to a screen where you can add new config files from file or from a list of official configurations (potentionally in a sperate repository)

[Zverik]

Interesting idea. Maybe some configuration format for the entire editor (default presets, filters, custom fields, etc etc) might be useful. With a central server for publishing, so that e.g. HOT could just publish one for Tanzania, and it will be immediately visible. Or I could make a preset for tree types. Possibly with submenus for the preset chooser. Not with an in-app editing (too complex for an app), but indeed useful for targeted mapping activities.

Not for 1.0 though. I'll look at the demand.

[mfbehrens]

Custom profiles would also solve many issues concerning what to include in the profile since everybody can just write their own profile

[pyrog]

Maybe there could be an additional button "Add more mapping modes" which leads to a screen where you can add new config files from file or from a list of official configurations (potentionally in a sperate repository)

Or use Deep Linking: a special URL could run Every Door with a custom presets:
https://every-door.app?preset=https://mycartoparty.org/mypreset.json

See Uni Links.

[rouelibre1]

Such a feature would be great.

As mentionned in #406, I believe that there is a case for highly targeted micromapping by specific groups that could be drawn to OSM through their own use case.

POI-type specific completionist approach within larger areas VS POI-type agnostic completionist aproach within smaller areas.

I'm in for bicycle parking, some people might want to map fire hoses etc.

[Zverik]

Not to forget: custom imagery (tms/wms) as well.

[Zverik]

In #513 it was recommended to try keeping some colors stable in the micromapping mode.

[Zverik]

So the current plan is, extension packages. Consisting of:

• A core file: a script in Dart (dart_eval), Hetu or Lua (lua_dardo).
• Some additional files, e.g. icons, geometry to display, a preset & imagery database.

Packages can be distributed as files (you download a file in your messenger, open it with ED, and it's installed) or with the central repository (ED → Settings → Extensions → search and install). Opening files could help with partial non-function "extensions": e.g. displaying a GeoJSON or GPX.

Each extension gets a block in the extension settings. They have a header with a toggle to disable and then remove, and a list of configurable fields. That way it might be possible to make some constant options in ED configurable.

Use cases I want to enable:

• Limiting and changing constants. That includes servers, basic lists and distances, all of "good_tags" file, drawing styles etc.
  • For example, an extension to use the OSM Sandbox server or replace OSM tiles.
• Redefining modes. We have three UI templates, so we can adjust them to specific cases.
  • E.g. instead of buildings mode, edit trees. "Add a tree" draggable button, popups on tap with fields for trees etc.
  • Possible to have e.g. three micromapping modes with different themes.
• Adding and replacing presets: e.g. specific HDM fields and dedicated presets for each type of tree. Maybe packaging databases in the same format and doing queries to each of them.
  • Also limiting default presets and imagery and everything else. Maybe disabling NSI even.
• Choosing colors: function to fix types for micromapping, more fills in building mode depending on values etc.
• Adding layers to maps: e.g. geojson boundaries for a mapping party.
• Displaying a description panel after enabling the extension (helpful with mapping events).

With this, made the default things into a package, to serve as an example and also to move things out of the code. And some things affecting a very small number of people — e.g. google services toggle — could be made into extensions.

I guess this would have to be a global object, not a provider, since we're replacing constant things. Also need to cache constants to not execute an interpreter for each number.

[Zverik]

Couple more use cases: saving or fixing state of "more fields", "publish to osm", the default state of draw mode etc.

[Zverik]

Good news: I got funding from NLNet to implement this!

[Zverik]

Another use case came from a cyclists' association: instead of buildings mode, have "bicycle infra" mode with a button for a cycle barrier. In the editing panel, it should have pictures for barrier types, an explanation for spacing/opening/overlap measures, and a type-dependent visibility of fields.

[Zverik]

We need to override some presets - or maybe just update them. Today Oliver from Germany asked if it's possible to use a digital direction field for highway=give_way. The preset has a direction_vertex_dual field, and it'd be useful to override it to direction.

[mnalis]

asked if it's possible to use a digital direction field for highway=give_way. The preset has a direction_vertex_dual field, and it'd be useful to override it to direction.

Ummm, but direction_vertex_dual should already be resolving to key direction - according to /data/fields/direction_vertex_dual.json#L2 , shouldn't it?

[Zverik]

Ummm, but direction_vertex_dual should already be resolving to key direction - according to /data/fields/direction_vertex_dual.json#L2 , shouldn't it?

It does! But it's a combo box with two options (forward and backward). And we need the number :) Oliver says, numbers are being used for signs, but for it to appear in the editor, it needs to be a proper field type.

[Zverik]

One thing that feels obvious but wasn't mentioned: plugins must have some persistent storage. I see it as a dedicated table in SQLite db, with a key-value API for modules.

Also Tobias mentioned (wrt MapRoulette) that modules might want to get state from somewhere. Like, I imagined FMTM integration as installing a module every time you scan a QR code (maybe updating one, with matching ids). But maybe we could install a module one time, and let it scan codes? On the second thought, no: it is more complicated to a user, knowing which module to install first.

But maybe we could embed some identifier in a module QR code, so that if it is installed, we first ask it if it can process the id, and if not, we reinstall it from the link. So a code would be like, module_id:data_id:url, with prefixes optional.