AscenDB Release: peaks-1.1.0

This release includes both new features and some improvements for the peaks API. One minor breaking change was introduced between the previous release, 1.0.0, and this release: the main function no longer returns an array of names for each peak. Instead, this function will return a maximum of one name per peak, chosen in no particular order from the set of names for that peak. The order may (and probably will) change in the future in order to bring back a peak's most 'iconic' name. All names for a peak can still be accessed by selecting the peak individually.

Here's the full change log:

  • Sorting by peak statistics has been added to the ascendb.all-near function! Why not add it to all search functions? Well, the result set from all-near will always be relatively small, and sorting will be fast as a result. Eventually, sorting will also be possible on the primary search function, but for now it is still too inefficient to apply at a global scale. See the documentation to learn how to use the new sorting parameter.
  • The main function no longer brings back an array of names per peak; instead it brings back a string representing a single name, if the peak has any names.
  • Greatly improved performance on search radii of more than 100,000 meters.
  • The primary search function now brings back up to 25 peaks per request, an increase from the previous max of 20.
  • All search functions now bring back only active peaks. The new differentiation between active and inactive peaks allows the database maintainers to exclude a peak from all search results without entirely removing it from the database. A deactivated peak can still be accessed by its ID number during a 'review period', after which the peak will either be reactivated or removed from the database entirely.
  • String values will be parsed as numbers in the near parameter of the search filter. Now, both of the following are valid:
    • { near: { lat: 30.0, lon: 100.0, rad: 1000.0 } }
{ near: { lat: "30.0", lon: "100.0", rad: "1000.0" } }
  • Clarifications to documentation.
  • More estimates calculated and included for isolation and ORS.

The next iteration will focus on some basic performance improvements, and potentially one or two new features related to 'parent' peaks, peak accessibility, or mountain ranges. Performance improvements take center stage for now, and not just for speed. Optimizing the search functions to behave more consistently will also enable a more stable pricing scheme than per-compute-second charging.

See you at the top!

ReleaseRob Kleffner