Enter width of platforms in the format that is standard for OSM (comma-seperated meters)

[wielandb]

Problem

After answering questions about the width of a bus stop, I got a comment on the changeset telling me that "498 cm" is non-standard for OSM and should be avoided. Instead, "4.98" should be the the value entered into the Database.

Which app version do you use?

0.3.0+8

What operating system do you use?

Android

What operating system version do you use?

10

Additional information

Link to the CS in concern

[Robbendebiene]

Thanks for the report!

At first I thought that this is not true, since the wiki explicitly allows specifying a unit and even seems to encourage one to do so.

By default, values will be interpreted as metres. To reduce the risk of misunderstandings, or if the width should be specified in a different unit, the unit can be added to the end of the value, separated by a space (see #Examples).

Unfortunately there exists a wiki page that defines all allowed units which doesn't contain centimetres https://wiki.openstreetmap.org/wiki/Map_features/Units

Our main reason for using centimetres is to indicate that the user shall input precise measurement data. Also it's usually slightly easier to enter whole numbers instead of comma separated values.

We could either change this to meters or try to keep the centimetre input and convert it to meters as needed. The latter is currently not possible, but should be fairly easy to implement due to the new question catalogue structure using a custom "expression".

We could also keep it as it is since it's not totally uncommon to use cm in OSM, but obviously it's rare for multiple reasons I suppose:

• https://taginfo.openstreetmap.org/tags/width=15%20cm
• https://taginfo.openstreetmap.org/tags/width=20%20cm

• https://taginfo.openstreetmap.org/tags/width=30%20cm

  (overpass currently isn't working for me, thats why I'm posting some taginfo links)

[Robbendebiene]

After revisiting this I see two solutions:

Solution 1:

Add an expression to convert the input values from cm to m.

Expression implementation:

String? _math(Iterable<String> args) {
  final iter = args.iterator..moveNext();
  try {
    var result = num.parse(iter.current);

    while(iter.moveNext()) {
      final operator = iter.current;
      iter.moveNext();
      final value = num.parse(iter.current);

      switch (operator) {
        case '+': result += value; break;
        case '-': result -= value; break;
        case '*': result *= value; break;
        case '/': result /= value; break;
        case '%': result %= value; break;
      }
    }
    // if result has no decimal places, convert and return as int to avoid empty 0 decimal
    return result == result.roundToDouble()
      ? result.toInt().toString()
      : result.toString();
  }
  catch(e) {
    debugPrint(e.toString());
    return null;
  }
}

This can be used in the question catalog (constructor) like this: "width": ["math", "$input", "/", "100"]

The problem is that calculating with doubles can always lead to undesired imprecisions. So we would need an additional package that handles computation without losing precision: https://pub.dev/packages/decimal I also cannot think of any other use case for the already quite generalized "math" expression.

Another solution would be to make an expression that does no mathematical computation and solely adds a decimal point at a certain position. Could look something like this: "width": ["insert/splice", "$input", "-2", "."]

Third option, and possible the most desirable one would be a number formatter expression like: https://api.flutter.dev/flutter/intl/NumberFormat-class.html (provided it works for this case)

Solution 2:

Keep everything as it is.

Even mm is a somehow an accepted value in OSM (https://wiki.openstreetmap.org/wiki/Category:Keys_indicating_lengths_in_millimetres) and suggested in other wiki pages: https://wiki.openstreetmap.org/wiki/Key:diameter#Unit_of_measure

I feel like no one would be surprised about seeing a cm unit.

[out:json][timeout:2665];
(
  nwr["width"~"cm$"];
  nwr["length"~"cm$"];
  nwr["height"~"cm$"];
);
// print results
out count;

-> At least 2284 elements with cm units (even though a good amount of them come from historic landmarks in Switzerland)

Maybe there is even a chance to add cm to the list of explicitly allowed units by starting a proposal or something similar.

[zorae]

I’m in favour of Solution 1.

Note that this issue also applies to the opening and spacing tags that can be set for cycle barriers.

[wielandb]

Did #183 make this issue closable?

[Robbendebiene]

Resolved by #183