The event configuration files are working well to help limit the number and order of attributes that are displayed. However, formatting of attributes is still defaulted and can result in, for example, floating point numbers that have too many digits after the decimal. These long numbers are ugly and obviously don't reflect the true accuracy of data. See the image below.
Modifier functions have been implemented in other InfoMapper code such as with graph configurations and I recommend doing something similar for the attributes. For example, the configuration might look like the following example (see L_Miles). Additional functions could be added over time, but a general format function would be useful. This would have functionality similar to C language sprintf, Java String.format, and Python str.format. C and Java use c-style % format specifiers and Python uses {} syntax. JavaScript and TypeScript likely provide similar functionality. The function would also need some default behavior like returning empty string for null rather than throwing an exception. The Python format function seems to be friendly this way. This approach would also allow more control over date/time formatting. One consideration is optimizing code so that formatting does not have to be reparsed every time popups are rendered. For example, a "formatter" object can be instantiated up front and used every time that formatting is required. Let's discuss the details.
Of course, an alternative to this is to have more intelligent metadata handling, for example if we knew that the attributes for a layer had certain data type and precision. However, this information does not come back by default from web services and GeoJSON files so being able to control formatting such as below is good.
The event configuration files are working well to help limit the number and order of attributes that are displayed. However, formatting of attributes is still defaulted and can result in, for example, floating point numbers that have too many digits after the decimal. These long numbers are ugly and obviously don't reflect the true accuracy of data. See the image below.
Modifier functions have been implemented in other InfoMapper code such as with graph configurations and I recommend doing something similar for the attributes. For example, the configuration might look like the following example (see
L_Miles). Additional functions could be added over time, but a generalformatfunction would be useful. This would have functionality similar to C languagesprintf, JavaString.format, and Pythonstr.format. C and Java use c-style%format specifiers and Python uses{}syntax. JavaScript and TypeScript likely provide similar functionality. The function would also need some default behavior like returning empty string for null rather than throwing an exception. The Python format function seems to be friendly this way. This approach would also allow more control over date/time formatting. One consideration is optimizing code so that formatting does not have to be reparsed every time popups are rendered. For example, a "formatter" object can be instantiated up front and used every time that formatting is required. Let's discuss the details.Of course, an alternative to this is to have more intelligent metadata handling, for example if we knew that the attributes for a layer had certain data type and precision. However, this information does not come back by default from web services and GeoJSON files so being able to control formatting such as below is good.