Elevations in feet are ignored

[1ec5]

If ele is expressed in feet using the usual units, it looks like the tag is dropped because it isn’t an integer or floating point number. (I’m only doing code inspection, so I could be wrong about this.)

ele is actually documented to be only in meters, but it is tagged in feet pretty commonly in practice, and this proposal would formalize that practice. Regardless, I just wanted to make sure you were aware that ele was being parsed this way, in case it was merely an oversight, since OSM2World does have code to parse other tags with support for units. If this is intentional and you believe ele should not contain units, I would welcome your feedback on the proposal’s talk page. Thanks!

OSM2World/src/main/java/org/osm2world/core/map_elevation/creation/EleTagElevationCalculator.java

Line 15 in aade8c5

return parseOsmDecimal(tags.getValue("ele"), true);

OSM2World/src/main/java/org/osm2world/core/util/ValueParseUtil.java

Lines 66 to 71 in aade8c5

	/**
	* parses a decimal value (e.g. "5", "0", "3.56" or "-12.30")
	*
	* @return the parsed value as a floating point number; null if value is null or has syntax errors.
	*/
	public static final @Nullable Double parseOsmDecimal(@Nullable String value, boolean allowNegative) {

[tordanik]

Hi, thank you for making me aware of this proposal. For OSM2World, different units for elevation values are not a problem as long as these units are explicit and well-defined. (Different standards for what elevation 0 means are a problem, as are incorrect elevation values even if they're signposted "on the ground" – but that's not directly affected by this proposal either way.)

If the proposal is approved, I have no problem with updating OSM2World to use the same value parsing logic which already exists for keys such as height.