Update lookups

[afischerdev]

This is the call for a bigger update on lookups.dat

The Android apk doesn't need an update for that. Lookups.dat and profiles are updated automaticly.
Next apk update will then contain the new versions.

So only web services are affected.

And an update for the profiles is needed when there is an interest on man_made=pier or other changes.

Please see #416 for more.

[zod]

If we generate new segments using this update lookups.dat all users must update their segment files as soon as they get the new lookup.dat. Correct?

• I'm not to sure about compatibility. When do we need to increase the major version?
• I don't think we need hiking-beta.brf in the repository, but just as downloadable profile.

[afischerdev]

If we generate new segments using this update lookups.dat all users must update their segment files as soon as they get the new lookup.dat. Correct?

Yes. When the server update is done and an apk user updates the data lookups.dat and profiles are downloaded first then rd5 download starts. But when user has called e.g. only one rd5 but has 4 on board he has a problem when next enter an outdated rd5 - he will get a notice.
We already discussed if we drop the others or not.

I'm not to sure about compatibility. When do we need to increase the major version?

When index changes a new number is needed. Smaller changes like aliases don't change it.

I don't think we need hiking-beta.brf in the repository, but just as downloadable profile.

Yes, until new apk version is out. Current looks for hiking-beta
But we could exclude it from profile zip

[polyscias]

I think breaking things for (many) users is bad and like I wrote in #416, I see quite some pain for removing oneway=true.

I did post PR to update the profiles of @poutnik, see poutnikl/Trekking-Poutnik/pull/30 but that has not been merged as of now.

Apart from the profiles of @poutnik it also impacts most other profiles so I think it is better to keep it in the profile for now, but let's remove it for the brouter profiles.

But when user has called e.g. only one rd5 but has 4 on board he has a problem when next enter an outdated rd5 - he will get a notice.

How does that notice look like?
I run my tests with the server but there the error reporting is not good, the error is only logged at the server side.

Also, what about return meta.lookupVersion == 10;

For the remainder the patch looks good to me, I can run later this weekend a map generation run with it and give some stats.

[nrenner]

Quoting @polyscias from #416 (comment):

For tracktype=4, can we added "grade3-5" as alias, that is mapped 917 times

I wondered where the tracktype=grade3-5 value comes from.

The OSM tag history graph (see also Taginfo chronology) looks suspicious:

And indeed, there are two unique uses:

• 945 ways added by an import in 2014 with changeset 21660337 for some region in Norway [1]
• 538 ways added since July by a single paid mapper from Kaart [2], almost all to highway=residential in South Africa

The latter and other sporadic edits are all using the iD editor, which actually has that value in the list of suggestions when using the properties table, which is most probably because of the value count of that single import.

Therefore I think the grade3-5 alias should not be included, such an endorsement would only further propagate the use of this undocumented and unsupported value.

---

[1]

curl -o changeset-21660337.osc https://www.openstreetmap.org/api/0.6/changeset/21660337/download
grep "grade3-5" changeset-21660337.osc | wc -l

[2] https://overpass-turbo.eu/s/1kNX

[polyscias]

Nice analysis @nrenner!

I am perfectly fine with removing the grade3-5 alias but my opinion is, also with knowing this story, such an alias is fine.

There are more tags in lookups.dat that are undocumented, for instance noexit=yes in way context and junction=approach

[poutnikl]

I did post PR to update the profiles of @poutnik, see poutnikl/Trekking-Poutnik/pull/30 but that has not been merged as of now.

I have somehow missed the PR and related discussion. I will try to address it and generate new profiles, but after Aug 15, due vacation.

Another delay will be for LocusMap users, with profiles embedded to application or online LocusMap client. They use profiles from several sources.

[polyscias]

I have somehow missed the PR and related discussion. I will try to address it and generate new profiles, but after Aug 15, due vacation.

That would be nice.

Another delay will be for LocusMap users, with profiles embedded to application or online LocusMap client. They use profiles from several sources.

Do you have some more information on this, in particular the exact profiles that are used? I like to add them to my collection of profile that I check for impact of this update.

I can run later this weekend a map generation run with it and give some stats.

With quite some delay I did run it and looking at all the .rd5 files generated versus those on http://brouter.de/brouter/segments4/
I see a mix of segments that did increase in size and decrease in size but net effect is that the overall size is -0.04%

The extremes:

W90_N30.rd5   4998766   34854799 +14.34%
E25_S10.rd5    477592    3252900 +14.68%
E45_S30.rd5    113831     768699 +14.81%
..
E10_N65.rd5   -505069    3792746 -13.32%
E15_N65.rd5   -952119    7259065 -13.12%
E10_N60.rd5  -3225188   23634055 -13.65%

I am planning to get the updated lookup.dat, profiles and one .rd5 on my mobile and see what it does.

[polyscias]

See also brouter-web#669, can we add also:

• railway=platform
• public_transport=platform
• man_made=pier

The first two are accessible on foot and a pier is often a way to access a ferry both on foot and by bicycle.

[xuiqzy]

Hi, I read the previous discussion and the related issue #416 but I am unclear on what is needed for these lookup updates to be able to be merged and to be available in brouter web and other brouter based use cases?
(Mainly interested in the cycleway:both, cycleway:lane and related updates)

[afischerdev]

To all friends of profiles:

Please keep in mind for testing your profiles against a new/changed lookups.dat call

java -cp  brouter-1.7.3-all.jar  btools.expressions.IntegrityCheckProfile profiles2/lookups.dat profiles2_my

[devemux86]

@afischerdev

Any news on this pull request?

[afischerdev]

Unfortunately not.
At the beginning of this request there were some concerns about the hard change of the lookup version number.
I can't say if they are all gone.

When we are ready for update:
All the actions of using the new lookups fro generation of rd5 files is part of the maintaining. The Server is running since installation in last summer with the same configuration. There is always high traffic and hard to detect a date for a bigger update session. As you see all this needs an update - not only a new BRouter library and a new lookups file.

And it would be a good idea to update the BRouter web for this issue #710. So we prepare a nightly docker build for the server build but it could not be used with the BRouter web docker file. And it would be easier to install direct from github on an server update - I guess.

[afischerdev]

Will add key shoulder as mentioned here.