Vespucci 20.1 BETA Highlights#

2024-07-01

End of support for Android 4.1 to 4.4#

This version removes support for Android 4.1 to 4.4. While we aspire to maintain backwards compatibility as long as reasonably possible, 4.4 was released in October 2013 and is now more than a decade old, these versions have issues with support of more recent TLS variants and certificates and in practical terms were likely only to work on private instances of the OSM API. This has allowed us to remove some version specific code and the legacy build for pre-Android 5 devices.

Workaround issues with sites using Letsencrypt certificates on Android 7 and earlier#

Android devices running Android 7 and earlier do not trust the root certificates used to sign new or re-issued Letsencrypt certificates since earlier this year, leading to failures to down-/upload data to the OpenStreetMap API and to authenticate with the OpenStreetMap site since the beginning of June. The later being particular annoying as google decided to simply show a blank screen in webviews for SSL errors due to untrusted certificates instead of displaying an error message.

Version 20.1 contains workarounds for both issues (and displays an error message if this happens again in the future for any of the usages of webviews in the app).

Note that both submitting crash dumps and the feedback mechanism currently don't work on pre-Android 7 devices as they are provided by 3rd party libraries, we may be able to address this for the production release.

Both workarounds were backported to 20.0

Workaround issues with certain launchers restarting instead of resuming the app#

On certain devices and Android versions if you switch to a different app while in Vespuccis Property Editor and then return to Vespucci by clicking the app icon in the launcher, the app will be restarted instead of being resumed losing any unsaved changes made in the Property Editor in the process. Selecting Vespucci from the recent apps will in our experience always resume the app, but to avoid the issue on affected devices we've added a workaround that you can enable in the Experimental section of the preferences.

Enabling this option starts the Property Editor in the same mode we use for split-window support and experimentally seems to avoid the issues on some of the devices that are affected by the issue. As this uses a different method to communicate back to the main map display than previously (the same as we use in split-window mode) we haven't made this the default at this point in time and would like have some more feedback from our users before doing so.

It should be noted that this and similar issues have been an ongoing problem with Android since Android API 1 and are totally outside of our control.

For some indication if your device could be affected see testing on selected devices.

This workaround was backported to 20.0

Forced configuration change to OAuth 2#

As the OpenStreetMap API on openstreetmap.org no longer supports any other authorization mechanism than OAuth 2, the corresponding API configurations (default and sandbox) are now forced migrated to OAuth 2. As a consequence you will need to have the login and password for your OSM account available the next time you want to upload, or you can naturally execute Authorize OAuth from the Tools menu at any time before that.

UI changes#

Re-arrange entries in the layer modal with drag and drop#

Entries in the layer modal can be moved by long pressing and then dragging the entry to its new position. You will get a visual cue when you have pressed long enough by a dimmed image of the entry appearing.

Re-arrange relation members with drag and drop#

In the Members tab in the Property Editor (present when you are editing a Relation) you can now re-arrange member entries per drag and drop. As above you can start the process with a long press, however you will not be shown an image before you actually start dragging (that is Android for you).

Default set of keys used for the nearby POI display configurable#

In the absence of a filter being set the nearby POI display uses a default set of keys for which it will display entries. This makes sense as you typically don't want to display entries for all objects on the screen, just for those that have POI character, but work flows differ and to accommodate a wide range of uses we've now made the set of keys configurable in the Preferences in Nearby POI display.

Validation styling highlights instead of replacing normal styling#

Previously the colors returned by the validation styling replaced the normal styling of an object, in some cases making affected objects difficult to manipulate. We have changed this to use the colors as a highlight "behind" the normal element rendering which seems to work better.

Value selectors for direction and integers#

Providing dedicated selector UIs for values in OpenStreetMap is not straight forward as there is no formal typing system and a value can have literally any value representable by an UTF-8 string.

For example a selector for the value of the the layer tag needs to equally be able to deal with numbers as with the string I don't like integers . The approach we have taken in the past and intend to continue in the future is to provide UI support for the selection of existing and preset derived values and provide free form input via the Details tab. For this release we've added two dedicated modals for entering integer and direction values (this can be set in the presets) replacing previous text only entry.

Direction values#

This provides input either of tag specific values via a conventional single choice radio button selector or via a compass direction display below it, besides using any built in magnetic compass to determine the value or you can simply drag the display to the correct value.

Integer values#

This provides input of tag specific values as above, or selection of a whole number via a number picker.

Rendering of direction values#

Elements with a direction tag that contains a degree value are now rendered with a pointer in the the direction.

Support for rotating nodes with a direction tag and multiple elements and relations#

Selected nodes with a direction tag, multiple elements and relations now support rotation just a previously available for ways.

Per-preset item support for pre-filling tags with default values#

We now support setting a preferred behaviour on how to handle pre-filling tag values with either the previously used or the default value.

This is again a case of one size doesn't fit all, so you can now turn on pre-filling on a per preset item base. In the most recently used display a long press will display three options (instead of previously simply removing the item from the display):

  • Apply with last values apply the item using previously used values or defaults (persistent)
  • Apply with optional apply the item with optional tags (persistent)
  • Remove remove item from MRU display

Note that pre-filling will only have an effect on tags without a value.

Improved Todo support#

The Todo support has been re-factored to support

  • editing of the comment field
  • easier skipping of todos (both in the modal as in the menu associated with any references OSM element)

To make skipping a bit more useful the sorting to determine the nearest Todo to display with sort open items before skipped ones.

Facility to create Todos from the objects in a GeoJSON layer#

In some situations it is useful to work through a set of GeoJSON objects in the manner of todos, we now support creation of Todos from objects in a GeoJSON layer. You can either use a built in conversion that will create a Todo with a comment containing the GeoJSON properties, or use JavaScript to run a custom conversion. The later is particularly useful if the GeoJSON has references to OSM objects and you want to create Todos that will directly references these.

See sample conversion script.

Miscellaneous#

  • Add support for multi-line preference titles
  • Add support for labels for all GeoJSON geometries
  • Indicate in the taginfo project file if an entry is "not recommended" (aka deprecated)

Upgrading from previous versions#

As a general precaution you should upload any pending changes before updating, particularly if you are upgrading from any major version that doesn't immediately precede this one.

Known problems#

  • The documentation is out of date.
  • For other known problems with this build please see our issue tracker