Feature Request: consider maxheight

[francwalter]

Hello

I would love to see a feature where I can consider the maxheight of streets underneath bridges or such.
Often I use BRouter in Locus Maps to get some routing for our car, which is 2.75 m of height (camping car). Sometimes we cannot pass, the maxheight is not high enough and we need to make big drivearounds.
Is there maybe a possibility to add this as profile?

It could be also useful to have the max weight in a profile, I guess.

Thanks.
Frank

[poutnikl]

there is lookups.dat data file, where is exposed the subset of OSM data tags BRouter includes in its routing data. Such info is not currently implemented. Profile authors have to wait, until that is eventually done. Another question is how reliably are such data included in OSM data for tunnels and bridges, Something is better than nothing. ( Unless one relies too much something would be there.)

[Totorrr]

Pleases see PR #889 for this. It adds the relevant maxheight keys to lookups.dat.

[afischerdev]

@Totorrr
Thanks for your excellent work.
But please hang on a while with the PR #889
I like to point you to the discussion in #878.

There we discuss to add truck data to the lookups.dat and how to do that.

Short summary:

Trucks need more data than maxheight and there are more interests like camper or boat people in this values.
As you can see in your PR, these changes require a lot of entries for the values. And it will grow with all the others from #878.

So main question is: do we like to add all this as your main focus is on biking and hiking?

Next question is how to do that:
BRouter can work with index based and value based entries (some test results for this please see here).

index based

• add every relevant values to the lookups (with sub values for other system of measurement)
• add for every index an entry in the profile to calculate with the value (please see here and more lines)

value based

• add only one line to lookups for each tag like
  maxheight;000000001 *
• add one line in the profile to get the value, like

assign no_height
    switch and not  maxheight=
	              lesser v:maxheight    boat_height true
    false  

[Totorrr]

Hello @afischerdev,

thank you for pointing the discussion in issue #878, I did not knew it before.

index based

• add every relevant values to the lookups (with sub values for other system of measurement)

How could we convert values from other (non metric) systems of measurement if we don't used indexed? Changing Brouter's engine code to do the conversion itself as suggested here? (note that this example would not be sufficient as it's lacking parsing of values like 16"9')

• add for every index an entry in the profile to calculate with the value (please see here and more lines)

Do we need to do this? I mean, for maxheight, there can only be 2 string values, otherwise it's empty or an real number. Once we test those 2 strings in the profile code, if it's not <empty> or unknown, we know it's an integer. So at this point, can't we just use the lesser operand directly with the tag value like this?

assign height_ok = and not maxheight= lesser maxheight car_height

value based

• add only one line to lookups for each tag like
  maxheight;000000001 *
• add one line in the profile to get the value, like

assign no_height
    switch and not  maxheight=
	              lesser v:maxheight    boat_height true
    false  

Can you explain me the meaning of the v: prefix please? I don't see it in the profile developer doc.
EDIT: looking at the code, I suppose it changes the value of the OSM tag into a variable that can be used in the profile, isn't it?

The obvious interest here would be the low maintenance of lookups.dat. This would imply units parsing by Brouter's engine though, with all the error handling and fallback mechanisms if the value is weird. I'm am not sure this would be good. Still thinking about it a bit while you consider my clarfying questions. ;)

[afischerdev]

@Totorrr
The code for parsing different measurement is already done in BRouter lib.
And value like 16"9' would come to an error. Normally the notation goes 16'9".
Only missing code is for weight, but this is already done locally when I tested #878. Please see here
And this we hold in the data, may be some day we have country information what means default.

maxheight;001188430 default
maxheight;000177910 below_default

[Totorrr]

Hello @afischerdev,

you wrote in your comment #878 (comment) :

The result for an europe export:

106 Datei(en), 2.891.832.038 Bytes
106 Datei(en), 2.905.190.574 Bytes

It doesn't look as much like it felt. Germany only was around 2.5 percent.

If the map file size increase is this low (you say for Germany, it increases the file size by 2.5%, but for Europe, it's +0.46 % if I'm not mistaken), I would be in favour of using the * in lookup.

I would be curious of file increase with the index based technique though. But that would imply some work to make most frequent key-values pairs appear in lookup for the concerned keys. Also, future changes of usage, although not frequent nor prone to happen soon, would not be considered without a lookup update.

PS: I saw your PR #896 and left 2 or 3 small comments.

[afischerdev]

@Totorrr

I would be in favour of using the * in lookup

Thanks for your clear voting. I would prefer it as well.
But
at the moment we are near to a bigger update #885 and the switch of the server to the current lookups.dat version 11.1

This means that in this situation, the lookups.dat file should not be updated.