Clarify questions related to customizable routing

[karussell]

Follow up issue of #2209

• [x] Remove space characters from multiply by, limit to and else if and use _
• [x] Allow "else": "" not only "else": null (important for JSON)
• [x In documentation: should we focus on JSON format so that users of the web API can directly use it and only mention YAML for simpler creation of server-side models? -> opened #2275
• [x] If production format is decided, eventually move /route-custom into /route via a separate custom_model entry. This would also allow integration e.g. into /isochrone -> #2252
• [x] improve UI and auto complete feature (I found Ajv and [this example for the editor] (https://microsoft.github.io/monaco-editor/playground.html#extending-language-services-configure-json-defaults)) (see #2239)
• [x] make server-side models without separate file possible
• [x] should we add the set_to operator (yet)? -> later
• [x] should we add description/comment fields to statements? -> later
• [x] send custom request when markers are moved and custom model box is open? -> opened #2276
• [x] keep current selection of path-detail diagram in ui-state so it remains when we send another custom request (and it is still available) -> #2258

[easbar]

improve UI and auto complete feature

I think this is the most important thing to improve by far. Users need to get proper feedback for their actions: Syntax checking is important to not get frustrated with annoying little errors, auto-completion is important to easily see what can be customized and interactively learn the custom model language. Ultimately we should also be able to 'understand' why some route was chosen over another. For this we will need to be able to visualize the edge weights and the edge properties (but this won't really happen without a proper rewrite of GH maps, so probably for another issue).

which points are missing for a production-state format?

I guess this becomes easier to find out the more people are use the feature (therefore the first point is so important IMO)

In documentation: should we focus on JSON format so that users of the web API can directly use it and only mention YAML for simpler creation of server-side models?

This is a tricky question. I expect most users to start with the GH maps UI and enter some custom models in the flex box to see how their example routes change. The format that is entered there should be the same as in the documentation. On the other hand I expect it will be easiest to give proper hints / provide some kind of 'autocomplete' if we use the YAML format (with one statement per line) in the flex box. When a user is satisfied with the result it should be easy enough to translate the YAML format to JSON. We could even offer this in the UI: 'show current model as JSON'.

So with this reasoning I would suggest to:

• strictly enforce the (verbose) YAML format in the flex box, maybe allow pasting the more compact YAML format, but then convert it to the verbose format for editing. The fewer variations there are to enter stuff the easier it will be to learn what can be achieved with custom models.
• implement syntax checking and 'autocomplete/hints' for this format specifically
• offer a read only and copyable view of the flex box in JSON format (or something like 'copy JSON to clipboard'). Maybe also similar for the compact YAML format.

make server-side models without separate file possible

why?

If production format is decided, eventually move /route-custom into /route via a separate custom_model entry. This would also allow integration e.g. into /isochrone

Ok and at this point we should probably also remove the standard profiles/weightings and only use CustomWeighting.

[karussell]

I expect most users to start with the GH maps UI

I also expect hopefully many users to get started via the web API (via JSON). Also we should not forget that JSON is also valid YAML :)

which points are missing for a production-state format? I guess this becomes easier to find out the more people are use the feature (therefore the first point is so important IMO)

IMO it is also a bit of an chicken and egg problem as people will hesitate to invest time into it when it is still subject to change.

maybe allow pasting the more compact YAML format, but then convert it to the verbose format for editing

Ah, yes. I like your ideas. And pasting as JSON and converting it to YAML would make it very simple to copy&paste it from the docs that are e.g. only in JSON (for the web API).

offer a read only and copyable view of the flex box in JSON format (or something like 'copy JSON to clipboard').

:+1:

make server-side models without separate file possible why?

It is easier especially for short custom models (I implemented it already and tried it in production) and you requested it in #1841 I remember :)

Ok and at this point we should probably also remove the standard profiles/weightings and only use CustomWeighting

The reason for moving the custom_model into /route (and defining the format at some point as production state) is also that I would like to avoid too many changes to the web JSON API and to start delivering this without the "alpha notice" in 3.0, maybe only with a "beta notice" that is removed in 4.0 or 5.0. And removing the other weightings is IMO more an internal thing that we should do independently.

[easbar]

It is easier especially for short custom models (I implemented it already and tried it in production) and you requested it in #1841 I remember :)

Ok ;) I just thought this doesn't seem so important right now and it might be better to reduce the number of ways the same things can be done to make it easier to understand instead of adding more possibilities for convenience.

The reason for moving the custom_model into /route (and defining the format at some point as production state) is also that I would like to avoid too many changes to the web JSON API

Ok

[otbutz]

Do you want to allow users to target predefined areas(#2037) in the custom model?

[karussell]

Do you want to allow users to target predefined areas(#2037) in the custom model?

Probably only via encoded values like country for now.

[otbutz]

2201 might be relevant depending if we want to provide access to this kind of "dynamically" created EVs

[easbar]

Allow "else": "" not only "else": null (important for JSON)

Now we do not use yaml anymore I rather wonder if we should really allow null (and not just "")

[easbar]

In documentation: should we focus on JSON format so that users of the web API can directly use it and only mention YAML for simpler creation of server-side models?

Yes! I think the custom model language should be described for JSON. Maybe in a separate .md file? It should maybe contain some special advice for REST and UI users. For the server-side configuration of custom profiles we can then refer to this custom model explanation (but not the other way around as we currently do in profiles.md).

[easbar]

I opened separate tickets for the remaining issues (#2275, #2276). Closing here.