Tags with unkown values disappear in recent

[abrensch]

I noticed a subtle change in data processing

It was probably triggered by my recent update the the pre-processor binary (on Sunday 8.1.2022). There used to be a binary >3 years old.

However, since the behaviour is the same on the "bikerouter.de" instance (which has it's own preprocessing) I guess the real trigger is much older.

The iintended behaviuor for tags with unkown values is that they appear as =unknown

But now it seems the tag just dissapears.

The car-profile should refuse to route along unknown access tags, but here are two examples where that does not work anymore:

http://brouter.de/brouter-web/#map=19/51.07744/13.73239/standard&lonlats=13.732513,51.077507;13.732237,51.077399&profile=car-eco

http://brouter.de/brouter-web/#map=17/50.15487/8.96989/standard&lonlats=8.971431,50.155312;8.968661,50.155468

[abrensch]

fixed by 1640baf

[afischerdev]

I'm sorry to come back to this point.
I added this 'feature' a while ago because I found to many entries on that.
So I made a short test with Hessen.pbf. Data in folder comes like this
lookupData2[inum] =
0 = 22.581.613 Bytes
1 = 22.704.496 Bytes
but only ~ 800 motor_vehicle unknown entries

Anyway it is necessary to have the 'unknown' info for some tags.
So I did a investigation on this:

motor_vehicle;0000184982 yes
motor_vehicle;0000045128 private
motor_vehicle;0000032622 agricultural forestry agricultural;forestry agricultural,forestry
motor_vehicle;0000025396 designated official
motor_vehicle;0000025092 destination
motor_vehicle;0000010895 permissive
motor_vehicle;0000000175 emergency Emergency
motor_vehicle;0000000100 psv
motor_vehicle;0000000100 hov
motor_vehicle;0000212692 no *

Moved the 'no' tag as last motor_vehicle entry and add a '*'.
This means all 'unknown' values are equal to 'no'.
Second sample (trekking) comes now back with
"highway=unclassified surface=asphalt maxspeed=30 motor_vehicle=no"

What do you think?

[abrensch]

What do you think?

tag-value data is about 20% of rd5-size, so unknown-entry is not a hot-spot

I count 132.000 unkown-entries for hessen.pbf, and that's mostly waterway=stream/ditch and lit=no
lit=no is not counted because for this type of "boolean value" unkown is supressed by default.

2 problem for your motor_vehicle example:

• "moving" values in the lookup table would require a change a change in major-version or otherwise leed to scrambled data. Minor changes require that tags and values are only appended.

• "*" as an alias is not recognized (only as primary value), as far as I read the code

[afischerdev]

I count 132.000 unkown-entries for hessen.pbf, and that's mostly waterway=stream/ditch and lit=no

Yes that's what I got. I see the problem in stream/ditch (have in total ~18 Mio entries with way data).

"moving" values in the lookup table would require a change a change in major-version or otherwise leed to scrambled data. Minor changes require that tags and values are only appended.

Should not be a problem. Server is changed manually I guess. APK loads a new loockup and/or profile on download.

The problem I see is that the 'no' value triggers all other 'no' values as well, not only the 'motor_vehicle'.

"*" as an alias is not recognized (only as primary value), as far as I read the code

Yes I had a extra check in BExpressionLookupValue matches.

What about having a 'use case unknown' table with the entries access, vehicle, motor_vehicle. May be more. And set only this to lookupData2[inum] = 1?

[abrensch]

What about having a 'use case unknown' table with the entries
access, vehicle, motor_vehicle. May be more. And set only this
to lookupData2[inum] = 1?

Evaluating a solution requires knowing the problem...

The waterway=stream/ditch network is already filtered out by the "all.brf" filter ( https://github.com/abrensch/brouter/blob/master/misc/profiles2/all.brf )

Only what adds to geometry is likely to blow up rd5-data-size. I doubt that unknown-value tags for ways that are nethertheless part of the network are a significant problem

[afischerdev]

No, not a significant part = 0.5 % (~120K for Hessen.pbf). But easy to save.
Ok, I'm quiet now.