Index
+ +
+
+
+
+
+ Document not found (404)
-This URL is invalid, sorry. Please use the navigation bar or search to continue.
- -This URL is invalid, sorry. Please use the navigation bar or search to continue.
- -' + + '' + + _("Hide Search Matches") + + "
" + ) + ); + }, + + /** + * helper function to hide the search marks again + */ + hideSearchWords: () => { + document + .querySelectorAll("#searchbox .highlight-link") + .forEach((el) => el.remove()); + document + .querySelectorAll("span.highlighted") + .forEach((el) => el.classList.remove("highlighted")); + localStorage.removeItem("sphinx_highlight_terms") + }, + + initEscapeListener: () => { + // only install a listener if it is really needed + if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) return; + + document.addEventListener("keydown", (event) => { + // bail for input elements + if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return; + // bail with special keys + if (event.shiftKey || event.altKey || event.ctrlKey || event.metaKey) return; + if (DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS && (event.key === "Escape")) { + SphinxHighlight.hideSearchWords(); + event.preventDefault(); + } + }); + }, +}; + +_ready(() => { + /* Do not call highlightSearchWords() when we are on the search page. + * It will highlight words from the *previous* search query. + */ + if (typeof Search === "undefined") SphinxHighlight.highlightSearchWords(); + SphinxHighlight.initEscapeListener(); +}); diff --git a/ayu-highlight.css b/ayu-highlight.css deleted file mode 100644 index 32c9432..0000000 --- a/ayu-highlight.css +++ /dev/null @@ -1,78 +0,0 @@ -/* -Based off of the Ayu theme -Original by Dempfi (https://github.com/dempfi/ayu) -*/ - -.hljs { - display: block; - overflow-x: auto; - background: #191f26; - color: #e6e1cf; -} - -.hljs-comment, -.hljs-quote { - color: #5c6773; - font-style: italic; -} - -.hljs-variable, -.hljs-template-variable, -.hljs-attribute, -.hljs-attr, -.hljs-regexp, -.hljs-link, -.hljs-selector-id, -.hljs-selector-class { - color: #ff7733; -} - -.hljs-number, -.hljs-meta, -.hljs-builtin-name, -.hljs-literal, -.hljs-type, -.hljs-params { - color: #ffee99; -} - -.hljs-string, -.hljs-bullet { - color: #b8cc52; -} - -.hljs-title, -.hljs-built_in, -.hljs-section { - color: #ffb454; -} - -.hljs-keyword, -.hljs-selector-tag, -.hljs-symbol { - color: #ff7733; -} - -.hljs-name { - color: #36a3d9; -} - -.hljs-tag { - color: #00568d; -} - -.hljs-emphasis { - font-style: italic; -} - -.hljs-strong { - font-weight: bold; -} - -.hljs-addition { - color: #91b362; -} - -.hljs-deletion { - color: #d96c75; -} diff --git a/book.js b/book.js deleted file mode 100644 index aa12e7e..0000000 --- a/book.js +++ /dev/null @@ -1,697 +0,0 @@ -"use strict"; - -// Fix back button cache problem -window.onunload = function () { }; - -// Global variable, shared between modules -function playground_text(playground, hidden = true) { - let code_block = playground.querySelector("code"); - - if (window.ace && code_block.classList.contains("editable")) { - let editor = window.ace.edit(code_block); - return editor.getValue(); - } else if (hidden) { - return code_block.textContent; - } else { - return code_block.innerText; - } -} - -(function codeSnippets() { - function fetch_with_timeout(url, options, timeout = 6000) { - return Promise.race([ - fetch(url, options), - new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), timeout)) - ]); - } - - var playgrounds = Array.from(document.querySelectorAll(".playground")); - if (playgrounds.length > 0) { - fetch_with_timeout("https://play.rust-lang.org/meta/crates", { - headers: { - 'Content-Type': "application/json", - }, - method: 'POST', - mode: 'cors', - }) - .then(response => response.json()) - .then(response => { - // get list of crates available in the rust playground - let playground_crates = response.crates.map(item => item["id"]); - playgrounds.forEach(block => handle_crate_list_update(block, playground_crates)); - }); - } - - function handle_crate_list_update(playground_block, playground_crates) { - // update the play buttons after receiving the response - update_play_button(playground_block, playground_crates); - - // and install on change listener to dynamically update ACE editors - if (window.ace) { - let code_block = playground_block.querySelector("code"); - if (code_block.classList.contains("editable")) { - let editor = window.ace.edit(code_block); - editor.addEventListener("change", function (e) { - update_play_button(playground_block, playground_crates); - }); - // add Ctrl-Enter command to execute rust code - editor.commands.addCommand({ - name: "run", - bindKey: { - win: "Ctrl-Enter", - mac: "Ctrl-Enter" - }, - exec: _editor => run_rust_code(playground_block) - }); - } - } - } - - // updates the visibility of play button based on `no_run` class and - // used crates vs ones available on https://play.rust-lang.org - function update_play_button(pre_block, playground_crates) { - var play_button = pre_block.querySelector(".play-button"); - - // skip if code is `no_run` - if (pre_block.querySelector('code').classList.contains("no_run")) { - play_button.classList.add("hidden"); - return; - } - - // get list of `extern crate`'s from snippet - var txt = playground_text(pre_block); - var re = /extern\s+crate\s+([a-zA-Z_0-9]+)\s*;/g; - var snippet_crates = []; - var item; - while (item = re.exec(txt)) { - snippet_crates.push(item[1]); - } - - // check if all used crates are available on play.rust-lang.org - var all_available = snippet_crates.every(function (elem) { - return playground_crates.indexOf(elem) > -1; - }); - - if (all_available) { - play_button.classList.remove("hidden"); - } else { - play_button.classList.add("hidden"); - } - } - - function run_rust_code(code_block) { - var result_block = code_block.querySelector(".result"); - if (!result_block) { - result_block = document.createElement('code'); - result_block.className = 'result hljs language-bash'; - - code_block.append(result_block); - } - - let text = playground_text(code_block); - let classes = code_block.querySelector('code').classList; - let edition = "2015"; - if(classes.contains("edition2018")) { - edition = "2018"; - } else if(classes.contains("edition2021")) { - edition = "2021"; - } - var params = { - version: "stable", - optimize: "0", - code: text, - edition: edition - }; - - if (text.indexOf("#![feature") !== -1) { - params.version = "nightly"; - } - - result_block.innerText = "Running..."; - - fetch_with_timeout("https://play.rust-lang.org/evaluate.json", { - headers: { - 'Content-Type': "application/json", - }, - method: 'POST', - mode: 'cors', - body: JSON.stringify(params) - }) - .then(response => response.json()) - .then(response => { - if (response.result.trim() === '') { - result_block.innerText = "No output"; - result_block.classList.add("result-no-output"); - } else { - result_block.innerText = response.result; - result_block.classList.remove("result-no-output"); - } - }) - .catch(error => result_block.innerText = "Playground Communication: " + error.message); - } - - // Syntax highlighting Configuration - hljs.configure({ - tabReplace: ' ', // 4 spaces - languages: [], // Languages used for auto-detection - }); - - let code_nodes = Array - .from(document.querySelectorAll('code')) - // Don't highlight `inline code` blocks in headers. - .filter(function (node) {return !node.parentElement.classList.contains("header"); }); - - if (window.ace) { - // language-rust class needs to be removed for editable - // blocks or highlightjs will capture events - code_nodes - .filter(function (node) {return node.classList.contains("editable"); }) - .forEach(function (block) { block.classList.remove('language-rust'); }); - - code_nodes - .filter(function (node) {return !node.classList.contains("editable"); }) - .forEach(function (block) { hljs.highlightBlock(block); }); - } else { - code_nodes.forEach(function (block) { hljs.highlightBlock(block); }); - } - - // Adding the hljs class gives code blocks the color css - // even if highlighting doesn't apply - code_nodes.forEach(function (block) { block.classList.add('hljs'); }); - - Array.from(document.querySelectorAll("code.hljs")).forEach(function (block) { - - var lines = Array.from(block.querySelectorAll('.boring')); - // If no lines were hidden, return - if (!lines.length) { return; } - block.classList.add("hide-boring"); - - var buttons = document.createElement('div'); - buttons.className = 'buttons'; - buttons.innerHTML = ""; - - // add expand button - var pre_block = block.parentNode; - pre_block.insertBefore(buttons, pre_block.firstChild); - - pre_block.querySelector('.buttons').addEventListener('click', function (e) { - if (e.target.classList.contains('fa-eye')) { - e.target.classList.remove('fa-eye'); - e.target.classList.add('fa-eye-slash'); - e.target.title = 'Hide lines'; - e.target.setAttribute('aria-label', e.target.title); - - block.classList.remove('hide-boring'); - } else if (e.target.classList.contains('fa-eye-slash')) { - e.target.classList.remove('fa-eye-slash'); - e.target.classList.add('fa-eye'); - e.target.title = 'Show hidden lines'; - e.target.setAttribute('aria-label', e.target.title); - - block.classList.add('hide-boring'); - } - }); - }); - - if (window.playground_copyable) { - Array.from(document.querySelectorAll('pre code')).forEach(function (block) { - var pre_block = block.parentNode; - if (!pre_block.classList.contains('playground')) { - var buttons = pre_block.querySelector(".buttons"); - if (!buttons) { - buttons = document.createElement('div'); - buttons.className = 'buttons'; - pre_block.insertBefore(buttons, pre_block.firstChild); - } - - var clipButton = document.createElement('button'); - clipButton.className = 'fa fa-copy clip-button'; - clipButton.title = 'Copy to clipboard'; - clipButton.setAttribute('aria-label', clipButton.title); - clipButton.innerHTML = ''; - - buttons.insertBefore(clipButton, buttons.firstChild); - } - }); - } - - // Process playground code blocks - Array.from(document.querySelectorAll(".playground")).forEach(function (pre_block) { - // Add play button - var buttons = pre_block.querySelector(".buttons"); - if (!buttons) { - buttons = document.createElement('div'); - buttons.className = 'buttons'; - pre_block.insertBefore(buttons, pre_block.firstChild); - } - - var runCodeButton = document.createElement('button'); - runCodeButton.className = 'fa fa-play play-button'; - runCodeButton.hidden = true; - runCodeButton.title = 'Run this code'; - runCodeButton.setAttribute('aria-label', runCodeButton.title); - - buttons.insertBefore(runCodeButton, buttons.firstChild); - runCodeButton.addEventListener('click', function (e) { - run_rust_code(pre_block); - }); - - if (window.playground_copyable) { - var copyCodeClipboardButton = document.createElement('button'); - copyCodeClipboardButton.className = 'fa fa-copy clip-button'; - copyCodeClipboardButton.innerHTML = ''; - copyCodeClipboardButton.title = 'Copy to clipboard'; - copyCodeClipboardButton.setAttribute('aria-label', copyCodeClipboardButton.title); - - buttons.insertBefore(copyCodeClipboardButton, buttons.firstChild); - } - - let code_block = pre_block.querySelector("code"); - if (window.ace && code_block.classList.contains("editable")) { - var undoChangesButton = document.createElement('button'); - undoChangesButton.className = 'fa fa-history reset-button'; - undoChangesButton.title = 'Undo changes'; - undoChangesButton.setAttribute('aria-label', undoChangesButton.title); - - buttons.insertBefore(undoChangesButton, buttons.firstChild); - - undoChangesButton.addEventListener('click', function () { - let editor = window.ace.edit(code_block); - editor.setValue(editor.originalCode); - editor.clearSelection(); - }); - } - }); -})(); - -(function themes() { - var html = document.querySelector('html'); - var themeToggleButton = document.getElementById('theme-toggle'); - var themePopup = document.getElementById('theme-list'); - var themeColorMetaTag = document.querySelector('meta[name="theme-color"]'); - var stylesheets = { - ayuHighlight: document.querySelector("[href$='ayu-highlight.css']"), - tomorrowNight: document.querySelector("[href$='tomorrow-night.css']"), - highlight: document.querySelector("[href$='highlight.css']"), - }; - - function showThemes() { - themePopup.style.display = 'block'; - themeToggleButton.setAttribute('aria-expanded', true); - themePopup.querySelector("button#" + get_theme()).focus(); - } - - function updateThemeSelected() { - themePopup.querySelectorAll('.theme-selected').forEach(function (el) { - el.classList.remove('theme-selected'); - }); - themePopup.querySelector("button#" + get_theme()).classList.add('theme-selected'); - } - - function hideThemes() { - themePopup.style.display = 'none'; - themeToggleButton.setAttribute('aria-expanded', false); - themeToggleButton.focus(); - } - - function get_theme() { - var theme; - try { theme = localStorage.getItem('mdbook-theme'); } catch (e) { } - if (theme === null || theme === undefined) { - return default_theme; - } else { - return theme; - } - } - - function set_theme(theme, store = true) { - let ace_theme; - - if (theme == 'coal' || theme == 'navy') { - stylesheets.ayuHighlight.disabled = true; - stylesheets.tomorrowNight.disabled = false; - stylesheets.highlight.disabled = true; - - ace_theme = "ace/theme/tomorrow_night"; - } else if (theme == 'ayu') { - stylesheets.ayuHighlight.disabled = false; - stylesheets.tomorrowNight.disabled = true; - stylesheets.highlight.disabled = true; - ace_theme = "ace/theme/tomorrow_night"; - } else { - stylesheets.ayuHighlight.disabled = true; - stylesheets.tomorrowNight.disabled = true; - stylesheets.highlight.disabled = false; - ace_theme = "ace/theme/dawn"; - } - - setTimeout(function () { - themeColorMetaTag.content = getComputedStyle(document.documentElement).backgroundColor; - }, 1); - - if (window.ace && window.editors) { - window.editors.forEach(function (editor) { - editor.setTheme(ace_theme); - }); - } - - var previousTheme = get_theme(); - - if (store) { - try { localStorage.setItem('mdbook-theme', theme); } catch (e) { } - } - - html.classList.remove(previousTheme); - html.classList.add(theme); - updateThemeSelected(); - } - - // Set theme - var theme = get_theme(); - - set_theme(theme, false); - - themeToggleButton.addEventListener('click', function () { - if (themePopup.style.display === 'block') { - hideThemes(); - } else { - showThemes(); - } - }); - - themePopup.addEventListener('click', function (e) { - var theme; - if (e.target.className === "theme") { - theme = e.target.id; - } else if (e.target.parentElement.className === "theme") { - theme = e.target.parentElement.id; - } else { - return; - } - set_theme(theme); - }); - - themePopup.addEventListener('focusout', function(e) { - // e.relatedTarget is null in Safari and Firefox on macOS (see workaround below) - if (!!e.relatedTarget && !themeToggleButton.contains(e.relatedTarget) && !themePopup.contains(e.relatedTarget)) { - hideThemes(); - } - }); - - // Should not be needed, but it works around an issue on macOS & iOS: https://github.com/rust-lang/mdBook/issues/628 - document.addEventListener('click', function(e) { - if (themePopup.style.display === 'block' && !themeToggleButton.contains(e.target) && !themePopup.contains(e.target)) { - hideThemes(); - } - }); - - document.addEventListener('keydown', function (e) { - if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey) { return; } - if (!themePopup.contains(e.target)) { return; } - - switch (e.key) { - case 'Escape': - e.preventDefault(); - hideThemes(); - break; - case 'ArrowUp': - e.preventDefault(); - var li = document.activeElement.parentElement; - if (li && li.previousElementSibling) { - li.previousElementSibling.querySelector('button').focus(); - } - break; - case 'ArrowDown': - e.preventDefault(); - var li = document.activeElement.parentElement; - if (li && li.nextElementSibling) { - li.nextElementSibling.querySelector('button').focus(); - } - break; - case 'Home': - e.preventDefault(); - themePopup.querySelector('li:first-child button').focus(); - break; - case 'End': - e.preventDefault(); - themePopup.querySelector('li:last-child button').focus(); - break; - } - }); -})(); - -(function sidebar() { - var body = document.querySelector("body"); - var sidebar = document.getElementById("sidebar"); - var sidebarLinks = document.querySelectorAll('#sidebar a'); - var sidebarToggleButton = document.getElementById("sidebar-toggle"); - var sidebarResizeHandle = document.getElementById("sidebar-resize-handle"); - var firstContact = null; - - function showSidebar() { - body.classList.remove('sidebar-hidden') - body.classList.add('sidebar-visible'); - Array.from(sidebarLinks).forEach(function (link) { - link.setAttribute('tabIndex', 0); - }); - sidebarToggleButton.setAttribute('aria-expanded', true); - sidebar.setAttribute('aria-hidden', false); - try { localStorage.setItem('mdbook-sidebar', 'visible'); } catch (e) { } - } - - - var sidebarAnchorToggles = document.querySelectorAll('#sidebar a.toggle'); - - function toggleSection(ev) { - ev.currentTarget.parentElement.classList.toggle('expanded'); - } - - Array.from(sidebarAnchorToggles).forEach(function (el) { - el.addEventListener('click', toggleSection); - }); - - function hideSidebar() { - body.classList.remove('sidebar-visible') - body.classList.add('sidebar-hidden'); - Array.from(sidebarLinks).forEach(function (link) { - link.setAttribute('tabIndex', -1); - }); - sidebarToggleButton.setAttribute('aria-expanded', false); - sidebar.setAttribute('aria-hidden', true); - try { localStorage.setItem('mdbook-sidebar', 'hidden'); } catch (e) { } - } - - // Toggle sidebar - sidebarToggleButton.addEventListener('click', function sidebarToggle() { - if (body.classList.contains("sidebar-hidden")) { - var current_width = parseInt( - document.documentElement.style.getPropertyValue('--sidebar-width'), 10); - if (current_width < 150) { - document.documentElement.style.setProperty('--sidebar-width', '150px'); - } - showSidebar(); - } else if (body.classList.contains("sidebar-visible")) { - hideSidebar(); - } else { - if (getComputedStyle(sidebar)['transform'] === 'none') { - hideSidebar(); - } else { - showSidebar(); - } - } - }); - - sidebarResizeHandle.addEventListener('mousedown', initResize, false); - - function initResize(e) { - window.addEventListener('mousemove', resize, false); - window.addEventListener('mouseup', stopResize, false); - body.classList.add('sidebar-resizing'); - } - function resize(e) { - var pos = (e.clientX - sidebar.offsetLeft); - if (pos < 20) { - hideSidebar(); - } else { - if (body.classList.contains("sidebar-hidden")) { - showSidebar(); - } - pos = Math.min(pos, window.innerWidth - 100); - document.documentElement.style.setProperty('--sidebar-width', pos + 'px'); - } - } - //on mouseup remove windows functions mousemove & mouseup - function stopResize(e) { - body.classList.remove('sidebar-resizing'); - window.removeEventListener('mousemove', resize, false); - window.removeEventListener('mouseup', stopResize, false); - } - - document.addEventListener('touchstart', function (e) { - firstContact = { - x: e.touches[0].clientX, - time: Date.now() - }; - }, { passive: true }); - - document.addEventListener('touchmove', function (e) { - if (!firstContact) - return; - - var curX = e.touches[0].clientX; - var xDiff = curX - firstContact.x, - tDiff = Date.now() - firstContact.time; - - if (tDiff < 250 && Math.abs(xDiff) >= 150) { - if (xDiff >= 0 && firstContact.x < Math.min(document.body.clientWidth * 0.25, 300)) - showSidebar(); - else if (xDiff < 0 && curX < 300) - hideSidebar(); - - firstContact = null; - } - }, { passive: true }); -})(); - -(function chapterNavigation() { - document.addEventListener('keydown', function (e) { - if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey) { return; } - if (window.search && window.search.hasFocus()) { return; } - var html = document.querySelector('html'); - - function next() { - var nextButton = document.querySelector('.nav-chapters.next'); - if (nextButton) { - window.location.href = nextButton.href; - } - } - function prev() { - var previousButton = document.querySelector('.nav-chapters.previous'); - if (previousButton) { - window.location.href = previousButton.href; - } - } - switch (e.key) { - case 'ArrowRight': - e.preventDefault(); - if (html.dir == 'rtl') { - prev(); - } else { - next(); - } - break; - case 'ArrowLeft': - e.preventDefault(); - if (html.dir == 'rtl') { - next(); - } else { - prev(); - } - break; - } - }); -})(); - -(function clipboard() { - var clipButtons = document.querySelectorAll('.clip-button'); - - function hideTooltip(elem) { - elem.firstChild.innerText = ""; - elem.className = 'fa fa-copy clip-button'; - } - - function showTooltip(elem, msg) { - elem.firstChild.innerText = msg; - elem.className = 'fa fa-copy tooltipped'; - } - - var clipboardSnippets = new ClipboardJS('.clip-button', { - text: function (trigger) { - hideTooltip(trigger); - let playground = trigger.closest("pre"); - return playground_text(playground, false); - } - }); - - Array.from(clipButtons).forEach(function (clipButton) { - clipButton.addEventListener('mouseout', function (e) { - hideTooltip(e.currentTarget); - }); - }); - - clipboardSnippets.on('success', function (e) { - e.clearSelection(); - showTooltip(e.trigger, "Copied!"); - }); - - clipboardSnippets.on('error', function (e) { - showTooltip(e.trigger, "Clipboard error!"); - }); -})(); - -(function scrollToTop () { - var menuTitle = document.querySelector('.menu-title'); - - menuTitle.addEventListener('click', function () { - document.scrollingElement.scrollTo({ top: 0, behavior: 'smooth' }); - }); -})(); - -(function controllMenu() { - var menu = document.getElementById('menu-bar'); - - (function controllPosition() { - var scrollTop = document.scrollingElement.scrollTop; - var prevScrollTop = scrollTop; - var minMenuY = -menu.clientHeight - 50; - // When the script loads, the page can be at any scroll (e.g. if you reforesh it). - menu.style.top = scrollTop + 'px'; - // Same as parseInt(menu.style.top.slice(0, -2), but faster - var topCache = menu.style.top.slice(0, -2); - menu.classList.remove('sticky'); - var stickyCache = false; // Same as menu.classList.contains('sticky'), but faster - document.addEventListener('scroll', function () { - scrollTop = Math.max(document.scrollingElement.scrollTop, 0); - // `null` means that it doesn't need to be updated - var nextSticky = null; - var nextTop = null; - var scrollDown = scrollTop > prevScrollTop; - var menuPosAbsoluteY = topCache - scrollTop; - if (scrollDown) { - nextSticky = false; - if (menuPosAbsoluteY > 0) { - nextTop = prevScrollTop; - } - } else { - if (menuPosAbsoluteY > 0) { - nextSticky = true; - } else if (menuPosAbsoluteY < minMenuY) { - nextTop = prevScrollTop + minMenuY; - } - } - if (nextSticky === true && stickyCache === false) { - menu.classList.add('sticky'); - stickyCache = true; - } else if (nextSticky === false && stickyCache === true) { - menu.classList.remove('sticky'); - stickyCache = false; - } - if (nextTop !== null) { - menu.style.top = nextTop + 'px'; - topCache = nextTop; - } - prevScrollTop = scrollTop; - }, { passive: true }); - })(); - (function controllBorder() { - function updateBorder() { - if (menu.offsetTop === 0) { - menu.classList.remove('bordered'); - } else { - menu.classList.add('bordered'); - } - } - updateBorder(); - document.addEventListener('scroll', updateBorder, { passive: true }); - })(); -})(); diff --git a/clipboard.min.js b/clipboard.min.js deleted file mode 100644 index 02c549e..0000000 --- a/clipboard.min.js +++ /dev/null @@ -1,7 +0,0 @@ -/*! - * clipboard.js v2.0.4 - * https://zenorocha.github.io/clipboard.js - * - * Licensed MIT © Zeno Rocha - */ -!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return function(n){var o={};function r(t){if(o[t])return o[t].exports;var e=o[t]={i:t,l:!1,exports:{}};return n[t].call(e.exports,e,e.exports,r),e.l=!0,e.exports}return r.m=n,r.c=o,r.d=function(t,e,n){r.o(t,e)||Object.defineProperty(t,e,{enumerable:!0,get:n})},r.r=function(t){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(t,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(t,"__esModule",{value:!0})},r.t=function(e,t){if(1&t&&(e=r(e)),8&t)return e;if(4&t&&"object"==typeof e&&e&&e.__esModule)return e;var n=Object.create(null);if(r.r(n),Object.defineProperty(n,"default",{enumerable:!0,value:e}),2&t&&"string"!=typeof e)for(var o in e)r.d(n,o,function(t){return e[t]}.bind(null,o));return n},r.n=function(t){var e=t&&t.__esModule?function(){return t.default}:function(){return t};return r.d(e,"a",e),e},r.o=function(t,e){return Object.prototype.hasOwnProperty.call(t,e)},r.p="",r(r.s=0)}([function(t,e,n){"use strict";var r="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t},i=function(){function o(t,e){for(var n=0;nThis is the documentation for Urban Analyst (UA). -Urban Analyst analyses the structure and function of cities across the world. -Each city can be viewed as an interactive map -displaying several different properties or variables. These include -socio-demographic conditions and the structure and function of transport -systems. The platform also analyses relationships between individual variables, -such as between socio-demographic conditions and frequency of transport -services, or between distances to nearest schools and access to natural spaces.
-UA also provides statistical comparisons -between all cities, enabling comparisons across all UA cities of single -variables, as well as relationships between any pair of variables, such as -transport and socio-demographic disadvantage.
-Finally, UA enables cities to "learn" from one another, by visualising how the -properties of any chosen city can best be transformed to become more like the -properties of any other chosen city. Paris, for example, has better bicycle -infrastructure than Berlin, and the UA transformation algorithm can calculate -how Berlin can most easily transform its bicycle infrastructure to become more -like Paris. Values for every area in Berlin are then displayed as the -proportional increase in bicycle infrastructure which would be necessary for -the whole city to have infrastructure equivalent to Paris.
-Urban Analyst present a variety of variables for each city -analysed, as well as relationships between these variables. Values for each -variable are derived at every street intersection in each city. These values -are then aggregated into the polygons shown in the "Map" -page and -"Transform" pages, and across entire -cities for the values shown in the -"Compare" page. Aggregations are always -weighted by local population densities, so that all UA values represent values -per person as experienced in each city. Details are provided in the Data -Sources and Software and Algorithms chapters.
-The values presented in Urban Analyst are derived from estimates of travel -times from every point in each city to every other point using any combination -of possible modes of transport. The following table summarises numbers of -street intersections, public transport ("PT") stops, and calculations for a -selection of Urban Analyst cities.
-| city | intersections (thousands) | PT stops | PT calcs (millions) | routing calcs (billions) |
|---|---|---|---|---|
| Berlin | 360 | 9,302 | 173 | 150 |
| Hamburg | 192 | 4,585 | 42 | 56 |
| London | 506 | 20,072 | 806 | 160 |
| Paris | 313 | 29,393 | 1,728 | 124 |
This is the documentation of the Urban Analyst platform.
+Contents
+ +This is the documentation for Urban Analyst (UA). -Urban Analyst analyses the structure and function of cities across the world. -Each city can be viewed as an interactive map -displaying several different properties or variables. These include -socio-demographic conditions and the structure and function of transport -systems. The platform also analyses relationships between individual variables, -such as between socio-demographic conditions and frequency of transport -services, or between distances to nearest schools and access to natural spaces.
-UA also provides statistical comparisons -between all cities, enabling comparisons across all UA cities of single -variables, as well as relationships between any pair of variables, such as -transport and socio-demographic disadvantage.
-Finally, UA enables cities to "learn" from one another, by visualising how the -properties of any chosen city can best be transformed to become more like the -properties of any other chosen city. Paris, for example, has better bicycle -infrastructure than Berlin, and the UA transformation algorithm can calculate -how Berlin can most easily transform its bicycle infrastructure to become more -like Paris. Values for every area in Berlin are then displayed as the -proportional increase in bicycle infrastructure which would be necessary for -the whole city to have infrastructure equivalent to Paris.
-Urban Analyst present a variety of variables for each city -analysed, as well as relationships between these variables. Values for each -variable are derived at every street intersection in each city. These values -are then aggregated into the polygons shown in the "Map" -page and -"Transform" pages, and across entire -cities for the values shown in the -"Compare" page. Aggregations are always -weighted by local population densities, so that all UA values represent values -per person as experienced in each city. Details are provided in the Data -Sources and Software and Algorithms chapters.
-The values presented in Urban Analyst are derived from estimates of travel -times from every point in each city to every other point using any combination -of possible modes of transport. The following table summarises numbers of -street intersections, public transport ("PT") stops, and calculations for a -selection of Urban Analyst cities.
-| city | intersections (thousands) | PT stops | PT calcs (millions) | routing calcs (billions) |
|---|---|---|---|---|
| Berlin | 360 | 9,302 | 173 | 150 |
| Hamburg | 192 | 4,585 | 42 | 56 |
| London | 506 | 20,072 | 806 | 160 |
| Paris | 313 | 29,393 | 1,728 | 124 |
One way to appreciate the scale of these calculations is through comparison -with commercial alternatives. One service, traveltime.com, charges a flat -subscription fee of €540 per month for a maximum of 60 requests per minute. -That rate would permit 31.5 million queries per year. The city of Hamburg, for -example, would then take almost 2,000 years to calculate, and would cost -€12 million. Google also offers a commercial routing service, limited to a -maximum of 500,000 queries per month, for a total price of US$2,000. At that -rate, the analyses for Hamburg would cost US$224 million.
-The results presented in Urban Analyst are simply not possible using commercial -tools, or indeed any other open source tools. These analyses truly are uniquely -powerful, and provide a depth of insight into how people move through cities -not available in any other way.
-Not directly, but feel free to open a GitHub -issue to start a discussion -about requesting full data sources.
-This documentation includes the following five chapters:
-Contributions to, or questions regarding, this documentation, are welcome at -this GitHub repository.
-This chapter provides an overview of the four main pages of the Urban Analyst -platform:
-The best place to start is the Summarise -page. The summary for any chosen city -will indicate which properties of the other pages are most important. Each of -the latter three pages also includes a pop-up "guided tour" explaining the key -features. These tours will automatically start the first time a page is opened, -or can be manually opened by clicking on the "Help" button on any of the main -pages.
-The Summarise page provides an overview -of the general statistical properties of any chosen UA city. Statistics for -each chosen city are compared with those for all other cities, and textual -summaries generated for all statistics which are significantly different. -Summaries are provided not just for individual statistics, but for the -strengths of relationship between all pairs of statistics.
-The values described in this initial part of the Summarise -page indicate which statistics might be -particularly worth examining in both the -Compare and the Map - pages.
-The Summarise page also includes a -section describing the best "Target city" for each chosen city. As explained -there, the best target city is the city which is best in all the ways that the -chosen city is worse than average. This target city, and corresponding -variables described there, indicate which cities and variables might be -particularly worth examining in the Transform -page.
-The Compare page enables comparisons -between all UA cities, both in terms of single variables and relationships -between any selected pair of variables. A pull-down panel enables each variable -or "layer" to be selected. The page then displays a graphical representation of -values of the chosen layer for all cities. As in all UA pages, lower values are -generally better than higher values. The control panel includes an "Explain -Layer" button which opens a text panel explaining details of the chosen -variable.
-The control panel of the compare page -includes an option to select "paired" variables. The resultant graphs then -display the strength of relationship between any chosen pair of variables. -For example, choosing social index and the nature index will display the -strength of relationship between access to natural spaces and social -disadvantage. Both of these variables are measured such that low values are -better than high values. A positive relationship between the two would then -mean that lower social disadvantage is coupled with better access to natural -spaces, while high social disadvantage is coupled with worse access to natural -spaces. Conversely, a negative relationship would indicate that higher social -disadvantage was coupled with better access to natural resources. Or, in the -words brought up by clicking the "Explain Layer" button, "Low values indicate -that good access to natural spaces is coupled with disadvantageous social -conditions."
-The Map page shows interactive maps for each -city, with values for all UA variables displayed in small polygons. These -polygons are defined by city-specific assessments of spatial disadvantage. -Berlin, for example, regularly measures a compound index of social disadvantage -aggregated into XX polygons. The map for Berlin uses these polygons provided by -the city to aggregate all measured variables. The variables are described in a -subsequent chapter.
-Details of the polygons for each city can be seen by selecting the "Social" -layer in the Map page and then clicking on the "Explain Layer" button.
-As in all UA measurements, lower values of all variables are generally better -than higher values. Colour scales on all maps thus generally display lower -values in brighter, yellow colours, while higher values are displayed in -darker, blue or violet colours. The control panel includes an "Explain Layer" -button which opens a text panel explaining details of the chosen variable.
-The Transform page enables the -properties of any chosen city to be transformed to reflect equivalent -properties of some chosen "target" city. This page is best explained by an -example. Looking at the Compare page for -the "bike index" shows that Berlin has relatively poor bicycle infrastructure, -while Paris is a very good city for cyclists. The -Transform page can be used to visualise -how Berlin could best transform its current bicycle infrastructure to have an -overall distribution across the whole city equivalent to Paris. Conversely, -Paris has poorer access to natural spaces than Berlin, and the page could also -be used to examine how Paris could best transform its access to natural spaces -so that it functioned more like Berlin.
-Urban Analyst values displayed in the Map page -are aggregated from generally hundreds of thousands of individual calculations -at every street junction in each city. For the chosen variable, subsets of -these individual data points are sampled from each city, and the statistical -distribution for the chosen city is then transformed by changing each point by -the smallest amount possible so that they reflect the distribution in the -target city. These values are then aggregated into the polygons defined for the -city, to produce a visual representation of the least-cost transformation that -would be necessary for the city to have the same distribution as that of the -target city. The transformation algorithm is described in detail in the final -Software and Algorithms chapter.
-The Transform page includes an -additional button labelled Extra Layers. The transformations described above -described transforming single layers or variables. The Extra Layers panel -enables transformations not just of single chosen variables, but also of their -relationships with other variables. Examining the Compare -page, for example, shows that not only does -Paris provide poorer access to natural spaces than Berlin, but also that Berlin -has a better relationship between access to natural spaces and social -disadvantage. (This can be seen by clicking on the "Paired" layer option and -selecting those two layers.) The Extra Layers panel can be used in this case -to examine not just how Paris might best transform its access to nature to look -more like Berlin, but also how it might also improve its relationship between -access to nature and social disadvantage.
-By default, values of Extra Layers are automatically selected as those which -have better relationships in the chosen target city. These default values will -thus change for each choice of target city and focal layer. It may be necessary -to click on the "Reset" button in the Extra Layers panel to update this -default selection after changing any of these options.
-Finally, the Transform page also has an -Output Layer option at the bottom of the control panel. This enables results -of the transformation algorithm to be displayed in one of four ways:
-This chapter demonstrates most of the capabilities of the Urban Analyst -platform through exploring comparisons between the -cities of Paris, France, and Berlin, Germany. It is important to remember -throughout that lower values in all UA statistics are always better. Values -are also weighted by local population densities. This is important because, for -example, public transport systems should be constructed to offer the fastest -services to the areas where most people live. Not implementing this weighting -would, in contrast, leave measures in some form of times per unit area, so that -for example travel times from unpopulated parts of a city would be weighted -equally to times from densely populated parts. Weighting travel times, and all -other UA variables, by population density converts them to values as -experienced on average by each person in a city.
-The comparisons in this chapter between Paris and Berlin are mostly drawn from -the "Stats" page, which provides overviews of entire cities, and comparisons -with all other UA cities. The "Maps" page can then be used to examine the -actual spatial distributions of particular variables or relationships within -any given city.
-This comparison starts by stepping through each variable to describe kinds of -information able to be extracted, before examining pairwise relationships -between these variables, and concluding with a general summary. The Urban -Analyst platform currently measures 11 variables, -along with strengths of relationship between all paired combinations of these. -This amounts to 11 * (11 - 1) / 2 = 55 pairwise combinations. Strengths of -relationship are standardised, so are comparable throughout between all pairs -of variables, and between different cities. Two additional variables are -included for cities from the USA, enabling even more pairwise comparisons for -these cities.
-The following table summarises the values of the individual variables for each -city (each measured on its own distinct scale).
-| Variable | Berlin | Paris |
|---|---|---|
| Times (abs; min) | 40.9 | 39.5 |
| Times (rel) | 1.09 | 1.03 |
| Num. Transfers | 0.9 | 1.5 |
| Intervals (min) | 6.9 | 4.9 |
| Transport | 33.2 | 25.5 |
| Pop. Dens. | 3 | 3 |
| School Dist (m) | 338 | 186 |
| Bike Index | 0.81 | 0.76 |
| Nature Index | 0.88 | 0.93 |
| Parking | 1.32 | 1.55 |
Social disadvantage is also quantified for all cities. However, each city -calculates this in different ways, and values are not comparable between -cities. Values are nevertheless standardised for the pairwise comparisons, and -strengths of relationship described there remain valid.
-The "Transport Absolute" variable measures the absolute time (in minutes) -required to travel a distance of 10km from each point in a city, using any -combination of travel modes except private automobile, including walking, -bicycling, and any available public transport options. Travelling 10km in -Paris takes under 40 minutes on average, while equivalent journeys in -Berlin require almost 1.5 minutes more.
-The "Transport Relative" values divide the absolute travel times described above -by times for equivalent journeys with private automobile. Ratios of one imply -automobile times equal to multi-modal times; ratios of less than one imply that -multi-modal transport is faster than private automobile. Paris and Berlin both -have comparably low values for this ratio, implying relatively fast multi-modal -transport, with Paris notably faster than Berlin. This is likely influenced by -Paris's recent introduction of a uniform maximum speed limits of 30km/hour -through the city, whereas Berlin features a number of "autobahns" with much -higher speed limits.
-Note that travel times with private automobiles include estimates of times -required to park a vehicle and ultimately walk to any desired destination. -Vehicular times calculated here are thus notably longer than with most -commercial routing engines, which give vehicular travel times only, and ignore -the critical need to park a vehicle and walk to a destination.
-All individual variables also enable comparison in terms of "Variation", rather -than "Average" values. Comparing these reveals that Berlin generally has -markedly lower variation than Paris. A comparison of these statistics on the -"Maps" page reveals that this is largely because Paris is simply much larger -than Berlin, and the ranges of both absolute and relative transport times are -correspondingly greater. The fact that relative transport in Paris is still -better on average than in Berlin is thus even more impressive considering this -stark difference in scale.
-Travelling in Paris requires notably greater numbers of transfers to travel -equivalent distances than Berlin. The values in the "Number of Transfers" layer -are for journeys of 10km total distance (including walking or cycling distances -at either end). Travelling in Paris requires > 50% more transfers than journeys -in Berlin.
-The fourth transport variable, "Interval", measures the time to wait (in -minutes) until the next equivalent service. Intervals in Paris are slightly -under 5 minutes, whereas values in Berlin are just under 7 minutes.
-Finally, the "Compound Transport" variable simply multiplies absolute travel -times by intervals between services. Low values of this statistic reflect fast -and frequent transport. This statistic also indicates considerably superior -service in Paris compared with Berlin.
-This section considers relationships between each individual variable and all -other variables. All strengths of relationship shown in the "Stats" page are -assessed in standardised ways, so they may be directly compared between cities. -Moreover, the scales shown in the "Stats" page may also be directly compared. -Values of one or greater indicate very strong relationships, whereas values -less than 0.1 or so indicate weak relationships, and values less than around -0.01 should generally be interpret to indicate no relationship. Pairs of -variables with very weak or negligible strengths of relationship are generally -not interpreted in the following sub-sections.
-The following table summarises the values of the strongest pairwise -relationships for each city:
-| Variable1 | Variable2 | Berlin | Paris |
|---|---|---|---|
| Times (abs) | Bike | 1.0 | 2.0 |
| Times (abs) | Natural | -1.0 | -0.5 |
| Times (abs) | Parking | 0 | -0.15 |
| Times (abs) | Pop. Dens. | -0.15 | -0.11 |
| Times (abs) | School dist | 0.12 | 0.06 |
| Times (abs) | Transfers | -0.31 | -0.48 |
| Times (rel) | Bike | 0 | 0.16 |
| Transport | Natural | -0.22 | 2.46 |
| Transport | Parking | 1.7 | 1.9 |
| School dist | Bike | 0 | 0.4 |
| School dist | Natural | -0.12 | -0.06 |
| Social | Bike | 0.52 | -0.38 |
| Social | Natural | -0.1 | 2.0 |
| Social | Parking | 0.04 | -2.18 |
| Social | School dist | -0.05 | -0.25 |
This sub-section only considers transport times, both in absolute and relative -sense. The other transport variables, of intervals and numbers of transfers, -generally follow similar patterns and are not explicitly considered here. -Relative transport times are only very weakly related to most other variables. -In contrast, absolute transport times are strongly related to most other -variables.
-Relative transport times are negligibly associated with population densities, -while absolute times are particularly strongly and negatively correlated. These -negative relationships indicate that faster transport is associated with higher -population densities, more so in Berlin than Paris.
-Slightly weaker relationships are manifest between absolute travel times and -distances to nearest schools. Relationships in both Berlin and Paris are -positive, indicating that fast public transport is positively associated with -shorter distances to schools, with the relationship about twice as strong in -Berlin as in Paris.
-Travel times are very strongly, and positively, correlated with bicycle -infrastructure, indicating faster travel times in regions with better bicycle -infrastructure. This relationship is much stronger in Paris than in Berlin, for -reasons easy to discern by looking at the maps of Berlin for these two -variables. Bicycle infrastructure there is much better in the periphery of the -city, whereas transport times exhibit more of a systematic discrepancy between -the east (fast) and west (slow) portions of the city. In Paris, in contrast, -faster transport times and better bicycle infrastructure are both concentrated -more towards the centre of the city.
-Relationships between transport times and the index of accessibility to natural -spaces are also very strong, and negative. This means that faster transport -times are associated with lower accessibility to natural spaces, as might be -generally expected of most high-density cities. The relationship is stronger in -Berlin than Paris, indicating that faster transport times are most strongly -associated with poorer access to natural spaces there than in Paris.
-Finally, absolute transport times are slightly negatively associated with -numbers of automobile parking spaces in Paris, whereas there is no relationship -in Berlin. This negative relationship indicates that regions with faster public -transport also tend to have more automobile parking spaces, reflecting planning -decisions that associate use of public transport with the driving of private -automobiles. No such relationship appears to exist in Berlin.
-Shorter school distances are positively associated with the bicycle index in -Paris, indicating a positive association between good bicycle infrastructure -and short distances to schools. Berlin manifests no such relationship, likely -for reasons described above, that bicycle infrastructure in Berlin is generally -more peripheral than in Paris.
-Although much weaker, relationships between schools distances and the index of -accessibility to natural spaces are negative, indicating that locations closer -to schools are further from nature, and more so in Berlin than in Paris.
-Finally, the social variables are more strongly related to all other -non-transport variables in Paris than in Berlin, except for with the index of -bicycle infrastructure. This variable is more strongly, and positively, -correlated with the social indicator in Berlin than in Paris, where the -relationship is negative. The positive relationship in Berlin indicates that -the provision of bicycle infrastructure is positively associated with social -advantage, an effect again readily seen in examining the map of Berlin. In -contrast, Paris is more effective in providing bicycle infrastructure in areas -of relative social disadvantage.
-Paris also seems to be more effective in educational provision in areas of -social disadvantage, with the strong negative correlation indicating that -socially disadvantaged Parisians generally have to travel shorter distances to -schools. Although this relationship is also negative in Berlin, it is much -weaker.
-In contrast, Paris's very strong and positive relationship between social -advantage and access to natural spaces indicates the relatively far greater -difficulty experienced by less socially advantaged Parisians in accessing -natural spaces compared with equivalent inhabitants of Berlin.
-Finally, Paris manifests a very strong and negative association between social -advantage and numbers of automobile parking spaces, indicating that low social -disadvantage is strongly associated with high numbers of automobile parking -spaces, or conversely that socially disadvantaged parts of the city offer -relatively few automobile parking spaces. The relationship in Berlin is, in -contrast, slightly positive.
-Paris's transport system is considerably faster and more frequent. -Nevertheless, it also involves greater numbers of transfers, suggesting that -any attempt to improve the system in Berlin should take care to avoid -inadvertently increasing numbers of transfers.
-Berlin's average relative speed is also notably higher than Paris's, and at -1.09 likely too high to effectively discourage large numbers of people from -opting to travel via private automobile. Examination of the map of relative -travel times clearly reveals the effect of the connected ring out autobahns -encircling the city. While reducing speeds on these carriageways may not be -feasible, a uniform 30km/hour limit as introduced in Paris may nevertheless -significantly reduce this ratio, and further incentivise many more people to -opt for public transport rather than private automobile.
-Although Paris is a far larger city, its average population density is -nevertheless very similar to Berlin's. It is then even more striking that Paris -offers considerably shorter average distances to schools than Berlin. School -distances in Berlin are also only weakly correlated with social conditions, -whereas average distances to schools in Paris are shorter in less socially -advantaged areas. Both of these factors indicate a need in Berlin for more -provision of local schooling in general, and particularly in socially -disadvantaged regions, if it is to match the educational opportunities provided -in Paris.
-Paris's bicycle infrastructure is considerably better than Berlin's, and -perhaps even more importantly, becomes better towards the inner city regions. -In contrast, Berlin really only offers good bicycle infrastructure in the -relatively peripheral, and more affluent, outer regions. Berlin really needs to -proactively focus on improving bicycle infrastructure in the inner city -regions.
-Berlin is fortunately greatly enhanced by an abundance of natural space, -including access to the city's rivers and canals, and access to these natural -spaces is only weakly related to social advantage. This provides robust -evidence for Berlin to appreciate its natural spaces, and to ensure that they -remain accessible for everybody.
-Paris's transport system is notably better than Berlin's in almost all ways -except for the number of transfers necessary to travel equivalent distances. -This difference is especially notable given that Paris is much larger than -Berlin. Improvements to Paris's public transport system should focus on -decreasing numbers of transfers.
-Paris's average relative speed is very close to the "magical" value of one, at -which point private automobiles are no faster than multi-modal transport -including walking and cycling.
-Paris has done a great job of providing bicycle infrastructure in the inner -city regions, and notably of proactively enhancing or creating bicycle -infrastructure in regions of social disadvantage.
-Contrasts with Berlin nevertheless emphasise a couple of aspects which Paris -could focus on improving. The most notable of these is the index of -accessibility to natural spaces, and the relationship of this to other -variables. Paris simply has far less natural space than Berlin, and much poorer -general accessibility. Moreover, access to natural spaces is positively -associated with social advantage, so that it is relatively difficult for -socially disadvantaged Parisians to access natural spaces.
-All UA variables are measured such that lower or negative values are good, -whereas higher values are bad. (Exceptions are neutral variables such as -population density which are nevertheless straightforward to interpret.) For -example, unemployment or transport times are both better when values are lower. -Indices of bicycle infrastructure and access to natural spaces are also -transformed so that lower values indicate better or more of either. In these -cases, the transformations are simply one minus the respective proportions of -journeys out to a fixed distance travelled along bicycle infrastructure, or -through or alongside natural spaces. Values of 0 then reflect 100% of all -journeys spent on bicycle infrastructure or in natural spaces, while values of -1 would represent complete absence of either bicycle infrastructure or natural -spaces.
-Variables are measured for every way, path, or street intersection within each -city. Values for the maps are aggregated within polygons defined by the -Socio-demographic variables described in the following sub-section, while -values within the statistics page are aggregated across entire cities. Unless -explicitly described otherwise, values of all variables are weighted by -population density. This means that, for example, distances to nearest schools -represent average distances that each person must travel to get to school. Full -descriptions of the calculation of all variables are given in the Software -and Algorithms chapter.
-The extent and structure of each city is defined by its "socio-demographic -variable," or "social variable" for short. These are taken from open-source -datasets provided by the cities as a series of geographic areas, defined as -polygonal shapes, and some corresponding measure of socio-demographic -disadvantage. The cities themselves decide the resolution and extent of these -polygonal data. These polygons then define the extent and shape of cities -analysed in Urban Analyst, and the individual polygons into which the map data -are aggregated.
-Values of these socio-demographic variables are the only aspect that differs -between different cities. One of the simplest versions is unemployment rate, -generally measured either as a percentage (0-100), or a proportion (0-1). The -UA platform selects the most representative measure of general social -disadvantage provided by each city, and defaults to rates of unemployment only -where no more comprehensive of integrative measures are openly provided by -cities.
-Urban Analyst provides highly detailed statistics on transport systems. Many of -these are derived from estimates of times required to travel fixed distances of -10km. This value is chosen to capture the general efficiency of public -transport systems. Shorter distances do not sufficiently capture the influence -of transport modes such as express or long-distance train services, while -longer distances unfairly penalise smaller cities in which most journeys are -only of shorter distances.
-Values at this distance of 10km are obtained by following these three steps, -taking the example statistic of travel times:
-Values shown in the maps are aggregated within each polygon of a chosen city, -while values shown in the statistics page are aggregated over entire cities.
-The remainder of this section describes the five travel variables:
-Urban Analyst enables comparisons of travel times between two primary modes of -transport:
-Private Automobile. Travel times with private automobile are used as a -benchmark for measures of travel time using other modes. UA generates -realistic estimates of private automobile travel times through scaling to -empirically observed data on actual vehicular travel times. (Calibration -procedures are implemented and documented in this GitHub -repository.) Importantly, UA -includes an additional, unique aspect of automobile travel times not -quantified in any other equivalent system, through an algorithm to accurately -estimate the likely time required to park a private vehicle, and then to walk -to a desired destination. These parking times are crucial, as direct travel -times to many inner-city destinations do not provide realistic estimates of -actual journey times to locations where it may be impossible to actually park -a private automobile.
-Multi-Modal Transport. UA's "multi-modal travel times" represent fastest -possible times taken for journeys from every single point in a city to travel -10km using any combination of transport modes excluding private automobile. -The primary modes considered are walking, bicycling, and all available modes -of public transport within each city. Where it is faster to cycle 10km than -to take public transport (such as from locations with very poor public -transport connections, or on the top of long hills where downhill cycling may -actually be faster), these times will represent the single mode of cycling -only, but multi-modal times will generally reflect fastest times formed by -combining multiple modes of transport.
-Travel times measured these two ways are then combined to generate the -following two primary travel time statistics:
-Absolute travel times as the multi-modal travel times; that is, using any -mode except private automobile.
-Relative travel times as the ratios of absolute travel times compared with -equivalent travel times with private automobile. Relative travel times of -less than one indicate that multi-modal transport is faster than equivalent -transport with private automobile, while values greater than one indicate -that private automobile transport is faster.
-In addition to travel times, UA also includes the following two additional -statistics quantifying other aspects of public transport systems. Both are -measured for every point of origin with a city, with final values again derived -by following the steps described above to obtain average values of each for all -trips of 10km distance. Numbers of transfers are thus the average number -required for all journeys of 10km, while intervals are the required waiting -times for the next equivalent journey out to that distance.
-Intervals to Next Service are measured in minutes. For each point of origin -in a city, this statistic measures the waiting time necessary before -departing to each destination within a city on the service after the one -corresponding to the fastest journey. This delayed service may not be fast as -the original, or it may even be faster in some cases, as the UA algorithms -also prioritise connections with the fewest possible transfers. It can happen -that subsequent services are actually faster, yet involve additional -transfers not required in the originally identified "fastest" service.
-Numbers of Transfers measure the number of transfers necessary for a -minimal-transfer journey out to a distance of 10km. These -minimal-transfer journeys are selected to allow for journeys slightly -slower than absolute fastest journeys (generally by up to 5 minutes) if they -involve fewer transfers.
-All three of the statistics described above - travel times, intervals, and -numbers of transfers - are measured such that lower values are more desirable. -Travel times are then directly multiplied by (a logarithmically-transformed -version of) intervals between services to generate a "compound travel -statistic". Low values of this statistic only arise in locations which have -fast travel times and short intervals between services. Low values may -accordingly always be interpreted as indicating overall good transport -services. In contrast, high values may arise through various combinations of -variables, from extremely high values of one single variable, to less extreme -combinations of the two variables. It is thus generally not possible to -directly discern reasons for high values of this compound travel statistic. -Urban Analyst nevertheless provides direct insight into all individual values, -as well as all pairwise combinations of values, permitting indirect insight.
-Population density values are taken directly from the European Union Global -Human Settlement Layer data, -aggregated into polygons for maps, or across entire cities for statistics.
-Distances to nearest schools are measured in kilometres, as shortest walking -distances from each point to the nearest school. These are network distances, -and not simple straight line distances. A single value is ascribed to each -point within a city, and all points aggregated after weighting by local -population densities.
-The bicycle infrastructure index is derived from a measure of the proportion of -all possible journeys from each point out to a fixed distance of five -kilometres that travel along dedicated bicycle infrastructure. To conform with -all other UA variables, the index is one minus this proportion, so that low -values reflect high proportions of bicycle infrastructure. Values of zero would -then reflect all journeys taken along dedicated bicycle paths, while values of -one would mean a complete absence of dedicated bicycle infrastructure.
-Travel is calculated using a bicycle-specific algorithm that only extends along -ways unsuitable for bicycle travel where no alternatives exist. The weighting -scheme used adds total distances for all portions of travel along designated -cycleways that are separated from vehicular traffic. Portions of trips -extending along other types of ways are added with "half weightings" so, for -example, one kilometre along these types is equivalent to two kilometres on -dedicated bicycle ways. These "half-weight" ways include residential or -"living" streets, unpaved tracks, and bicycle lanes directly alongside -automobile lanes. A third category of ways are weighted at one-quarter, -including footpaths and general pedestrian areas which permit bicycle travel. -The precise weighting scheme can be viewed in this source code -file.
-The weighted sums of all distances along these types of ways traversed out to -five kilometres from any given point are then divided by the sum of all -distances travelled regardless of way type to give a ratio between zero and -one. This bicycle infrastructure index is then one minus this value.
-Natural space accessibility is measured in a similar way to the bicycle -infrastructure variable, except it quantifies proportions of walking distances -out to maximal distances of two kilometres that traverse natural spaces. This -provides a more realistic measure of natural space than simple aggregations of -areas, because it measures the ability of people to directly walk from every -point in a city through or alongside nearby natural spaces.
-Moreover, aggregate metrics do not generally capture the ability of people to -actually access natural spaces. A park may, for example, have restricted or -even private access. This would count as a natural space in a simply aggregate -metric, yet not in UA because access restrictions are taken into account in the -routing algorithms.
-The algorithm also measures lengths of ways walked adjacent to water - -so-called "blue space", providing a comprehensive metric of the actual ability -to access natural spaces from every point in a city. A natural space index of -zero would represent an entire city of natural space, with no built structures -at all, while a value of one would represent a complete absence of natural -spaces.
-The parking index is the ratio of numbers of nearby parking spaces to total -volumes of nearby buildings. The parking statistic is calculated for each point -by adding all nearby parking spaces with a weighting scheme that decreases -exponentially with distance, so that nearby parking spaces count more than -parking spaces that are farther away. Building volumes are also aggregated -using an identical weighting scheme. The parking index at each point is then -the ratio of the sum of distance-weighted numbers of parking spaces to the sum -of distance-weighted total building volumes.
-All publicly accessible parking spaces are counted, including on-street -parking, open parking lots, and multi-level parking garages. Building volumes -are aggregated regardless of type or purpose.
-For USA cities only, additional statistics are provided for average housing -value per room, and average rental per room, both in US dollars.
-The Urban Analyst platform aims to be applicable to as much of the world as -possible. To achieve this, data sources are chosen which are ideally have -global coverage, and which are not specific to any one city. The global sources used are:
-The following additional data are then required for each city:
-The last of these data requirements is the most restrictive, as most cities of -the world do not have or provide public transport data in GTFS format. There -are nevertheless thousands of cities which do provide GTFS feeds, as can be -seen for example in the GTFS feed aggregation platform -transit.land.
-For USA cities, data for the additional two variables of housing value and -rental price per room are obtained from US Government census data.
-The primary software used to generate the results presented on Urban Analyst are:
-osmdata for accessing and processing
-data from Open Street Map.
dodgr for general network routing queries.
gtfsrouter for public transport routine queries.
m4ra for multi-modal routing queries
uaengine for additional
-algorithms combining aspects of these other routing algorithms for tasks
-specific to Urban Analyst.
All of this software was primarily developed by the same team responsible for -Urban Analyst itself.
-(... coming soon)
- -The primary software used to generate the results presented on Urban Analyst are:
-osmdata for accessing and processing
-data from Open Street Map.
dodgr for general network routing queries.
gtfsrouter for public transport routine queries.
m4ra for multi-modal routing queries
## Software
+The primary software used to generate the results presented on Urban Analyst are:
+osmdata for accessing and processing +data from Open Street Map.
dodgr for general network routing queries.
gtfsrouter for public transport routine queries.
m4ra for multi-modal routing queries
uaengine for additional algorithms combining aspects of these other routing algorithms for tasks -specific to Urban Analyst.
-All of this software was primarily developed by the same team responsible for Urban Analyst itself.
-(... coming soon)
+(… coming soon)
+