Custom profiles and lookups.dat change

[afischerdev]

Custom profiles and a new lookups.dat could cause problems if a lookup entry or value was previously used and is now removed. Related to #458

Some thoughts what could be done:

• don't remove entries/values from lookup The result is a growing definition file that carries unused things that are already obsulete in OSM data

• remove entries/values but ignore an upcomming IllegalArgumentException, build a warning but not an error message - to help a profile designer to find a right defined logic

assign custom_access
  if not barrier=hello_world then true
  else false

This will never be true when error is ignored

• add a fallback info to profile profiles are usually build as a copy from standard profile. When the standard profile contains its name a breaking custom profile move back to its root and bring at least a result.

---context:fallback=trekking

Result should contain a warning what causes the fallback

• check all profiles on lookup update we have a IntegrityCheckProfile class for profile designer to check against a lookup file. This could also be done inside the Android app with a remark for the user. Should include an update for serviceconfig.dat when custom profile is in there.

What do you think?

[zod]

Perhaps we should add functionality for deprecating lookup values

• rd5 files would no longer contain the data
• Using deprecated lookup values would cause a warning
• Using non existent lookup values would still cause an IllegalArgumentException

Profiles would still work (with some features disabled) and our rd5 files would not grow in size.