Opened 8 years ago

Closed 8 years ago

#8610 closed defect (fixed)

[Patch] getAreaText corrupts some area values

Reported by: Cobra Owned by: Don-vip
Priority: normal Milestone:
Component: Core Version:
Keywords: Cc:


Working with the Measurement plugin I noticed that some areas are displayed as 0.00km². This affects any area >1000m² and <10000m². Areas between 10000m² and 99999m² are displayed with very little precision.

This is caused by some bogous comparison using the same logic for both distance and area, switching units at 1000: source:josm/trunk/src/org/openstreetmap/josm/gui/
I've created a simple patch fixing this issue by using a proper area comparison.

area    | current  | new
1       | 1.00 m²  | 1.00 m²
10      | 10.0 m²  | 10.0 m²
100     | 100.0 m² | 100.0 m²
1000    | 0.00 km² | 1000.0 m²
10000   | 0.01 km² | 10000.0 m²
100000  | 0.10 km² | 100000.0 m²
1000000 | 1.00 km² | 1.00 km²

I'm not completely sure about the behaviour for larger values. Maybe we could drop the decimals for values >= 10000m² or use km² for values >=100000m² (->0.10 km²), limiting the length of the resulting string.

Attachments (2)

fixAreaText.patch (855 bytes) - added by Cobra 8 years ago.
8610.patch (1.7 KB) - added by Preferred 8 years ago.
Version 2 cleaning up whitespace and adding 1 change

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by Cobra

Attachment: fixAreaText.patch added

comment:1 Changed 8 years ago by Don-vip

Owner: changed from team to Don-vip
Status: newassigned

Thanks for the patch :)

comment:2 Changed 8 years ago by Don-vip

Resolution: fixed
Status: assignedclosed

In 5870/josm:

fix #8610 - Wrong display of areas (based on patch by Cobra)

comment:3 Changed 8 years ago by Preferred

Resolution: fixed
Status: closedreopened

The current code has an issue with order of operations. a > bValue*bValue / aValue*aValue works for metric since aValue is 1 and thus order doesn't end up mattering. When it is set to Imperial and aValue is 0.3048, it causes undesired results because the divide occurs before the square. This turns the equation into a > bValue *bValue which is not what was intended.

I am attaching a patch that should fix the order of operations issue. Also, I added the custom area unit for the Imperial system, acre, abbreviated ac. I find that I only care about the custom area unit and do not want to see square ft for values less than an acre and square miles for values greater than 640 acres (1 sq mi). I am including a custom attribute to specify to only use the custom area unit named system_of_measurement.use_only_custom_area_unit. It should compliment and not conflict with the system_of_measurement.use_only_lower_unit since that setting is for distance and area.

Changed 8 years ago by Preferred

Attachment: 8610.patch added

Version 2 cleaning up whitespace and adding 1 change

comment:4 Changed 8 years ago by Don-vip

Resolution: fixed
Status: reopenedclosed

In 5952/josm:

fix #8610 - wrong area computation, new preference system_of_measurement.use_only_custom_area_unit(patch by Preferred)

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.