Skip to content

added ability to show UserOutput variables in brouter-web#893

Open
kameamea wants to merge 3 commits into
abrensch:masterfrom
kameamea:master
Open

added ability to show UserOutput variables in brouter-web#893
kameamea wants to merge 3 commits into
abrensch:masterfrom
kameamea:master

Conversation

@kameamea
Copy link
Copy Markdown

When developing/debugging profiles I found it helpful to watch arbitrary variables in the brouter-web data table not just node$, elevation$, initial$, turn$

I implemented the ability to create variables starting with the name "userOutput" which then are shown in brouter-web (and in the json output as well). No modification to brouter-web is necessary.

@afischerdev
Copy link
Copy Markdown
Collaborator

@kameamea
Thanks for your nice idea. I'd like to see results soon.
But first:
Please build your repo before you check in. Use:
gradlew build
this will show you your errors or formating problems.

@afischerdev
Copy link
Copy Markdown
Collaborator

@kameamea
Great, it works now. I'll run some more local tests and wait a few days to see if there's any further feedback.

@afischerdev
Copy link
Copy Markdown
Collaborator

I did my first test with results:

profile entry:
assign userOutputisMyFirstValue 1
  • car profiles do not have this values, but the headline has the field isMyFirstValue
  • bike profiles have both but unexpected values (1000 vs 1)
    ["Longitude", "Latitude", "Elevation", "Distance", "CostPerKm", "ElevCost", "TurnCost", "NodeCost", "isMyFirstValue", "InitialCost", ....
    ["8646961", "49872189", "142", "55", "1050", "0", "0", "0", "1000", "0", ....

@afischerdev
Copy link
Copy Markdown
Collaborator

The announced conflict with BExpressionContext I could resolve on merging.

@kameamea
Copy link
Copy Markdown
Author

The values are multiplied by 1000 like the costfactor since I assumed this to be the main purpose, so this was expected (by me). And I assume that only integer values are transported to brouter-web, but I'm not sure about that.

I cannot reproduce the problem with car profiles. However so far user variables do not work in the context:node section (as I needed it only for ways). But it looks like you hit some other issue since you see the variable in the headline

@afischerdev
Copy link
Copy Markdown
Collaborator

But it looks like you hit some other issue since you see the variable in the headline

The problem was in car profile (way section, node section I haven't tested). Just copy my userOutput to a car profile.

The values are multiplied by 1000 like the costfactor since I assumed this to be the main purpose

Please follow your naming userOutput. That means to me I can see my designed values as it is.

But there is an other main issue, I think.
It could be a problem when you insert your extra values in the existing array structure.
The extra values are found in the data view of the BRouter web server.
However, there are also data analyzers that query the array field based on its index. But you move the index forward.
So I would recommend to put the user values at the end of the array. Any other software can still use the data as usual and you can see your values as well.
You could test that with the Analysis view in BRouter web server. When you insert your values like before this analyse is gone.

An additional idea:
May be you like to put the values into one field called 'userOutput' and has a logic like way description.

[..., "userOutput"]
[..., "isMyFirstValue=1 myExtraCost=1500"]

This keeps you open for more like userNodeOutput.

@afischerdev
Copy link
Copy Markdown
Collaborator

And I assume that only integer values are transported

As before follow your naming.

@kameamea
Copy link
Copy Markdown
Author

Thanks for the hints:

  1. I removed the multiplication with 1000 but kept the rounding to integers just to keep the table readable
    It really isn't helpful if it looks like this:
Screenshot 2026-03-28 at 16-08-24 BRouter Web Client
  1. Breaking the track analysis is an issue. I'd prefer to solve that on the brouter-web side and already have done that at https://github.com/kameamea/brouter-web/

Your suggestion of putting the userOutput after the last column typically requires scrolling horizontally a lot to see it at all and thus makes the feature hardly usable.

I've thought about using two different keywords like userOutputFront (which breaks analysis) and userOutputBack (after last column), but I'm not sure whether this is a good idea.

In the end it's meant to help debugging profiles and can easily be turned off by the profile developer when track analysis becomes important. Of course this behaviour should be documented.

What do you think would be best?

  1. Trying to reproduce the issue with the car profiles still not successful here. I inserted it to Car-Eco and Car-Fast and in both cases userOutput worked as expected. Can you please recheck with another profile?

  2. In case you are interested: I also modified brouter-web to show track analysis on userOutput variables if their name ends on "Stat": This is in the dev branch: https://github.com/kameamea/brouter-web/tree/dev

@afischerdev
Copy link
Copy Markdown
Collaborator

to 1.:

It really isn't helpful if it looks like this

In my opinion, this is extremely useful, if I only had an integer number in this output, it would be useless. We are talking about debugging, that needs exact values and not a beautiful view.

to 2.:

I'd prefer to solve that on the brouter-web side

There are other clients outside that may use the json output.
So please don't add values or logic that breaks the original output.

to 3.:
I'll do new tests with car profile when other issues are solved.

to 4.:
Please see number 2

@devemux86
Copy link
Copy Markdown
Contributor

There are other clients outside that may use the json output.
So please don't add values or logic that breaks the original output.

@afischerdev That's right. 👍

It's absolutely important with public API to maintain compatibility
and not break already working responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants