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.